both entries never worked as expected. Install bootloader almost ever says it was unsuccessfull, e.g. because efibootmgr shows errors (#32722) mounting the partitions /mnt often fails. I guess we must improve some condtions here.
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
Blocks: (none) => 33234
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_ERRATA9CC: lewyssmith => (none)Component: RPM Packages => InstallerAssignee: bugsquad => mageiatoolsSummary: 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 10Keywords: FOR_ERRATA9 => IN_ERRATA9CC: (none) => friSummary: 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