heiser@tdw206.ed.ray.com (Bill Heiser - Unix Sys Admin) (06/07/91)
I've always been under the impression that a machine should be in single user mode before installing a new kernel. As such, I've always brought the machine down before removing /unix and installing the new version there. If a machine is in a controlled lab environment where no one else will be logged in, is there any reason not to install a new /unix while in multi-user mode (with me being logged in across the ethernet)? The procedure would be something like this: - build new kernel - get rid of all logged in users - cd / - remove (or move) old /unix - cp in new unix - shutdown -r (or whatever to reboot) Is there a problem with this? All the manuals, etc, always say to be in single user. Is there a reason for that? Thanks in advance, Bill -- Work: heiser@tdw201.ed.ray.com Home: bill@unixland.natick.ma.us Public Access Unix/USENET 508-655-3848
clewis@ferret.ocunix.on.ca (Chris Lewis) (06/09/91)
In article <2534@sud509.ed.ray.com> heiser@tdw206.ed.ray.com (Bill Heiser - Unix Sys Admin) writes: |I've always been under the impression that a machine should be |in single user mode before installing a new kernel. As such, |I've always brought the machine down before removing /unix and |installing the new version there. |If a machine is in a controlled lab environment where no one |else will be logged in, is there any reason not to install a |new /unix while in multi-user mode (with me being logged in |across the ethernet)? The procedure would be something like this: |- build new kernel |- get rid of all logged in users |- cd / |- remove (or move) old /unix |- cp in new unix |- shutdown -r (or whatever to reboot) |Is there a problem with this? All the manuals, etc, always |say to be in single user. Is there a reason for that? The only difficulty with doing it this way is that any program that tries to read /unix and /dev/kmem (such as "ps") will get grossly confused. Multi-user doesn't really matter, nor does having users logged in, but ps will start behaving a bit strangely... The /etc/rc.? shutdown scripts might go a bit nutty if they attempt to do ps's to find out the pids of stuff they have to kill. But few (if any) of the shutdown scripts do that. -- Chris Lewis, Phone: (613) 832-0541, Domain: clewis@ferret.ocunix.on.ca UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!
meissner@osf.org (Michael Meissner) (06/10/91)
In article <2534@sud509.ed.ray.com> heiser@tdw206.ed.ray.com (Bill Heiser - Unix Sys Admin) writes: | I've always been under the impression that a machine should be | in single user mode before installing a new kernel. As such, | I've always brought the machine down before removing /unix and | installing the new version there. | | If a machine is in a controlled lab environment where no one | else will be logged in, is there any reason not to install a | new /unix while in multi-user mode (with me being logged in | across the ethernet)? The procedure would be something like this: | | - build new kernel | - get rid of all logged in users | - cd / | - remove (or move) old /unix | - cp in new unix | - shutdown -r (or whatever to reboot) | | Is there a problem with this? All the manuals, etc, always | say to be in single user. Is there a reason for that? I do it all the time, though I usually take it a step further by doing it from a modem from home. Obviously, if the kernel is bad, I lose in the modem case, but thems the breaks. I believe the main reason the manuals says to go to standalone mode is to prevent people from logging in after you have started copying the kernel, since ps typically goes off into the wild blue yonder if the installed kernel is not the same as the kernel running. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 You are in a twisty little passage of standards, all conflicting.
bressler@iftccu.ca.boeing.com (Rick Bressler) (06/11/91)
Bill Heiser - Unix Sys Admin writes in part: >I've always been under the impression that a machine should be >in single user mode before installing a new kernel. As such, >I've always brought the machine down before removing /unix and >installing the new version there. > Well, one day, in a moment of brain lock, I actually did this. All sorts of weird things started happening. I'm no wizard, but from the symptoms, I expect that at a minimum, many routines look at the object to find offsets to various variables in the kernel. When you change the kernel, the offsets no longer match the copy in memory.... It didn't take me long to realize that I'd forgotten to get to single user, so I have no idea what would have broken in the long run. I know vmstat and similar stuff didn't work. No file systems were corrupted, but as I said, it was sort of an OH S**t situation, and I didn't leave it running for more than a couple of minutes. I'd recommend not trying it. The system in question was a BSD 4.3 system. Rick.
johnr@lotus.lotus.com (John Rouillard) (06/14/91)
The way I install kernels on Sun workstations is to move my new kernal to /vmunix.new. THen I execute a shutdown -h to halt the cpu. Then at the boot prompt I do a "b vmunix.new" to boot off the new kernel. Granted a few ps's in the /etc/rc* stuff get confused, but I expect that and use them as a test to make sure everyting is working fine. Once the system boots on the new kernel, I move /vmunix to /vmunix.old and hard link /vmunix.new to /vmunix. Then I run ps and if everything works fine, I am all set. If at any point the reboot with the new kernel bombs out, I just reboot or power off the machine, and my old configureation is still in place, so a standard reboot will get me going again. -- John