Recovering base system files after failed installworld - RESOLVED

Alejandro Imass ait at
Tue Mar 16 22:34:48 UTC 2010

(sorry, I had mailed this directly by mistake intead of the list)
On Mon, Mar 15, 2010 at 3:29 PM, Matthew Seaman
<m.seaman at> wrote:
> Hash: SHA1
> On 15/03/2010 18:16:17, Alejandro Imass wrote:
>> Hi,
> Yes.  In essence what you need to do is obtain the 6.2 sources and run
> through a standard buildworld type update.  In principle, you could use
> freebsd-update similarly, but 6.2 is out of support and not available
> that way. 6.4 is still under support, and the 6.2 -> 6.4 upgrade should
> be a lot less risky than 6.2 -> 7.3 if you're still eager t try
> freebsd-update.

Yep. I reconfigured my supfile and got the sources for 6.2 STABLE with
csup, the same one I started off with. Nevertheless, I was assuming
that some files from 7.3 were copied by the failed installworld
(confirmed by your response). I tested this theory by rebuilding and
installing libc manually, and afterwards the build process advanced a
bit further, and got stuck in libstdc++,

So I got a bit bolder and studied the main makefile and discovered the
'libraries' target. After building, I was able to buildworld,
buildkernel, installkernel, merge, etc. Now my system seems to be back
in 6.2, but now it's RELEASE-p12 and seems to be working flawlessly.

> It is possible that you will have files installed by 7.3 still on your
> hard drive. Ones that don't exist in 6.X and so don't get overwritten by
> reinstalling 6.X.  As the prime candidates for that sort of thing are
> the updated shlibs from 7.3, you need to check into that, and remove
> anything that shouldn't be there.  Otherwise you can run into trouble if
> you update any ported software -- programs crashing because they try and
> dynamically link against two different versions of the same shlib.  It's
> the same problem you can encounter after a major version upgrade (and
> the reason for the recommended practice of reinstalling all ported
> software), just in reverse.

Ok, here is what I did for future reference in the list archives:

1) backdated sources with csup. This is, configured a supfile with 6_2
and used csup to download the closest sources to my original version.
2) tried to make buildworld and failed due to installed based libs
from the failed installworld of 7.3
3) make libraries
4) make buildworld
5) make buildkernel, installkernel, reboot, etc. and the rest of the
process described in:

This makes me conclude that buildworld will effectively use the libs
in /usr/src/obj instead of the systems libs, which is awesome, because
it's just what I needed to complete buildworld in the first place.
It's very clever and of course, this makes sense because it's the same
logic that is used to build the new kernel! -duh! The magic here was
the 'libraries' target. Anyway, FreeBSD really kicks every single
*NIXs ass that I've used in the past. This clean separation of system
and ports is honestly amazing. I'm a noob in FreeBSD but getting to
really love it!

> I don't recall any warnings of possible problems with gvinum
> compatibility between versions 6, 7 or 8.  However, that does not in any
> way mean there weren't any, and you should check the release notes for
> the various releases since 6.2 carefully.  It may be a worst case
> scenario of backing the system up, and then reinstalling from scratch --

What I conclude at this point is that the library mixup after the
failed installworld may have contributed to the gvinum problem with
the 7.3 kernel running perhaps with some 6.2/7.3 mixup. The problem
was obviously gone after I sprinkled the libraries magic, since I was
able to compile and install everything back to 6.2 without any
hiccups. I think I was lucky that the old 6.2 kernel booted and
mounted my gvinum devices without the crazy stuff that was happening
with the 7.3 kernel.

> in which case, a good strategy would be to have a RAID1 mirror (ie.
> gmirror(8)) for the OS and separate data partitions using whatever RAID
> level you had implemented using gvinum.  Or else go the whole hog and
> build the system using ZFS.  Either of those should give you good future
> proofing against this sort of thing happening to you again.

Yeah, I'm looking at ZFS for the future, but for the time being all I
wanted was to compile the nvidia 64bit driver and got into this whole
mess of upgrading the system ;-) Also, gvinum has proved so stable for
us that we will probably stick with it for while.

>        Cheers,
>        Matthew
> - --

Thanks Matthew for such a prompt and detailed answer and to give me
the confidence I was in the right track! I think my main mistake was
to jump from such an old version to the latest 7 release. This time
I'm going a version at a time, reading UPDATING every time, and yes, I
will make system backups ;-)

- Hide quoted text -

> Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
>                                                  Flat 3
> PGP:     Ramsgate
>                                                  Kent, CT11 9PW
> Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
> Comment: Using GnuPG with Mozilla -
> iEYEARECAAYFAkueiqsACgkQ8Mjk52CukIwKhgCgjgS/cxaA4tk22gKBC9fhxonk
> a1kAn1kffiZwlV5ydvLiDUWlCALeiDY5
> =TfeA

More information about the freebsd-questions mailing list