Bug 32723

Marc, please give much more information about what you are trying to do, and the system details - especially of the disc.
Outputs of the following if you can run & capture them:
 $ inxi -MSDop
 # fdisk -l /dev/...
or
 # gdisk -l /dev/...
 # efibootmgr

CC: (none) => lewyssmith

sorry, I missed the comment, but ran again into this:

first, the device is encrypted, which is discovered right by the rescue image, but mounting afterwards always fails. And after the device was successfully decrypted, e.g. install bootloader or mount partitions does not recognize this


 inxi -MSDop
System:
  Host: lap06.xxx Kernel: 6.6.28-desktop-1.mga9 arch: x86_64 bits: 64
    Desktop: MATE v: 1.26.1 Distro: Mageia 9
Machine:
  Type: Laptop System: LENOVO product: xx v: ThinkPad T460
    serial: PC0L5ATC
  Mobo: LENOVO model: xx serial: xx UEFI: LENOVO
    v: R06ET71W (1.45 ) date: 02/21/2022
Drives:
  Local Storage: total: 252.91 GiB used: 14.4 GiB (5.7%)
  ID-1: /dev/sda vendor: Toshiba model: THNSFJ256GCSU size: 238.47 GiB
  ID-2: /dev/sdb type: USB vendor: Kingston model: DataTraveler 2.0
    size: 14.44 GiB
Partition:
  ID-1: / size: 9.73 GiB used: 8.01 GiB (82.4%) fs: jfs dev: /dev/dm-1
  ID-2: /boot size: 296.8 MiB used: 159.2 MiB (53.6%) fs: jfs dev: /dev/sda2
  ID-3: /boot/EFI size: 96 MiB used: 9.3 MiB (9.7%) fs: vfat dev: /dev/sda1
  ID-4: /home size: 9.73 GiB used: 6.22 GiB (64.0%) fs: jfs dev: /dev/dm-3
  ID-5: swap-1 size: 3.91 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/dm-2
Unmounted:
  ID-1: /dev/sdb1 size: 100 MiB fs: jfs
  ID-2: /dev/sdb2 size: 14.34 GiB fs: jfs


 LANGUAGE=C fdisk -l /dev/sda
Disk /dev/sda: 238,47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: TOSHIBA THNSFJ25
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: xx

Device       Start       End   Sectors   Size Type
/dev/sda1     2048    614433    612386   299M EFI System
/dev/sda2   616448   1228833    612386   299M Linux filesystem
/dev/sda3  1230848 500115489 498884642 237,9G Linux filesystem

I tried to reproduce this with:

root@localhost ~]# fdisk -l /dev/sda
Disk /dev/sda: 40 GiB, 42949672960 bytes, 83886080 sectors
Disk model: VBOX HARDDISK   
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: BAD82A31-4347-4517-86ED-1948F631BAF2

Device        Start      End  Sectors  Size Type
/dev/sda1      2048   614433   612386  299M EFI System
/dev/sda2    616448  1228833   612386  299M Linux filesystem
/dev/sda3   1230848 74956833 73725986 35.2G Linux filesystem
/dev/sda4  74958848 83882017  8923170  4.3G Linux swap

[root@localhost ~]# inxi -p
Partition:
  ID-1: / size: 35.01 GiB used: 3.89 GiB (11.1%) fs: jfs dev: /dev/dm-0
  ID-2: /boot size: 296.8 MiB used: 73.8 MiB (24.9%) fs: jfs dev: /dev/sda2
  ID-3: /boot/EFI size: 298.4 MiB used: 168 KiB (0.1%) fs: vfat
    dev: /dev/sda1
  ID-4: swap-1 size: 4.25 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda4

The rescue system reinstalled the bootloader without any problem. So without more information about why the mounts are failing, or a reliable way to reproduce it, I can't help with this.

CC: (none) => mageia

@Martin: what output do u need? I can reproduce this every time.

Note I am using encrypted lvm volume.
If relevant, I am not using the mageia names for the lvm volumes

Further experimentation confirms the rescue system does not detect a root partition if it is inside an encrypted lvm volume. Nor does the installer, so you can't perform an off-line upgrade in this case.

An encrypted root partition on its own is detected.

Summary: Rescue: reinstall bootloader/mnt partitions always fails => Rescue system: reinstall bootloader/mount partitions always fails when the root partition is inside an encrypted lvm volume

(In reply to Marc Krämer from comment #4)
> Note I am using encrypted lvm volume.
This is indeed in the bug title, but not reminded in comment 2 which just mentions encryptation; LVM adds a signifcant complication.

Marc, note "you can't perform an off-line upgrade in this case". You are stuck on that.

Thank you Martin for all your research.
I think this warrants an ERRATA.
Transferring as an Installer bug.

Keywords: (none) => FOR_ERRATA9
CC: lewyssmith => (none)
Component: RPM Packages => Installer
Assignee: bugsquad => mageiatools
Summary: Rescue system: reinstall bootloader/mount partitions always fails when the root partition is inside an encrypted lvm volume => Rescue system: reinstall bootloader/mount partitions always fails when the root partition is inside an encrypted LVM volume

good to know, what is the cause.
The strange thing is, the partions get encrypted, so the search routine must only search the new volumes which appeared.

I guess it would be not to complicated to fix.

Added under https://wiki.mageia.org/en/Mageia_9_Errata#Installer_images

Target Milestone: --- => Mageia 10
Keywords: FOR_ERRATA9 => IN_ERRATA9
CC: (none) => fri
Summary: Rescue system: reinstall bootloader/mount partitions always fails when the root partition is inside an encrypted LVM volume => Installer and rescue system fails to find a root partition inside an encrypted LVM volume