Positional arguments/load command broken in boot loader; cannot load old kernel

Garrett Cooper yaneurabeya at gmail.com
Tue Aug 13 19:51:37 UTC 2013


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!


More information about the freebsd-current mailing list