Jan Henrik Sylvester wrote:
> Colin Percival wrote:
>> I believe that your system is now 6.3-BETA1 with a few shared libraries
>> from 6.2-RELEASE mixed in. If you can get a copy of /lib/*.so.* and
>> /usr/lib/*.so.* from a 6.3-BETA1 system and install those into place
>> (in fact, probably all you need is /lib/libc.so.6) your system should
>> be ok. Let me know if you need any help with this.

>
> I guess I can download a 6.3-BETA1 cd and copy the files over from
> there. If you have a better way, please, let me know.


That's probably the safest approach. Theoretically you could get all of
the files from FreeBSD Update's database in /var/db/freebsd-update/files,
but actually finding the right ones and installing them is likely to be
difficult and error-prone.

>> Getting the system back to 6.2-RELEASE might be more difficult, now that
>> the FreeBSD Update code thinks that it has rolled back its updates, but
>> I might be able to find a way to do that for you -- is it a disaster if
>> this system ends up stuck at 6.3-BETA1?

>
> Not to be able to go back to 6.2-RELEASE is ok. If updating to 6.3-BETA2
> (and eventually perhaps 7.0) is not possible because of the mixed
> system, it will limit my testing and I will have to reinstall at some
> point, which would not be a disaster, either.


Upgrading to future releases should be fine. Once you get the libraries
from 6.3-BETA1 installed again the system should be in exactly the same
state as if you installed 6.3-BETA1 from the cd.

> Is there any cleanup to do besides replacing the libs (such as removing
> temporary freebsd-update directories)?


You can save some disk space if you want by nuking everything in
/var/db/freebsd-update/, but keeping those files will make upgrading to
future releases with FreeBSD Update faster.

> Since your blog seems not to tell and there is no other documentation:
> Is freebsd-update -r supposed to work if not all files are from
> GENERIC/SMP? Does it skip files or overwrite them with GENERIC versions?
> (For security updates, the former might be desirable, but for updates
> between releases, only the latter would make sense to me.)


FreeBSD Update does its best to handle recompiled and/or customized kernels,
according to the following rules:
1. If /boot/GENERIC or /boot/SMP exist, assume that they contain a GENERIC
or SMP kernel respectively (and update it accordingly).
2. If the running kernel identifies itself as "GENERIC" or "SMP" (or as
"SMP-GENERIC", which FreeBSD Update considers to be a synonym for "SMP"),
assume it was built from the standard GENERIC or SMP kernel configuration.
3. If the running kernel identifies itself as something else, don't touch
it.

When upgrading, a couple more rules are applied:
1. If a custom kernel configuration is running, a warning message is printed
telling the user to update the kernel manually before installing upgrades.
2. If the kernel configuration is one which was distributed in the current
release but does not exist in the new release (e.g., FreeBSD 6.2 has "GENERIC"
and "SMP" kernel configurations, but 7.0 only has a "GENERIC" configuration),
upgrade it to a "GENERIC" kernel.

In short, as long as you don't build a custom kernel but call it "GENERIC" or
"SMP", FreeBSD Update should automatically DTRT.

Colin Percival
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis...freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"