On 10/9/13 1:29 PM, Nick Holland wrote:
On 10/09/2013 02:43 PM, Jeff Ross wrote:
I've got to upgrade some remote machines that I only have access via
ssh.
I've been using a script based on the "Upgrade without install kernel"
for years. I modified it slightly for this upgrade by adding
/usr/sbin/pwd_mkdb /etc/master.passwd
to /etc/rc.local so the password databases can be updated and I can log
in after the first reboot.
But how do I make the remote system reboot? Attempting to use the
/sbin/oreboot file I made in accordance to the "Upgrade without install
kernel" method fails with a "Bad system call (core dump)" error, as does
trying *any* command after base is extracted.
I think you are doing something wrong here...
/sbin/oreboot should be the old binary, which should -- and can! --
run on the old kernel.
I just did this last night, so I know it can work. :)
Are you using standard, supplied shells, such as ksh, sh, or csh? I
could imagine that bash or something else would get really really
unhappy there, but ksh et al. should be fully resident in RAM.
or did you happen to try "sudo oreboot"? that also would be expected
to not work, not because of oreboot, but because of sudo.
Do an ls -l /sbin/*reboot, I think your /sbin/oreboot isn't what you
are thinking it is.
Nick.
Hi Nick!
Just the person I was hoping to hear chime in!
Standard ksh shell, as root, although I got there via sudo.
I for sure thought it was odd, but actually on 4 separate systems I've
had reboot fail. The first was my little netbook in my lap, but that
was not problem because I could physically access the keyboard. The
next was half of another pair of CARPed firewalls--I have yet to get
someone in there to fix that--and then the CARPed pair at my
work--yesterday for one and this morning for the other.
Here is the output of ls -l /sbin/*reboot
jross@samsara1:/home/jross $ ls -l /sbin/*reboot
-r-xr-xr-x 1 root wheel 189236 Oct 8 13:42 /sbin/oreboot
-r-xr-xr-x 2 root bin 193332 Oct 1 11:46 /sbin/reboot
The oreboot is the copy of the previous /sbin/reboot--and the size
matches exactly the /sbin/reboot file on another system from about a
month before the time_t change.
Here's my update script from the first system I tried to upgrade at
work. In this case I tried running pwd_mkdb (since I'd checked that it
was a static binary) before rebooting.
Every command after the extracting base failed.
#!/bin/sh
path=/usr/releasedir/
export RELEASEPATH=$path # where you put the files
cd ${RELEASEPATH}
rm /obsd ; ln /bsd /obsd && cp bsd.mp /nbsd && mv /nbsd /bsd
cp bsd.rd /
cp bsd /bsd.sp
rm -rf /usr/X11R6/lib/modules/*
cp /sbin/reboot /sbin/oreboot
files="xserv xfont xshare xetc xbase game comp man base"
for i in $files
do
echo $i
tar -C / -xzphf $i*
rm -f $i*
sync
done
/usr/sbin/pwd_mkdb /etc/master.passwd
cp /dev/null /var/log/lastlog
cp /dev/null /var/log/wtmp
/sbin/oreboot
However, it just occurred to me that I was in a tmux shell as root--so
it was *not* ksh! I'll bet it was tmux that was croaking! I've gotten
in the habit of using tmux since it's been in base so if my internet
connection drops the script doesn't stop, leaving the whole system in an
inconsistent state--which I had happen about halfway through extracting
base one time.
Hmm--should (and can) tmux be switched to a static binary in base? It's
great to have that safety net if either side of my sometimes crappy
internet goes away.
Thanks, as always, Nick!
Jeff
