Sorry. Hit the send button too soon... On Aug 13, 2013, at 10:15 AM, Xin Li <delphij_at_delphij.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 08/13/13 09:36, Garrett Cooper wrote: >> I made the mistake of installing CURRENT on my file server at home >> this morning and thought I could just boot the old kernel, do a >> zfs rollback, then continue on my merry way. >> >> Turns out I was horribly wrong. >> >> In addition to colors added to the boot loader (ooooh shiny!!!), >> it appears the loading kernels with the load sub command from zfs >> pools does not work (load kernel.old, boot -s kernel.old, etc). >> Period. It works just fine with my stable/9 kernel/userland, but >> not the CURRENT one. > > Don't work -- how? I rebuild my laptop daily and does not see that > and I don't see a way Devin's changes could possibility cause problems > like this. Unfortunately I don't have definitive data other than the symptoms I noted, and some other data I can put together when I can unripple my home machine. > BTW since this sounds like a ZFS related issue -- did you do a 'zpool > upgrade' without updating loader or boot block and used some new features? Nope. An important item that I realized is that my boot0 bits are still based on stable/9 sources built on August 9th (with backports from CURRENT so zfsboottest works with the stable/9 sources), so it might actually be that the upgrade path from 9 to 10 doesn't "just work" without resetting the boot bits with gpart. Would be nice if mergemaster -p automated this, or something along those lines... I feel that due to the amount of churn in ZFS, there are edge cases where due to things getting out of synch a system can easily become unbootable. Thanks!Received on Tue Aug 13 2013 - 17:51:37 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:40 UTC