Date: Tue, 16 Mar 2010 18:34:47 -0400 From: Alejandro Imass <ait@p2ee.org> To: freebsd-questions@freebsd.org Subject: Re: Recovering base system files after failed installworld - RESOLVED Message-ID: <a14066a01003161534u50ff192erfce5aad37c5b0942@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
(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@infracaninophile.co.uk> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > 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: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html 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 ;-) Best! Alex - Hide quoted text - > Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard > Flat 3 > PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate > Kent, CT11 9PW > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkueiqsACgkQ8Mjk52CukIwKhgCgjgS/cxaA4tk22gKBC9fhxonk > a1kAn1kffiZwlV5ydvLiDUWlCALeiDY5 > =TfeA > -----END PGP SIGNATURE----- >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a14066a01003161534u50ff192erfce5aad37c5b0942>