Skip site navigation (1)Skip section navigation (2)
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>