Date: Tue, 19 Feb 2002 18:12:02 -0600 From: "Mike Meyer" <mwm-dated-1014595922.e40fcc@mired.org> To: "Kevin Oberman" <oberman@es.net>, Richard Glidden <richard@glidden.org>, Cliff Sarginson <csfbsd@raggedclown.net>, questions@freebsd.org Subject: Re: Dropping to single user Message-ID: <15474.59858.403535.412935@guru.mired.org> In-Reply-To: <113194271@toto.iv>
next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Oberman <oberman@es.net> types: > Yes, a 'shutdown now' will "drop you to single-user mode, but you > REALLY want to reboot after you installkernel and before you > installworld. Proper order: > cvsup > cd /usr/src > make buildworld > make kernel KERNCONF=xxxx > REBOOT to single-user mode (boot -s)! > fsck -p > mount -a -t ufs > cd /usr/src > make installworld > mergemaster > REBOOT! > > In both cases the REBOOT really means to reboot, not to drop into > single-user mode. While steps may be skipped, doing so is taking a > risk of having a system in a badly corrupted state where the only > way out is to re-install the OS. Two comments: First, the fsck -p isn't needed. If they file systems are clean, it won't do anything but tell you it's not doing anything. If they aren't clean, mount will refuse to mount them and recommend you do the fsck. Second, you really don't need to do a full reboot the second time. You're already running the proper kernel for that world, so you can just exit the shell and let the system go multiuser. The only problem with doing that is that it leaves all kinds of spooge in /var/run/dmesg.boot. Richard Glidden <richard@glidden.org> types: > On 19 Feb, Kevin Oberman wrote: > > Yes, a 'shutdown now' will "drop you to single-user mode, but you > > REALLY want to reboot after you installkernel and before you > > installworld. > Actually, isn't this dangerous, since you would be booting a new kernel > with an old world, which could cause problems if there are significant > changes to the kernel that breaks the old world? What I usually do is: Not really. The new kernel will provide all the features the old world used, because backwards compatability is important. The reverse is *not* true - if something in the new world expects new kernel features, they won't be there, and you'll be hosed. There are a few things so tightly coupled to the kernel that they may break anyway, but those aren't things you're liable to use while you boot the new kernel and install the world. > make buildworld > make buildkernel KERNCONF=xxxx > shutdown +15 "Upgrading the World. Be right back." > <backup /etc, the old kernel, anything else that's critical> > make installkernel KERNCONF=xxxx > mergemaster > make installworld > shutdown -r now > This way, the running kernel always matches the installed world until > that final "shutdown -r now" command. At worst, if the new world > completely breaks everything, even your ability to reboot, you can just > hit the reset switch and hope everything was written to disk first. What good will hitting the reset button do? If you're hosed, you're hosed. Doing it the other way, if the kernel doesn't boot, you can just boot the old kernel and be back where you started from. Cliff Sarginson <csfbsd@raggedclown.net> types: > On Tue, Feb 19, 2002 at 01:23:11PM -0500, Richard Glidden wrote: > > On 19 Feb, Kevin Oberman wrote: > > make buildworld > > make buildkernel KERNCONF=xxxx > > shutdown +15 "Upgrading the World. Be right back." > > <backup /etc, the old kernel, anything else that's critical> > > make installkernel KERNCONF=xxxx > > mergemaster > > make installworld > > shutdown -r now > Yes, surely the mergemaster *has* to be done before the installworld > since the new world may expect certain new things to exist in /etc. Doesn't matter, because the things in the new world that need them aren't going to be started until after you go multiuser. Generally, I wait until afterwards, just to make sure the installworld is going to finish properly. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15474.59858.403535.412935>