/sbin/cryptsetup: not found on boot after Grub repair - manual mounting works

Asked by Aaron Whitehouse

Hello,

I'm using Ubuntu 16.04.

I recently had to reinstall Windows on a dual-boot machine. That meant that I had to use boot repair to get my Grub back. I now have what seems to be a working Grub, but when I boot into Ubuntu and enter my password into the
"Please unlock disk sda6_crypt", it keeps saying it couldn't mount:
"cryptsetup: cryptsetup failed, bad password or options?"

If I press escape and get to the console output, it says:
/scripts/local-top/cryptroot: line 1: /sbin/cryptsetup: not found
over and over.

If I boot with a Live CD, I can unlock the disk/partition fine with the same password.

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu cryptsetup Edit question
Assignee:
No assignee Edit question
Solved by:
Manfred Hampl
Solved:
Last query:
Last reply:
Revision history for this message
Aaron Whitehouse (aaron-whitehouse) said :
#1

http://paste.ubuntu.com/16443425/
was the output of the boot-repair reconfiguration of Grub.

Revision history for this message
Aaron Whitehouse (aaron-whitehouse) said :
#2

It would be great to get some guidance from somebody on this. I've done a fair bit of reading about related issues, but I'm not entirely sure what the best next step is. Given this has always worked before, I wonder if there is a way to chroot into the Ubuntu installation from a repair disk, or something, and have it regenerate the files I need automatically. I would rather not start trying to manually change /etc/crypttab files or Grub boot options, as it seems likely that could break on an update (if it isn't how Ubuntu normally configures this setup).

For reference, the links I found that could be relevant are:
http://www.faqssys.info/sbincryptsetup-not-found-on-boot/
http://unix.stackexchange.com/questions/178666/sbin-cryptsetup-not-found-on-boot
http://forum.siduction.org/index.php?topic=4901.0
http://blog.nguyenvq.com/blog/2014/07/25/upgrading-ubuntu-12-04-to-14-04-breaks-encrypted-lvm/
Bug #1256730

Revision history for this message
Aaron Whitehouse (aaron-whitehouse) said :
#3

Just to keep track of what I did in case that helps (or I fix it and the steps help others).

1) Boot with Boot Repair Live CD
2) Manually mount/unlock encrypted partitions:
3) Bind together stuff from live system to chroot and then change into my installed system to be able to run commands:
$ sudo mount --bind /dev/ /media/lubuntu/[UUID of mount point]/dev/
$ sudo mount --bind /tmp/ /media/lubuntu/[UUID of mount point]/tmp/
$ sudo mount --bind /proc/ /media/lubuntu/[UUID of mount point]/proc/
$ sudo mount --bind /run/resolvconf/ /media/lubuntu/[UUID of mount point]/run/resolvconf/
$ sudo chroot /media/lubuntu/[UUID of mount point]/

(I left out the resolvconf step at first and had no internet)

Then I'm "in" my installed system:
$ apt-get update
$ apt-get upgrade

I'm hoping that something in one of the updates will trigger a reconfiguration of initramfs or whatever I need for this to work automatically again.

I see in the output of the apt-get upgrade:
Processing triggers for initramfs-tools (0.122ubuntu8) ...
update-initramfs: Generating /boot/initrd.img-4.4.0-22-generic
device-mapper: table ioctl on sda6_crypt failed: No such device or address
Command failed
cryptsetup: WARNING: failed to determine cipher modules to load for sda6_crypt

Will reboot just in case it has fixed itself despite this error.

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

Googling for such error messages I find a forum posting in German, https://forum.ubuntuusers.de/topic/update-initramfs-device-mapper-table-ioctl-fa/

Maybe you have to execute a command similar to
cryptsetup {open or luksOpen} /dev/sda6 sda6_crypt
before
sudo update-initramfs -u -k all

(Disclaimer: disk encryption is not my area of expertise)

Revision history for this message
Aaron Whitehouse (aaron-whitehouse) said :
#5

Many thanks Manfred, that is exactly correct.

In the end, the full list of commands that I typed in the Live CD (boot-repair) to fix this was:
$ sudo cryptsetup luksOpen /dev/sda6 sda6_crypt
Enter passphrase for /dev/sda6:
$ sudo mkdir /media/sda6_crypt
$ sudo mount /dev/mapper/sda6_crypt /media/sda6_crypt
$ sudo mount --bind /dev /media/sda6_crypt/dev/
$ sudo mount /dev/sda5 /media/sda6_crypt/boot/
$ sudo chroot /media/sda6_crypt/
root@lubuntu:/# mount -t proc proc /proc
root@lubuntu:/# mount -t sysfs sys /sys
root@lubuntu:/# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.4.0-22-generic
update-initramfs: Generating /boot/initrd.img-4.4.0-21-generic
update-initramfs: Generating /boot/initrd.img-4.2.0-35-generic
update-initramfs: Generating /boot/initrd.img-4.2.0-34-generic
update-initramfs: Generating /boot/initrd.img-4.2.0-25-generic
update-initramfs: Generating /boot/initrd.img-4.2.0-18-generic
update-initramfs: Generating /boot/initrd.img-3.19.0-30-generic
root@lubuntu:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-22-generic
Found initrd image: /boot/initrd.img-4.4.0-22-generic
Found linux image: /boot/vmlinuz-4.4.0-21-generic
Found initrd image: /boot/initrd.img-4.4.0-21-generic
Found linux image: /boot/vmlinuz-4.2.0-35-generic
Found initrd image: /boot/initrd.img-4.2.0-35-generic
Found linux image: /boot/vmlinuz-4.2.0-34-generic
Found initrd image: /boot/initrd.img-4.2.0-34-generic
Found linux image: /boot/vmlinuz-4.2.0-25-generic
Found initrd image: /boot/initrd.img-4.2.0-25-generic
Found linux image: /boot/vmlinuz-4.2.0-18-generic
Found initrd image: /boot/initrd.img-4.2.0-18-generic
Found linux image: /boot/vmlinuz-3.19.0-30-generic
Found initrd image: /boot/initrd.img-3.19.0-30-generic
done

Booting into Ubuntu then worked as expected and the password unlocked the encrypted disk. I don't know if the update-grub was necessary and in hindsight I would try without it first -- when I rebooted only Ubuntu was in the Grub listing and, once inside Ubuntu, I had to run
$sudo update-grub
again to put Windows back in the list.

Revision history for this message
Aaron Whitehouse (aaron-whitehouse) said :
#6
Revision history for this message
Aaron Whitehouse (aaron-whitehouse) said :
#7

Thanks Manfred Hampl, that solved my question.