Date: Tue, 13 Aug 2013 12:51:32 -0700 From: Garrett Cooper <yaneurabeya@gmail.com> To: "d@delphij.net" <d@delphij.net> Cc: Devin Teske <dteske@freebsd.org>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: Positional arguments/load command broken in boot loader; cannot load old kernel Message-ID: <DDD80C65-91F6-46EA-8169-98C98CA4CB60@gmail.com> In-Reply-To: <520A6996.9050803@delphij.net> References: <9739C69E-FA2B-43F1-BBB6-FB0018BF1DC5@gmail.com> <520A6996.9050803@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry. Hit the send button too soon... On Aug 13, 2013, at 10:15 AM, Xin Li <delphij@delphij.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 08/13/13 09:36, Garrett Cooper wrote: >> I made the mistake of installing CURRENT on my file server at home=20 >> this morning and thought I could just boot the old kernel, do a >> zfs rollback, then continue on my merry way. >>=20 >> Turns out I was horribly wrong. >>=20 >> 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. >=20 > 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, a= nd 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 base= d on stable/9 sources built on August 9th (with backports from CURRENT so zf= sboottest 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 bi= ts with gpart. Would be nice if mergemaster -p automated this, or something along those lin= es... I feel that due to the amount of churn in ZFS, there are edge cases wh= ere due to things getting out of synch a system can easily become unbootable= . Thanks!=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DDD80C65-91F6-46EA-8169-98C98CA4CB60>