Why does luks data partition fail to mount from fstab/crypttab entries?

Ask Fedora
1

I have recently begun moving my boxes from parrot os to fedora (40) because I want better security that SELinux promises. During install, I deleted all partitions except a 9TB luks data partition (sda5).

Fedora installed fine, but when I add entries in /etc/fstab: UUID=56ec7d8d-1fed-4e16-831c-0b275ffd89db /mnt/home71 ext4 defaults 0 0

and /etc/crypttab: luks-56ec7d8d-1fed-4e16-831c-0b275ffd89db UUID=56ec7d8d-1fed-4e16-831c-0b275ffd89db none discard

to mount the luks data partition during boot, prompting me for a password during boot to open the luks partition, a mount -a command fails with: mount: /mnt/home71: wrong fs type, bad option, bad superblock on /dev/sda5, missing codepage or helper program, or other error.

I have no problem manually mounting the luks data partition using: cryptsetup luksOpen /dev/sda5 home71; mount /dev/mapper/home71 /mnt/home71

and after being manually mounted, a lsblk -o name,fstype,label,uuid,mountpoint command returns:

├─sda5 crypto_LUKS 56ec7d8d-1fed-4e16-831c-0b275ffd89db 
│ └─home71 ext4 06e81132-ec1f-4685-bd73-be91c2d2b7bc /mnt/home71

I dont know why I am having such issues as I’ve set luks data partitions to mount this way plenty of times before.

I am starting to wonder if maybe by keeping the luks data parition when installing fedora (I have been using debian distro variants for the past 15 years), while deleting all of the other system partitions and re-partitioning that somehow the system can’t recognize the previously encrypted partition, even tho it can be manually mounted?

I have already flipped two other boxes from parrot os to fedora 40 with a similar layout and no issue; all of the luks partitions are opened and mounted during boot. However, the luks data partition in those two cases were formatted and encrypted during the install process and not prserved from the previous install running parrot os., like this time.

BTW, I have of course tried mimicing the fstab/crypttab from those other two boxes, using the UUID of the luks part in this box of course, but the partition continues to fail mount -a regardless of the variation of details I have tried in both config table files.

Additionally, when running command $ lsblk I get a snapshot of my current disk’s partition setup.

$ lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                                             8:0    0   9.1T  0 disk  
├─sda1                                          8:1    0     1G  0 part  /boot
├─sda2                                          8:2    0   512M  0 part  /boot/efi
├─sda3                                          8:3    0     8G  0 part  [SWAP]
├─sda4                                          8:4    0    30G  0 part  
│ └─luks-e4d6a6b0-6889-4317-b13e-4cfad6f37f4b 253:1    0    30G  0 crypt /var
├─sda5                                          8:5    0   8.9T  0 part  
└─sda6                                          8:6    0 164.6G  0 part  
  └─luks-bfb67d91-aa41-40b1-81e9-b480e563a93e 253:0    0 164.6G  0 crypt /

The information listed for /dev/sda5, the luks data partition in question, shows less details than I would expect. I would would think TYPE column should list the partition as crypt and not jusy part, almost like the system doesn’t see /dev/sda5 as a luks_crypto partition, unless I manually feed it the info to luksOpen and mount it.

I really don’t want to have to wipe and delete the partition in order to try re-partioning and re-encrypting just to test if that works because I have a lot of data already on the partition (although it is backed up), and I just don’t want to have to re-rsync it all unnecessarily. So I hope someone can maybe see something obvious I am overlooking here and save me and my HDD some time and wear and tear. Thks.

2

Shouldn’t the UUID in /etc/fstab be 06e81132-ec1f-4685-bd73-be91c2d2b7bc?

BTW, welcome to :fedora: .

3 Likes
3

Thnks for the reply. I did try using the ext4 fs UUID in fstab instead of the luks UUID. No change. Is the ext4 UUID available to at the time during boot when fstab needs to process it? It makes sense that it would be since the filetype in fstab cannot be luks_CRYPTO.

4

Shouldn’t the luks option be there in /etc/crypttab?

Also, I don’t think mount -a should work since the partition might be yet unencrypted in your example.

1 Like
5

I have recreated your setup in a virtual machine, with the only differences that:

  • I have encrypted an entire disk (should make no difference);
  • After creating the mount point, I have changed owner (chown) to the current user;
  • In /etc/fstab the UUID is of the decrypted disk, as mentioned in my post above.

With this setup, during system startup, I was prompted for the LUKS passhprase, and in the user’s session the encrypted disk was successfully decrypted, mounted and accessible.

You might want to check your logs after some error messages (e.g. with journalctl -b -g crypt).

2 Likes
6

Hey Mike,

Yes it works as it should. Stupid me, I never actually rebooted to test out any of the variations I tried, including the fs UUID instead of the luks UUID in /etc/fstab. I would have swore sudo mount -a actaully reads crypttab and fstab the same as during boot and prompts for a key for any luks_CRYPTO partitions to decrypt.

Anyway it is working as it should, and I sure appreciate you hanging in there and even spinning up a VM to help out. Thks.

1 Like
7

Happy to hear the issue is solved. I did consider at a certain point that you might not have rebooted, but I thought I’d rather refrain from asking “did you plug in the appliance” kind of questions.