Bug 33788 - Diskdrake should enforce separate /boot when needed (or make it work with i.e encrypted LVM root)
Summary: Diskdrake should enforce separate /boot when needed (or make it work with i.e...
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: Mageia 10
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard:
Keywords: FOR_ERRATA9
Depends on:
Blocks:
 
Reported: 2024-11-22 13:55 CET by Morgan Leijström
Modified: 2024-11-24 16:52 CET (History)
2 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments

Description Morgan Leijström 2024-11-22 13:55:16 CET
Description of problem:
Installer allow making a setup that is bound to fail.

When using an encrypted pv for LVM, with / in it, Mageia need a separate /boot outside the LVM.

Mageia do not need a separate /boot partition if / is unencrypted or if / is in a LVM using en unencrypted pv.


Wish:
Either make it work, or make installer warn if there is no separate /boot when it is needed.


Version: Mageia 9 installer and earlier


How reproducible: Always

It seen not to matter if it is old BIOS style boot, or new style with EFI partition.

I have not tested if plain encrypted / without LVM works.

Steps to Reproduce: During install,
1. Select manual partitioning, expert mode
2. If EFI, create such partition
3. On rest of drive create LVM, checkmark to encrypt, give key
4. in the LVM, create /, swap, /home

The reboot after install drops to:

error: ../../grub-core/kern/disk.c:236:disk `Lvmid/qHYuzP-cUPT-uBzc-h7el-VVkG-bp1s-B8b9mf/56nlgJU3LK-hX80-ORtm-dkYD-FN0g-PneeLT' not found.
Entering rescue mode...
grub rescue>
Comment 1 Morgan Leijström 2024-11-22 14:04:49 CET
Minor note, typo in my typing from screenshot: "Lvmid" should be "lvmid".

Too late to fix mga9...  Did not test Cauldron installer ;), but setting it.

Encrypted LVM is the most convenient way to make a fully encrypted install (except /boot and EFI).
IMO, this should be the most popular way to install... 

If not fixed, it should be noted in installer documentation.

Pondering mga9 errata. (And until fixed, for next erratas too)

While rendering system unbootable, I deem this issue to not be severe because user have not lost anything except time (and we potentially a user).

Target Milestone: --- => Mageia 10
Keywords: (none) => FOR_ERRATA9
Version: 9 => Cauldron
CC: (none) => doc-bugs

Comment 2 Florian Hubold 2024-11-24 16:26:17 CET
(In reply to Morgan Leijström from comment #0)
 
> When using an encrypted pv for LVM, with / in it, Mageia need a separate
> /boot outside the LVM.

No that is not correct and that is not required. Did a fresh install for mga9, and my /boot is inside LVM.
Technically it's even possible to also have /boot LUKS-encrypted although there are a few conditions to this:
https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html
https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system
https://unix.stackexchange.com/questions/702498/grub-install-with-encrypted-boot-partition

On a related note, you don't even need a separate /boot partition when using grub, as grub2 is able to open LUKS-encrypted partitions by itself with the cryptomount command since quite some time.

CC: (none) => doktor5000

Comment 3 Morgan Leijström 2024-11-24 16:32:06 CET
Florian, please repeat the test, and when in installer creating the LVM, *checkmark encryption*.

With / in a lv and no /boot, grub landed with the error message I transcribed in end of Description.
Comment 4 Florian Hubold 2024-11-24 16:46:21 CET
Well I set this up with the mga9 installer.

Although in general I do have to say that LVM handling in installer is horrible overall. You have to know all sizes of the LVs in advance, resizing is not possible, sometimes the sizes are not what you entered.
Comment 5 Morgan Leijström 2024-11-24 16:52:15 CET
But did you select encryption when setting up LVM?
( not when creating / )

lv can be resized, but only enlarged... So I usually make / and /home rather small and enlarge when needed.  Works good during use, never failed.
Yes it is a pity they can not be downsized by diskdrake, but that process is also more advanced behind the scenes.

Note You need to log in before you can comment on or make changes to this bug.