Sounds like a perfect use case for Boot Environments. Create a new BE, install the new kernel into it, set it as the default, reboot. If it fails, you manually set the previous BE as the default, and reboot. That way, your "known-good", working environment is never affected.
beadm should be part of 10-CURRENT. If not, there should be a port for it. On Wed, Feb 20, 2013 at 7:05 AM, O. Hartmann <ohart...@zedat.fu-berlin.de>wrote: > At the moment, the most recent kernel of FreeBSD 10.0-CURRENT crashes on > all of the boxes I compiled the most recent kernel sources (build a > world ncluding kernel, not only the kernel, so the system is "consistent"). > > At the loader prompt, I need to unload the buggy kernel and load the old > working one via > > load /boot/kernel.old/kernel > > Then I load also the ZFS related modules > > load /boot/kernel.old/opensolaris.ko > load /boot/kernel.old/zfs.ko > > Issuing boot at the end of that stage boots the kernel - the old one > -successfully - but there is no working ZFS and no ZFS volume gets > mounted although the rc.conf is executed correctly. > > What am I doing wrong at that point? Why isn't ZFS run and mount properly? > > Luckily, just booting the old kernel via load /boot/kernel.old/kernel > and booting it having zfs_enable="YES" in /etc/rc.conf set loads the > /boot/kernel/opensolaris/zfs stuff - usually those kernel modules are > out of sync compared to kernel.old but in this case its just a > coincidence that this works. > > So, what is the proper way to have ZFS mounted in an emergency case when > I'm in need of loading a working kernel manually? > > Regards, > Oliver > > -- Freddie Cash fjwc...@gmail.com _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"