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