Date: Fri, 23 Mar 2001 10:11:09 -0700 From: Warner Losh <imp@harmony.village.org> To: "Matt Simerson" <mpsimerson@hostpro.com> Cc: "'freebsd-hackers@freebsd.org'" <freebsd-hackers@FreeBSD.ORG> Subject: Re: The "right" way to build a new world WAS: 4.3-BETA world crashin g 4.2-RELEASE kernel ? Message-ID: <200103231711.f2NHB9911637@harmony.village.org> In-Reply-To: Your message of "Thu, 22 Mar 2001 18:01:16 MST." <8D18712B2604D411A6BB009027F6449801B4B544@0SEA01EXSRV1> References: <8D18712B2604D411A6BB009027F6449801B4B544@0SEA01EXSRV1>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <8D18712B2604D411A6BB009027F6449801B4B544@0SEA01EXSRV1> "Matt Simerson" writes: : 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 most obvious reason to do it is that it works. Updating a system can cause pain. Get used to it. There are often times that many of the binaries that are running in multiuser mode can crash your system, so you can't get up into multi user. On major upgrades, you can't even get through the installworld with the old kernel. Having said that, I have often done things not in single user when the jumps were small. I usually get away with it, but have at times really hozed my system. Once or twice to the point I had to take the disk out of the machine and over to a working machine for touch ups. : 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. mountd is a big one why we wouldn't get through rc. I've had it crash the new kernel due to weaknesses in the kernel/user api that it uses. : 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. This introduces other problems. In the interrum between ifconfig and ipfw you are wide open to the world. Many attacks only need a few packets to gain root. : cd /usr/src : make buildworld : make kernel KERNCONF=<MY_KERN_CONF> : make installworld : mergemaster : reboot : cd /usr/src : make installkernel KERNEL=<MY_KERN_CONF> Why install the kernel twice? make kernel installs the kernel. : 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. You can also run into problems with -stable. I've run into those problems. It is espeically accute when updating 4.0 machines to 4.3, for example. You are dodging a minefield in doing things this way. You'll also get better milage out of make -j N (say 3 or 4) and doing things sequentially. It is safer and runs just as fast. Warner 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?200103231711.f2NHB9911637>