Boot cassé Le sujet est résolu

[sioban]

Coucou tout le monde

J'ai besoin de votre aide bienveillante...

J'essaie de résoudre un problème de boot et je suis assez perdue.
Ce matin, j'ai redémarré mon serveur Debian pour appliquer un nouveau noyau.

Mais le système a refusé de démarrer en affichant cette erreur : "Error 1962 : no operating system found" (erreur 1962 : aucun système d'exploitation trouvé)
D'après ce que j'ai vu, l'erreur peut être liée au câble SATA ou à un disque dur défaillant.

J'ai deux disques en miroir et je doute que le problème vienne des disques.
Ils sont vus par le système, je peux même les monter à l'aide d'un Live CD.

J'ai donc cherché du coté de grub ou d'UEFI.

J'ai changé le mode UEFI en Legacy dans le bios et ce
Cette fois, le boot a atteint Grub mais je passe en Grub Rescue avec l'erreur: "error : disk 'mduuid/ba60d49b53e45326ba6fdb4c393e7420' not found"

J'ai essayé l'iso usb live debian pour installer boot-repair.
Voici les résultats :
> UEFI mode: https://paste.debian.net/hidden/a605c991/
> Legacy mode: https://paste.debian.net/hidden/dec6d8d2/
(vous pouvez ignorer le grub dans le mbr sur sdd, c'est probablement un reliquat d'une ancienne installation)

Une chose m'inquiète dans les rapports : "GPT detected. Please create a BIOS-Boot partition (>1MB, unformatted filesystem, bios_grub flag). This can be performed via tools such as Gparted. Then try again."
Je ne sais pas trop quoi en penser et si je peux lancer boot-repair ou pas (j'ai l'impression que non :/)

Ce que je ne comprends pas c'est que les partitions sda1/sdb1 où se trouve (selon mes souvenirs) la partition EFI ne sont pas montables.
Pas automontées par mdadm et quand j'essaie de les monter via mount j'ai une erreur comme quoi ce sont des partitions raid.

A ce stade, c'est au-delà de mes compétences et les recherches que j'ai faites sur Google ne m'ont pas vraiment aidée.

Mon système is a Lenovo Thinkstation P500
Mes disques sont deux SSD:
- sda: CT1000MX500SSD1
- sdb: CT1000MX500SSD1

Je peux essayer de vous donner plus d'informations si vous le souhaitez, il faut juste m'indiquer les commandes à exécuter.

Merci beaucoup pour vos lumières.

[adlp]

Salut,

Bon vu tes messages je me demande si
a) Ton grub sait encore voire les disques (meme si c'est son propre support, il a besoin de drivers)
b) Ton uuid aurait changé ( j'ai des doutes vue ce que tu as fait)

Bref, deja, dans le shell de grub, regarde s'il arrive avoir les disque (la commande ls ferait cela)
Et sinon, si tu tennuie, essaye de preciser une autre variable au kernel comme root fs, avec un truc du genre /dev/mda1 ou pire /dev/sda1 (cela ne devrait pas poser trop de pb je pense, car le vrai mount sera fait par l'OS lui meme)

'Toine

[PascalHambourg]

Mes disques sont deux SSD:
- sda: CT1000MX500SSD1
- sdb: CT1000MX500SSD1

Et sdc et sdd ?

D'après le rapport de boot-repair, les partitions sda1 et sdb1 sont de type ESP dans la table de partition mais sont en RAID format 1.2, ce qui n'est pas cohérent, mais ne portent pas d'ensemble RAID actif.
D'autre part elles ont les mêmes UUID (d'ensemble RAID) et UUID_SUB (de membre RAID) que la partition sdc1, ce qui n'est pas normal car l'UUID_SUB est censé être unique. sdc1 porte un ensemble RAID actif avec sdd1.

Le plan d'action serait donc de booter en mode EFI, reformater sda1 en FAT, chrooter sur la racine du système, monter tout ce qu'il faut (/dev /proc /sys /run) monter sda1 sur /boot/efi, réinstaller GRUB avec

Code : Tout sélectionner

grub-install --force-extra-removable

puis faire de même avec sdb1.
Puis mettre l'UUID de l'une des deux pour /boot/efi dans /etc/fstab.

[sioban]

Hello,

Merci beaucoup pour ce retour détaillé :D

Je n'avais pas précisé SDC et SDD car ils n'entrent pas dans la chaîne du boot mais dans tous les cas, on peut les voir dans le boot-repair.
Ce sont des WDC WD5003ABYZ-011FA0.

Je pense effectivement que le soucis vient des sda1/sdb1 qui ne sont pas dans le bon format.

Voilà ce que je compte faire en reprenant tes recommandations:
- boot en live cd Debian
- installer gparted et grub-efi-amd64
- reformater sda1/sdb1 en FAT32 via gparted (pour simplifier)
- mettre le drapeau boot
- monter tout ça (/usr /boot /boot/efi /dev /proc /sys /run) avec sda1
- chroot
- grub-install --force-extra-removable
- démonter sda1, monter sdb1 en /boot/efi
- recommencer
- mettre l'UUID de sda1 dans /etc/fstab

ça me semble plutôt cohérent et ya plus qu'a.

Petite question subsidiaire, lors des updates futurs de grub/kernel, est-ce que je devrais recommencer les manips montage/démontage de la partition efi pour synchroniser les deux ou il y a un système un peu plus automatisé ?

[PascalHambourg]

installer gparted et grub-efi-amd64

Pas besoin d'installer gparted dans le système live, mkfs.fat du paquet dosfstools suffit pour formater en FAT.
Installer grub-efi-amd64 dans le système live ne sert à rien puisqu'il faut exécuter grub-install dans le chroot.

mettre le drapeau boot

Inutile, avec GPT le drapeau boot est équivalent au drapeau esp (encore une choix discutable de parted) qui est déjà présent sur les partitions EFI.

mettre l'UUID de sda1 dans /etc/fstab

L'entrée de boot EFI "debian" créée par grub-install pointe vers la partition EFI qui était montée lors de la dernière exécution de grub-install (donc sdb1).
En cas de mise à jour des paquets grub ou shim, c'est la partition EFI actuellement montée sur /boot/efi qui sera mise à jour automatiquement (donc sda1).
Il serait plus cohérent que ce soit la même.

lors des updates futurs de grub/kernel, est-ce que je devrais recommencer les manips montage/démontage de la partition efi pour synchroniser les deux ou il y a un système un peu plus automatisé ?

Bonne question. Avec GRUB comme chargeur d'amorçage les mises à jour de noyau n'impactent pas la partition EFI (c'est différent avec systemd-boot). En revanche, comme écrit ci-dessus, dans Debian la mise à jour de grub (rare) ne met à jour que la partition EFI montée sur /boot/efi. C'est différent dans Ubuntu qui a un mécanisme (pas très propre) pour gérer automatiquement plusieurs partitions EFI. L'UEFI ne supportant évidemment pas le RAID logiciel de Linux, différents bricolages ont été suggérés pour synchroniser automatiquement plusieurs partitions EFI :
- script appelé lors des mises à jour de noyau (mais ce n'est pas le bon endroit)
- partitions EFI en RAID1 logiciel au format 1.0 (superbloc à la fin), ce qui permet au firmware UEFI de les voir comme des partitions normales, à condition de ne pas écrire dedans sinon le RAID1 est corrompu, et ne permet pas l'enregistrement par grub-install dans les entrées de boot EFI, ce qui oblige à installer dans le chemin de support amovible et/ou à enregistrer dans les entrées de boot EFI manuellement avec efibootmgr (à faire une seule fois pour chaque partition EFI)
- exécution de rsync pour synchroniser le contenu des partitions EFI périodiquement

Mais vu la faible fréquence de mise à jour des paquets grub et shim, on peut se permettre de le faire manuellement.

L'alternative, puisque le serveur supporte l'amorçage legacy, c'est de remplacer l'amorçage EFI par l'amorçage legacy avec grub-pc qui supporte nativement plusieurs disques sans bricolage douteux. Sur les disques au format GPT il faudra juste créer une petite partition de type "BIOS boot"/bios_grub (entre 100 ko et 1 Mo, non formatée) en prérequis. Il y a quasiment toujours un espace libre suffisant pour cette partition. Et dans les options d'amorçage du firmware, modifier l'ordre d'amorçage legacy pour ne mettre que sda et sdb et pas sdc ni sdd.

[sioban]

J'ai pu avancer.

L'UUID de sda1 avait changé avec le reformatage, j'ai donc du le mettre d'équerre dans le fstab.

J'ai pu avoir le boot mais lors du boot, j'ai une grosse erreur que j'ai prise en photo.

[PascalHambourg]

Je ne vois pas le lien avec les partitions EFI. Ce sont des systèmes de fichiers et swap spécifiés dans /etc/fstab qui ne sont pas trouvés. S'il sont contenus dans des ensembles RAID, vérifier si ces derniers sont bien actifs depuis le shell de dépannage après avoir saisi le mot de passe root.

Code : Tout sélectionner

lsblk -f
cat /proc/mstat
mdadm --examine --scan

(un peu les mêmes commandes que celles du rapport de boot-repair)

[sioban]

Pour info, j'ai essayé de boot avec selinux=0 mais même problème.

Les répertoires en question sont sur le 2eme ensemble raid (sdc/sdd).
lsblk -f ne les affichent pas
/proc/mdstat confirme que le 2eme ensemble n'existe pas à ce stade
idem pour mdadm.

Donc pour moi, pour une raison que je ne saisis pas pour l'instant, il ne veut pas monter la 2eme grappe de disque en Raid

[sioban]

Ok, je crois avoir compris.

un fdisk -l me montre qu'il n'y a pas de partitions...

j'avais voulu nettoyer le mbr pour supprimer les grub sur ces disques suite à ce message de boot repair:
"Grub2 (v2.00) is installed in the MBR of /dev/sdd and looks at sector 1 of
the same hard drive for core.img. core.img is at this location and looks
for (mduuid/ba60d49b53e45326ba6fdb4c393e7420)/grub"

j'ai utilisé "dd if=/dev/zero of=/dev/sdc bs=512 count=1" mais ça a du flingué la liste des partitions.

Je pense que je suis bonne pour tout reconstruire sauf s'il y a un moyen magique de la récuperer.

[PascalHambourg]

Il ne fallait effacer que les 440 premiers octets du MBR.

Pas besoin de magie pour recréer les tables de partition, tu as toutes les informations dans le rapport de boot-repair.

Code : Tout sélectionner

      Boot     Start       End   Sectors   Size Id Type
sdc1            2048  58722303  58720256    28G fd Linux raid autodetect
sdc2        58722304 125831167  67108864    32G fd Linux raid autodetect
sdc3       125831168 220203007  94371840    45G fd Linux raid autodetect
sdc4       220203008 976773167 756570160 360.8G  5 Extended
sdc5       220205056 314576895  94371840    45G fd Linux raid autodetect
sdc6       314578944 408950783  94371840    45G fd Linux raid autodetect
sdc7       408952832 976773167 567820336 270.8G fd Linux raid autodetect

Je recommande d'utiliser fdisk pour cela.

[PascalHambourg]

Autre possibilité pour éviter les erreurs de saisie manuelle dans fdisk : créer un fichier de table de partition à injecter avec sfdisk.

[sioban]

j'ai utilisé testdisk mais, clairement on dirait qu'il y a un soucis:

Code : Tout sélectionner

/dev/sdc1  *         2048  58689535  58687488    28G fd Linux raid autodetect
/dev/sdc2        58722304 125765631  67043328    32G fd Linux raid autodetect
/dev/sdc3       125831168 220137471  94306304    45G fd Linux raid autodetect
/dev/sdc4       220137472 976773119 756635648 360.8G  f W95 Ext'd (LBA)
/dev/sdc5       220205056 314511359  94306304    45G fd Linux raid autodetect
/dev/sdc6       314578944 408885247  94306304    45G fd Linux raid autodetect
/dev/sdc7       408952832 976510975 567558144 270.6G fd Linux raid autodetect

les starts sont bon mais pas les fins.

et gparted me montre bien qu'il y a un soucis, j'ai des partitions "unallocated" entre chaque partition.

Si j'utilise fdisk, il ne va pas me supprimer les données??

Là je vais attendre ta réponse avant d'aller plus loin...
Clairement, à vouloir essayer par moi même j'ai bien l'impression que je fais plus de mal que de bien...

[PascalHambourg]

Je n'ai jamais fait confiance à testdisk pour retrouver des partitions perdues, ses résultats ne sont pas assez fiables. Il place le début de la partition étendue sdc4 et donc écrit la première table de partition étendue (EBR) à l'intérieur de la partition précédente sdc3 (et possiblement les EBR suivants à l'intérieur des partitions logiques aussi) donc j'espère que tu n'as pas enregistré sa proposition sur le disque ou bien que ces emplacements ne contenaient aucune donnée.

Je te suggère d'utiliser sfdisk pour recréer correctement la table de partition.
1) Crée un fichier texte avec le contenu suivant (les espaces pour aligner sont facultatifs) :

Code : Tout sélectionner

label: dos

sdc1 : start=      2048, size=  58720256, type= fd
sdc2 : start=  58722304, size=  67108864, type= fd
sdc3 : start= 125831168, size=  94371840, type= fd
sdc4 : start= 220203008, size= 756570160, type= f
sdc5 : start= 220205056, size=  94371840, type= fd
sdc6 : start= 314578944, size=  94371840, type= fd
sdc7 : start= 408952832, size= 567820336, type= fd

2) Simule l'application du fichier avec la commande suivante :

Code : Tout sélectionner

sfdisk --wipe-partitions=never --no-act /dev/sdc < fichier

Normalement la commande devrait afficher comme résultat la table de partition identique à celle que j'ai récupérée de boot-repair. Si c'est le cas, tu peux l'appliquer en répétant la même commande sans l'option --no-act. L'option --wipe-partitions=never préservera le superbloc des partitions.
Puis répéter l'opération sur sdd avec le même fichier, inutile de remplacer "sdc" par "sdd" dans le fichier, seulement dans la commande.

[sioban]

OMG j'ai tout récupéré !!!!

Un énorme merci pour ton aide, tu as été génial, patient et tu m'as vraiment fourni les commandes qui m'ont permis d'avancer

Franchement, je ne sais pas ce que j'aurais fait sans toi !

Encore merci.

Si un jour tu passes sur Nantes, je te dois une bière ou tout autre boisson non alcoolisée!

[PascalHambourg]

Une remarque générale sur la configuration RAID de ce serveur : avec un découpage aussi important, je n'aurais pas créé un ensemble RAID par volume. C'est trop rigide en cas de besoin de redimensionner des volumes (redimensionner un ensemble RAID est une plaie), et ça nécessite de reconstruire chaque ensemble l'un après l'autre en cas de remplacement de disque. J'aurais plutôt créé un seul ensemble RAID par jeu de disques, et l'aurais découpé en volumes logiques avec LVM qui est beaucoup plus flexible pour le redimensionnement ou la création de volumes.

[sioban]

Oui c'est ce qu'on me dit souvent mais LVM m'a toujours fait peur car je trouve ça complexe, et j'avoue que LVM+RAID ça me dépasse vu déjà comment le RAID me pose soucis :(

Et justement j'ai des partitions un peu "perdues" sur le 1er set :/ (partitions déplacées sur le 2nd set)
Je pense démarrer en live cd pour redimensionner avec gparted mais j'avoue que je suis frileuse/

[PascalHambourg]

Je en suis pas sûr qu'il soit possible de redimensionner des partitions RAID avec gparted car il faut également redimensionner l'ensemble RAID correspondant ainsi que son contenu, et au bon moment selon qu'on agrandit ou réduit.