1

After reducing the size of /root volume of an encrypted partition using lvm, I get this error when ubuntu boots:

cryptsetup: cryptsetup failed, bad password or options

The partition itself is fine. I can open the encrypted container, and mount and browse the file system, if I go in manually from a live usb.

I reduced the size of root using the steps given in these guides:

https://ubuntuforums.org/showthread.php?t=726724
https://help.ubuntu.com/community/ResizeEncryptedPartitions
https://askubuntu.com/questions/262211/how-do-i-resize-an-encrypted-lvm-to-install-another-copy-of-ubuntu

Since the resize did actually work, it is not strictly necessary to show what steps I took to do the resize. But I replicate them here for assurance, and the possibility that they are the source of the error.

(I also renamed the logical volume group, for ease of typing, from ubuntu-studio-vg to sys-vg).

Steps I took to reduce the volume size were as follows:

sudo cryptsetup luksOpen /dev/sda5 bonse
sudo e2fsck -f /dev/mapper/sys--vg-root
sudo resize2fs -p /dev/mapper/sys--vg-root 150G
sudo e2fsck -f /dev/mapper/sys--vg-root
sudo lvreduce -L 150.1G /dev/sys-vg/root
sudo lvremove /dev/sys-vg/swap_1
sudo pvresize --setphysicalvolumesize 158.2G /dev/mapper/bonse
sudo lvcreate -L 8G -n swap_1 sys-vg
sudo mkswap -L swap_1 /dev/sys-vg/swap_1
sudo mount /dev/sys-vg/root /mnt
sudo umount /mnt
sudo pvchange -c n /dev/mapper/bonse
sudo cryptsetup status bonse

Last statement gives:

...offset: 4096 sectors ...size: 624136192 sectors

Then:

sudo cryptsetup resize --size 309082032 bonse
sudo vgchange -an
sudo cryptsetup luksClose bonse
sudo fdisk /dev/sda

In fdisk:

  • deleted sda5 and sda2
  • created new sda2 as an extended partition: size +159G
  • created new sda2 as an extended partition: size +159G
  • created new sda5 as an extended partition: size +158.9G
  • changed sda5 partition type to '8e: linux LVM'

Finally, edited /mnt/etc/fstab mousepad, initially replacing the root and swap devices so that references to ubuntu--studio--vg were replaced with sys--vg. But this didn't work. So I changed the device references to UUID=< and used the LV UUID given for each volume by lvdisplay >.

The result, to recap, was error on boot. But still able to open, mount and read the drive manually.

  • 1
    Try recreating your initramfs - update-initramfs -c -k – Panther Jan 11 '18 at 15:25
  • Thankyou, @Panther. I ran: "sudo /mnt/usr/sbin/update-initramfs". That gave an error: "cryptsetup: ... failed to detect canonical device of aufs ... cryptsetup: ... could not determine root device from /etc/fstab". – markling Jan 11 '18 at 22:40
  • can you post /etc/crypttab and /etc/fstab ? – Panther Jan 12 '18 at 7:54
  • Unfortunately not, coz I since overwrote the installation with a new one. Your initramfs question helped. Poking around, I found grub.cfg still referenced the old lv name: ubuntu-studio-vg. This may be the source of the problem. But it also suggests there may be other places where my lvrename has created a need for a manual fix. And since grub.cfg says "DO NOT EDIT THIS FILE", and grub is frighteningly arcane and (when I've looked in the past) dreadfully documented, seemed easier to start again. I will confirm, but I suspect the procedure will work when I do it again with default lv labels. – markling Jan 12 '18 at 10:51
  • ('twas not lvrename, but vgrename) – markling Jan 12 '18 at 11:04
1

The problem was that I had used vgrename to change the name of the volume group.

This had seemed sensible because (notwithstanding cut-and-paste) the default ubuntu-studio-vg is a pain to type. So I changed it to sys-vg.

But the rename did not cascade throughout my system settings. The lv documentation gave no warning. Nor did it report the necessity of the change being cascaded. Nor where else it might need to made.

There are two places at least: /etc/fstab and /boot/grub/grub.cfg

  • The lesson is: don't vgrename. – markling Jan 12 '18 at 13:10

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.