cryptsetup removed from initrd.img on upgrade to 13.10

Bug #1237556 reported by vamped on 2013-10-09
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
Undecided
Dimitri John Ledkov

Bug Description

After an apparently successful upgrade from 13.04 to 13.10 (Kubuntu), reboot was requested. My computer failed to boot. Error:
/scripts/local-top/cryptroot: line1: /sbin/cryptsetup: not found.

`lsinitramfs initrd.img-3.11.0-11-generic` does not list cryptsetup

It should have been detected that my filesystem is encrypted, and cryptsetup and associated files should have been placed into the initramfs

I have an encrypted partition, created with `cryptsetup luksFormat`, containing LVM for /root /home and swap.

apt-cache policy cryptsetup
cryptsetup:
  Installed: 2:1.4.3-4ubuntu4
  Candidate: 2:1.4.3-4ubuntu4
  Version table:
 *** 2:1.4.3-4ubuntu4 0
        500 http://us.archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: cryptsetup 2:1.4.3-4ubuntu4
ProcVersionSignature: Ubuntu 3.2.0-54.82-generic 3.2.50
Uname: Linux 3.2.0-54-generic x86_64
NonfreeKernelModules: twofish_generic twofish_x86_64_3way twofish_x86_64 twofish_common serpent nls_iso8859_1 nls_cp437 vfat fat ext2 snd_hrtimer rfcomm bnep bluetooth parport_pc ppdev binfmt_misc snd_hda_codec_via snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi nvidia snd_rawmidi psmouse snd_seq_midi_event snd_seq snd_timer snd_seq_device snd joydev serio_raw lp asus_atk0110 mac_hid soundcore parport snd_page_alloc xts gf128mul dm_crypt vesafb usbhid hid pata_jmicron atl1e usb_storage
ApportVersion: 2.12.5-0ubuntu1
Architecture: amd64
Date: Wed Oct 9 11:10:38 2013
InstallationDate: Installed on 2013-04-25 (166 days ago)
InstallationMedia: Kubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
MarkForUpload: True
ProcEnviron:
 LANGUAGE=
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/usr/bin/zsh
SourcePackage: cryptsetup
UpgradeStatus: Upgraded to saucy on 2013-10-05 (3 days ago)
crypttab: lvm_crypt UUID=0c3f710d-9844-4145-a8f8-465c6d6be4f8 none luks

vamped (robert-strahl) wrote :
vamped (robert-strahl) on 2013-10-09
tags: added: raring2saucy
vamped (robert-strahl) wrote :

/var/log/dist-upgrade/main.log

vamped (robert-strahl) wrote :
vamped (robert-strahl) wrote :
Changed in cryptsetup (Ubuntu):
assignee: nobody → Dmitrijs Ledkovs (xnox)
Dimitri John Ledkov (xnox) wrote :

From term.log:
update-initramfs: Generating /boot/initrd.img-3.11.0-11-generic
cryptsetup: WARNING: invalid line in /etc/crypttab for red-dwarf -
cryptsetup: WARNING: invalid line in /etc/crypttab for red-dwarf -

Can you please paste your /etc/crypttab? Mine looks like this:
sda5_crypt UUID=<UUID_VALUE> none luks

Changed in cryptsetup (Ubuntu):
status: New → Incomplete
vamped (robert-strahl) wrote :

The contents of /etc/crypttab is:
lvm_crypt UUID=0c3f710d-9844-4145-a8f8-465c6d6be4f8 none luks

Dimitri John Ledkov (xnox) wrote :

What's red-dwarf then? Does generating initramfs now, include cryptsetup it in? Are you booted off mounted cryptpartitions?

vamped (robert-strahl) wrote :

"red-dwarf" is a previous LVM PV name. It looks like I have some cruft left over from a previous installation in the file: /etc/initramfs-tools/conf.d/cryptroot. I just deleted it.

I am booted into a backup installation (12.04) on a different hard disk. I am unable / don't_know_how to boot into the updated installation.

I manually mounted the 13.10 (previously 13.04) installation. To generate a new initramfs, i did the following.

I mounted the 13.10 installation at /media/new_root. Then

# for i in /dev /dev/pts /proc /sys /run; do mount -B $i /media/new_root$i; done
# chroot /media/new_root

I added CRYPTSETUP='y' to /etc/initramfs-tools/initramfs.conf

# update-initramfs -u -k 3.11.0-11-generic
update-initramfs: Generating /boot/initrd.img-3.11.0-11-generic
cryptsetup: WARNING: invalid line in /etc/crypttab for XYZ -
cryptsetup: WARNING: invalid line in /etc/crypttab for XYZ -
ln: failed to create symbolic link ‘/tmp/mkinitramfs_162yAK/bin/sleep’: File exists

The errors: "cryptsetup: ..." have been there for years, and have not prevented successful update of initramfs. Last I researched this issue I found no solution. The last error "ln: failed..." is new.

# lsinitramfs /boot/initrd.img-3.11.0-11-generic | grep cryptsetup
yields no results.
# update-initramfs -c -k 3.11.0-11-generic # -c vs -u
fails likewise

vamped (robert-strahl) wrote :

Problem solved.

To install Ubuntu on encrypted partitions, the usual steps are: 1) boot liveDVD and "try" Ubuntu. 2) manually mount encrypted partitions with a cryptsetup command. 3) Launch the installer.

I've always typed something like this:
cryptsetup luksOpen $my_partition WHATEVER

It turns out that the "WHATEVER" needs to match what is in /etc/crypttab -- "lvm_crypt" in mine. I've not done this in the past (because I didn't understand), and have been able to install new Ubuntu versions anyway. Now it is necessary to get it right.

I think matching those words is all that is needed. Adding 'CRYPTSETUP=y' was not needed.

Steve Langasek (vorlon) wrote :

Ok, marking as invalid then. Thanks!

Changed in cryptsetup (Ubuntu):
status: Incomplete → Invalid
Andres Gomez (Tanty) (tanty) wrote :

Just upgraded from 13.04 to 13.10.

Exactly the same problem with "linux-image-3.11.0-19-generic"

# lsinitramfs /boot/initrd.img-3.11.0-19-generic | grep cryptsetup

gives no results

However, I can boot with the older images:

# lsinitramfs /boot/initrd.img-3.8.0-35-generic | grep cryptsetup
lib/libcryptsetup.so.4
lib/cryptsetup
lib/cryptsetup/askpass
sbin/cryptsetup

Regenrating the initrd.img doesn't help:

# update-initramfs -c -k 3.11.0-19-generic
update-initramfs: Generating /boot/initrd.img-3.11.0-19-generic
cryptsetup: WARNING: invalid line in /etc/crypttab for pomeron -
/usr/share/initramfs-tools/hooks/intel_microcode: 136: /usr/share/initramfs-tools/hooks/intel_microcode: prepend_earlyinitramfs: not found
E: intel-microcode: failed to prepend early firmware to initramfs
W: intel-microcode: will try to use late initramfs update mode...

Andres Gomez (Tanty) (tanty) wrote :

OK, I've been able to solve this manually.

I had to add a new line in /etc/crypttab for the LUKS encrypted partition that had my root system. I have another LUKS encrypted partition for my SWAP and /tmp that was already present in /etc/crypttab

In my case, to get the UUID

root@pomeron:~# blkid /dev/sda6
/dev/sda6: UUID="b44fed8d-2a58-4d70-ba19-eaf76c5f1b11" TYPE="crypto_LUKS"

root@pomeron:~# nano -w /etc/crypttab
# <target name> <source device> <key file> <options>
pomeron UUID=b44fed8d-2a58-4d70-ba19-eaf76c5f1b11 none luks
...

root@pomeron:~# update-initramfs -c -k 3.11.0-19-generic
update-initramfs: Generating /boot/initrd.img-3.11.0-19-generic
/usr/share/initramfs-tools/hooks/intel_microcode: 136: /usr/share/initramfs-tools/hooks/intel_microcode: prepend_earlyinitramfs: not found
E: intel-microcode: failed to prepend early firmware to initramfs
W: intel-microcode: will try to use late initramfs update mode...

root@pomeron:~# lsinitramfs /boot/initrd.img-3.11.0-19-generic | grep cryptsetup
lib/libcryptsetup.so.4
lib/cryptsetup
lib/cryptsetup/askpass
sbin/cryptsetup

This was NOT needed before and it seems that the only way of solving this is manually, which is pretty bad :(

Steve Langasek (vorlon) wrote :

If your /etc/crypttab did not include a line for the device that your root filesystem is on, then this is a local configuration error, not a bug in Ubuntu.

Andres Gomez (Tanty) (tanty) wrote :

It actually is a bug in Ubuntu because:

1. The /etc/crypttab was autogenerated during the installation. I never touched it before. The warning was always there.
2. A WARNING, in a file that actually has 1 valid cryptsetup line shouldn't lead to NOT including the cryptsetup tool in the initrd image. It is a WARNING, not an ERROR. That WARNING was not preventing the installation of cryptsetup in the initrd image until I upgrade from 13.04 to 13.10.

On Sun, Mar 16, 2014 at 11:52:11PM -0000, Andres Gomez wrote:
> It actually is a bug in Ubuntu because:

> 1. The /etc/crypttab was autogenerated during the installation. I never
> touched it before. The warning was always there.

In that case, it would be a bug in whatever method you used to install
Ubuntu, yes. Please provide us details on how you installed Ubuntu, so we
can reproduce this error.

> 2. A WARNING, in a file that actually has 1 valid cryptsetup line
> shouldn't lead to NOT including the cryptsetup tool in the initrd image.

Yes, it should. It was a bug that we were unconditionally installing
cryptsetup to the initramfs before for all users that had cryptsetup
installed, bloating the initramfs and slowing down their boot. This bug has
now been *fixed*, and in the process it has exposed a problem with your
system. That may, as you say, also be a bug in the Ubuntu installer; but
that is NOT grounds for restoring the previous buggy behavior.

lostboy1 (brett-blzj) wrote :

I too ran in to a problem after upgrading a luks full disk encrypted 12.04.5 system to 14.04.1. After successfully upgrading, upon reboot I was asked for the luks password for the root system. After entering the password, I see sever errors including "/sbin/cryptsetup not found".

After doing research I came across bug https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1256730. After booting from a rescue cd, creating the file in comment #4 and updating the initrd, the cryptsetup could be found in the initrd.

Another reboot and all was good.

Serhiy Zahoriya (xintx-ua) wrote :

How can I get the name that was automatically assigned to the volume (as in 'sda5_crypt') ?
I've lost my cryptsetup.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers