Ubuntu
initramfs-tools package

16.04 - /usr on own partition + cryptsetup won't boot, initrd issue

Asked by Alessandro Selli

System running:
lsb_release -d
Description: Ubuntu 16.04 LTS

Upgraded from a 15.10.
Beginning 16.04, system cannot boot. Initramd fails at setting up the encrypted /usr partition.
At the (initramfs) prompt the following command is accepted and succeeds at decrypting the partition:

cryptsetup --key-file /root/etc/keys/sda5_usr open --type luks /dev/sda5 sda5_usr

After entering this command and pressing <Ctrl>+<d> to exit the initramfs shell, system boot resumes and completes successfully.
/etc (in the initramd) does not have the crypttab file, which is present in the decrypted and mounted root filesystem in /root/etc.

The problem is present regardless that in /etc/initramfs-tools/initramfs.conf MODULES=most or MODULES=dep is set before generating the initrd.

I tried creating by hand a custom initramfs from the one generated by mkinitramfs, but the kernel fails boot (cannot find and mount root filesystem).

What can be done to have a fully automatic boot of an Ubuntu 16.04 where /usr is sitting on it's own, encrypted partition, like 15.10 did?

I paste the terminal output of the failed boot up to the initramfs prompt:

Begin: Running /scripts/init-premount ... done
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Please unlock disk sda3_ubuntu_root:
[ 120.025413] NET: Registered protocol family 38
cryptsetup: sda3_ubuntu_root set up successfully
done.
Begin: Running /scripts/local-premount ... done.
Begin: Will now check root file system ... fsck from util-linux 2.27.1
[/sbin/fsck.ext4 (1) -- /dev/mapper/sda3_ubuntu_root] fsck.ext4 -a -C0 /dev/mapper/sda3_ubuntu_root
Ubuntu_rootfs: clean, 44092/625056 files, 801590/2499604 blocks
done.
[ 126.996543] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)
done.
Begin: mounting /usr file system ... Begin: Waiting for /usr file system ... Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for /usr device. Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT! UUID=6b18125b-32be-458c-a623-612a14e74eb3 does not exist. Dropping to a shell!

BusyBox v1.22.1 (Ubuntu 1:1.22.0-15ubuntu1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) _

Question information

Language:
English Edit question
Status:
Answered
For:
Ubuntu initramfs-tools Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
actionparsnip (andrew-woodhead666) said : 		#1

Why would you encrypt /usr anyway ?
What does it achieve ?

Revision history for this message
Alessandro Selli (alessandroselli) said : 		#2

What kind of request of information is this?
Encrypting /usr is done exactly for the same purposes filesystem encryption is performed in all the other cases: it protects information, prevents access to the filesystem even were the disk taken off to be inspected/altered on another machine.
Now, any idea why initrd fails at unencrypting it even though I manage to do so at the initramfs command line?

Revision history for this message
actionparsnip (andrew-woodhead666) said : 		#3

Just curious. Seems like a strange thing to do. I can understand an encrypted /var or /home but /usr is strange. That folder simply holds the system binaries that make applications work.

I dont use encrypted file systems myself, and certainly not LUKs. Maybe others can advise

Revision history for this message
Alessandro Selli (alessandroselli) said : 		#4

Please, let's reduce the unnecessary noise. I know very well what /usr is for. I did not ask for advice on the usefulness of an encrypted /usr: I asked why does 16.04 fail at unencrypting an encrypted /usr like 15.10 (and 15.04 before) managed to. It clearly is an initrd issue that was introduced with 16.04, and correcting it would be good, could be helpful for other purposes than just having an encrypted /usr.
I wanted to test putting /etc/crypttab in the initrd filesystem, but doing so by hand produced a wrong initrd and I do not know how I can configure mkinitramfs to do so. If anyone has an idea, please let me know.

Revision history for this message
Manfred Hampl (m-hampl) said : 		#5

Are you running 16.04 or 16.10?

"Upgraded from a 15.10.
Beginning 16.10, system cannot boot"

Maybe the message
ALERT! UUID=6b18125b-32be-458c-a623-612a14e74eb3 does not exist
points towards the cause.

Do you have a partition with such UUID on your system? ("sudo blkid" and/or "sudo lsblk")
Is this UUID referenced in /etc/fstab?

Revision history for this message
Alessandro Selli (alessandroselli) said : 		#6

Sorry for the mistake, I'm running 16.04 (I'm going to correct the OP).
The alert points out that the initrd scripts could not locate the decrypted partition. After I run the command:

cryptsetup --key-file /root/etc/keys/sda5_usr open --type luks /dev/sda5 sda5_usr

this partition (/dev/dm-1, /dev/mapper/sda5_usr -> ../dm-1) does show up. In fact when I exit the initrd shell the boot process pick up again and mounts /usr, decrypts and mounts /home, encrypts and start swap. It's supposed to do everything by itself, /usr included, like 15.04 and 15.10 did before I upgraded.

Revision history for this message
Alessandro Selli (alessandroselli) said : 		#7

Filed bug #1594073.

Revision history for this message
glubsy (greob) said : 		#8

I have the exact same problem. The UUID is clearly wrong, it's the UUID of the mapper partition once it's already unencrypted.
My guess is that grub should somehow be told to decrypt the right partition and set root only once the partition is unencrypted.
Really tricky to pull that of with Ubuntu somehow, much easier to do with Arch Linux. :(

Can you help with this problem?

Provide an answer of your own, or ask Alessandro Selli for more information if necessary.

To post a message you must log in.