Solved Just one question about /boot

I have two machines that run root on ZFS. I noticed only yesterday while upgrading both to 11.1R-p2 that on one of the machines /boot is just /boot, a directory. On the other machine /boot is a symlink to bootpool/boot. Each has only one pool, that covers the entire 2-disk mirror. Both run beadm.

I don't recall any differences during the installations although I might certainly have chosen something during install (from CD). All the ZFS related options appear to work fine and both survive pull-the-plug-repeatedly tests without issue. Pretty annoyed with myself that I did this and didn't see it for so long. Nothing critical, "just" my home machine and a file server.

Is this something I should/can change and can it be done without a re-install? And how might I have done this?

thanks,
s-a
 
Yes! Didn't even think of that, probably it never occurred to me that encryption would play a part in this. But of course it must because the hardware would need to read un-encrypted data if it was to read any data at all. Under my nose...

Thanks!
s-a
 
Yes! Didn't even think of that, probably it never occurred to me that encryption would play a part in this. But of course it must because the hardware would need to read un-encrypted data if it was to read any data at all. Under my nose...

Thanks!
s-a

If you read the manpage for geli you'll see that you can have the whole thing encrypted... just specify -g at creation time, I think... maybe you can even set this right now without changing anything else...

I think running an OS where everything is encrypted except the kernel and its modules is pretty weak... almost not worth it, actually...
 
I think running an OS where everything is encrypted except the kernel and its modules is pretty weak... almost not worth it, actually...
There's a "chicken and egg" problem. You can't read the disk because it's encrypted. Therefor you can't read the kernel. How is a system supposed to boot?

So the kernel must be on an un-encrypted part in order for it to load. Once the kernel is loaded the rest can be decrypted.
 
There's a "chicken and egg" problem. You can't read the disk because it's encrypted. Therefor you can't read the kernel. How is a system supposed to boot?

So the kernel must be on an un-encrypted part in order for it to load. Once the kernel is loaded the rest can be decrypted.

Well, I'm not sure how it works, but the latest manpage for geli says that when you create an encrypted drive with it, you can either create an unencrypted partition like we used to have to do, or there's a flag where GELI will ask for a password before the kernel is loaded... I don't have any unencrypted partitions on my boot drive...

-g Enable booting from this encrypted root filesystem. The boot loader prompts for the passphrase and loads loader(8) from the encrypted partition.​
 
This is done by loader(8). Which needs to be on an un-encrypted partition or else it cannot be loaded. How else could you load loader(8) and loader.conf(5) if they are on an encrypted partition? Same chicken and egg situation.

I don't know! I'm just telling you how it is.... Like when I boot, it asks me for a password, I put it in, then it says it's calculating the key, then loader runs, it says which BIOS drives are what devices, then it calculates another key, then it runs init...

Maybe you could try with a USB key or something, just put dd some live image to the dev.eli descriptor and try to boot... I've been compiling Firefox for three days now...
 
Back
Top