Test booting kernel for one boot only (Was: Testing a 5.0 kernel remotely (Dedibox FWIW))

[David Brownlee <abs%netbsd.org@localhost>]

2009/10/4 Jeremie Le Hen <jeremie%le-hen.org@localhost>:
> Hi list,
>
> Please Cc: me when replying as I'm nto subscribed.
>
> I rent a dedicated server on which I've installed NetBSD 4.0. ÂI have
> root access through ssh, but no access to the console. ÂI'd like to
> switch to NetBSD 5.0 but it seems it cannot boot. ÂUnfortunately I can't
> see the panic message and, worse for me, once the 5.0 kernel is
> installed, I can't go back to the previous working one. ÂSo for each
> failing kernel I have to reinstalled the box from scratch.
>
> I'd like to know if there is anything I can do to easy my life.
>
> For example, FreeBSD has nextboot(8) which allows to boot a new kernel
> only once. ÂWhether it works or not doesn't matter, on the second
> reboot, the old kernel will be booted. ÂIt would at least prevent me
> from reinstalling the box after each unsuccessful test.

I don't know of such a facility in NetBSD, though it would be a
welcome feature. The freebsd nextboot(8) implementation makes me a bit
twitchy as it relies on storing state in the filesystem and then
modifying it on next boot before fsck or anything else has run ... "If
it scrambles your file system, do not blame me."

The obvious ways (at least as far as I can see) for implementing this would be:
- Setting some state which is transient for a single reboot, which is
decidedly machine dependent (setting something in the BIOS or some
area of memory which is not going to be cleared on reboot)
- Setting state in the filesystem which is cleared on boot (see issues above)
- Setting state in filesystem and toggling a single bit in the
filesystem metadata or bootblock to tell the bootblocks whether to use
it
- Setting state in the filesystem including "use this data if system
clock is between N & M", which avoids the modifying state issue and
gives you a "boot test kernel for any reboot in the next ten minutes"
option.

What do other people think?

> Another interesting thing for me, would be to capture the panic message
> somewhere. ÂMaybe dump the kernel messages to a pre-configured dedicated
> partition, or something.

Dedibx also seem to offer a KVM over IP facility which could help with
the testing, 15EURO per half day seems a little steep tho.

For reference I have a bunch of NetBSD/xen {4,5}{i386,amd64} boxes at
panix and am a big fan of their ssh access to console facility :)