Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 20 Nov 2017 14:47:52 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        lausts@acm.org
Cc:        FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: Loader.conf problem
Message-ID:  <CANCZdfoUdB5TrE3Vc44VSuLzpULKno6F_G42TL0JiEp1fEyjTQ@mail.gmail.com>
In-Reply-To: <20171120214220.GA18207@mail.laus.org>
References:  <a4cf592d-3b1b-5b16-3e65-78ce61b91833@acm.org> <CANCZdfrFCbJ6YyysMZaU_S6ua9QEppe9USBFrah8Vrg-%2BQwe=g@mail.gmail.com> <20171120214220.GA18207@mail.laus.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 20, 2017 at 2:42 PM, Thomas Laus <lausts@acm.org> wrote:

> Warner Losh [imp@bsdimp.com] wrote:
> > On Mon, Nov 20, 2017 at 1:30 PM, Thomas Laus <lausts@acm.org> wrote:
> >
> > > I recently upgraded my FreeBSD-Current system today and did not fully
> > > understand the impact of changes to loader.conf.  My system has a Geli
> > > encrypted ZFS pool.  In the past whenever I screwed up, I was able to
> > > use 'Beadm' into boot the most recent good kernel or enter a shell to
> > > reread the UPDATING notes for a clearer understanding of what needs to
> > > be done before rebooting.
> > >
> > > Is my system recoverable or does it require wiping and reloading from a
> > > snapshot?  If it is recoverable, how to do?
> > >
> >
> > My changes to the system hasn't changed how things work. Or at least
> > shouldn't have changed anything. If they do, that's likely a bug, and
> > likely my fault.
> >
> > The one exception is if you're booting off GELI + ZFS with UEFI based on
> > boot1.efi changes that were in the tree for a few days...
> >
> This PC is not using UEFI to boot.  After booting I get the following
> message:
>
> gptzfsboot: No ZFS pools located; Cant't boot
>
> That is as far as things go.  I read the UPDATING file before I
> builtworld and built a kernel.  This was the first boot after doing an
> installworld and performing mergemaster and then copying the
> /boot/gptzfsboot file to ada0p1 and ada1p1.


Can you revert this part of the change? Go back to a known-working version
of those files? Let me know if that fixes the problem? Bonus points for
bisecting which one of the few dozen commits I did that caused this
regression...

I don't have  a GELI + ZFS test bed here.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoUdB5TrE3Vc44VSuLzpULKno6F_G42TL0JiEp1fEyjTQ>