Comment installer Ubuntu 14.04 / 16.04 64 bits avec une partition RAID 1 à double démarrage sur un système UEFI / GPT?
Mise à jour: La question et la réponse ci-dessous s'appliquent également à Ubuntu 16.04
J'ai un ordinateur avec deux disques SSD et Win (7) préinstallé sur un autre disque. La pré-installation utilise le démarrage (U) EFI/GPT. Je souhaite installer le bureau Ubuntu 14.04 64 bits sur une partition racine RAID1 sur mes SSD tout en pouvant effectuer un double amorçage de mon système Win7. Est-ce possible?
Ce guide utilisant le programme d'installation de bureau ne fonctionnait pas, probablement parce qu'il suppose (implicitement) le démarrage du MBR. n'a pas non plus installé la distribution du serveur , probablement pour la même raison.
UPDATE: J'ai vérifié que la description ci-dessous fonctionne également pour Ubuntu 16.04. D'autres utilisateurs ont indiqué avoir travaillé le 17.10 et le 18.04.1.
NOTE: Ce HOWTO ne vous donnera pas LVM. Si vous voulez aussi LVM, essayez Installez le bureau Ubuntu 18.04 avec RAID 1 et LVM sur la machine avec le BIOS UEFI.
Après des jours d’essai, j’ai maintenant un système qui fonctionne! En bref, la solution consistait en les étapes suivantes:
- Démarrez avec un Live CD/USB Ubuntu.
- Partitionne les disques SSD selon les besoins.
- Installez les paquets manquants (mdadm et grub-efi).
- Créez les partitions RAID.
- Exécutez le programme d'installation Ubiquity (mais ne démarrez pas dans le nouveau système).
- Appliquez une correction au système installé (initramfs) pour activer le démarrage à partir d'une racine RAIDed.
- Remplissez la partition EFI du premier disque SSD avec GRUB et installez-le dans la chaîne de démarrage EFI.
- Clonez la partition EFI sur l'autre disque SSD et installez-la dans la chaîne de démarrage.
- Terminé! Votre système va maintenant avoir la redondance RAID 1. Notez que rien de spécial ne doit être fait après, par exemple. une mise à jour du noyau, car les partitions UEFI ne sont pas modifiées.
Un élément clé de l’étape 6 de la solution était un retard dans la séquence de démarrage qui m’avait sinon été renvoyé directement à l’invite GRUB (sans clavier!) Si l’un des disques SSD était manquant.
HOWTO détaillé
1. démarrage
Démarrez en utilisant EFI à partir de la clé USB. Exactement comment va varier selon votre système. Sélectionnez Essayez ubuntu sans installer .
Démarrez un émulateur de terminal, par exemple. xtermpour exécuter les commandes ci-dessous.
1.1 Connexion depuis un autre ordinateur
Lors de l’essai, j’ai souvent trouvé plus facile de se connecter à partir d’un autre ordinateur déjà configuré. Ce copier-coller simplifié de commandes, etc. Si vous voulez faire la même chose, vous pouvez vous connecter via ssh en procédant comme suit:
Sur l'ordinateur à configurer, installez le serveur openssh:
Sudo apt-get install openssh-server
Changer le mot de passe. Le mot de passe par défaut pour l'utilisateur ubuntuest vide. Vous pouvez probablement choisir un mot de passe de force moyenne. Il sera oublié dès que vous redémarrez votre nouvel ordinateur.
passwd
Maintenant, vous pouvez vous connecter à la session Ubuntu Live à partir d'un autre ordinateur. Les instructions ci-dessous sont pour Linux:
ssh -l ubuntu <your-new-computer>
Si vous recevez un avertissement concernant une attaque suspecte de type homme au milieu, vous devez effacer les clés ssh utilisées pour identifier le nouvel ordinateur. En effet, openssh-server génère de nouvelles clés de serveur chaque fois qu'il est installé. La commande à utiliser est généralement imprimée et devrait ressembler à
ssh-keygen -f <path-to-.ssh/known_hosts> -R <your-new-computer>
Après avoir exécuté cette commande, vous devriez pouvoir vous connecter à la session Ubuntu Live.
2. Disques de partition
Effacer toutes les anciennes partitions et les blocs de démarrage. Attention! Cela détruira les données sur vos disques!
Sudo sgdisk -z /dev/sda
Sudo sgdisk -z /dev/sdb
Créez de nouvelles partitions sur le plus petit de vos disques: 100 Mo pour ESP, 32G pour RAID SWAP, reste pour RAID racine. Si votre disque dur est le plus petit, suivez la section 2.1, sinon la section 2.2.
2.1 Créer des tables de partition (/ dev/sda est plus petit)
Effectuez les étapes suivantes:
Sudo sgdisk -n 1:0:+100M -t 1:ef00 -c 1:"EFI System" /dev/sda
Sudo sgdisk -n 2:0:+32G -t 2:fd00 -c 2:"Linux RAID" /dev/sda
Sudo sgdisk -n 3:0:0 -t 3:fd00 -c 3:"Linux RAID" /dev/sda
Copiez la table de partition sur un autre disque et régénérez des UUID uniques (en réalité, les UUID seront régénérés pour sda).
Sudo sgdisk /dev/sda -R /dev/sdb -G
2.2 Créer des tables de partition (/ dev/sdb est plus petit)
Effectuez les étapes suivantes:
Sudo sgdisk -n 1:0:+100M -t 1:ef00 -c 1:"EFI System" /dev/sdb
Sudo sgdisk -n 2:0:+32G -t 2:fd00 -c 2:"Linux RAID" /dev/sdb
Sudo sgdisk -n 3:0:0 -t 3:fd00 -c 3:"Linux RAID" /dev/sdb
Copiez la table de partition sur un autre disque et régénérez des UUID uniques (en réalité, les UUID seront régénérés pour sdb).
Sudo sgdisk /dev/sdb -R /dev/sda -G
2.3 Créer le système de fichiers FAT32 sur/dev/sda
Créez le système de fichiers FAT32 pour la partition EFI.
Sudo mkfs.fat -F 32 /dev/sda1
mkdir /tmp/sda1
Sudo mount /dev/sda1 /tmp/sda1
Sudo mkdir /tmp/sda1/EFI
Sudo umount /dev/sda1
3. Installer les paquets manquants
Le CD d'Ubuntu Live est livré sans deux packages clés; Grub-efi et mdadm. Installez-les. (Je ne suis pas sûr à 100% que grub-efi soit nécessaire ici, mais pour conserver une symétrie par rapport à l'installation à venir, apportez-le également.)
Sudo apt-get update
Sudo apt-get -y install grub-efi-AMD64 # (or grub-efi-AMD64-signed)
Sudo apt-get -y install mdadm
Vous aurez peut-être besoin de grub-efi-AMD64-signed au lieu de grub-efi-AMD64 si le démarrage sécurisé est activé. (Voir le commentaire d'Alecz.)
4. Créez les partitions RAID
Créez les périphériques RAID en mode dégradé. Les appareils seront complétés plus tard. Créer un RAID1 complet m'a parfois causé des problèmes lors de l'installation de ubiquityci-dessous, sans savoir pourquoi. (monter/démonter? format?)
Sudo mdadm --create /dev/md0 --bitmap=internal --level=1 --raid-disks=2 /dev/sda2 missing
Sudo mdadm --create /dev/md1 --bitmap=internal --level=1 --raid-disks=2 /dev/sda3 missing
Vérifiez le statut RAID.
cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sda3[0]
216269952 blocks super 1.2 [2/1] [U_]
bitmap: 0/2 pages [0KB], 65536KB chunk
md0 : active raid1 sda2[0]
33537920 blocks super 1.2 [2/1] [U_]
bitmap: 0/1 pages [0KB], 65536KB chunk
unused devices: <none>
Partitionnez les périphériques md.
Sudo sgdisk -z /dev/md0
Sudo sgdisk -z /dev/md1
Sudo sgdisk -N 1 -t 1:8200 -c 1:"Linux swap" /dev/md0
Sudo sgdisk -N 1 -t 1:8300 -c 1:"Linux filesystem" /dev/md1
5. Exécutez le programme d'installation
Exécutez le programme d'installation de l'ubiquité, à l'exception du chargeur de démarrage qui échouera de toute façon . ( Remarque : Si vous vous êtes connecté via ssh, vous voudrez probablement l'exécuter sur votre nouvel ordinateur.)
Sudo ubiquity -b
Choisissez quelque chose d'autre comme type d'installation et modifiez le type md1p1 en ext4, formatez oui, et montez le point /. La partition md0p1 sera automatiquement sélectionnée comme swap.
Obtenez une tasse de café pendant que l'installation se termine.
Important: Une fois l'installation terminée, sélectionnez Continuer à tester en tant que système. n'est pas encore prêt.
Terminez les périphériques RAID
Reliez les partitions sdb en attente au RAID.
Sudo mdadm --add /dev/md0 /dev/sdb2
Sudo mdadm --add /dev/md1 /dev/sdb3
Vérifiez que tous les périphériques RAID sont corrects (et éventuellement synchronisés).
cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdb3[1] sda3[0]
216269952 blocks super 1.2 [2/1] [U_]
[>....................] recovery = 0.2% (465536/216269952) finish=17.9min speed=200000K/sec
bitmap: 2/2 pages [8KB], 65536KB chunk
md0 : active raid1 sdb2[1] sda2[0]
33537920 blocks super 1.2 [2/2] [UU]
bitmap: 0/1 pages [0KB], 65536KB chunk
unused devices: <none>
Le processus ci-dessous peut continuer pendant la synchronisation, y compris les redémarrages.
6. Configurez le système installé
Configurez pour activer le chroot dans le système d'installation.
Sudo -s
mount /dev/md1p1 /mnt
mount -o bind /dev /mnt/dev
mount -o bind /dev/pts /mnt/dev/pts
mount -o bind /sys /mnt/sys
mount -o bind /proc /mnt/proc
cat /etc/resolv.conf >> /mnt/etc/resolv.conf
chroot /mnt
Configurer et installer des packages.
apt-get install -y grub-efi-AMD64 # (or grub-efi-AMD64-signed; same as in step 3)
apt-get install -y mdadm
Si vos appareils sont toujours en phase de synchronisation, des avertissements tels que:
/usr/sbin/grub-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..
Ceci est normal et peut être ignoré (voir la réponse au bas de cette question ).
nano /etc/grub.d/10_linux
# change quick_boot and quiet_boot to 0
Désactiver quick_boot évitera les bugs les écritures Diskfilter ne sont pas supportées . Désactiver quiet_boot est de préférence personnel seulement.
Modifiez /etc/mdadm/mdadm.conf pour supprimer toutes les références d’étiquettes, c’est-à-dire changer
ARRAY /dev/md/0 metadata=1.2 name=ubuntu:0 UUID=f0e36215:7232c9e1:2800002e:e80a5599
ARRAY /dev/md/1 metadata=1.2 name=ubuntu:1 UUID=4b42f85c:46b93d8e:f7ed9920:42ea4623
à
ARRAY /dev/md/0 UUID=f0e36215:7232c9e1:2800002e:e80a5599
ARRAY /dev/md/1 UUID=4b42f85c:46b93d8e:f7ed9920:42ea4623
Cette étape est peut-être inutile, mais certaines pages suggèrent que les schémas de nommage peuvent être instables (nom = ubuntu: 0/1), ce qui peut empêcher un périphérique RAID parfaitement fin de s'assembler au démarrage.
Modifier les lignes dans /etc/default/grub pour les lire
#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
Encore une fois, cette étape peut être inutile, mais je préfère démarrer les yeux ouverts ...
6.1. Ajouter un script de sommeil
(La communauté a suggéré que cette étape serait peut-être inutile et qu'elle pourrait être remplacée par GRUB_CMDLINE_LINUX="rootdelay=30" dans /etc/default/grub. Pour les raisons expliquées au bas de ce HOWTO, je suggère de rester avec le script de veille bien que cela soit plus laid que d'utiliser rootdelay. Nous continuons donc avec notre programme régulier ... )
Créez un script qui attend que les périphériques RAID soient installés. Sans ce délai, le montage de la racine peut échouer car l'assemblage RAID n'est pas terminé à temps . J'ai découvert cela à la dure - le problème ne s'est pas manifesté tant que je n'avais pas déconnecté l'un des disques SSD pour simuler une défaillance du disque! La synchronisation peut devoir être ajustée en fonction du matériel disponible, par ex. disques USB externes lents, etc.
Entrez le code suivant dans /usr/share/initramfs-tools/scripts/local-premount/sleepAwhile:
#!/bin/sh
echo
echo "sleeping for 30 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 25 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 20 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 15 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 10 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 5 seconds while udevd and mdadm settle down"
sleep 5
echo "done sleeping"
Rendre le script exécutable et l'installer.
chmod a+x /usr/share/initramfs-tools/scripts/local-premount/sleepAwhile
update-grub
update-initramfs -u
7. Activer le démarrage à partir du premier SSD
Maintenant que le système est presque prêt, seuls les paramètres de démarrage UEFI doivent être installés.
mount /dev/sda1 /boot/efi
grub-install --boot-directory=/boot --bootloader-id=Ubuntu --target=x86_64-efi --efi-directory=/boot/efi --recheck
update-grub
umount /dev/sda1
Cela installera le chargeur de démarrage dans /boot/efi/EFI/Ubuntu (a.k.a. EFI/Ubuntu sur /dev/sda1) et l'installera d'abord dans la chaîne de démarrage UEFI sur l'ordinateur.
8. Activer le démarrage à partir du deuxième disque SSD
Nous avons presque fini. À ce stade, nous devrions pouvoir redémarrer sur le lecteur sdaname__. De plus, mdadmdevrait être en mesure de gérer les échecs du lecteur sdaou sdbname__. Cependant, l'EFI n'est pas en RAID, nous devons donc le cloner .
dd if=/dev/sda1 of=/dev/sdb1
En plus d'installer le chargeur de démarrage sur le deuxième lecteur, l'UUID du système de fichiers FAT32 de la partition sdb1 (comme indiqué par blkidname__) correspond à celui de sda1 et /etc/fstab. (Notez cependant que les UUID des partitions /dev/sda1 et /dev/sdb1 seront toujours différents. Comparez ls -la /dev/disk/by-partuuid | grep sd[ab]1 avec blkid /dev/sd[ab]1 après l'installation pour vérifier par vous-même.)
Enfin, nous devons insérer la partition sdb1 dans la séquence d'amorçage. (Remarque: cette étape peut être inutile, selon votre BIOS. J'ai reçu des rapports selon lesquels certains BIOS génèrent automatiquement une liste des ESP valides.)
efibootmgr -c -g -d /dev/sdb -p 1 -L "Ubuntu #2" -l '\EFI\ubuntu\grubx64.efi'
Je ne l’ai pas testé, mais il est probablement nécessaire d’avoir des étiquettes uniques (-L) entre ESP sur sdaet sdbname__.
Cela générera une impression de la commande de démarrage actuelle, par exemple.
Timeout: 0 seconds
BootOrder: 0009,0008,0000,0001,0002,000B,0003,0004,0005,0006,0007
Boot0000 Windows Boot Manager
Boot0001 DTO UEFI USB Floppy/CD
Boot0002 DTO UEFI USB Hard Drive
Boot0003* DTO UEFI ATAPI CD-ROM Drive
Boot0004 CD/DVD Drive
Boot0005 DTO Legacy USB Floppy/CD
Boot0006* Hard Drive
Boot0007* IBA GE Slot 00C8 v1550
Boot0008* Ubuntu
Boot000B KingstonDT 101 II PMAP
Boot0009* Ubuntu #2
Notez que Ubuntu # 2 (sdb) et Ubuntu (sda) sont les premiers dans l’ordre de démarrage.
Redémarrer
Nous sommes maintenant prêts à redémarrer.
exit # from chroot
exit # from Sudo -s
Sudo reboot
Le système devrait maintenant redémarrer sous Ubuntu (vous devrez peut-être d'abord supprimer le support d'installation d'Ubuntu Live.)
Après le démarrage, vous pouvez exécuter
Sudo update-grub
attacher le chargeur de démarrage Windows à la chaîne de démarrage grub.
Machine virtuelle obtient
Si vous voulez d'abord essayer ceci sur une machine virtuelle, il y a certaines mises en garde: Apparemment, la NVRAM qui contient les informations UEFI est mémorisée entre les redémarrages, mais pas entre les cycles d'arrêt/redémarrage. Dans ce cas, vous pouvez vous retrouver sur la console du shell UEFI. Les commandes suivantes doivent vous démarrer sur votre ordinateur à partir de /dev/sda1 (utilisez FS1: pour /dev/sdb1):
FS0:
\EFI\ubuntu\grubx64.efi
La première solution dans la réponse principale de démarrage de UEFI dans la virtualbox - Ubuntu 12.04 pourrait également être utile.
Simuler une panne de disque
La défaillance de l'un des composants RAID peut être simulée à l'aide de mdadmname__. Cependant, pour vérifier que le matériel de démarrage survivrait à une panne de disque, je devais éteindre l'ordinateur et débrancher l'alimentation d'un disque. Si vous le faites, assurez-vous d'abord que les périphériques md sont synchronisés .
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid1 sdb3[2] sda3[0]
216269952 blocks super 1.2 [2/2] [UU]
bitmap: 2/2 pages [8KB], 65536KB chunk
md0 : active raid1 sda2[0] sdb2[2]
33537920 blocks super 1.2 [2/2] [UU]
bitmap: 0/1 pages [0KB], 65536KB chunk
unused devices: <none>
Dans les instructions ci-dessous, sdX est le périphérique défaillant (X = a ou b) et sdY est le périphérique ok.
Déconnecter un lecteur
Éteindre l'ordinateur. Déconnectez un lecteur. Redémarrer. Ubuntu devrait maintenant démarrer avec les disques RAID en mode dégradé. (Célébrez! C'est ce que vous tentiez de réaliser!;)
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid1 sda3[0]
216269952 blocks super 1.2 [2/1] [U_]
bitmap: 2/2 pages [8KB], 65536KB chunk
md0 : active raid1 sda2[0]
33537920 blocks super 1.2 [2/1] [U_]
bitmap: 0/1 pages [0KB], 65536KB chunk
unused devices: <none>
Récupérer d'un disque en panne
C'est le processus à suivre si vous avez besoin de remplacer un disque défectueux. Si vous souhaitez émuler un remplacement, vous pouvez démarrer dans une session Ubuntu Live et utiliser
dd if=/dev/zero of=/dev/sdX
pour nettoyer le disque avant de redémarrer dans le système réel. Si vous venez de tester la redondance de démarrage/RAID dans la section ci-dessus, vous pouvez ignorer cette étape. Cependant, vous devez au moins effectuer les étapes 2 et 4 ci-dessous pour récupérer la redondance de démarrage/RAID complète de votre système.
La restauration du système de démarrage RAID + après le remplacement d’un disque nécessite les étapes suivantes:
- Partitionnez le nouveau lecteur.
- Ajouter des partitions aux périphériques md.
- Cloner la partition de démarrage.
- Ajoutez un enregistrement EFI pour le clone.
1. Partitionnez le nouveau disque
Copiez la table de partition à partir du lecteur en bonne santé:
Sudo sgdisk /dev/sdY -R /dev/sdX
Re-randomisez les UUID sur le nouveau lecteur.
Sudo sgdisk /dev/sdX -G
2. Ajouter aux périphériques md
Sudo mdadm --add /dev/md0 /dev/sdX2
Sudo mdadm --add /dev/md1 /dev/sdX3
3. Cloner la partition de démarrage
Clonez le ESP à partir du disque sain. (Attention, faites peut-être d'abord une sauvegarde dans un fichier des deux ESP pour permettre la récupération si vous le ratez vraiment.)
Sudo dd if=/dev/sdY1 of=/dev/sdX1
4. Insérez le disque récemment relancé dans la séquence d'amorçage.
Ajoutez un enregistrement EFI pour le clone. Modifiez le libellé -L selon les besoins.
Sudo efibootmgr -c -g -d /dev/sdX -p 1 -L "Ubuntu #2" -l '\EFI\ubuntu\grubx64.efi'
Maintenant, le redémarrage du système devrait revenir à la normale (les périphériques RAID sont peut-être encore en phase de synchronisation)!
Pourquoi le script de sommeil?
La communauté a suggéré que l'ajout d'un script de veille pourrait être inutile et pourrait être remplacé par GRUB_CMDLINE_LINUX="rootdelay=30" dans /etc/default/grub suivi de Sudo update-grub. Cette suggestion est certainement plus propre et fonctionne dans un scénario de défaillance/remplacement du disque. Cependant, il y a une mise en garde ...
J'ai déconnecté mon deuxième disque SSD et découvert qu'avec rootdelay=30, etc. au lieu du script de veille:
1) Le système ne démarre pas en mode dégradé sans le lecteur "en panne".
2) Au démarrage non dégradé (deux lecteurs présents), le temps de démarrage est réduit. Le retard n'est perceptible qu'avec le deuxième disque manquant.
1) et 2) sonnait bien jusqu'à ce que je rajoute mon deuxième disque. Au démarrage, la matrice RAID n'a pas pu s'assembler et m'a laissé à l'invite initramfssans savoir quoi faire. Il aurait peut-être été possible de sauver la situation en a) démarrant sur la clé USB Ubuntu Live, b) en installant mdadmet c) en assemblant le tableau manuellement mais ... je me suis trompé quelque part. Au lieu de cela, quand j’ai relancé ce test avec le script de veille (oui, j’ai démarré le HOWTO du haut pour la nième fois ...), le système n'a démarré. Les tableaux étaient en mode dégradé et je pouvais rajouter manuellement les partitions /dev/sdb[23] sans clé USB supplémentaire. Je ne sais pas pourquoi le script de veille fonctionne alors que rootdelayne fonctionne pas. mdadmest peut-être dérouté par deux périphériques légèrement désynchronisés, mais je pensais que mdadmétait conçu pour gérer cela. Quoi qu'il en soit, puisque le script de sommeil fonctionne, je m'y tiens.
On pourrait faire valoir que retirer un périphérique RAID parfaitement sain, réinitialiser le RAID en mode dégradé puis rajouter le périphérique composant est un scénario irréaliste: le scénario réaliste est plutôt celui d'un périphérique en panne qui est remplacé par un nouveau , ce qui laisse moins de chance à mdadmd’être confus. Je suis d'accord avec cet argument. Cependant, je ne sais pas comment tester la façon dont le système tolère une panne matérielle, à moins de désactiver du matériel! Et après les tests, je souhaite revenir à un système redondant et opérationnel. (Eh bien, je pourrais joindre mon deuxième disque SSD à une autre machine et le glisser avant de le rajouter, mais ce n'est pas faisable.)
En résumé: À ma connaissance, la solution rootdelayest propre, plus rapide que le script de veille pour les démarrages non dégradés et devrait fonctionner pour un scénario de panne/remplacement de lecteur réel. Cependant, je ne sais pas comment le tester. Donc, pour le moment, je vais m'en tenir au script de sommeil moche.
Ma suggestion concerne le système d’exploitation Debian, mais je pense que cela fonctionnerait également pour Ubuntu et d’autres.
Un moyen possible de résoudre un problème qui survient avec de nombreuses cartes mères ne manipulant pas correctement les entrées UEFI (Debian ne démarre pas même si vous avez entré le bon code efibootmgr -c -g -d /dev/sda -p 1 -w -L "debian" -l /EFI/debian/grubx64.efi, UEFI BIOS affiche un disque amorçable "debian" mais ne démarre pas depuis. it), consiste à utiliser à la place l'entrée générique /boot/efi/EFI/boot/bootx4.efi.
Par exemple, Asus Z87C n'aime pas /EFI/debian/grubx64.efi.
Donc, si vous avez monté la partition efi /dev/sda1 dans /boot/efi path:
mkdir /boot/efi/EFI/boot
cp /boot/efi/EFI/debian/grubx64.efi /boot/efi/EFI/boot/bootx4.efi
Puis redémarrez.
Le BIOS UEFI verra un disque générique "UEFI OS", ainsi que toute autre entrée précédemment créée avec efibootmgr, mais il démarrera sans problème à partir du générique "UEFI OS".