Please help with a partitioning scheme (unable to install with LUKS)

[kubuntu-love]

Hi,

I want to install Kubuntu 24.04.1 LTS on my NVME disk.

Here is my table (GPT):

1. 8 MiB - unformatted, flag: bios-grub *
2. 512 MiB, FAT32, /boot/efi, flag: boot
3. 1024 MiB, LUKS EXT4, /boot **
4. 64000 MiB, LUKS EXT4, /

Unfortunately, after installation I immediately fall into Grub console, and boot process stops.

Notes:
* - Calamares suggests creating unfmatted 8Mb partition to support GPT loading
** - It's nice that the Calamares installer offers me to encrypt /boot partition in addition to / one, and off course I use this option.

Please review my partition table and advice me how to change it to finish installation. I need as high level of encryption as it is possible. Secure Boot is enabled.

[Princey]

Question is why dedicate only 1GB for boot? What's the total size of your drive? 128GB? Only when we know the total size capacity can a suitable layout be advised.

[kubuntu-love]

Princey, do you suppose that Linux can't start from /boot partition that is just 1Gb?

As I know the recommended size of /boot partition is below 1Gb.

To be honest, I would prefer to keep /boot on the same partition / is located on. But I tried this way too, it doesn't work as well.

My disk total size is 4Tb (unused at installation stage space I will manually format into a seaparated encrypted partition), so please advice any reasonable sizes.

[jglen490]

Here's mine. Now, I don't use LUKS, but that's really not an issue. I'm not sure why there are any flags on the 2MB, unformatted leading blank space.

So anyway, all individual partitions (partition sizing approximate): Leading blanks 2MB, ESP /boot/efi (w/flag) fat32 300MB, / ext4 42GB, /home ext4 760GB, SWAP 16GB. The only differences between this and the OP would likely be how / and /home are treated under LUKS. Been using this layout for a long time - stable, flexible, and isolates OS and my data from each other (EDIT: for Backup and Restore purposes).

[claydoh]

I'm not sure why there are any flags on the 2MB, unformatted leading blank space.

There shouldn't be, and to be honest I think that space for the GPT is left behind when creating the file system iirc.
I have not once ever, never ever manually created any blank space, ever, and definitely not set a bios-grub flag.

FDE does need different requirements, but not sure if /boot being 1Gb is more than enough (too much), unless it is shared be different OS installs maybe.
My entire /boot with 2 kernels is ~200mb. I am probably missing some parts, and I don't use encryption - a major pita and somewhere does break every damn time. Like last week.

I set my /boot/efi to 100mb and ignore Calamares' complaints about it since I don't dual boot, or rather when I do, it is on a separate drive.
The reason Calamares wants 300 is that ESPs being a shared location, some distros put more stuff in it, as well as encryption needing all the kernels and bits outside of " /"

[jglen490]

Makes sense that /boot should be outside the LUKS environment. Even so, /boot for a single Linux OS with only a few kernels would be < 300MB and probably less that 200MB. I checked mine and du shows all of /boot to be 201MB, and then /boot/efi (6.2MB) is in it's own partition.

[kubuntu-love]

Hi guys, are you kidding me?

10-20 years ago, I would have expected Windows users to say something like, "You're just a rural person; you don't need any security at all."

So, I'm surprised that now Windows offers full disk encryption out of the box, while Linux users try to persuade me that it's better to leave the Linux kernel (!!!) unencrypted rather than using all the security features that open-source offers.
This was the point of Windows-funs!
Meanwhile, Windows users now enjoy BitLocker, which does encrypt all Windows files, and secure boot is implemented by default as well.

The Calamares installer literally warns you: "Your /boot is unencrypted! This is a security breach" and offers to use LUKS. And you ignore it? Wow.

It's not just you - the whole internet is full of "advice" to screw own security.

I'm really disappointed with the technical level of Linux users today.


But I've found the solution.

This is simply a bug in Calamares. Since GRUB doesn't support the Argon2 key derivation function, but Calamares sets it up for /boot, you should fix this bug immediately after installation by running:

cryptsetup luksConvertKey --hash sha256 --pbkdf pbkdf2 /dev/nvmeXXX

That's literally all!

Of course, you should also remove the cryptokey for the / partition from initramfs editing cryptotab to avoid compromising the security of the / partition (you shouldn't keep Argon2 keys on a legacy-type LUKS variant), update it, and then securely erase the empty space on /boot. This last step may be unnecessary, but there is no option in Calamares to avoid this configuration.

Actually, I have no idea why all distros keep replacing one terrible installer with another, even worse one. I remember a time when I could configure both LUKS and RAID with the standard terminal-based installer (it was Ubuntu!). Now, even essential features either don't work or have been removed altogether.

More info is here: https://wiki.archlinux.org/title/GRUB#Encrypted_/boot

[kubuntu-love]

P.S.: As for why there’s "8 MiB - unformatted, flag: bios-grub" - Calamares installer offered me to do this. It claimed that my GPT boot process would be broken otherwise.

[jglen490]

Calamares was simple. I just told it to do a manual install, and it did exactly what I wanted it to do.

Like I said, I didn't use LUKS. And I'm not concerned.

On the other hand, if you want to use LUKS, you'll get no complaints from me

[claydoh]

P.S.: As for why there’s "8 MiB - unformatted, flag: bios-grub" - Calamares installer offered me to do this. It claimed that my GPT boot process would be broken otherwise.

As I understand it, this is only needed when using a GPT disk and either a really old system without UEFI, or having a newer system set to use the emulated "legacy BIOS" option in the system's firmware (still called "BIOS") settings..

I can't get my installer to mention anything about needing the empty space

But I think the issue is that the installer, or ubuntu, doesn't like having 2 separate LUKS partitions -- so either don't bother encrypting /boot (not necessary, even for 99.9999999999% of those who are "security conscious") and just using the automatic install

Or you need to set up an lvm (and thus only one LUKS setup), which will be set up much easier in Partition Manager or the cli before staring the install.

[jglen490]

Good point about using a Legacy BIOS setting. A legacy BIOS setting would look at the very beginning of the bootable disk, in what used to be a size limited 512KB MBR. In almost all cases UEFI is much preferable to any sort of legacy BIOS boot process. And I do understand the "almost" part of that.

In my case, and I am no Linux or BIOS god, I use UEFI with Secure Boot disabled and AHCI enabled in the BIOS-like motherboard settings. And I also realize that some motherboards make it very hard to do that configuration. And I have used Linux since the previous millennium. And, at the risk of repeating myself, again, I don't use LUKS - but y'all do you

[Qqmike]

I've read all of jglen's posts here, and I agree with everything he said about everything (so far).

Been using Linux since 2007 (or before?). Never gave a thought to encryption or anti-virus or anything like that.
No need to ... (?)
I do other things to avoid scams/spam, like not clicking on email links I don't recognize (or even if I do recognize them, in the age of AI-written spam letters).

Worst case scenarios? Well, some kind of attack where my Kubuntu OS is demo'd to ruin.
Solution: Take a few minutes and re-install from scratch. Period. (Yes, keep your back-ups ready, too.)

[Snowhog]

In Real Estate it's "Location, location, location". In an OS: ANY OS; it's "Backup, backup, backup".

[oshunluvr]

P.S.: As for why there’s "8 MiB - unformatted, flag: bios-grub" - Calamares installer offered me to do this. It claimed that my GPT boot process would be broken otherwise.

This has been discussed before here:

GPT with NON-EFI booting requires a "bios boot" or "bios grub" partition (ef02)

EFI booting requires GPT and and "efi" partition (ef00)