Comment installer Ubuntu 14.04 / 16.04 64 bits avec une partition RAID 1 à double démarrage sur un système UEFI / GPT?

22

Mise à jour: la question et la réponse ci-dessous s'appliquent également à Ubuntu 16.04

J'ai un ordinateur avec deux 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 et toujours pouvoir démarrer en double mon système Win7. Est-ce possible?

Ce guide utilisant le programme d'installation de bureau n'a pas fonctionné, probablement parce qu'il suppose (implicitement) le démarrage du MBR. L' installation du serveur de distribution n'a pas non plus fonctionné , probablement pour la même raison.

Niclas Börlin
la source

Réponses:

36

MISE À JOUR: J'ai vérifié que la description ci-dessous fonctionne également pour Ubuntu 16.04. D'autres utilisateurs ont signalé avoir travaillé les 17.10 et 18.04.1.

REMARQUE: ce HOWTO ne vous donnera pas LVM. Si vous souhaitez également LVM, essayez plutôt d' installer le bureau Ubuntu 18.04 avec RAID 1 et LVM sur une machine avec BIOS UEFI .

Après des jours d'essais, j'ai maintenant un système qui fonctionne! En bref, la solution comprenait les étapes suivantes:

  1. Démarrez à l'aide d'un Ubuntu Live CD / USB.
  2. Partitionne les SSD selon les besoins.
  3. Installez les packages manquants (mdadm et grub-efi).
  4. Créez les partitions RAID.
  5. Exécutez le programme d'installation d'Ubiquity (mais ne démarrez pas sur le nouveau système).
  6. Corrigez le système installé (initramfs) pour activer le démarrage à partir d'une racine RAID.
  7. Remplissez la partition EFI du premier SSD avec GRUB et installez-la dans la chaîne de démarrage EFI.
  8. Clonez la partition EFI sur l'autre SSD et installez-la dans la chaîne de démarrage.
  9. Terminé! Votre système aura désormais une 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 sont intactes.

Un élément clé de l'étape 6 de la solution était un retard dans la séquence de démarrage qui, autrement, me plaçait carrément à l'invite GRUB (sans clavier!) Si l'un des SSD était manquant.

HOWTO détaillé

1. Démarrage

Démarrez en utilisant EFI à partir de la clé USB. Exactement comment variera votre système. Sélectionnez Essayer ubuntu sans installer .

Démarrez un émulateur de terminal, par exemple xtermpour exécuter les commandes ci-dessous.

1.1 Se connecter depuis un autre ordinateur

En essayant cela, j'ai souvent trouvé plus facile de me connecter à partir d'un autre ordinateur déjà entièrement configuré. Ce copier-coller simplifié des commandes, etc. Si vous souhaitez faire de même, 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émarrerez votre nouvel ordinateur.

passwd

Vous pouvez maintenant vous connecter à la session live ubuntu depuis un autre ordinateur. Les instructions ci-dessous concernent Linux:

ssh -l ubuntu <your-new-computer>

Si vous recevez un avertissement concernant une attaque suspecte d'homme au milieu, vous devez effacer les clés ssh utilisées pour identifier le nouvel ordinateur. Ceci est dû au faitopenssh-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 live ubuntu.

2. Disques de partition

Supprimez toutes les anciennes partitions et 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: 100M pour ESP, 32G pour RAID SWAP, reste pour la racine RAID. Si votre lecteur sda 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)

Procédez comme suit:

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 (régénérera en fait des UUID pour sda).

sudo sgdisk /dev/sda -R /dev/sdb -G

2.2 Créer des tables de partition (/ dev / sdb est plus petit)

Procédez comme suit:

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 (régénérera en fait des UUID pour sdb).

sudo sgdisk /dev/sdb -R /dev/sda -G

2.3 Créer un système de fichiers FAT32 sur / dev / sda

Créez un 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. Installez les packages manquants

Le CD 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 maintenir la symétrie avec l'installation à venir, apportez-la é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 devrez peut-être grub-efi-amd64-signedau lieu degrub-efi-amd64 si vous avez activé le démarrage sécurisé. (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 terminés plus tard. La création d'un RAID1 complet m'a parfois posé des problèmes lors de l' ubiquityinstallation ci-dessous, je ne sais pas 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 l'état 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 d'ubiquité, à l'exclusion 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 à la place sur votre nouvel ordinateur.)

sudo ubiquity -b

Choisissez Autre chose comme type d'installation et modifiez le md1p1type en ext4, format: oui et point de montage /. La md0p1partition sera automatiquement sélectionnée comme swap.

Obtenez une tasse de café pendant la fin de l'installation.

Important: Une fois l'installation terminée, sélectionnez Continuer les tests car le système n'est pas encore prêt à démarrer.

Complétez les périphériques RAID

Attachez 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 se poursuivre pendant la synchronisation, y compris les redémarrages.

6. Configurez le système installé

Configurer pour activer 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

Configurez et installez 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 md sont toujours en cours de synchronisation, vous pouvez voir des avertissements occasionnels comme:

/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

La désactivation quick_bootévitera que les écritures de Diskfilter ne soient des bogues pris en charge . La désactivation quiet_bootn'a qu'une préférence personnelle.

Modifiez /etc/mdadm/mdadm.conf pour supprimer toute référence d'étiquette, c.-à-d. Changez

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 n'est peut-être pas nécessaire, mais j'ai vu certaines pages suggérer que les schémas de dénomination peuvent être instables (nom = ubuntu: 0/1) et cela peut empêcher un périphérique RAID parfaitement fin de s'assembler pendant le démarrage.

Modifier les lignes /etc/default/grubpour 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

(Il a été suggéré par la communauté que cette étape pourrait être inutile et peut être remplacée en utilisant GRUB_CMDLINE_LINUX="rootdelay=30"in /etc/default/grub. Pour des raisons expliquées au bas de ce HOWTO, je suggère de s'en tenir au script sleep même s'il est plus laid que d'utiliser rootdelay. Ainsi, nous continuons avec notre programme régulier ... )

Créez un script qui attendra le règlement des périphériques RAID. 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 révélé avant d'avoir déconnecté l'un des SSD pour simuler une défaillance du disque! La synchronisation peut devoir être ajustée en fonction du matériel disponible, par exemple des 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"

Rendez le script exécutable et installez-le.

chmod a+x /usr/share/initramfs-tools/scripts/local-premount/sleepAwhile
update-grub
update-initramfs -u

7. Activez 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(aka EFI/Ubuntusur /dev/sda1) et l'installera d'abord dans la chaîne de démarrage UEFI sur l'ordinateur.

8. Activez le démarrage à partir du deuxième SSD

Nous avons presque fini. À ce stade, nous devrions pouvoir redémarrer le sdalecteur. De plus, mdadmdevrait être en mesure de gérer l' échec de l' une ou l' autre sdaou d' sdbentraînement. Cependant, l'EFI n'est pas 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, cela fera correspondre l'UUID du système de fichiers FAT32 sur la sdb1partition (comme indiqué par blkid) à celui de sda1et /etc/fstab. (Notez cependant que les UUID des partitions /dev/sda1et /dev/sdb1seront toujours différents - comparez ls -la /dev/disk/by-partuuid | grep sd[ab]1avec blkid /dev/sd[ab]1après l'installation pour vérifier par vous-même.)

Enfin, nous devons insérer la sdb1partition dans l'ordre de démarrage. (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 d'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 l'ESP sur sdaet sdb.

Cela va générer une impression de l'ordre de démarrage actuel, 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 qu'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 dans 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

pour attacher le chargeur de démarrage Windows à la chaîne de démarrage grub.

Problèmes de machine virtuelle

Si vous voulez d'abord essayer cela sur une machine virtuelle, il y a quelques 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 UEFI Shell. Les commandes suivantes devraient vous démarrer sur votre machine à partir de /dev/sda1(utiliser FS1:pour /dev/sdb1):

FS0:
\EFI\ubuntu\grubx64.efi

La première solution dans la première réponse du démarrage UEFI dans 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 mdadm. Cependant, pour vérifier que les éléments de démarrage survivraient à une défaillance du disque, j'ai dû éteindre l'ordinateur et déconnecter 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éconnectez 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 à partir d'un disque défaillant

C'est le processus à suivre si vous avez eu 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 sur 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 pour votre système.

La restauration du système d'amorçage RAID + après un remplacement de disque nécessite les étapes suivantes:

  1. Partitionnez le nouveau lecteur.
  2. Ajoutez des partitions aux périphériques md.
  3. Clonez la partition de démarrage.
  4. Ajoutez un enregistrement EFI pour le clone.

1. Partitionnez le nouveau lecteur

Copiez la table de partition du lecteur sain:

sudo sgdisk /dev/sdY -R /dev/sdX

Re-randomiser les UUID sur le nouveau lecteur.

sudo sgdisk /dev/sdX -G

2. Ajouter aux appareils md

sudo mdadm --add /dev/md0 /dev/sdX2
sudo mdadm --add /dev/md1 /dev/sdX3

3. Clonez la partition de démarrage

Clonez l'ESP du disque sain. (Attention, peut-être effectuez d'abord un vidage vers un fichier des deux ESP pour activer la récupération si vous le faites vraiment foirer.)

sudo dd if=/dev/sdY1 of=/dev/sdX1

4. Insérez le disque récemment relancé dans l'ordre de démarrage

Ajoutez un enregistrement EFI pour le clone. Modifiez l'étiquette -L selon vos 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 le ramener à la normale (les périphériques RAID peuvent toujours se synchroniser)!

Pourquoi le script sleep?

Il a été suggéré par la communauté que l'ajout d'un script de sommeil pourrait être inutile et pourrait être remplacé par l'utilisation GRUB_CMDLINE_LINUX="rootdelay=30"de /etc/default/grubsuivi de sudo update-grub. Cette suggestion est certainement plus propre et fonctionne dans un scénario de panne / remplacement de disque. Cependant, il y a une mise en garde ...

J'ai déconnecté mon deuxième SSD et j'ai découvert qu'avec rootdelay=30, etc. au lieu du script de veille:
1) Le système démarre en mode dégradé sans le disque "en panne".
2) En démarrage non dégradé (les deux disques sont présents), le temps de démarrage est réduit. Le retard n'est perceptible qu'avec le second 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' initramfsinvite sans 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 réassemblant la baie manuellement mais ... je me suis trompé quelque part. Au lieu de cela, lorsque j'ai relancé ce test avec le script sleep (oui, j'ai démarré le HOWTO par le haut pour la nième fois ...), le système a démarré. Les baies étaient en mode dégradé et je pouvais rajouter manuellement les /dev/sdb[23]partitions sans clé USB supplémentaire. Je ne sais pas pourquoi le script sleep fonctionne alors que le script rootdelayne fonctionne pas. Peut-être mdadmconfondu par deux appareils composants légèrement désynchronisés, mais je pensaismdadma été 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 la suppression d'un périphérique de composant RAID parfaitement sain, le redémarrage du RAID en mode dégradé, puis le rajout du périphérique de composant est un scénario irréaliste: le scénario réaliste est plutôt qu'un périphérique tombe en panne et est remplacé par un nouveau. , laissant moins de possibilités mdadmde se confondre. Je suis d'accord avec cet argument. Cependant, je ne sais pas comment tester comment le système tolère une panne matérielle, sauf pour désactiver réellement certains matériels! Et après les tests, je veux revenir à un système redondant et fonctionnel. (Eh bien, je pourrais attacher mon deuxième SSD à une autre machine et le faire glisser avant de le rajouter, mais ce n'est pas possible.)

En résumé: à ma connaissance, la rootdelaysolution est propre, plus rapide que le script de mise en veille pour les démarrages non dégradés, et devrait fonctionner pour un scénario de panne / remplacement de disque réel. Cependant, je ne connais pas de moyen réalisable de le tester. Donc, pour le moment, je m'en tiendrai au script de sommeil laid.

Niclas Börlin
la source
Remarque 1: Si vous démarrez accidentellement dans Windows pendant votre installation et que DHCP échoue mystérieusement plus tard (ce qui m'est arrivé) lorsque vous redémarrez dans Ubuntu (en direct ou autrement), l'arrêt + le redémarrage de l'ordinateur + les routeurs peuvent aider. Apparemment, certains routeurs essaient d'être "intelligents" sur les requêtes DHCP récurrentes qui, pour une raison quelconque, affectent Ubuntu mais pas Windows ... soupir
Niclas Börlin
1
Remarque 2: Bien que la séquence de démarrage installée ci-dessus suggère que le chargeur de démarrage sur sdb soit utilisé, vous pouvez constater que / boot / efi est toujours monté à partir de sda ​​( mount | grep efi). Apparemment, Linux monte la première partition dont blkid correspond /etc/fstab. Cela ne devrait cependant pas être un problème.
Niclas Börlin
Remarque 3: Si, pour une raison quelconque, vous vous retrouvez sans pouvoir démarrer sur vos appareils md (par exemple, en gâchant la récupération de la partition de démarrage à l'étape 3 ci-dessus), j'ai pu récupérer l'accès en démarrant à l'aide du support Ubuntu Live suivi de apt-get install mdadmet mdadm -A /dev/md0 mdadm -A /dev/md1.
Niclas Börlin
3
Oui. :) Voilà comment j'ai configuré mon système.
Niclas Börlin du
1
J'ai dû installer grub-efi-amd64-signedsinon j'obtenais une erreur efi "signature invalide" si le démarrage sécurisé était activé.
Alecz
0

Ma suggestion est pour Debian OS, mais je pense que cela fonctionnerait également pour Ubuntu et d'autres.

Une façon possible de résoudre un problème qui se produit avec beaucoup de cartes mères qui ne gèrent pas correctement les entrées UEFI (Debian ne démarre pas même si vous avez fait la bonne entrée efibootmgr -c -g -d /dev/sda -p 1 -w -L "debian" -l /EFI/debian/grubx64.efi, le BIOS UEFI affiche un disque de démarrage "debian" mais il ne démarre pas à partir de celui-ci ), est d'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 sur /boot/efipath:

mkdir /boot/efi/EFI/boot
cp /boot/efi/EFI/debian/grubx64.efi /boot/efi/EFI/boot/bootx4.efi

Redémarrez ensuite.

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".

Nicola Giampietro
la source