No, if being static was enough you wouldn't need to copy
/sbin/reboot. Static binaries only help when library ABIs change, not
the kernel syscall ABI.
The kernel ABI has changed. By unpacking base*.tgz you have replaced the
binaries in /sbin with copies that expect a new kernel, but you are
still running the old kernel. In principle you can't safely run anything
you have unpacked from the new base*.tgz because they expect a newer
kernel than you are running. That's why you need to save a copy of the
old /sbin/reboot that matches the running kernel - the new /sbin/reboot
won't work.
Things that are already in memory should mostly be fine because they
were started (that is, the running binary was loaded from disk) before
you replaced the files. They won't always work though, for example if
you try to create a new tmux window it will try to run /bin/ksh which
has been replaced and won't start.
After you have unpacked the new sets, you should not expect anything
except /sbin/oreboot to work. Why that actually doesn't work for you is
a mystery.
On Wed, Oct 09, 2013 at 03:56:49PM -0600, Jeff Ross wrote:
> Speaking of failing internet...using my phone...
>
> All of the programs at the end of my script are static binaries, either in
> /bin or /usr/sbin, so they should work, right? Yet nothing ran, ls and cat
> both failed with the bad system call error.
>
> I only have one version of my script. It doesn't call tmux nor did I kill
> the tmux server.
>
> Interesting! Thanks for replying.
>
> Jeff
> Sent from my iPhone,
> Reluctantly hunting and pecking on a virtual keyboard :-)
>
> > On Oct 9, 2013, at 3:19 PM, Nicholas Marriott <nicholas.marri...@gmail.com>
> > wrote:
> >
> > So long as tmux is running and attached it is already in memory and
> > replacing the binary on disk should have no effect.
> >
> > Also ksh is still ksh even if it's inside tmux. tmux is not a
> > shell. Once your script is going then whether you are running it inside
> > tmux or not should make no difference. Assuming the script doesn't
> > itself invoke tmux and you don't do anything to kill the tmux server.
> >
> > Your script is running rm, sync, pwd_mkdb and cp after replacing them so
> > I guess they it is expected they will fail.
> >
> > No idea why oreboot is failing.
> >
> > Are you sure you aren't running an old version of the script by
> > accident, or something like that?
> >
> >
> >> On Wed, Oct 09, 2013 at 02:47:52PM -0600, Jeff Ross wrote:
> >>> 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
