Discussion:
Loader.conf problem
(too old to reply)
Warner Losh
2017-11-20 20:37:52 UTC
Permalink
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...

Warner
Thomas Laus
2017-11-20 21:42:20 UTC
Permalink
Post by Warner Losh
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.

Tom
--
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
Warner Losh
2017-11-20 21:47:52 UTC
Permalink
Post by Thomas Laus
Post by Warner Losh
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
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
Thomas Laus
2017-11-20 23:31:12 UTC
Permalink
Post by Warner Losh
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.
I have another PC that is operational and is running CURRENT last
built about a week ago. I'll copy it's gptzfsboot file to a memory
stick and try loading it on the non-functioning PC in the morning.
I'll let you know how it comes out.

Tom
--
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
Warner Losh
2017-11-20 23:46:55 UTC
Permalink
Post by Warner Losh
Post by Warner Losh
Can you revert this part of the change? Go back to a known-working
version
Post by Warner Losh
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.
I have another PC that is operational and is running CURRENT last
built about a week ago. I'll copy it's gptzfsboot file to a memory
stick and try loading it on the non-functioning PC in the morning.
I'll let you know how it comes out.
Please do. I fear I screwed something up in the massive rototilling I did,
despite efforts to the contrary, and any help you can give me tracking it
down would be greatly appreciated.

Warner
Thomas Laus
2017-11-21 12:48:50 UTC
Permalink
Post by Thomas Laus
Post by Warner Losh
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.
I have another PC that is operational and is running CURRENT last
built about a week ago.  I'll copy it's gptzfsboot file to a memory
stick and try loading it on the non-functioning PC in the morning.
I'll let you know how it comes out.
Please do. I fear I screwed something up in the massive rototilling I
did, despite efforts to the contrary, and any help you can give me
tracking it down would be greatly appreciated.
I had boot success when copying gptzfsboot file from my laptop that is
running r325474. The problem CURRENT version running on my desktop is
r326012. The UPDATING note describing the latest changes just has a
date of 201711xx. How far back should I go to start the isolation process?

Tom
--
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
Andriy Gapon
2017-11-21 17:38:38 UTC
Permalink
Post by Thomas Laus
I had boot success when copying gptzfsboot file from my laptop that is
running r325474. The problem CURRENT version running on my desktop is
r326012.
Thomas,

could you please compare sizes of the files before going further?
--
Andriy Gapon
Warner Losh
2017-11-21 18:04:39 UTC
Permalink
Post by Andriy Gapon
Post by Thomas Laus
I had boot success when copying gptzfsboot file from my laptop that is
running r325474. The problem CURRENT version running on my desktop is
r326012.
Thomas,
could you please compare sizes of the files before going further?
I think I see the problem... There's no LOADER_SUPPORT_GELI in the
gptzfsboot built. Let me fix that... Seems to be caused by having HAVE_GPT
instead of HAVE_GELI.... r326069 should get this working again. Can you
confirm this independently.

Sorry for the breakage. Clearly a bonehead mistake on my part.

Warner
Thomas Laus
2017-11-21 21:21:49 UTC
Permalink
Post by Warner Losh
I think I see the problem... There's no LOADER_SUPPORT_GELI in the
gptzfsboot built. Let me fix that... Seems to be caused by having
HAVE_GPT instead of HAVE_GELI.... r326069 should get this working again.
Can you confirm this independently.
Sorry for the breakage. Clearly a bonehead mistake on my part.
Updating to r326070 fixed that problem. I have another one when
performing a nfs mount on my desktop to update my laptop to the same
release. Mergemaster complains about not having permission to write to
the nfs mounted /usr/src directory. All of my previous updates always
wrote the temporary files to a local laptop tmp directory and never
required write access to the nfs mounted /usr/src.

I'll dig into the second problem a little more and see if additional
information can be gained.

Thank you and Andriy for the help in solving this one.

Tom
--
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
Thomas Laus
2017-11-21 18:53:17 UTC
Permalink
Post by Andriy Gapon
Post by Thomas Laus
I had boot success when copying gptzfsboot file from my laptop that is
running r325474. The problem CURRENT version running on my desktop is
r326012.
could you please compare sizes of the files before going further?
The gptzfsboot file size on r326102 is 69839 bytes. The gptzfsboot file
size on r325474 is 116940 bytes. I hope that this helps finding this issue.

Tom
--
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
Warner Losh
2017-11-21 21:04:39 UTC
Permalink
Post by Thomas Laus
Post by Andriy Gapon
Post by Thomas Laus
I had boot success when copying gptzfsboot file from my laptop that is
running r325474. The problem CURRENT version running on my desktop is
r326012.
could you please compare sizes of the files before going further?
The gptzfsboot file size on r326102 is 69839 bytes. The gptzfsboot file
size on r325474 is 116940 bytes. I hope that this helps finding this issue.
That's the ticket. My commit this morning should fix it.

Warner
Loading...