0

I have a laptop with what I believed to be basic LUKS single-disk from a fresh 14.04 install. After updating to 16.04, I found my initrd had no LUKS support so I couldn't boot.

The culprit seems to be that my /dev/mapper has no "sda5_crypt" entry but instead dm-0 is linked by the physicald disks UUID. Presumably this is because something in the initrd does the equiv of cryptsetup open /dev/sda5 UUID=xxx (instead of sda5_crypt as the last parm)

$ ls -l /dev/mapper
total 0
crw------- 1 root root 10, 236 Aug  3 13:05 control
lrwxrwxrwx 1 root root       7 Aug  3 13:05 f401322a-1596-47e7-a1c8-844ba27ef326 -> ../dm-0
lrwxrwxrwx 1 root root       7 Aug  3 13:05 ubuntu-root -> ../dm-1
lrwxrwxrwx 1 root root       7 Aug  3 13:05 ubuntu-swap_1 -> ../dm-2


$ sudo sfdisk -l /dev/sda                                                                                                                                             
Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors                                                                                                                         
Units: sectors of 1 * 512 = 512 bytes                                                                                                                                                   
Sector size (logical/physical): 512 bytes / 512 bytes                                                                                                                                   
I/O size (minimum/optimal): 512 bytes / 512 bytes                                                                                                                                       
Disklabel type: dos                                                                                                                                                                     
Disk identifier: 0x000a9196                                                                                                                                                             

Device     Boot  Start       End   Sectors   Size Id Type                                                                                                                               
/dev/sda1  *      2048    499711    497664   243M 83 Linux                                                                                                                              
/dev/sda2       501758 500117503 499615746 238.2G  5 Extended                                                                                                                           
/dev/sda5       501760 500117503 499615744 238.2G 83 Linux


 sudo lsblk
NAME                                     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                        8:0    0 238.5G  0 disk  
├─sda1                                     8:1    0   243M  0 part  /boot
├─sda2                                     8:2    0     1K  0 part  
└─sda5                                     8:5    0 238.2G  0 part  
  └─f401322a-1596-47e7-a1c8-844ba27ef326 252:0    0 238.2G  0 crypt 
    ├─ubuntu-root                        252:1    0 230.3G  0 lvm   /
    └─ubuntu-swap_1                      252:2    0   7.9G  0 lvm   [SWAP]
sr0                                       11:0    1  1024M  0 rom   

On a "normal" install w/ LUKS, /dev/mapper/sda5_crypt would be the link to dm-0. The /usr/share/initramfs-tools/hooks/cryptroot finds this device by name and looks for it as the FIRST column in /etc/crypttab which is what breaks me.

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

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

or

/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.
0

It seems like the root of this problem is using the 16.04 as a rescue CD to unlock/mount/chroot/fix packages/update-initramfs.

If you unlock the LUKS device in the boot CD's unity, it happens to call cryptsetup with the UUID. /usr/share/initramfs-tools/hooks/cryptopen then fails to understand the slightly different naming in /etc/crypttab and decides you don't have a root device w/ LUKS.

The fix is to once again boot into the rescue CD, don't double-click the device in the unity launcher. Run

cryptsetup -v lukeOpen /dev/sda5 sda5_crypt

and proceed with the same mount/chroot/update-initramfs dance.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.