compreview-nbde - Can't mount via UUID

[Rilindo]

I completed the lab, but I found something that may be a problem in real life.

Going through the exercise, I decide to mount via UUID, as that is a good practice. So my crypttab would look like this:

storage UUID=4a7f1af2-2024-43eb-9e70-30f7be69f8f3 none _netdev

And my fstab looks like this:

UUID=058645b7-00e5-496d-9989-aef0b53d692e /encrypted xfs _netdev 1 2

The expected behavior is that I am about to open the encrypted volume, and I can mount it on /encrypted.

What happens is that the encrypted volume doesn't appear on boot, and it doesn't get mounted onto /encrypted.

What is odd is that if I specify the device mapper path but leave the UUID parameter in /etc/crypttab, then I can mount on boot.

I ended up specifying the device path for both configuration files since I need to have a consistent solution in my exam, but this bugs me—what would cause this behavior? Is it possible that if I were to specify the UUID in both configurations, I would need to re-run dracut (which basically means that I need to re-run the ansible-playbook)?

[Karim_Expert]

<name>    <device>   none

The <device> field should be given in the form "UUID=<luks_uuid>", where <luks_uuid> is the LUKS uuid as given by the command cryptsetup luksUUID <device>. This ensures the correct device will be identified and used even if the device node (eg: /dev/sda5) changes.

[Chetan_Tiwary_]

@Rilindo after @Karim_Expert 's suggestion - is it resolved for you now ?

[Rilindo]

I need to test, but the UUID returned by *blkid* (where I got the UUID) is the same as the one returned by *cryptsetup luksUUID <device>*. Is there any reason the UUID I used in *blkid* wouldn't be valid? Furthermore, I can create the mapper with the UUID from blkid. I can't mount it on boot (using the UUID generated when I formatted the file system on the storage.

[Rilindo]

So no, not resolved yet. I can confirm that it is not a lab issue, because I was able to reproduce it on my own personal lab. It is pretty consistent. This is a working setup:

1. Setup LUKS on /dev/vdb1
2. Update /etc/crypttab to setup /dev/mapper/storage
3. Update /etc/fstab to mount /dev/mapper/storage on to /encrypted
4. Reboot
5. Confirm that /encrypted is mounted

It breaks completely once I do the following:

1. Update /etc/fstab to use UUID.
2. Reboot
3. Confirm that not only is /encrypted not mounted, but also that /dev/mapper/storage device is not created. It is as if /dev/mapper/storage could not be instantiated if fstab is not configured to mount /dev/mapper/storage.

It feels like a bug was introduced in RHEL 9, but it's not documented. I will have to fuss around with it and do some digging.

I guess the takeaway is that to be safe, use the full device map in both places, at least for exam prep purposes.

[Travis]

@Rilindo -

I suspect you are getting the UUIDs confused. UUIDs are unique and are created for "formatted" filesystems. So what is confusing is that you will have essentially 2 UUIDs for a LUKS encrypted filesystem. One for the "LUKS FORMAT" version (encrypted) and one for the actual filesystem (unencrpyed). Unfortunately, it isn't quite as clean maybe in the guided exercise because we are using DevMapper and names rather than the UUIDs.

So you need to ensure if you are trying to mount things automatically with UUIDs on boot that the correct items end up in the correct files ... meaning the right UUID in the Cryptab because that is the LUKS formatted UUID (the one needed for unlocking the encrypted device) and then in /etc/fstab, the UUID of the "unencrypted/unlocked" device because /etc/fstab is the the filesystem UUID or filesystem name.

Also in terms of "good practice" it is perfectly fine to mount by the LUKS device mapper names because those would be unique. This isn't to get confused with the regular devmapper names of /dev/vda1 /dev/sda1, etc, where boot order might enuerate things differently. You are selecting a unique Device Mapper name when you create a LUKS filesystem. Just like another good practice could be mounting by filesystem labels which are again "unique" and not determined by boot order. Mounting by UUID is a very good thing and it is used quite often, but sometimes it is hard to remember which UUID to use in which location.

One thing that could potentially help illustrate this is to take a blank disk and just partition it. With a couple partitions. Then run the lsblk command and get the UUIDs and see what is there. Most likely you won't see anything. Then format one of the new partitions and run the command again, making note of the UUID. Then format the same partition again, and make note of UUID (feel free to try XFS, EXT3, whatever else) and notice how the UUID changes. 

Now review how LUKS works ... first thing you do is a "Cryptsetup LUKSFORMAT" to create an encrypted partiion. You can do a LUKSDUMP to get data now (think UUID). Compare that with the raw device UUID. Keep in mind, you must use a LUKSOPEN to open the disk and on first use, you are "formatting" that disk and giving it the unencrypted filesystem. Now try getting UUIDs again.