Bug 33225

Bonjour,
Le but final était d'installer la partion UEFI sur mon SSD NVME M2 PCie. C'est sur ce SSD que j'ai fraichement installé Mageia 9 et je souhaite donc maintenant que l'UEFI soit situé sur ce SSD et non sur le disque Sata.
Cordialement;
    F.A.

Infos sur le SSD :

Identification
Fabricant: ‎Micron/Crucial Technology

Description: ‎P5 Plus NVMe PCIe SSD

Classe de média: ‎Non-Volatile memory controller

Connexion
Bus: ‎PCI Express

Domaine PCI: ‎0

Bus PCI n°: ‎4

Périphérique PCI n°: ‎0

Fonction PCI n°: ‎0

Identifiant du fabricant: ‎0xc0a9

Identifiant du périphérique: ‎0x5407

Identifiant du sous-vendeur: ‎0xc0a9

Identifiant du sous-périphérique: ‎0x0100

Bonjour,
A partir du Live Mageia 9 sur USB j'ai téléchargé Grub2 et Grub-customizer.
Malheuresement ce dernier génère le m^me type d'erreur :

grub2-mkconfig ne peut pas s'exécuter correctment. Message d'erreur :
/usr/sbin/grub2-probe: erreur: impossible d'obtenir le chemin canonique de "overlay".

Cordialement,
    F.A.

Pour info, (si cela pour vous e^tre utile), j'ai essayé la commande suivante :

[live@localhost ~]$ grub2-probe -v /dev/nvme0n1p1
grub2-probe : information : impossible d'ouvrir « /boot/grub2/device.map » : Aucun fichier ou dossier de ce type.
grub2-probe : erreur : impossible d'obtenir le chemin canonique de « devtmpfs ».
[live@localhost ~]$

Info complémentaires sur la partition cible d'amorçage :

Taille             537 Mo (536 870 912 octets)
Contenu            FAT (version 32 bit) — Non monté
Périphérique       /dev/nvme0n1p1
UUID               2C1A-4D75
Type de partition  EFI (FAT-12/16/32) (Amorçable)

Can you please provide information on the system 'discs' together, for example:
 $ lsblk
 $ inxi -MDop
 # fdisk -l
 # gdisk -l /dev/...
 $ mount | grep /dev/
 # efibootmgr

"installer la partion UEFI sur mon SSD NVME M2 PCie .. et non sur le disque Sata"
The UEFI partition is called the ESP (EFI System Partition). Changing it on a configured system could be hazardous...

CC: (none) => lewyssmith

[frederic@localhost ~]$ inxi -Mdop
Machine:
  Type: Desktop Mobo: ASUSTeK model: Z170 PRO GAMING/AURA v: Rev X.0x
    serial: <superuser required> UEFI: American Megatrends v: 3805
    date: 05/16/2018
Drives:
  Local Storage: total: 6.37 TiB used: 156.25 GiB (2.4%)
  ID-1: /dev/nvme0n1 vendor: Crucial model: CT1000P5PSSD8 size: 931.51 GiB
  ID-2: /dev/sda vendor: Seagate model: ST1000DX002-2DV162 size: 931.51 GiB
  ID-3: /dev/sdb vendor: Seagate model: ST1000DM010-2EP102 size: 931.51 GiB
  ID-4: /dev/sdc vendor: Seagate model: ST31000528AS size: 931.51 GiB
  ID-5: /dev/sdd vendor: Seagate model: ST31000528AS size: 931.51 GiB
  ID-6: /dev/sde vendor: Seagate model: ST2000VN003-3CW102 size: 1.82 TiB
  Message: No optical or floppy data found.
Partition:
  ID-1: / size: 628.89 GiB used: 38.02 GiB (6.0%) fs: ext4 dev: /dev/nvme0n1p2
  ID-2: /boot/EFI size: 511 MiB used: 7.9 MiB (1.5%) fs: vfat dev: /dev/sda1
  ID-3: /home size: 899.82 GiB used: 118.22 GiB (13.1%) fs: ext4
    dev: /dev/sde3
  ID-4: swap-1 size: 32 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sde2
Unmounted:
  ID-1: /dev/nvme0n1p1 size: 512 MiB fs: vfat
  ID-2: /dev/nvme0n1p3 size: 291.01 GiB fs: ext4
  ID-3: /dev/sda2 size: 292.97 GiB fs: ext4
  ID-4: /dev/sda3 size: 606.79 GiB fs: ext4
  ID-5: /dev/sda4 size: 31.25 GiB fs: swap
  ID-6: /dev/sdb1 size: 285 MiB fs: vfat
  ID-7: /dev/sdb2 size: 279.4 GiB fs: ext4
  ID-8: /dev/sdb3 size: 29.8 GiB fs: swap
  ID-9: /dev/sdb4 size: 622.03 GiB fs: ext4
  ID-10: /dev/sdc1 size: 512 MiB fs: vfat
  ID-11: /dev/sdc2 size: 931.01 GiB fs: ext4
  ID-12: /dev/sdd1 size: 931.51 GiB fs: ext4
  ID-13: /dev/sde1 size: 512 MiB fs: vfat
  ID-14: /dev/sde4 size: 915.26 GiB fs: ext4
[frederic@localhost ~]$

OK, your ESP is currently
 /boot/EFI size: 511 MiB used: 7.9 MiB (1.5%) fs: vfat dev: /dev/sda1
and you want to move it to
 /dev/nvme0n1p1 size: 512 MiB fs: vfat

You have already created the new ESP; does it have type 'EF00'?

We have not mentioned NVRAM, but that has pointers to the ESP, and will need changing from the old to the new. I am unsure whether install-grub removes things from NVRAM. This gets delicate if you do not want to have an unbootable machine.
Post the output of
 # efibootmgr
If you do not have 'tree', install it; it is useful. Then post
 $ tree /boot/EFI
or if you have other systems (to limit output)
 $ tree -d /boot/EFI

You mention various Grub failures, but not exactly what you were doing. Were they all from a Live system? What exactly were you asking Drakboot to do - all the exact steps?

Created attachment 14544 [details]
sda is the actual disk where ESP partition is.

Created attachment 14545 [details]
sda1 is the actual ESP partition

Created attachment 14546 [details]
nvme0n1 is the disk (SSD) for the new ESP

Created attachment 14547 [details]
nvme0n1p1 is for the new ESP.

See the Attachments for ESP (actual and new).

I don't know how to get the type of ESP ...

Probably:

gdisk /dev/nvme0n1

then i

then 1

If its not 'EFI System Partition' you can use gdisk to change it using l to get a list of the type codes and the t command to change it.

CC: (none) => zen25000

I do not change because ESP is already an EFI system partition with type "ef00" ==> See below, the result of gdisk t command.


[frederic@localhost ~]$ sudo gdisk /dev/nvme0n1
GPT fdisk (gdisk) version 1.0.9

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
typing 'q' if you don't want to convert your MBR partitions
to GPT format!
***************************************************************

Command (? for help): i
Partition number (1-4): 1
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI system partition)
Partition unique GUID: 27C4AE4F-9DEC-467E-AD0F-6EF9C0EC983E
First sector: 2048 (at 1024.0 KiB)
Last sector: 1050623 (at 513.0 MiB)
Partition size: 1048576 sectors (512.0 MiB)
Attribute flags: 0000000000000000
Partition name: 'EFI system partition'

Command (? for help): l
Type search string, or <Enter> to show all codes: 
....                        
8300 Linux filesystem                    8301 Linux reserved                    
8302 Linux /home                         8303 Linux x86 root (/)                
8304 Linux x86-64 root (/)               8305 Linux ARM64 root (/)              
8306 Linux /srv                          8307 Linux ARM32 root (/)              
8308 Linux dm-crypt                      8309 Linux LUKS                        
830a Linux IA-64 root (/)                830b Linux x86 root verity             
830c Linux x86-64 root verity            830d Linux ARM32 root verity           
830e Linux ARM64 root verity             830f Linux IA-64 root verity           
8310 Linux /var                          8311 Linux /var/tmp                    
8312 Linux user's home                   8313 Linux x86 /usr                                           
...
...                      
ed01 Lenovo system partition             ef00 EFI system partition              
ef01 MBR partition scheme                ef02 BIOS boot partition               
...
...

Command (? for help): t
Partition number (1-4): 1
Current type is ef00 (EFI system partition)
Hex code or GUID (L to show codes, Enter = ef00): 
Changed type of partition to 'EFI system partition'

Command (? for help): q
[frederic@localhost ~]$

Thanks Barry for intervening.
I did not like the gdisk error when citing just the partition, but found the same thing (and worse!) on my own system! Citing just the device produced normal output...
The new ESP looks correct.

Please post the output of:
 # efibootmgr
to look at the NVRAM.

[frederic@localhost ~]$ efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,000E,000A,000F,000C,000D
Boot0000* mageia        HD(1,GPT,2be347f2-a6fe-45dd-b600-caa81e0f6b88,0x800,0x100000)/File(\EFI\MAGEIA\GRUBX64.EFI)
Boot000A* Hard Drive    BBS(HD,,0x0)0000474f00004e4f9b000000010000006d00430054003100300030003000500035005000530053004400380000000501090002000000007fff040002010c00d041030a0000000001010600001d010106000000031710000100000000a075013678b9137fff040001043000ef47642dc93ba041ac194d51d01b4ce6430054003100300030003000500035005000530053004400380000007fff04000000424f00004e4fa7000000010000006f0053005400320030003000300056004e003000300033002d0033004300570031003000320000000501090002000000007fff040002010c00d041030a0000000001010600001703120a000400ffff00007fff040001043e00ef47642dc93ba041ac194d51d01b4ce620002000200020002000200020002000200020002000200057005a003000440051005a005700380000007fff04000000424f00004e4fa7000000010000006f00530054003100300030003000440058003000300032002d0032004400560031003600320000000501090002000000007fff040002010c00d041030a0000000001010600001703120a000000ffff00007fff040001043e00ef47642dc93ba041ac194d51d01b4ce620002000200020002000200020002000200020002000200034005a00450059004e0052005200370000007fff04000000424f00004e4fa7000000010000006f0053005400310030003000300044004d003000310030002d0032004500500031003000320000000501090002000000007fff040002010c00d041030a0000000001010600001703120a000100ffff00007fff040001043e00ef47642dc93ba041ac194d51d01b4ce620002000200020002000200020002000200020002000200039005a0039004100320048003400500000007fff04000000424f00004e4f9b000000010000006f0053005400330031003000300030003500320038004100530000000501090002000000007fff040002010c00d041030a0000000001010600001703120a000200ffff00007fff040001043e00ef47642dc93ba041ac194d51d01b4ce62000200020002000200020002000200020002000200020005600390035005000320047003900320000007fff04000000424f00004e4f9b000000010000006f0053005400330031003000300030003500320038004100530000000501090002000000007fff040002010c00d041030a0000000001010600001703120a000300ffff00007fff040001043e00ef47642dc93ba041ac194d51d01b4ce62000200020002000200020002000200020002000200020005600390037005000440050005a004a0000007fff04000000424f00004e4f99000000010000006f005300540033003300320030003600320030004100530000000501090002000000007fff040002010c00d041030a0000000001010600001703120a000500ffff00007fff040001043e00ef47642dc93ba041ac194d51d01b4ce620002000200020002000200020002000200020002000200051003900350046005a0031004e00410000007fff04000000424f
Boot000C* UEFI: IP4 Intel(R) Ethernet Connection (2) I219-V     PciRoot(0x0)/Pci(0x1f,0x6)/MAC(38d5470fc29a,0)/IPv4(0.0.0.00.0.0.0,0,0)0000424f
Boot000D* UEFI: IP6 Intel(R) Ethernet Connection (2) I219-V     PciRoot(0x0)/Pci(0x1f,0x6)/MAC(38d5470fc29a,0)/IPv6([::]:<->[::]:,0,0)0000424f
Boot000E* ubuntu        HD(1,GPT,2be347f2-a6fe-45dd-b600-caa81e0f6b88,0x800,0x100000)/File(\EFI\UBUNTU\SHIMX64.EFI)0000424f
Boot000F* ubuntu        HD(1,GPT,8cd91cbc-d19f-4999-91e6-7e463575025f,0x800,0x100000)/File(\EFI\UBUNTU\SHIMX64.EFI)0000424f
[frederic@localhost ~]$

Thank you for all the information.
It would be nice to have also the output of the original ESP contents with
 $ ls -R /boot/EFI

The Grub update will need to (1) put the Mageia booloader in
 EFI/mageia:
  grubx64.efi
on the new ESP. (2) Change the mageia NVRAM entry to point to disc 2.
What are you going to do for Ubuntu?

Now I repeat the end of comment 8:
Please describe precisely what you did to see the original error.
You say in comment 0 that you were working from a Plasma Live USB. Was this doing the installation of the system on /dev/nvme0n1p2 ? Can you say exactly what you did/chose/specified at the Bootloader installation stage?

Once again, CC'ing Martin to cast an eye on this.

CC: (none) => mageia

[frederic@localhost ~]$ ls -R /boot/EFI
/boot/EFI:
EFI/

/boot/EFI/EFI:
BOOT/  mageia/  memtest/  ubuntu/

/boot/EFI/EFI/BOOT:
BOOTX64.EFI*  fbx64.efi*  mmx64.efi*

/boot/EFI/EFI/mageia:
grubx64.efi*

/boot/EFI/EFI/memtest:
bootx64.efi*

/boot/EFI/EFI/ubuntu:
BOOTX64.CSV*  grub.cfg*  grubx64.efi*  mmx64.efi*  shimx64.efi*
[frederic@localhost ~]$

Ubuntu was only a test carried out on a disk dedicated to various tests.
So it's not important to keep it in the new ESP.

658 / 5 000
When I installed "Mageia 9", I left all the disks plugged in.
The installation of / on /dev/nvme0n1p2 went well but it was on the boot of /dev/sda that GRUB was modified. So I always boot via disk /dev/sda (disk that I want to free).
When the problem happened, I unplugged all the disks except /dev/sde which contains the /home (and the .M2 SSD of course) and I started the live Mageia 9 USB to try to Repair/Install GRUP on the new ESP (/dev/nvme0n1p1) when trying to update the previously installed Mageia 9.
This did not allow changing the destination and the problem appeared.

(In reply to Frédéric ACHARD from comment #22)
> When the problem happened, I unplugged all the disks except /dev/sde which
> contains the /home (and the .M2 SSD of course) and I started the live Mageia
> 9 USB to try to Repair/Install GRUP on the new ESP (/dev/nvme0n1p1) when
> trying to update the previously installed Mageia 9.
> This did not allow changing the destination and the problem appeared.

The Live ISOs don't provide an option to upgrade an existing installation, or to repair/install GRUB. Did you actually use the classical installer ISO? To clarify, tell us the exact name of the ISO file you copied onto the USB stick.

To do what you want to do, I would do the following:

1. Boot the installed system with the old disk (/dev/sda) still connected.

2. Using drakdisk
  - Select the old ESP partition (/dev/sda1)
  - Unmount the partition
  - Change the mount point from "/boot/EFI" to blank
  - Select the new ESP partition (/dev/nvme0n1p1)
  - Change the mount point to "/boot/EFI"
  - Mount the partition
  - Exit, saying yes to saving the modifications in /etc/fstab

3. Check that /boot/EFI is now accessible.

4. Run drakboot. It should report that no bootloader is detected. Proceed to installing the bootloader of your choice.

And finally

5. In a terminal window, as root, run "dracut -f"

This updates the copy of /etc/fstab in the initrd image. If you don't do this, systemd will try to mount the old ESP during the early boot stage, which will probably cause the boot to hang if you disconnect the old disk.

I have two USB sticks; one with Live Mageia 9 and another with the classic 64 bit installation. The installation of Mageia 9 on /dev/nvme0n1 was carried out with the key containing the classic installation (Mageia-9-x86_64.iso).
As the Live USB could not modify the installation I used the installation USB key to try to repair/modify/move the ESP partition.

Martin has provided super instructions. Over to you.

Good morning,
with a little delay, I have just carried out the operations that Martin suggested. Everything worked fine and now the ESP is on the SSD.
Many thanks to Lewis, Barry and Martin for helping me resolve my ESP migration issue.
I think that the "drakboot" crash was caused by the fact that I had unplugged the sda ​​disk that the boot was installed on.
Long live Linux and long life to Mageia which benefits, thanks to you, from very efficient technical support.
Sincerely,
 F.A.

Thank you for the update, Frédéric.
And thanks for helping out, Martin.

I think we can close this bug as invalid or worksforme.

But before that, a question:
Is there something we should improve in some documentation or tool?

CC: (none) => fri

Yes, you can close this ticket.

Here is what could be improved:

1) For drakboot:
Perhaps a more explicit error message would be welcome, when the disk, containing the ESP, is inaccessible (or unplugged in my case ;-(().

2) For ESP:
The case of moving the ESP, from one disk to another, (notably to an SSD), could give rise to a tutorial in a Wiki for example. An automation tool would also be welcome.

Sincerely.
 F.A.

(In reply to Frédéric ACHARD from comment #29)
> 1) For drakboot:
> Perhaps a more explicit error message would be welcome, when the disk,
> containing the ESP, is inaccessible (or unplugged in my case ;-(().
Hmmm If you disconnect a disc being used... The error message came from grub, not drakboot. 

> 2) For ESP:
> The case of moving the ESP, from one disk to another, (notably to an SSD),
> could give rise to a tutorial in a Wiki for example
Possibly, when someone has the time. Comment 23 comment 24.
It is such a rare requirement, and it may even be possible to have more than one ESP anyway. The problem more specifically was how to get the bootloader installed in the new ESP and referenced there from NVRAM.

Status: NEW => RESOLVED
Resolution: (none) => WORKSFORME