Sorry. Hit the send button too soon...

On Aug 13, 2013, at 10:15 AM, Xin Li <delp...@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!
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to