LUKS + BTRFS + unencrypted /boot partition made by manual partitioning = unbootable system #2281
Comments
|
Can we the full install log? |
Is this a typo because we create a file called Assuming it is a typo, I am not sure I see anything obvious that would cause this. What does the |
|
Oops, yes it is a typo. It's looking for In case it's helpful, I actually can get the system to boot once I'm at the initramfs prompt by typing Here are the contents of |
|
Looks like the crypttab is looking for the keyfile. Looking at |
|
OK, so I did a bit more digging by patching the fstab module's This gave me a very messy line of debug output that I formatted nicely: Looks like the BTRFS partition isn't recognized as being mounted on |
|
Also, here's the VM's fstab: https://termbin.com/6dvt |
|
The btrfs partition actually should have a mountpoint of From your debug output, it looks like something in the fstab main.py is modifying the |
|
The issue here is that BTRFS subvolumes are akin to separate block devices for As @ArrayBolt3 shows in the additional debug output That then breaks the tests in The attached patch should show what is happening |
Not really. The way Calamares handles btrfs is that it applies the subvolume layout to the partition assigned to However, from the looks of the debug output, |
|
This is probably the issue: https://github.com/calamares/calamares/blob/calamares/src/modules/fstab/main.py#L204 I can fix it this weekend unless someone wants to PR it before I get to it. |
|
Although there is a logic problem with the code of course, the Using the Lubuntu 24.04 amd64 installer ISO in a virtual machine I followed the reproducer instructions several times, with debug logic added to report the BTRFS items and the state of Although that shows the partition being modified by each of the BTRFS subvolumes and ending up with its Extracts from the "bad" ( "Bad": And the "Good": Now, the only way I managed to reproduce @ArrayBolt3 scenario was when I re-ran the installer and in the manual partitioning step kept the existing partition #1 and forgot to set its mount point to |
|
@iam-TJ The bug isn't that the keyfile is not generated - the keyfile should not be generated because /boot is unencrypted. The bug is that the system looks for one anyway. I was able to reproduce this reliably in virt-manager, so I'm not sure what I'm leaving out on accident. I can try to take a video of the process. Just to be doubly sure, you do see a picture of a numbat (looks like a brown stripey squirrel with a long face) on the desktop when you first boot the ISO, right? Just making sure you're booting the right ISO. |
Oh - good point! I've been so fixated on the installer-time logic I neglected the second issue - that of the |
When using BTRFS multiple subvolumes exist and whilst iterating them the partition["mountPoint"] is inadvertently changed due to taking a reference rather than a copy. Closes: issue calamares#2281
|
I'm about to run a "bad" reproducer to confirm the |
|
Just noticed another issue, slightly cosmetic, that has caught me out several times now. When doing manual partitioning and there is an existing partition and I choose to Edit it, and I change the format option from "Keep" to "Format", if after saving the edited changes one returns to edit it again the formatting option again shows "Keep" - making one think the previous change didn't save. I did this several times before continuing and then saw in the Install summary actions list there were four entries for formatting partition #1 ! It would be good if saved changes were reflected in the radio button selection rather than defaulting to "Keep". |
It would also be good if the action wasn't in the summary 4 times (and potentially executed 4 times). We should probably track that in a different issue though. |
Indeed - on my ToDo list but wanted to note it before I forget! As for the "bad" run and the generated |
|
I would even classify the formatting issue as a potential data loss bug! Just think of the use case where one accidentally selects "Format", then goes back to switch to "Keep", but the partition gets formatted anyway… bye bye data! |
|
Just verified that the patch from @iam-TJ does indeed fix this in production. Thank you! |
Please note that I am not using patches to enable automatic creation of an unencrypted /boot partition to trigger this bug. This should be reproducible using a vanilla Calamares and manual partitioning.
Describe the bug
When using manual partitioning on Lubuntu 24.04 Alpha, it is possible to set up a partition layout as follows:
/boot/Installing with this partition layout succeeds, but the resulting system fails to boot. Instead, an error appears on the Plymouth screen from
cryptsetupstatingbad passphrase or options?, then soon another error appears stating that the maximum number of passphrase input attempts has been reached. HittingEscreveals that the system is attempting to read from a non-existent file/crypto_keysetup.binin a loop. After probably thirty or forty seconds of this, the system drops to an initramfs prompt.To Reproduce
Steps to reproduce the behavior:
/boot, and enable thebootflag.Encryptbox and type a password, and set the mount point to/.Expected behavior
You should be asked on the Plymouth screen for the passphrase you typed earlier, and providing that passphrase should result in the system booting properly.
Additional context
This does not occur if you follow the reproduction steps but set the root partition's filesystem to
ext4rather thanbtrfs. Something about usingbtrfstriggers this.It looks like the initramfs is looking for a crypto keyfile that was never generated and thus feeding a blank (and incorrect) password into
cryptsetup. Indeed, the crypto keyfile should (and even must) be absent so as to avoid bypassing encryption entirely with an unencrypted /boot partition - the bug is that the system is looking for it and attempting to use it even though/bootwas left unencrypted.This was first encountered while attempting to install Kubuntu using a patched Calamares to allow unencrypted
/bootto be used with automatic partitioning. However, the above steps do not require the extra patches to reproduce.The text was updated successfully, but these errors were encountered: