On Mon, Aug 19, 2013 at 11:08:09PM +0200, Moritz Grimm wrote:
| Hi,
|
|
| This is an FYI on how to move past flag day with SSH access only. I used
| this process on my local workstation first, then verified it on a VM
| actually using SSH only (both amd64). I'll do it again when updating a
| bunch of important boxes to 5.5 in 2014, so this is also for the
| archives in case I lose my notes ...
|
|
| For every step that counts: Work in a real root shell. Do not rely on
| sudo for this, except for maybe an initial ``sudo su -l''.
|
|
| 1. Download the new installation sets (you need bsd* and *.tgz). If you
| care about the original sets, make another copy of them before the next
| step.
|
|
| 2. Unzip the tarballs, to remove any dependency on gzip(1):
|
| # for x in *.tgz; do gunzip $x; done
|
|
| 3. Copy essential pre flag day files.
| NB: My use of sync(1) is, first and foremost, to make me feel good.
| It's maybe reducing certain risk, but it won't eliminate it.
|
| # mkdir /bin54
| # cp -p /sbin/reboot /bin/tar /bin/sync /bin54
|
|
| 4. Save packages information as per current.html:
|
| # pkg_info -mq > /root/pkg_list_manual
| # pkg_info -q > /root/pkg_list_full
|
|
| 5. Before continuing on this soon-to-be destructive path, put the tip of
| your right hand's little finger on your slightly puckered lips, raise
| your left eyebrow, and think: "Do I really want to continue?"
|
|
| 6. Update /etc.
|
|
| 7. Allow login after first reboot post flag-day:
|
| # cat << EOF >> /etc/rc.local
|
| echo ">>>>>>>> FLAG DAY >>>>>>>>"
| pwd_mkdb /etc/master.passwd
| cp /dev/null /var/log/lastlog
| cp /dev/null /var/run/utmp
| echo "<<<<<<<< FLAG DAY <<<<<<<<"
| EOF
You can stick this in /etc/rc.firsttime (that's what it's there for).
Also, I'd add `cp /dev/null /var/log/wtmp` (or rotate it away, if you
care enough .. you're on your own reading those rotated files anyway).
This way, last(1) works as it should.
|
| 8. Uninstall all but (any) firmware packages as per current.html, but
| maybe do some extra things, too:
|
| a) Stop all non-base daemons, make database dumps, the one or other
| last-minute backup ...
|
| b) Re-visit current.html for extra migration steps w/ 3rd party
| software, like the rrdtool stuff.
|
| c)
| # pkg_delete -X /var/db/pkg/*-firmware-[0-9]*
|
|
| 9. Install new kernel, unpack install sets (previously unzipped):
|
| a) Make backups of your kernels to have *something* to boot to if all
| goes wrong:
| # for x in /bsd*; do cp -p $x $x.54; sync; done
|
| b) Install the new kernel. This is a lazy gamble, and not a
| replacement for doing it properly as per Nick's FAQ:
| # cp -p bsd.mp /bsd && cp -p bsd.rd /bsd.rd && sync
So don't copy bsd.rd when copying bsd.mp exited non 0 ?
| c) optional: use this opportunity for some (incomplete) housekeeping:
| # rm -rf /usr/include /usr/libdata/perl5/site_perl/amd64-openbsd
| /usr/share/locale /usr/share/man
|
| d) Destroy the system for good:
| # for x in base54.tar comp54.tar man54.tar game54.tar xbase54.tar
| xshare54.tar xfont54.tar xserv54.tar; do echo $x; /bin54/tar xphf $x -C
| /; /bin54/sync; done
Reverse the list of files and you won't need your /bin54/tar (and you
can continue using gzip'ed tarballs). In fact, all you really need is
to stick base54 at the end of the list.
| 10. Reboot immediately afterwards; the system is no longer good for
| anything else:
|
| # /bin54/reboot
|
| Good luck.
|
|
| 11. Clean up upon successful re-login:
|
| a)
| # rm -r /bin54 /bsd*.54
|
| b) Remove FLAG DAY stuff from rc.local.
|
| c) Look for coredumps that accumulated since the unpacking of
| baseXX.tgz, as there might be some due to (then) bad system calls.
| # find / -type f -name '*.core'
|
|
| 12. Re-add packages as per current.html:
|
| # pkg_add -z -l /root/pkg_list_manual
| # pkg_add -za -l /root/pkg_list_full
I don't really understand why you're doing the -za dance with the full
pkg list. For all those dependencies that were required for the
manually installed packages ? Or for all the dependencies of manually
added packages that you've since deleted ?
| 13. Maybe reboot once more to get everything running as it were, i.e.
| verify that it does.
|
|
| So, that's it. What could possibly go wrong! Well, maybe try this once
| in a local VM, first ... the practice helps.
Other than the above, this is what I did too. First on my laptop
(which uses a modified kernel), then I did my workstation over SSH
(easy to walk over to), then my home gateway (slightly more cumbersome
to get console access to) and now I'm confident the process works well
enough for "real" upgrades ;)
I just want to recommend one more additional step: Before all of this,
think: "How am I going to fix shit if things blow up ?" Prepare for
that, and you'll find you don't need it (or don't prepare and find
that you do)
Cheers,
Paul 'WEiRD' de Weerd
--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
