Date: Thu, 18 Feb 1999 17:23:47 -0800 From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> To: stable@freebsd.org Subject: State of the 3.1 world and upgrading from earlier releases. Message-ID: <40353.919387427@zippy.cdrom.com>
next in thread | raw e-mail | index | archive | help
Since so many people seem to be asking about this in email, the newsgroups, web boards and several aircraft-towed banners above my house, let me just see if I can summarize the current state of affairs. First off, in my last message on this topic I discussed various 11th-hour bits of rock-polishing that would be going on for 3.1-RELEASE and why people should wait for that bit to be over. Well, 3.1-RELEASE is out now and there's probably no better time to fire up the old cvsup and catch up to RELENG_3 if that's your desire - you stable-source-trackers can stop waiting (not that many of you did anyway ;) for a good time to run "make upgrade" Second, on the subject of upgrading from sources in general, the aformentioned upgrade target is what you want to use if you're still running an a.out userland OR an a.out kernel. How do you tell you're running an a.out kernel? If ``file /kernel'' doesn't immediately say it's an ELF blahdiddy-blah-blah file, it's a.out. Same goes for userland code - if ``file /bin/test'' doesn't claim it's ELF, you've got an a.out userland. In either case, run a make upgrade and NOT a make world or buildworld since that will simply fail due to bootstrapping issues from a.out to ELF that only the upgrade (AKA aout-to-elf) target knows how to deal with. If you're feeling especially brave, set the environment variable NOCONFIRM to yes (or any other value) in your upgrade build and it won't even ask you any questions until the very last stage, when it comes time to figure out which kernel config file you want to use and what disk your boot device is. This part of the procedure *IS* interactive and the only way of making it not interactive at all is to set NOCONFIRM and to also create a file called /var/db/update.cfg which contains just two lines: The name of your kernel config file, e.g. GENERIC, and the name of the disk device you want to write the new boot blocks to, e.g. sd0 for a SCSI drive or wd0 for an IDE drive. If detected, this file's contents will be used instead of prompting. However you do it, interactively or more optimistically in batch mode, the upgrade procedure will then proceed to eat up a large amount of disk space in /usr/obj (~450MB) and upgrade the system in stages to ELF, ending with the installation of a new ELF kernel and ELF boot blocks followed by a reboot. Yes, that's correct, a REBOOT. You have to do it at this stage anyway so we've automated it. Keep that in mind, all you crazy folks with aims to do this on production servers (I can't prevent you from doing such crazy things, but I can at least say: "ack!!" :-). Those of you doing production server upgrades should install 3.1 fresh on a box and then *rotate* it into place, preferably after carefully running it and the old machine in parallel for awhile to see how the new one holds up. Once you're comfortable with the upgrade, you can pull the old box and free it for use in the next service rotation. For those who just like to live life on the edge or are too cheap to buy a "staging box" for this purpose, however, I have to say that the source upgrade is probably the worst way to go about doing it. If you absolutely must upgrade a box in-place (or don't care because it's not a critical resource), do the binary upgrade by booting the installation disks for 3.1-RELEASE (or a later 3.1-STABLE snapshot from releng3.freebsd.org) and choosing an upgrade installation. This is a faster, less error prone and extremely direct way of upgrading from any previous release, be it a.out OR ELF, in comparison to a source upgrade. It still won't result in an installation which is quite as "clean" as a completely fresh install, but it does work (yes, I've tested it :). Once you've made the jump to ELF, the source upgraders can just ``make world'' as desired to track the ongoing state of 3.1-STABLE (or even to jump to 4.0-CURRENT, if they so desire). We've always tried to make upgrading from source an easy ``make world'' away, it's just the a.out->ELF transition giving us an especially difficult job of it this time around. Anyway, I'm rambling. I hope this at least clears things up a bit for some of the folks wondering what their next step should be. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40353.919387427>