# Issue auto mounting geli on boot



## w0rlds (Jan 7, 2013)

Hi,

I have a desktop running FreeBSD 9.1 Release and I am trying to setup an encrypted partition using geli. Currently I boot up the system and I have the geli key on a usb thumbdrive. Everything works great if i mount the usb thumbdrive, init geli and mount the encrypted partition manually once the system is up and running.  


```
#uname -rp
9.1-RELEASE amd64
# mount /dev/da0p1 /mnt/pend/
# geli attach -k /mnt/pend/keyz.key /dev/zvol/zmain/encrypt
Enter passphrase:
# mount /dev/zvol/zmain/encrypt.eli /data/mynoms
# ls -al /data/mynoms/
total 10
drwxr-xr-x  3 root  wheel     512 Jan  6 05:10 .
drwxr-xr-x  3 root  wheel       3 Jan  1 03:24 ..
drwxrwxr-x  2 root  operator  512 Jan  6 05:10 .snap
```

My problem is I can't seem to automate this process on boot.

I recognize I am trying to automate the following on boot: 
Mount the usb drive > have geli decrypt partition using key on usb drive > THEN mount .eli

Do I have a chicken/egg problem? It seems the thumbdrive can't be mounted until AFTER geli is triggered. If I do have a chicken/egg problem is my only solution writing a script that runs on boot or is there some awesome geli commands i can add to /boot/loader.conf to make this work?

I will say as a side note I have looked and tried several of the options for geli in loader with the geli__dev__keyfile0_load options to no joy.

Any input is appreciated, I've been at this for quite a while.


----------



## fonz (Jan 7, 2013)

A very quick question first: did you use the *-b* option when using geli init?

Fonz


----------



## w0rlds (Jan 7, 2013)

yes!

```
geli init -e aes -l 128 -s 4096 -K /mnt/pend/keyz.key -b -B none /dev/zvol/zmain/encrypt
```


----------



## fonz (Jan 7, 2013)

And do I understand correctly that you are _not_ booting from that pen drive?

Fonz


----------



## w0rlds (Jan 7, 2013)

correct. If I could find a way to boot my zfs array afterwards, I'd would be happy to make the necessary adjustments to move /boot to the pen drive.

As an alternative I am considering setting up a jail for this, then the pendrive will mount on the base system, I will make it available to the jail, then the jail will start and pull the key from the pendrive and decrypt/mount the encrypted partition.


----------



## fonz (Jan 8, 2013)

For starters, any geli(8) device created by `# geli init [b]-b[/b] [i]...[/i]` is attached before even the root partition is rw-mounted (which makes sense, because it enables one to use an encrypted root partition). Therefore, if there are any keyfiles involved _at this stage_, they have to be on the partition you're booting from. At this point there's simply no other place where the system can find anything yet. Since you probably don't want the keyfiles on your hard drive for obvious reasons, that means you're left with booting from the pen drive. That is not, however, without disadvantages: to start with it's likely to be (significantly) slower and if you don't set it up carefully you could find yourself in a right heap of trouble should you ever lose the pen drive(*). Further, I am by no stretch of the imagination a ZFS expert so I couldn't say whether ZFS is compatible with a boot-from-stick approach, but judging by how many HOWTOs about geli+ZFS I've seen flash by on these forums it will probably be possible.

However, if the encrypted partition is not essential to system operations (i.e. it's not a critical filesystem like /usr, /var or something), it doesn't necessarily have to be attached and mounted this early in the boot sequence and there are other options.

For instance, you could write a script that goes in /usr/local/etc/rc.d (or simply use /etc/rc.local, although I've been told that the latter is somewhat outdated). A few hints: 
If necessary, see rcorder(8) for how to specify when in the boot sequence the script is to be executed.
If the pendrive has been GPT-partitioned, you might want to use glabel(8) for easy reference.
Don't forget to remove the *-b* flag: `# geli configure -B /dev/whatever` Or just re-run geli init without the *-b* flag and re-run newfs(8) as well.

The jail(8) approach you proposed should work too, but seems somewhat overdone for your problem. It would be a bit like travelling from Los Angeles to San Francisco by Space Shuttle: sure, you'll probably get there and you will have had an interesting ride, but a normal plane would have been cheaper, faster and easier 

Hope this helps, but don't hesitate to follow up.

Fonz

Ad(*): Common "safety" measures are to either make sure you always have a (working and up to date!) backup pen drive and/or to set a second geli key comprised of an emergency password and NO keyfiles (that way you still have a backdoor if you ever lose the keyfile, but if the password is strong enough it won't be easily compromised).


----------

