ZFS ZFS on ELI, where is the unencrypted part?

zirias@

zirias@

Developer
Hi all,
maybe a stupid question, if so, that's because I'm a new zfs user ...

I used the automatic way of bsdinstall from 11.0-RC2 to install my new machine on a RAID-Z1 pool over 4 discs with encryption enabled. Now all my discs are partitioned like this:
Code: 
=>        40  7814037088  ada0  GPT  (3.6T)
          40        1600     1  efi  (800K)
        1640         408        - free -  (204K)
        2048     4194304     2  freebsd-swap  (2.0G)
     4196352  7809839104     3  freebsd-zfs  (3.6T)
  7814035456        1672        - free -  (836K)
and I don't see a separate mountpoint for /boot. I wonder -- how does this work? How can the loader read /boot/loader.conf if it's inside the encrypted part?
 
I haven't tried UEFI yet but I'd guess the UEFI boot code is smart enough/has enough functionality to decrypt the pool on its own to locate /boot/loader (which is what it locates to continue booting, not /boot/loader.conf).
 
Huh. There was work being done on getting the UEFI loader to decrypt partitions on its own, but it wasn't supposed to be ready for 11.0. If that's changed, well, I might have to actually upgrade during this release cycle.
 
I digged a bit deeper now ... found the same info (work going on) and some unsettling misconfiguration on my machine. Looks like bsdinstall somehow got it wrong, maybe a bug that was triggered because I had to chose the "restart" option once. :( Listed as encrypted partitions are *p2 (swap) and *p4 (don't exist on my disks). So ATM, only my swap is really encrypted.

Of course, this question is then pointless for now. I'll have to take a snapshot to another machine and restart from scratch.
 
Yep, works now as intended and everything restored right from the installer shell using nc(1) and zfs receive ... bsdinstall created a separate "bootpool" with only /boot on it. I probably hit another bug though, the partition offsets for the encrypted swap partitions in /etc/fstab were all off by one ( *p2 instead of *p3). Well, easily fixed ;)
 
You must log in or register to reply here.
Back
Top