Date: Thu, 22 Mar 2001 18:01:16 -0700 From: "Matt Simerson" <mpsimerson@hostpro.com> To: "'freebsd-hackers@freebsd.org'" <freebsd-hackers@freebsd.org> Subject: The "right" way to build a new world WAS: 4.3-BETA world crashin g 4.2-RELEASE kernel ? Message-ID: <8D18712B2604D411A6BB009027F6449801B4B544@0SEA01EXSRV1>
next in thread | raw e-mail | index | archive | help
OK, let's approach this from a little different angle:
Below is the appropriate entries from /usr/src/UPDATING on a FreeBSD
4-stable machine. As of 2/2/2001, the most correct and safest method for
updating your FreeBSD machine is as follows:
cd /usr/src
make buildworld
make kernel KERNCONF=<CUSTOM_KERN_CONFIG_NAME>
reboot (single user)
make installworld
mergemaster
reboot
I have found that there IS a variety of reasons NOT to do it that way. The
most obvious is that you might not have console access, thus making it
pretty hard to access the machine while it's in single user mode. I can also
think of a couple instances where this method could cause pain.
The first is changing of any of the files used at boot time. I don't allow
telnet access to any of my machines so SSH is often as close as I can get to
console. If anything changes enough that we don't cleanly make it through rc
and friends, processing stops, sshd won't be running and I can't get in. The
one time this happened the machine didn't make it multi user. Fortunately
that machine was in my basement so I walked down, looked at the errors on
the console and finished the upgrade.
IPFW changes. This one isn't quite obvious but if you don't compile your
kernel with IPFW_DEFAULT_TO_ACCEPT and changes are made to the kernel or
userland portions and not the other (as will happen in the above scenario)
then upon reboot, if your ruleset doesn't get applied, you won't be able to
access your machine via the network. Ouch. I always compile in the
DEFAULT_TO_ACCEPT for this reason and then add a default deny rule to the
IFPW ruleset. Even so, I find it's best to get my kernel, world, and config
files synced before rebooting.
Changes like that aren't terribly infrequent and if you aren't paying
attention, can bite you. This (and a few other things) have prompted me to
completely skip the first reboot. Also, I tend to keep everything I use in a
location (/usr/local) other than the default places installworld wants to be
touching. So, I can almost always get away with doing an installworld
without changing my runlevel. The last thing, which is seldom mentioned but
which I habitually do is another make installkernel after the system comes
back up and is happy. The reason(s) should be obvious. So, my procedure
looks a lot like this:
cd /usr/src
make buildworld
make kernel KERNCONF=<MY_KERN_CONF>
make installworld
mergemaster
reboot
cd /usr/src
make installkernel KERNEL=<MY_KERN_CONF>
One can also often get away with making a new kernel without first building
world but do so at your own peril (as I often do). :-) I often issue the
buildkernel and buildworld at the same time and then leave for the day. My
reasons for doing this are: laziness, impatience, and wanting to have the
entire compilation done when I return. Doing so can be risky but in my
experience, works just fine with the -stable tree. Others have been quick to
point out the possible hazards of doing so but they mostly apply when
playing with -current.
Matt
From /usr/src/UPDATING (on FreeBSD 4-STABLE):
COMMON ITEMS:
To build a kernel
-----------------
cd /usr/src
# If you have not already done so, please buildworld here
# You will also need to update your config file to 4.x. Usually
# people tend to start with GENERIC from 4.x and hack from there.
make buildkernel KERNCONF=<YOUR_KERNEL_HERE>
make installkernel KERNCONF=<YOUR_KERNEL_HERE>
# Verify that the new kernel works, it will be installed as
# /kernel
To rebuild disk /dev entries
----------------------------
MAKEDEV should be copied from src/etc/MAKEDEV to /dev before
starting the following:
For N in the list of disks
MAKEDEV N # eg ad0
for M in the list of slices
MAKEDEV NsMa # eg ad0s1a
To rebuild everything
---------------------
make world
Except when it doesn't work :-)
<snip>
To update from 4.0-RELEASE or later to the most current
4.x-STABLE
----------
make buildworld
make buildkernel KERNCONF=YOUR_KERNEL_HERE
make installkernel KERNCONF=YOUR_KERNEL_HERE
reboot (in single user) [1]
make installworld
mergemaster
reboot
[1] You can often get away without doing this step as the
system will be properly updated. During the running of the
installworld, however, system components may break and other
oddities may happen. Don't do this on systems that aren't
otherwise quiet as unpredictable results may happen. If in
doubt, reboot into single user. For remote installs, keep
a separate kernel around and use a serial console if at all
possible.
> -----Original Message-----
> From: David O'Brien [mailto:obrien@freebsd.org]
> Sent: Thursday, March 22, 2001 12:56 PM
> To: Matt Simerson
> Cc: 'freebsd-hackers@freebsd.org'
> Subject: Re: 4.3-BETA world crashing 4.2-RELEASE kernel ?
>
>
> On Thu, Mar 22, 2001 at 12:51:00PM -0700, Matt Simerson wrote:
> > Actually, they aren't backwards. You've gone and snipped
> the parts of my
> > original message that show that the commands are being
> executed at the same
> > time.
>
> I read you message twice and came away with the same idea. You should
> write more clearly.
I wrote the commands exactly as they would be issued, how much more clear
can one possibly get? Because you lack familiarity with the tool I was using
(screen) doesn't make my writing unclear. Your ignorance != my unclarity. To
make matters worse, you snipped out all the parts you didn't understand and
then reposted it with my name attached AND criticized it's behaviour which
you had incorrectly interpreted.
> > Maybe that's _YOUR_ method for installing but it's not necessarily the
best
> > one. Kernel's are not guaranteed to be backwards compatible and I've
> > installed a shiny new kernel that worked just fine and allowed my
machine to
> > come up single user but because of some rude change in /etc/rc, ipfw, or
any
> > of a number of places the machine couldn't make it to multi-user and
allow
> > me to get back in (via the network).
>
> That you're doing this remotely is your problem. Ask any of the
> developers living on -CURRENT where often one wants to back out of a
> newly compiled world.
I'm not running on -CURRENT and I certainly would never run -current on a
machine that I didn't have ready access to the console of. I've tracked
5.0-current months ago when I needed a feature that wasn't in the 4-stable
tree yet (dare I admit it was support for a sound card?). I find it to be
highly annoying when I have to babysit the buildworld process and manually
fix things to get a clean compile.
> The method I gave is the most sure and careful
> way. That you don't have consoles on your machines so you could do this
> properly doesn't mean what I posted isn't the safest and should be
> followed unless has special needs.
>
> I'm happy for you. But you have major flaws in your method where
> problems can bite you hard.
How so? If the buildkernel fails, odds are really good that it won't
successfully finish the compile, I won't get a kernel, I can't install a
kernel that isn't compiled, and there isn't a problem other than that I
don't have the new kernel I wanted. I can address this problem very easily
and it's not likely to cause any further pain.
> As I said, I want users to know and use the
> safest method. I've seen enough email from users that were all confused
> about the right steps -- often getting confused from posts such as yours
> where you [hopefully] understand the consequences of your method and can
> deal with them. Many do not want to or cannot.
OK then, the safest (and recommended) way to build 4-STABLE world is:
make buildworld
make kernel
reboot (into single user)
make installworld
mergemaster
reboot
Many sysadmins will find this doesn't work in their environment (for a
variety of reasons). The most obvious is that they need some custom features
in their kernel. So, make a copy of GENERIC in /sys/i386/conf/, edit it
accordingly (adding support for your sound card, x10 controller, IPFW, GB
ether card, quotas, and whatever else). The procedure will likely work
exactly that same:
make buildworld
make kernel KERNCONF=<NEW_KERNEL_NAME>
(1) reboot
make installworld
mergemaster
reboot
1. /usr/src/UPDATING
> > Second, if I'm going through the bother of compiling a buildworld it's
> > because I want the latest version of world on my system.
>
> Want != ability. I want a latest version of 5-CURRENT on my laptop, but
> CardBus is broken right now, so I am living with a Dec world. Such is
> life.
Such is life on -current. I think this is the majority of our desparity. You
live in a -current world where you're content to live with hacking and
tweaking source as a "normal" part of the buildworld process. It's nice that
you have console on all your boxes.
I live in -stable where I can't remember the last time a make buildworld
failed. In fact, it's been quite some time since building a kernel the new
way "make buildkernel" failed and I think that was on a 4.1.1-release
machine that I was upgrading to 4.3-stable. It required building via
./config KERNEL; cd ../../compile/KERNEL/; etc.... In my world where uptime
matters, I don't normally have the luxury of installing world in single user
mode either. I have a Portmaster at home so I can access console on my own
machines but my "console" for all the machines that live in our datacenters
is a portable KVM and a NOC monkey. Ouch. :-(
> > If there are some problems with the new kernel, I'm not going to revert
> > back to world.old. I'll fix whatever is screwed up with kernel and
> > proceed.
>
> Oh! Want a job as a kernel hacker then?
No thanks, that's why I'm back to tracking -stable. My dozens of FreeBSD
machines have jobs to do and building world every week trying to get a
version with only tolerable bugs isn't a very productive use of time.
> I'd like to have my CardBus working again (in current).
> Also my AHA-2930u2 on a K6-2 machine...
I'm sure you would but I have other things to spend time on. Tracking
-current on FreeBSD is just like tracking the latest releases of IOS on
Cisco. You know it's full of undocumented features for you to test and
report to the engineers. The only difference is that most of the bugs don't
make it into the -stable releases of FreeBSD where they do in IOS. In older
IOS though, all the bugs^H^H^H^Hundocumented features are well documented.
:-P
Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8D18712B2604D411A6BB009027F6449801B4B544>