LUKS LVM device mapped by UUID instead of e.g. sda5_crypt

Solution 1:

Blindly answering your exact question

How can I influence the name in /dev/mapper?

Generally speaking, if you were to manually mount the LUKS encrypted hard drive as a separate drive (not the system you're running off of) then the "sda5_crypt" mapped name is declared when you run cryptsetup luksOpen as covener has pointed out.

Since you're booting up from a system that boots and it asks you for the passphrase to continue, this process happens automatically (in the sense that you're not typing the command out yourself) and occurs behind the scenes so the name is declared by the script executing cryptsetup.

So if you want to affect the name, you would simply need to modify the script that runs cryptsetup on boot. And that is found in either:

/usr/share/initramfs-tools/scripts/local-top/cryptroot

/etc/initramfs-tools/scripts/local-top/cryptroot

Which you would just modify using sudo vi or sudo nano to accomplish what you're asking for.

There is likely some textbook lessons on which one should be modified here but I presume a system-wide change would be appropriate and accomplished with the latter. When you're done just remember to run the following command afterward to ensure the changes are applied:

update-initramfs -u

That's it...for your answer. It's also worth mentioning this bug from 2012 that might give good reason for not wanting to change the target name of root in /etc/crypttab

But Here's the Problem!

If your goal was to resolve boot issues, it's important to note that the reference provided above in reference to ls -l /dev/mapper is not quite what you think.

The output of ls -l is simply information about files in a given directory whereas the -l simply tells it to use a long list format. what you're seeing on the right with dm-1 and dm-02 is an indication that ubuntu-root and ubuntu-swap_1 are symbolic links that lead to dm-1 and dm-2 respectively. You can see for yourself by navigating to /dev/mapper to see for yourself:

cd /dev/mapper
stat ubuntu-root

will output something like:

File:'ubuntu-root' -> '../dm-1'
Size: 7              Blocks: 0    IO Block: 4096   symbolic link
...

So what does this all mean?

If you're having boot issues, it might not have anything to do with your /dev/mapper directory at all. You are correct, however, about the usage of the disk's UUID instead of some other mapped name such as "sda5_crypt" though that has very little to do with how you or the system would call upon the partition or would interact with the partition. And actually, when using the UUID, it offers a more robust reference where the system can even see the proper UUID prior to decryption and know that eventually, it will be the root drive it's looking for.

To elaborate, when you ran sudo lsblk above, then based on the output at that moment in time, it is known that your system has already mounted the 2 LVM drives appropriately. It's just that your "sda5" which you are expecting to become "sda5_crypt" after decryption, is what's known as an LVM, or in logical volume management form. So if you saw sda5 how the system sees it now, you'd actually see it as 3 partitions whereas if you ran lvscan it would probably report the partitions as:

/dev/ubuntu/root mounted at "/" (AKA your current root)
/dev/ubuntu/swap_1 mounted as [SWAP] (AKA nowhere but marked as a SWAP device)

Whereas if you hypothetically were accessing it from another system where mounting it at /mnt would represent where you access this drive's root, you would've manually mounted them using a more exact 'device mapping' so-to-speak:

mount /dev/mapper/ubuntu-root  /mnt
mount /dev/mapper/ubuntu-swap_1 /rfs

Notice the difference between the two, and how it is recognized by the system using lvscan and in my hypothetically outside system view, AKA the "physical view" whereas the first would be the "virtual view".

And just for the sake of reference, if you had not decrypted the drive, you would not have been able to see the LVM partitions by its mapped name or even that there were 2 partitions within sda5.

Can't address the problem with the requested answer

Since the system seems to have mounted all the drives properly, it's best at this point to explore other causes of boot-related issues as "LUKS support" is a matter of software and meeting specific minimum hardware requirements, just to be clear.

So to recap, though it seems to indicate the root drive has an association with dm-1, it's actually showing it's a symbolic link for dm-1 and the naming scheme is actually ubuntu-root. If you have a script that calls for "sda5_crypt" then that should be changed in the script rather than attempt to change the whole system.

If you have reason to believe it boot issue is a matter of disconnect, I would check that the UUID is mapped properly in fstab

cat /etc/fstab

and if you're still doubtful, you can check the script for cryptroot's target scheme by using

cat /etc/initramfs-tools/conf.d/cryptroot

As you'll find a line that associates cryptroot with the mapped name and assigns the source using the drive's UUID, similarly to how it's pronounced within fstab.

Notes

Other Useful tidbits for a non-booting system

Running fsck which is most easily done by holding down Esc or Shift while booting up to enter the Grub Menu, selecting Advanced settings, and selecting a recovery mode which will eventually offer a menu to check filesystems, boot files, etc.
Sometimes, a portion of the LUKS header could become corrupted which could render the header useless and thereby the data inaccessible. if you don't have a backup of the header, it may be that the corrupt key used to decrypt the masterkey may have been compromised
dev_mapper can't see the drives until the system runs lvscan as LUKs runs as a container on top of your physical drive using LVM. Hence the need to use a "device-mapper" in the first place.
That is to say that a udev script runs in init-premount to expose sda5_crypt before it finally will be mounted by fstab.