WIKI of Le Bottin des Jeux Linux / The Linux Games Book

Contexte :

• Après une mise à jour sous Synaptic traitée un peu à la légère (j'étais absorbé sur autre chose, je n'ai pas regardé de près comment se passait la mise à jour de Grub2), le lendemain je constate que mon système ne démarre plus.

Raisons possibles :

• J'ai constaté après mon dépannage que j'avais copié le MBR sur /dev/sda1 au lieu de /dev/sda.
• Un bug de Grub2 v.2.04-1, ce qui, après réflexion et REX, serait très étonnant, car cette version est encore disponible en dépôts plusieurs jours après (donc soit je suis le seul touché - hautement improbable, soit c'est encore un truc spécifique qui m'a plombé tout seul)

Problèmes rencontrés :

• Ce qui complique les choses c'est que mes disques (notamment /usr et /var) sont montés en RAID 1 sur mon SSD (qui est la racine du système) et que je n'ai qu'une confiance très limitée en mdadm en situation de crise (j'ai déjà perdu le contenu de l'un de mes disques principaux lors d'une opération analogue, sans comprendre vraiment pourquoi)
• Pas moyen de faire un chroot sur le disque à dépanner qui me renvoi systématiquement une erreur avec les commandes ls et mount (pas de /usr disponible, ni /var).
• Pas moyen de réinstaller Grub depuis la clé de dépannage (netinstall Debian) : dans tous les cas il signalait une erreur (voir plus bas).
• Pas moyen de lancer un noyau depuis Grub (sous Grub, la commande de chargement du noyau - dénommée “linux”, renvoyait une erreur)

Ce qui m'a sauvé :

• Une copie d'un répertoire /boot précédent (avec peu d'adaptations à réaliser pour le faire fonctionner) sur une clé USB
• De ne pas avoir baissé les bras ;)

Leçons retenues :

• Toujours conserver une copie du répertoire /boot (à nommer /boot-sv par exemple) fonctionnel et pas trop vieux sur le disque racine pour un dépannage ultérieur. Elle permettra de démarrer (moyennant quelques manipulations depuis une clé de dépannage).
• Toujours vérifier attentivement les mises à jour de Grub2 et des noyaux
• Garder quelques noyaux fonctionnels en réserve sous Grub

Le dépannage :

• J'utilise un netinstall Debian présent sur l'une de mes clés USB

J'ai à peine ré-installé mon système précédent qu'une nouvelle version de Grub vient casser son démarrage :)) J'ai vu passer les paquets grub, mais je ne me suis pas méfié…

Du coup au démarrage suivant j'ai le droit dès le début à un message :

error: symbol 'grub_file_filters' not found.
Entering rescue mode...
grub rescue>

Restons calme :))

C'est l'occasion d'aborder le dépannage à partir d'un netinstall Debian (indispensable) que vous aurez installé sur une clé USB (à partir d'un autre PC ou lorsque votre système fonctionne).

Quelques documentations :

• Sur le chroot : DebianFacile (chroot) et Le WIKI Debian
• Sur le répertoire /proc : Ubuntu-fr (À quoi sert le répertoire /proc ?)

Le netinstall Debian 64-bit : Installing Debian via the Internet
(la version 64-bit s'appelle amd64)

Le 10/07/2019 :

C'est la méthode que j'utilisais habituellement, mais je me rend compte qu'elle est obsolète (même si elle est tout à fait utilisable). Elle a le mérite de me permettre d'expliquer le chroot ;)

Nota à posteriori : ça n'a pas fonctionné car mes disques /usr et /var (en RAID 1) n'étaient pas montés, je n'y ai pas pensé sur le coup. Ensuite fstab ne parvient pas seul, à monter automatiquement (via le “# mount -a”) les partitions car les modules part_gpt.mod, diskfilter.mod, mdraid1x.mod et ext2.mod n'étaient pas chargés en mémoire je pense (je n'ai pas testé mais peut-être qu'un # modprobe suivi de ces modules aurait permis d'y arriver).

• Sur le menu de démarrage du netinstall Debian choisissez (je ne me souviens plus : à compléter)
• Vient les questions habituelles sur le pays, … (voir ci-avant, c'est identique)
• puis lorsqu'il va aborder le partitionnement des disques, vous pourrez choisir l'option “Revenir en arrière” qui vous fera revenir au menu principal de la clé.
• Choisissez “Exécuter un shell” et vous voilà en ligne de commande, sous la partition racine virtuelle montée par votre clé USB (ce n'est pas réellement sa partition physique mais une partition montée en mémoire).
• Il vous faudra connaître le périphérique de votre disque de démarrage (moi c'est /dev/sdb pour mon SSD) et le type de système de fichier installé (le plus courant actuellement étant ext4) et dans ce cas vous pouvez créer un répertoire (je l'ai appelé “tt” ci-après) sur cette partition virtuelle pour y monter votre disque :

# mkdir tt
# mount -t ext4 /dev/sdb1 tt
# cd tt
# ls

Vous êtes sur la partition racine de votre disque dur.

Le chroot permet de monter votre système client (ici votre disque dur à dépanner) sur votre système hôte (la partition racine virtuelle créée par votre clé USB) comme si vous aviez démarré dessus, afin d'y effectuer les opérations souhaitées.

Dans mon cas, l'idée est de voir si je peux soit réinstaller grub2 sur son MBR ou, si çà ne fonctionne pas comme prévu, d'essayer de réinstaller la précédente version de grub2 qui fonctionnait bien.

Je reprend la doc du site DebianFacile pour l'adapter à mon exemple :

Je reviens à la partition racine virtuelle de ma clé USB et y monte les périphériques que ma clé USB netinstall a trouvée (ces périphériques se trouvent sous la forme de fichiers sur le répertoire /dev virtuel de la clé USB, la commande –bind permet de les rediriger) :

# cd /
# mount --bind /dev /tt/dev

On monte aussi le répertoire /proc (un répertoire virtuel système, son système de fichier est de type “proc”, voir la doc Ubuntu-fr ci-avant pour l'utilité de ce répertoire)

# mount -t proc /proc /tt/proc

Puis l'on fait notre chroot :

# chroot tt
ou 
# chroot tt /bin/bash
(si vous souhaitez utiliser la console bash (il me semble que par défaut c'est la console sh)

Une fois cette commande lancée, le système se comporte comme si vous étiez sur votre client et aviez démarré dessus.

Je reprend le cours de mon dépannage :
Chez moi à présent lorsque je lance la commande précédente, j'ai :

# chroot tt /bin/bash
# ls
ls: error while loading shared libraries: libpcre2-8.so.0: cannot open shared object file: No such file or directory

Je vois sur un forum qu'en lançant la commande suivante ça a résolu un problème un peu analogue GitHub (Debian Jessie: Install succeeded but all tests failed #131) :

# ldconfig
# ls
ls: error while loading shared libraries: libpcre2-8.so.0: cannot open shared object file: No such file or directory

Sur le forum Ask Ubuntu (XFCE4-Terminal, error loading libraries libpcre) on conseille d'utiliser la commande suivante :

# /usr/bin/apt install --reinstall libpcre2-8-0
bash: /usr/bin/apt: No such file or directory

Si en plus je n'ai pas accès à apt…

Ok, j'avais oublié de monter mes répertoires, mais :

# exit
# cd /
# chroot tt /bin/bash
# mount -a
mount: error while loading shared libraries: libpcre2-8.so.0: cannot open shared object file: No such file or directory

Le casse-tête de l'été (“l'Escape Game” comme le surnomme mon frère à qui je confiais mes déboires), dont Debian a le secret… J'espère que vous n'êtes pas pressé, parce que là je sent que je suis parti encore pour quelques soirées…

Notez que la commande mdadm (montage de disques RAID) est disponible sous ce netinstall Debian dans les shell proposés ci-après.

Vous avez accès à un menu fort bien conçu qui vous propose :

• Exécuter un shell dans /dev/sdb1
• Exécuter un shell dans le contexte de l'installateur
• Réinstallation du programme de démarrage GRUB
• Changer de système de fichiers racine
• Redémarrer le système

Exécuter un shell dans /dev/sdb1

C'est un chroot direct sur mon disque.
Malheureusement dans le cas présent, lorsque je saisi (remarque à posteriori, car je n'y pensais pas à la rédaction des lignes ci-après : le problème dans ce cas était que mon /usr était un disque RAID 1 qui n'était pas monté) :

# chroot tt /bin/bash
# ls
ls: error while loading shared libraries: libpcre2-8.so.0: cannot open shared object file: No such file or directory

Il ne reconnaît plus les commandes ls, apt, mount
Ca va être un peu compliqué :)

Donc je clique sur le bouton “Revenir en arrière”

Réinstallation du programme de démarrage GRUB

Je saisi /dev/sdb1 (du fait de l'insertion de ma clé USB de dépannage, mon disque racine est devenu /dev/sdb) : L'exécution de “grub-install /dev/sdb1” a échoué. Cette erreur est fatale. Je précise que c'est mon 2ème redémarrage sur la clé, la première fois j'avais testé sur /dev/sdb (comme l'erreur est fatale, je pense qu'il valait mieux redémarrer et recommencer ma tentative).

Bon donc ça non plus c'est pas possible…

Exécuter un shell dans le contexte de l'installateur

Traduisez : vous n'êtes pas en chroot, votre disque à dépanner est monté sur l'un des répertoires (dénommé “/target”) de votre netinstall Debian et vous y avez accès à la fois en lecture et en écriture (et il est prêt à être chrooté si besoin).

Là il me précise que /dev/sdb1 (mon disque racine) est monté sur /target et que l'on peut utiliser les outils disponibles dans l'environnement de l'installateur. Si l'on a besoin d'utiliser /target comme racine, on peut utiliser la commande “chroot /target”. Si l'on a besoin d'autres systèmes de fichiers, comme un système de fichiers /usr distinct, on doit le monter soi-même.

Je clique sur “Continuer” et j'ai mon shell “externe” (je ne suis pas en chroot dans mon système en panne) sur le système de fichiers de la clé USB et mon disque en panne est monté sur /target

Le problème c'est que mes disques sont en RAID1.
Si je lance la commande (pour voir les périphériques disponibles) : # fdisk -l
(je ne vous met pas l'affichage car - du fait que je rédige actuellement depuis mon autre PC, il faudrait que je fasse un sacré paquet de saisies à la main)
Je vois mes disques RAID non assemblés (sous la forme de /dev/sdc et /dev/sdd, au lieu de /dev/md).

Si je veux les monter pour tenter de réparer, il faut que je trouve le moyen de les assembler en RAID depuis ma clé USB.

D'excellentes docs sur le RAID : UBUNTU-fr (RAID logiciel avec mdadm), et pour le RAID 1 : UBUNTU-fr (Comment installer Ubuntu sur un RAID-1 logiciel ?), ou WIKI Debian-fr (Raid logiciel (mdadm))

Cette dernière indique :

Cas 2 : panne du disque système, la grappe RAID est OK
(...)
"Choix 2 - Si vous aviez sauvegardé le fichier /etc/mdadm/mdadm.conf, vous pouvez le restaurer et taper la commande suivante :
# mdadm --assemble --scan
Choix 3 - (...)
# mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1
Choix 4 - (...)
# fdisk -l
(pour repérer les disques, puis : )
# mdadm --examine /dev/sdb1
(à adapter, pour examiner les disques, puis : )
# mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1
(à adapter, pour examiner les disques, puis : )
Une fois que tout est en ordre et bien synchro, tapez ceci :
# mdadm --detail --scan --verbose > /etc/mdadm/mdadm.conf

Donc voilà une piste intéressante que j'ai très envie de creuser : regarder dans /etc/mdadm/mdadm.conf si tout semble correct et en adéquation avec /etc/fstab, puis soit lancer la commande de montage complète et automatique (“# mdadm –assemble –scan”), soit les monter manuellement après examen de plus près (“# mdadm –examine /dev/sdb1”).

Mais pour l'instant j'ai aussi envie de tester le dépannage en direct via grub2 (très pénible à cause du manque de convivialité de grub2, mais peut-être intéressant à maîtriser).

Les 11/07/2019 et 12/07/2019 : voir Tentative de démarrage via le mode de dépannage de Grub

Le 13/07/2019 :

Le dépannage direct via grub2 semble compromis car visiblement Grub n'est pas en état de charger un noyau linux (la commande mount produit une erreur), ce qui semblerait indiquer que c'est bien le paquet Grub mis à jour qui est défectueux.

Ma stratégie ce matin (la nuit porte conseil :) :

• je met de côté les tests avec mdadm, en solution d'ultime secours, car je ne suis pas très chaud à lui redonner les rênes (la dernière fois j'ai perdu le contenu de mes 2 disques RAID sur une opération analogue - et je n'ai pas compris comment est-ce arrivé).
• Maintenant que je connais un peu mieux le fonctionnement de grub2, j'ai bien envie de récupérer un ancien paquet Debian de grub2 et de le décompresser manuellement (selon la même structure évidemment) dans /boot et ses répertoires. Car actuellement Grub2 démarre, donc le MBR est là, mais je pense qu'il y a un fichier ou un module qui ne fonctionne pas. Ca a de bonnes chances de fonctionner.

Tentative de Récupération d'une ancienne version de Grub2 :

Nota à posteriori : à ce moment de mes tests je m'interdit encore le montage des disques en RAID 1 par manque / perte de confiance envers mdadm en situation de crise (en fonctionnement normal j'ai confiance), ce qui complique les choses, car des répertoires importants (/usr, /var) sont en RAID 1 sur mon installation. L'idée était de me contenter de rétablir /boot qui se trouve sur mon disque SSD en un seul morceau (pas dans un montage séparé) et qui est autonome pour son démarrage. Ensuite une fois démarré (noyau chargé), le reste devrait suivre (montage automatique des disques RAID). Mon erreur, je ne le savais pas, c'est que /boot (sans parler des noyaux et autres fichiers de configuration et ramdisks qui y sont copiés lors de l'installation des noyaux) n'est qu'un patchwork de fichiers provenant de différentes sources. Ce qui m'a sauvé - encore un coup de bol (on ne peux pas être malchanceux partout), c'est que j'avais précédemment fais une copie de tout /boot sur une clé USB pour en récupérer les fichiers de configuration (mais je ne m'en souvenais plus).

J'ai tenté d'aller le chercher dans /var/cache/apt/archives/ de mon disque défectueux depuis le netinstall Debian, mais j'avais oublié une chose, c'est que /var est une partition RAID1 qui ne se montera pas sans mettre les doigts dans mdadm : les inconvénients du (presque) tout RAID1 !

J'ai essayé de monter l'un des disques RAID 1 en lecture seule (je n'ai besoin que de copier un paquet), mais ça ne fonctionne pas :

# mount -o ro -t ext4 /dev/sdc2 /var
mount: mounting /dev/sdc2 on /var failed: Invalid argument

(idem avec sdd2) car les disques sont marqués comme étant en RAID (avec “# fdisk -l” ils ont le type “Linux RAID”) même s'ils ne sont pas montés (“# cat /proc/mdstat” me renvoi : “Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] unused devices: <none>”).

Note à posteriori : J'aimerai bien savoir pourquoi je ne peux pas monter un disque (en bon état) RAID 1 en lecture seule lorsqu'il n'est pas monté en RAID 1.

Sur mon autre PC, je télécharge sur Debian le paquet grub2-common_2.02+dfsg1-20_amd64.deb et l'examine en l'ouvrant via le décompresseur Ark (son interface graphique est très pratique) : en dehors du fichier de contrôle habituel du paquet (control.tar.xz), il contient (dans data.tar.xz) des scripts d'installation à mettre dans /etc et des binaires dans /usr, mais rien qui servira immédiatement au démarrage dans /boot.

J'essaie l'une de ses dépendances grub-common (2.02+dfsg1-20) : idem, des fichiers et binaires pour /etc, /usr et /var, mais rien pour /boot.

Visiblement ça aurait trop simple :) Je ne trouve ces fichiers nulle part (j'ai aussi cherché avec les noms des fichiers et les commandes “# apt search” et “# apt-file search” sur mon autre PC : ils ne sont nulle part parce que vraisemblablement ils sont récupérés par un script (dans les fichiers des noyaux ?).

Note à posteriori :
Solution d'ultime secours envisagée et non retenue (j'avais déjà écris la phrase :) : J'ai bien l'impression que je vais être obligé de réactiver manuellement mdadm, car je ne parviendrai pas à réparer manuellement /boot (et je n'ai pas d'autre PC en 64-bit où j'aurai pu récupérer des fichiers).

J'ai trouvé d'où ils viennent, grâce à la commande locate (paquet éponyme, que j'avais un peu oublié et qui m'est revenu) :

# locate linux.mod
/boot/grub/i386-pc/linux.mod
/usr/lib/grub/i386-pc/linux.mod
# apt-file search /usr/lib/grub/i386-pc/linux.mod
grub-pc-bin: /usr/lib/grub/i386-pc/linux.mod
grub-pc-dbg: /usr/lib/grub/i386-pc/linux.module

C'est donc grub-pc-bin qui les met dans /usr/lib/grub/i386-pc/ et j'imagine qu'il doit y avoir un script qui vient également en déposer une copie dans /boot/grub/i386-pc/.

Grub2 a une dépendance à grub-pc (et grub-common), qui lui-même a une dépendance à grub-pc-bin (entre autres).

Ok, c'est bien çà grub-pc-bin, je vais tenter un truc à l'arrache / à la one again :

• faire une sauvegarde de /boot/grub/i386-pc/
• puis aller y copier le contenu /usr/lib/grub/i386-pc/ d'une version précédente du paquet grub-pc-bin (je le décompresse sur mon autre PC, et copie sur une clé USB ses fichiers)

(à suivre)

Ouah, je découvre que j'ai (beaucoup) mieux que ça : sur la clé que je m'apprêtais à utiliser j'ai une copie de l'ancien /boot de ce PC (j'en avais fais une copie avant ma nouvelle installation nVidia) ! Je m'en vais de ce pas le déverser sur mon PC (non sans avoir fais une copie de /boot au préalable tout de même).

Résultat : il y a du mieux, même si çà ne fonctionne pas encore. J'ai à présent le menu Grub (non graphique) (version 2.02+dfsg1-19) fonctionnel avec comme choix les noyaux 4.19.0-5-amd64 et 4.9.0-7-amd64, mais aucun ne se lance :

erreur : no such device: 632e0a03-3b54-4865-826a-07bd217b1134.
Chargement de Linux 4.19.0-5-amd64
erreur : cette partition n'existe pas.
Chargement du disque mémoire initial...
erreur: le noyau doit d'abord être chargé.

Appuyez sur une touche pour continuer...

je le sent mieux là :)

Ça doit pouvoir se résoudre en modifiant les adresses (j'imagine que la configuration initiale ne devais pas être tout à fait la même).

Donc sous Grub, je tape “e” pour éditer l'entrée, j'y vois - entre autres :

set root='hd1,msdos1' (pas bon)
--hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1 (pas bon)
et le n° de disque 632e0a03-3b54-4865-826a-07bd217b1134 (qui a lui aussi changé)

Ça tombe bien, j'avais noté ci-dessous les paramètres du grub précédent :

(...)
insmod part_gpt
insmod diskfilter
insmod mdraid1x
insmod ext2
set root='mduuid/6fe8d96483f645a523b3f8da43e65f36'
(...)
set root='hd0,msdos1'
(...)
linux /boot/vmlinuz-4.19.0-5-amd64 root=UUID=16baa59f-12cd-47a1-afb0-aff63e5a1d0d ro quiet
(...)
insmod gzio
insmod part_msdos
(...)
linux /boot/vmlinuz-4.9.0-9-amd64 root=UUID=16baa59f-12cd-47a1-afb0-aff63e5a1d0d ro quiet
(...)

Je n'ai qu'à les recopier ici (Attention : on est en QWERTY :)) :

• 'hd1,msdos1' devient 'hd0,msdos1'
• '632e0a03-3b54-4865-826a-07bd217b1134' devient '16baa59f-12cd-47a1-afb0-aff63e5a1d0d'

Je tape F10 et … ÇÀ MARCHE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Yeeeeeeeeeessssss !!!!!!!

Me voilà sous Xorg - sans réseau (???), mais ça faisait longtemps que je ne l'avais pas vu celui-là :)

Donc tout n'est pas gagné, mais une belle progression tout de même.

Je regarde sous Synaptic : donc la version de Grub incriminée est la 2.04-1 (ce qui est très étonnant, c'est qu'elle est encore aujourd'hui en dépôts, après plusieurs jours, donc soit je suis le seul touché - hautement improbable, soit c'est encore un truc spécifique qui m'a plombé tout seul), et la version précédente (et fonctionnelle) de ce paquet est la 2.02. Je vais copier ses paquets sur mon répertoire racine, dans le /boot - peut-être que ça servira plus tard (je n'espère pas devoir y retourner :)).

• Sous Xorg je commence par corriger manuellement /boot/grub/grub.cfg (car l'opération ci-dessus n'était que temporaire, elle n'est pas enregistrée dans le fichier, seulement utilisée pour le démarrage) avec les occurrences ci-dessus.
• Je me refais une copie du /boot (ça sera plus facile la prochaine fois, normalement) !!! D'autant qu'à la prochaine mise à jour de Grub (je vais le downgrader proprement), toutes mes modifs seront à nouveau écrasées (si ça ne fonctionne pas, j'aime autant ne pas avoir à tout re-saisir une autre fois).
• Je downgrade Grub (dans cet ordre sinon ça ne marche pas, du fait des dépendances) :

# dpkg -i --force-overwrite grub-common_2.02+dfsg1-20_amd64.deb
(...)
# dpkg -i --force-overwrite grub2-common_2.02+dfsg1-20_amd64.deb
(...)
# dpkg -i --force-overwrite grub-pc-bin_2.02+dfsg1-20_amd64.deb
(...)
# dpkg -i --force-overwrite grub-pc_2.02+dfsg1-20_amd64.deb
grub-install : attention : Le système de fichier "ext2" ne prend pas en charge l'embarquage.
grub-install : attention : l'embarquage est impossible. GRUB ne peut être installé sur cette configuration qu'en utilisant les listes de blocs. Cependant, les listes de blocs ne sont PAS fiables et leur utilisation est déconseillée..
Installation terminée, sans erreur.
Création du fichier de configuration GRUB...
Found (...)

C'est quoi encore ça ?
Il m'a fait une petite frayeur (aurais-je malencontreusement formaté l'un de mes disques en ext2 ?), mais non, la commande “# blkid” me confirme bien que tous mes disques sont en ext4. Par contre j'avais bien remarqué le chargement du module ext2 dans Grub (et m'étais dis que peut-être était-ce normal).

En attendant :

• je bloque les paquets Grub sous Synaptic (pour un bout de temps). J'avais désinstallé aussi le paquet unattended-upgrades (il est bogué et pourtant installé par défaut, et ça n'a toujours pas été réparé : il met à jour tous les paquets sous Synaptic même ceux qui sont marqués avec une version bloquée).
• Je vérifie à nouveau /boot/grub/grub.cfg (puisqu'il a été remis à jour par le downgrade de Grub) : tout me paraît bon. Il y a aussi toujours le chargement du module ext2. Je vais me renseigner sur le Web. Pas trouvé, mais de toute façon il n'y a pas le choix : dans /boot/grub/i386-pc/ il n'y a qu'un module ext2.mod et pas de modules ext3.mod ou ext4.mod !

Il y a une très bonne documentation sur le sujet sur : Debian-Facile (Grub attention : L'embarquage est impossible)

# debconf-show grub-pc | grep install_devices
  grub-pc/install_devices_empty: false
  grub-pc/install_devices_failed: false
  grub-pc/install_devices_disk_changed: 
  grub-pc/install_devices_failed_upgrade: true
* grub-pc/install_devices: /dev/disk/by-id/ata-INTEL_SSDSA2M080G2GC_CVP09313015J080BGN-part1
# blkid
/dev/sda1: LABEL="SSD" UUID="16baa59f-12cd-47a1-afb0-aff63e5a1d0d" TYPE="ext4" PTTYPE="dos" PARTUUID="691b0ea4-01"
(...)

Donc si je comprend bien ma partition de boot est au format DOS, donc si l'espace alloué est suffisant, il peut utiliser l'embarquage. Je ne vois donc pas pourquoi ce message (en dehors du module ext2 qui me semble superflu, mais je dois vérifier avant de l'enlever ou de le remplacer).

Et effectivement, je lance la commande :

# dpkg-reconfigure grub-pc
Ligne de commande Linux : (vide)
Périphériques où installer GRUB : 
[*] /dev/sda (800026 Mo; INTEL_SSDSA2M080G2GC) (je viens de la retenir)
[ ] - /dev/sda1 (64018 Mo; /) (c'était l'option retenue précédemment) 
[ ] /dev/sdb (4000787 Mo; ST4000DM004-2CV104)
[ ] /dev/sdc (4000787 Mo; ST4000DM004-2CV104)
Installation sur la plate-forme i386-pc.
Installation terminée, sans erreur.
Création du fichier de configuration GRUB...
Found (...)
fait

Mon problème serait-il venu de là ? À creuser. (le MBR était copié sur /dev/sda1 au lieu de /dev/sda)

Un dernier coup d'oeil à grub.cfg, rien d'anormal, je redémarre :)

Ca démarre nickel, mais toujours sans réseau. Plutôt que de tout mettre ici, je vais raccrocher la partie “Réseau” à un paragraphe spécifique (voir Le Réseau filaire).

(ce paragraphe est à déconnecter de celui ci-avant, il s'agit d'un autre test réalisé en amont)

Le 11/07/2019 :

J'ai envie de tester autre-chose : tenter un démarrage depuis le disque d'origine en me faisant la main sur le paramétrage de GRUB2. Je pars de la doc suivante : CoursInfoRevest (WIKI Grub-Rescue)

Ça n'est pas très ragoûtant parce que GRUB2 est tout sauf ergonomique. Les commandes sont obscures, le clavier en QWERTY, et il n'y a pas de rappel de commandes : à chaque fois que l'on valide une commande si l'on a fait une erreur de syntaxe (avec un clavier en QWERTY, rien d'anormal) il faut tout retaper, bref, une purge ce truc.

Donc je reboot après avoir enlevé ma clé de démarrage, me retrouve avec mon erreur Grub et me voilà à explorer les commandes (je suis parvenu - une fois :), à lancer un noyau de la sorte et à démarrer mon système. Beaucoup de galère pour un résultat médiocre. Je vais retenter pour voir.

Le message de Grub au démarrage :

error: symbol 'grub_file_filters' not found.
Entering rescue mode...
grub rescue>

Je tente des trucs :

grub rescue> set root=(hd0,0)
grub rescue> insmod linux
error: symbol 'grub_file_filters' not found.
grub rescue> set prefix=(hd0,0)/boot/grub
grub rescue> insmod linux
error: no such partition.
grub rescue> ls
(hd0) (hd0, msdos2) (hd0,msdos1) (hd1) ...
(de mémoire de moineau, je crois me souvenir que le noyau démarrait sur (hd0,msdos1) )
grub rescue> set prefix=(hd0,msdos1)/boot/grub
(il ne bronche pas)
grub rescue> insmod linux
error: symbol 'grub_file_filters' not found.
grub rescue> ls (hd0,msdos1)/
./ ../ lost+found/ home/ mnt/ opt/ usr/ var/ ... bin/ boot/ ... (je n'écris pas tout, c'est assez galère comme ça) vm linuz initrd.img
(ah, au moins c'est le bon répertoire)

C'est tout pour les festivités de la soirée, faut garder un peu de plaisir pour ce week-end :))

Reprise le 12/07/2019 :

Je me rend compte qu'hier il me manquait quelques infos concernant le paramétrage de grub2, je vais aller les glaner sur mon disque de démarrage (dans /boot/grub/grub.cfg avec l'éditeur nano) via ma clé de dépannage.

Dans ce fichier je trouve en vrac (je n'affiche ici que ce qui attire mon attention) :

(...)
insmod part_gpt
insmod diskfilter
insmod mdraid1x
insmod ext2
set root='mduuid/6fe8d96483f645a523b3f8da43e65f36'
(...)
set root='hd0,msdos1'
(...)
linux /boot/vmlinuz-4.19.0-5-amd64 root=UUID=16baa59f-12cd-47a1-afb0-aff63e5a1d0d ro quiet
(...)
insmod gzio
insmod part_msdos
(...)
linux /boot/vmlinuz-4.9.0-9-amd64 root=UUID=16baa59f-12cd-47a1-afb0-aff63e5a1d0d ro quiet
(...)

Je fais abstraction des autres modules graphiques (ça m'est égal pour l'instant si je n'ai pas de graphisme, du moment que ça démarre).

Voilà, j'ai davantage de matière pour mes tests

grub rescue> ls /boot
./ ../ config-4.9.0-9-amd64 grub/ vmlinuz-4.19.0-5-amd64 (...) (je n'affiche pas tout)
grub rescue> set prefix=(hd0,msdos1)/boot/grub
grub rescue> insmod ext2
grub rescue> insmod part_gpt
grub rescue> insmod diskfilter
grub rescue> insmod mdraid1x
grub rescue> linux /boot/vmlinuz-4.19.0-5-amd64 root=UUID=16baa59f-12cd-47a1-afb0-aff63e5a1d0d ro quiet
Unknown command 'linux".
grub rescue> lsmod
Unknown command 'lsmod".

Dommage, les autres commandes ont l'air de fonctionner :(

Juste pour voir s'il sait dire autre-chose :

grub rescue> boot
error: you need to load the kernel first.

Oui, je sais, mais j'aimerai que tu m'autorises à le charger…

Intéressant :

grub rescue> ls 
(hd0) (hd0,msdos2) (hd0,msdos1) (...) (hd4,msdos1) (md/4) (md/3) (md/2) (md/1) (md/0)

Il semblerait donc que les disques RAID soient actifs. Il faudrait juste que je parvienne à charger le noyau. Je ne comprend pas pourquoi la commande “linux” n'est pas/plus reconnue.

Autre info :

grub rescue> insmod gzio
error: symbol 'grub_file_filters' not found.
grub rescue> insmod part_msdos
grub rescue> insmod linux
error: symbol 'grub_file_filters' not found.

Je vois sur la doc CoursInfoRevest (WIKI Grub-Rescue) que les modules se trouvent soit dans /boot/grub, soit dans /boot/grub/i386-pc/.
Visiblement chez moi ils sont dans /boot/grub/i386-pc/ :

grub rescue> ls /boot/grub/i386-pc/
(affiche une page entière de fichiers ".mod", mais ici pas moyen de filtrer avec | more ou | grep :)) )

Donc je relance :

grub rescue> set prefix=(hd0,0)/boot/grub/i386-pc/
grub rescue> insmod linux
error: no such partition.
grub rescue> insmod gzio
error: no such partition.

C'est mieux, ça change de message :)

grub rescue> ls (hd0,0)/boot/grub/i386-pc/
error: no such partition.

Ok, c'est moi qui ne lui donne pas le bon disque probablement.

grub rescue> ls (hd0,msdos1)/boot/grub/i386-pc/
(affiche la page entière de fichiers ".mod" : ok, c'était bien moi qui me trompais )

Je recommence :

grub rescue> set prefix=(hd0,msdos1)/boot/grub/i386-pc/
grub rescue> insmod linux
error: file '/boot/grub/i386-pc//i386-pc/linux.mod' not found

Ok, ça communique un peu mieux, et je comprend mieux l'intérêt de la commande “set prefix” (lui indique où se trouvent les modules externes au noyau). Il faut que je trouve où se trouve ce fichier/module “linux.mod”.

Sur mon autre PC, j'ai bien un fichier /boot/grub/i386-pc/linux.mod

Sur celui-ci, coup de bol, je vois encore à l'écran dans la longue liste (même pas triée dans l'ordre alphabétique) un : “linux16.mod”.

Je vais essayer :

grub rescue> insmod linux16
error: file '/boot/grub/i386-pc//i386-pc//linux16.mod' not found.

Je l'ai encore sous les yeux ! Mais je remarque aussi le double affichage :

"/i386-pc//i386-pc/"

Je recommence :

grub rescue> set prefix=(hd0,msdos1)
grub rescue> insmod linux16
error: file '/i386-pc/linux16.mod' not found.

grub rescue> set prefix=(hd0,msdos1)/boot/grub
error: symbol 'grub_file_filters' not found.
grub rescue> linux
Unknown command 'linux".

Ah la syntaxe c'est important :)
Mais me voilà de retour à la case départ avec ce “symbol 'grub_file_filters' not found”. Et j'ai l'impression (sans être certain) qu'à cause de cela il ne reconnaît plus la commande “linux” permettant de charger le noyau.

(à suivre, c'est tout pour ce soir)

Nota à posteriori : ce test aura été un jalon important dans la résolution de mon problème puisqu'il m'aura permis de mieux comprendre le fonctionnement / paramétrage de Grub, à l'avenir je serais nettement plus serein avec Grub (même s'il peut certainement encore me piéger et me réserver des surprises, je n'en doute pas :). Il m'aura montré (grâce à la lecture de docs externes) comment démarrer à partir d'un fichier grub.cfg externe pas tout à fait adapté. Ici le souci venait probablement soit d'un bug de la version de Grub, soit du MBR installé sur /dev/sda1 au lieu de /dev/sda (je l'ai finalement changé, et j'ai aussi downgradé grub provisoirement).