Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.unix.misc
Subject: Re: booting a new kernel remotely
Message-ID: <9743@jpl-devvax.JPL.NASA.GOV>
Date: 30 Sep 90 04:44:53 GMT
References: <1990Sep29.153337.6707@ccu.umanitoba.ca>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 88

In article <1990Sep29.153337.6707@ccu.umanitoba.ca> mills@ccu.umanitoba.ca (Gary Mills) writes:
: 
: Does anyone know of a nice way to boot a new kernel when logged in via
: a dial-up line?  When I do it from the console, I do a `shutdown +5',
: and when it comes down to single-user mode, I do a couple of syncs, hit
: break to get to the monitor, and do a `b vmunix.new -s'.  When it comes
: up, I rename the kernel, and hit ^D to go to multi-user mode.  The machine
: is down for less than five minutes.  This is under SunOS 4.1.  When I'm
: dialed in, `shutdown -r +5' does not work once I have renamed
: /vmunix.new to /vmunix.  I can use `reboot', but it doesn't give the
: warning messages to the users.  Also, the boot checks all the disks, so
: the machine is down for about twenty minutes.  How do other people do this?

We just modify our rc.boot to look for /newvmunix on bootup, and do the
install for us.  Makes life real simple.  You can also use it to install
new kernels in the middle of the night with "at".  And you can put a
new kernel out there to be installed sooner or later, whenever the system
reboots for some other reason.

At larger installations, it's nice to automate the modification of rc.boot.
For SunOS 4.1, you might run the following bit of Perl script.  Other
systems will need to modify, but the principle is the same.

#!/usr/bin/perl

#########################################################################
# fix up /etc/rc.boot							#
#########################################################################

print "  Editing /etc/rc.boot\n";

chdir '/etc' || die "Can't cd to /etc";

open(RC_BOOT,'rc.boot') || die "Can't open /etc/rc.boot";

$nu = '';
while (<RC_BOOT>) {
    if (m!^\s*sh /etc/rc.single!) {
	$tmp = $_;
	while (<RC_BOOT>) {
	    last if /^\s+;;/;
	    $tmp .= $_;
	}
	($white) = /^(\s+);;/;
	$tmp .= <<EOF;
${white}if [ -r /newvmunix ]
${white}then
${white}	(echo -n "Installing new kernel...")    >/dev/console
${white}	/bin/mv /vmunix /oldvmunix
${white}	/bin/mv /newvmunix /vmunix
${white}	(echo) >/fastboot
${white}	(echo "done...rebooting...")    >/dev/console
${white}	/etc/reboot
${white}fi
 
EOF
	$nu .= $tmp . $_;
	next;
    }
    if (m!\s*if \[ -r /newvmunix \]\n!) {
	while ($_ && !/^\s*fi/) { $_ = <RC_BOOT>; }
	do {
	    $_ = <RC_BOOT>;
	} while /^\s*$/;
	redo;
    }
    $nu .= $_;
}
close RC_BOOT;

`cp rc.boot rc.boot.std` unless -f 'rc.boot.std';
chmod 0644, 'rc.boot';

open(RC_BOOT,">rc.boot.new") || die "Can't recreate /etc/rc.boot";
print RC_BOOT $nu;
close RC_BOOT;

rename('rc.boot', 'rc.boot.old');
rename('rc.boot.new', 'rc.boot');
__END__

Note that the code renames the old kernel to oldvmunix, so you're not
stuck if the new kernel doesn't work.

Just shutdown with the -f flag if you want to skip the disk checks.

Larry Wall
lwall@jpl-devvax.jpl.nasa.gov