LVM Full Disk Encryption - Non Bootable - Initramfs Decoding Error (Dell XPS 15)

[genbushi]

Installation:

LM 20 Beta, Cinnamon. Fresh beta iso install on Dell XPS 15 9570 with disk fully shreded before install. Advanced Option -> LVM Full DIsk Encryption Install completes successfully.

Problem:

On boot. initiramfs fails to decode error, no decryption screen prompt, drops to initiramfs shell. It appears LVM partitions not full created properly. Replicated 3 times on fresh install. System is bootable if not using LVM full disk encryption.

Workaround:

Do not use full disk encryption. System is then bootable after installation. Re-install LM 19.3 with LVM Full Encryption. Initiramfs decoding failed aspect may also be related to Ubuntu upstream known initramfs bug.

[saraaba]

Reference this for the manual steps https://forums.linuxmint.com/viewtopic.php?t=228836

Just a side note: If it is not possible to have custom LVM partitions on LUKS, Mint will not be on any of my machines

As long as the installer uses MY LVM partition structure and LUKS containers, it is good, I can do them via the command line and my own tools as before and after installation steps.

[genbushi]

agreed, ty for reference, i do a similar custom install myself. However for "standard" install testing purposes, the expected behavior is that clicking Advanced -> Use LVM with Full Disk Encryption button and options should result in a booting system as it always has in the past.

[themotu]

I see the same thing can't find volume group "vgmint"

[clefebvre]

We're missing something here.. cause it works for me and it passed QA..

It works for me with the following:

• Virtualbox in BIOS mode
• HDD already existed (used to install in various different modes without LVM)
• No media codecs
• Erase entire disk
• Advanced options: Use LVM, use full disk encryption, do NOT wipe the entire drive.

We're probably looking at a niche case bug here... i.e. a bug which only happens in some particular circumstances.

Usual suspects are:

• EFI mode
• Secureboot
• Media codecs (unlikely but they do go through a different code path)
• Option to wipe the drive
• Using a brand new HDD with no partition table
• Using an HDD with an already existing LVM structure (very likely)

When working on LMDE 4 we bumped into cases where the installer failed to create the LVM structure because there was one in place already and the partitioning tool just didn't want to do anything after removing it until the next reboot.

When installing Mint 20 BETA, early in the installation, one of the first things the installer will do is create the LVM structure.. you can use sudo lvs and sudo vgs to monitor that.

[clefebvre]

2nd install with same settings works fine.

[clefebvre]

3rd install, same settings except, media codecs and overwrite empty disk space selected.. successful.

[clefebvre]

4th install, same as 1st and 2nd, but using EFI instead of BIOS. Successful as well.

[genbushi]

interesting, i'll try to check it out again, this is a bare metal install where it's not finding vgmint volume on reboot. no issues with prior versions or other distros to date on it. see if i can track it down further this weekend, ty

[genbushi]

Did another attempt with same non-booting results, grabbed some output. While the initramfs decoding failure is likely a red herring and an upstream issue, the root cause of it not being bootable is also similar to Issue 139 which is a Lenovo lap with almost identical hardware.

Reverting back to another LM 19.x or any other distro is fine.

LVM output and some bad mobile screenshots:

mint@mint:~$ ## pre-install
mint@mint:~$ 
mint@mint:~$ sudo lvs
mint@mint:~$ sudo vgs
mint@mint:~$ 
mint@mint:~$ 
mint@mint:~$ sudo lvs
mint@mint:~$ sudo lvs
mint@mint:~$ sudo lvs
  LV     VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root   vgmint -wi-ao---- 474.75g                                                    
  swap_1 vgmint -wi-ao---- 980.00m                                                    
mint@mint:~$ sudo vgs
  VG     #PV #LV #SN Attr   VSize    VFree
  vgmint   1   2   0 wz--n- <475.71g    0 
mint@mint:~$ 
mint@mint:~$ 
mint@mint:~$ ## install successfully complete
mint@mint:~$ 
mint@mint:~$ sudo vgs
  VG     #PV #LV #SN Attr   VSize    VFree
  vgmint   1   2   0 wz--n- <475.71g    0 
mint@mint:~$ sudo lvs
  LV     VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root   vgmint -wi-a----- 474.75g                                                    
  swap_1 vgmint -wi-ao---- 980.00m                                                    
mint@mint:~$ sudo fdisk -l
Disk /dev/loop0: 1.74 GiB, 1854644224 bytes, 3622352 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

Disk /dev/nvme0n1: 476.96 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: PC401 NVMe SK hynix 512GB               
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: gpt
Disk identifier: ACA5FD5D-9621-430E-88D9-978AB335E169

Device           Start        End   Sectors   Size Type
/dev/nvme0n1p1    2048    1050623   1048576   512M EFI System
/dev/nvme0n1p2 1050624    2549759   1499136   732M Linux filesystem
/dev/nvme0n1p3 2549760 1000214527 997664768 475.7G Linux filesystem

Disk /dev/sda: 14.47 GiB, 15522070528 bytes, 30316544 sectors
Disk model: Cruzer Glide    
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: 0x366b3ed5

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sda1  *          0  3855295  3855296  1.9G  0 Empty
/dev/sda2           648     8583     7936  3.9M ef EFI (FAT-12/16/32)
/dev/sda3       3858432 30316543 26458112 12.6G 83 Linux

Disk /dev/mapper/nvme0n1p3_crypt: 475.73 GiB, 510787584000 bytes, 997632000 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

Disk /dev/mapper/vgmint-root: 474.77 GiB, 509758930944 bytes, 995622912 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

Disk /dev/mapper/vgmint-swap_1: 980 MiB, 1027604480 bytes, 2007040 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

[clefebvre]

@genbushi yes, you're right, the decoding/decompressing of the initram is a warning, we get that on successful boots and it's reported upstream as well.

In your screenshots, I don't see any failures related to LVM... vgmint seems to be properly created. At boot time it doesn't complain about it, it complains about ACPI.

Are you able to install without LVM on this computer?

[genbushi]

yes, agreed, the BIOS and ACPI stuff is not an issue - my bad for bad naming on issue. I was initially thinking the initramfs decoding failure was an issue until i saw all the upstream issues.

Are you able to install without LVM on this computer?

Indeed. If not using LVM w/encryption with LM20 beta I can successfully boot, and LVM w/encryption works fine with LM19.3 or any other Ubuntu, Manjaro, etc. . It's somehow LVM or maybe cryptsetup related, just not sure exactly where, lol. If I try to boot in to a recovery mode it'll fail due to not being able to find the root file system and /dev/mapper/vgmint-root not existing. If i can assist somehow let me know

[genbushi]

wait... is there a typo on the grub linux line? it's failing not finding vgmint-root but the config almost looks like vqmint-root with a lowercase Q - or maybe that's just different font rendering?

Update: that is just rendering apparently.. false alarm :)

Update 2: i think i have a few workarounds, standby...

Update 3: still no joy with LVM and full encryption. I thought I had some steps to correct post-install, but end result was same. As you noted previously, this must be a niche issue, but I'm unable to pin it down, and it sounds like no one has been able to replicate. I'll have to either remain on LM 19.3 for the time being (LM has been my fav work daily driver since Cinnamon rolled out) or dive in again.

We can close this out, we have the attached info/captures if it needs to be referred to. Thanks for you your time & input.

[clefebvre]

You too @genbushi, it's a shame we couldn't find the cause. I see some people on the blog giving similar feedback, but again, they don't have the cause.

If we get analysis post-stable we can issue an update for the installer and add a note in the release notes to let people know. I'm not sure what to do in the meantime, it just doesn't fail for me.

[clefebvre]

Fresh install on real hardware, EFI+Secureboot, works correctly.

[clefebvre]

Possible explanation: https://github.com/linuxmint/mint20-beta/issues/186

[genbushi]

That makes a lot of sense, i never use a connection when installing - and one of the workarounds I was trying post-install was trying to regenerate initramfs and cryptsetup via chroot, but was missing the package, excellent catch! Will try and confirm today, ty

[genbushi]

SOLVED