Mount encrypted GELI

Hi! I want to say I really like NomadBSD!

I am currently pondering about migrating to FreeBSD on my desktop and NomadBSD as live-usb for the workplace. On my FreeBSD desktop, I want to access the encrypted live-usb. Now I have been looking at the geli manual, but I am a bit at a loss how nomad BSD is structured

Since I can’t attach the partitions with geli attach, I assume there is some kind of persistent image file that is being mounted?

I’d appreciate some starting directions for a spoiled linux kid that has not looked at the inner workings for over 10 years. :face_with_hand_over_mouth:

Hi @hendrack,

NomadBSD’s data partition is /dev/da0s3a or /dev/label/nomaddata. So you can mount it as follows:

# geli attach /dev/da0s3a
# mount /dev/da0s3a.eli /mnt


# geli attach /dev/label/nomaddata
# mount /dev/label/nomaddata.eli /mnt

Also see 18.13. Encrypting Disk Partitions

Interesting, for some reason:

# geli attach /dev/label/nomaddata
# mount /dev/label/nomaddata.eli /mnt

works, while

# geli attach /dev/da0s3a
# mount /dev/da0s3a.eli /mnt

does not:

# root@freebsd:/usr/home/chris # geli attach /dev/da0s3a
# geli: Cannot read metadata from /dev/da0s3a: Invalid argument.
# geli: There was an error with at least one provider.

That being on an usb stick with a fresh nomad install, just the first reboot after setup.

# gpart show output:

=>       63  250626503  da0  MBR  (120G)
         63       1985       - free -  (993K)
       2048      81920    1  efi  (40M)
      83968    7256064    2  freebsd  [active]  (3.5G)
    7340032  243286016    3  freebsd  (116G)
  250626048        518       - free -  (259K)

=>      0  7256064  da0s2  BSD  (3.5G)
        0     2048         - free -  (1.0M)
     2048  7254016      1  freebsd-ufs  (3.5G)

=>        0  243286016  da0s3  BSD  (116G)
          0       2048         - free -  (1.0M)
       2048  243283968      1  freebsd-ufs  (116G)

Prior to your post I’ve spent quite some time on how to mount the encrypted zfs partition of FreeBSD in Nomad, that I’ve managed. I couldn’t get my head around why it would not work the other way around, since I already tried

# geli attach /dev/da0s3a (and da0s3)

Thanks, though!

glabel uses the last sector to store its label information. If you access the partition via its device name, say da0s3a, you can see that the last sector contains the GEOM label information. The label device, however, doesn’t contain da0s3a's last sector. This makes sense, because it protects the GEOM meta data from being destroyed when writing to the label device. If you now apply geli to /dev/label/nomaddata, the meta data is written to the last sector, which in case of da0s3a is last sector - 1.