Re: Recovering base system files after failed installworld - RESOLVED
(sorry, I had mailed this directly by mistake intead of the list) On Mon, Mar 15, 2010 at 3:29 PM, Matthew Seaman m.sea...@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
Re: Recovering base system files after failed installworld - RESOLVED
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16/03/2010 22:34:47, Alejandro Imass wrote: 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 ;-) Heh. No problem. You shouldn't need to upgrade to every different version in turn -- in fact, I'd have been fairly confident you could have gone direct from 6.2 to 7.3 or 8.0 in one step, if not for the gvinum problem you ran into. Are you using a custom kernel? If you're using GENERIC or something close to it, and just kldloading the modules you need for gvinum support a good thing to try out would be booting from the install media for various FreeBSD versions and testing gvinum compatibility. Try burning some of the disc1 or dvd .iso images (or the 8.0 USB key image) for various different releases, booting from them into fixit mode (or whatever it's called: there's a complete system image on those disks that can run stand-alone) and trying to get the system to recognise and mount your gvinum partitions without modifying them. If it doesn't work, then no harm done -- just pull the installation media and reboot. If it does work, then you can upgrade with a bit more confidence. Cheers, Matthew - -- 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/ iEYEARECAAYFAkugFvQACgkQ8Mjk52CukIwtlQCgi5A1WTjRSnBOvaPb1A6Epd8D U8kAoJA6QTNikGTSyv4HAnLLKQN7uAXw =HStP -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Recovering base system files after failed installworld
Hi, I tried upgrading from 6.2 STABLE to 7.3 RELEASE, and everything went very smooth until I rebooted the new kernel. Make installworld failed complaining that cc1 was not executable. After a lot of tests, I came to the conclusion that the new 7.3 kernel had some sort of problem with my gvinum partitions, since executables were mysteriously becoming corrupt and the miraculously fixed after reboot. So I reverted to the old kernel and the system booted without any problems. I reverted with csup to 6.2 STABLE sources, but now I realize that some binaries of the base system were modified by the failed installworld. For example, it seems that libc.a is not compatible with the compiler as I now get: /usr/lib/libc.a: could not read symbols: Malformed archive Now, the question I have is: is there any way to revert all system binaries to 6.2 STABLE without a previous backup? Can a utility like freebsd-update help me restore these binaries? Thanks in advance, Alejandro Imass ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Recovering base system files after failed installworld
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15/03/2010 18:16:17, Alejandro Imass wrote: Hi, I tried upgrading from 6.2 STABLE to 7.3 RELEASE, and everything went very smooth until I rebooted the new kernel. Make installworld failed complaining that cc1 was not executable. After a lot of tests, I came to the conclusion that the new 7.3 kernel had some sort of problem with my gvinum partitions, since executables were mysteriously becoming corrupt and the miraculously fixed after reboot. So I reverted to the old kernel and the system booted without any problems. I reverted with csup to 6.2 STABLE sources, but now I realize that some binaries of the base system were modified by the failed installworld. For example, it seems that libc.a is not compatible with the compiler as I now get: /usr/lib/libc.a: could not read symbols: Malformed archive Now, the question I have is: is there any way to revert all system binaries to 6.2 STABLE without a previous backup? Can a utility like freebsd-update help me restore these binaries? 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. 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. 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 -- 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. Cheers, Matthew - -- 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- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
