Hash: SHA512

On Dec 18, 2013, at 9:34 AM, Allan Jude wrote:

On 2013-12-18 12:27, Allan Jude wrote:
An issue we thought we had fixed, was not actually fixed.

When doing a GELI based Root-on-ZFS install, the 'bootpool' is not
always properly mounted in the installed system.

The lines added to loader.conf to make it use the zpool.cache file and
learn of the existence of the 2nd pool are required, and have the
desired effect.

However, it seems that the 2nd pool is not always listed in the cache file.

The attached patch should fix this issue.

Hopefully this can get MFCd in time for the next RC

A note for the release notes. If you have an existing install, it can be
'repaired' easily:

zpool import -f bootpool

Yes, I too had noticed this. Figured it was a minor annoyance.

zpool set cachefile=/boot/zfs/zpool.cache bootpool

I'll have to re-test, but I didn't find this to be necessary. After importing
the bootpool and rebooting, I noticed it always came back.

The explanation I told myself was:

1. You boot into the new system
2. You import the bootpool
3. That adds an entry to /boot/zfs/zpool.cache
4. Next time you reboot, that entry is still in there

But what I was trying to figure out was how exactly to get the bootpool
to auto-import into the newline installed system -- I think the above line
you shared shows me precisely how we can accomplish that (I see it
in the patch you submitted).

This will add the bootpool to the existing zpool.cache (which contains
the data for your main pool)

This only applies to users who opted to encrypt their zpool.

Minor nit... not only for geli; now all MBR layouts use a bootpool. I found
this to be required for the edge-case of MBR+NOSWAP (which I fiddled
with for almost a week and got nowhere without using a bootpool).
- -- 
Comment: GPGTools - https://gpgtools.org


The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to