[gull] [Resolu] alert! /dev/sd.. does not exist + update-grub + chroot + btrfs

Tue Apr 9 19:07:19 CEST 2024

Bonjour Philippe,
bonjour à tous,

> Peux-tu poster le contenu de /boot/grub/grub.cfg?

Ton réflexe Philippe était bon.

> ### BEGIN /etc/grub.d/10_linux ###

[SNIP]

> set root='hd2,msdos4'
> 	if [ x$feature_platform_search_hint = xy ]; then
> 	  search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk at 0,msdos4' --hint-bios=hd2,msdos4 --hint-efi=hd2,msdos4 --hint-baremetal=ahci2,msdos4  5352ab07-54c2-4dfa-ac47-c32455a6e1a6
> 	else
> 	  search --no-floppy --fs-uuid --set=root 5352ab07-54c2-4dfa-ac47-c32455a6e1a6
> 	fi

Et juste après... le coupable était là ! root=/dev/sdc4, au lieu de root=UUID=xxx
Mille merci.

>        linux	/@/boot/vmlinuz-4.15.0-101-generic root=/dev/sdc4 ro rootflags=subvol=@  quiet splash $vt_handoff
> 	initrd	/@/boot/initrd.img-4.15.0-101-generic

Dans le fichier grub.cfg, il ne sert à rien d'écrire à la main

> root=UUID=5352ab07-54c2-4dfa-ac47-c32455a6e1a6

à la place de 

> root=/dev/sdc4

puisque grub.cfg est écrasé à chaque commande update-grub (aka grub-mkconfig -o /boot/grub/grub.cfg "$@").

Je n'ai pas résolu le problème jusqu'au moment où je suis allé regarder ce qu'il y avait dans /etc/default/grub, et j'ai eu du mal à le croire:

> # Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
> GRUB_DISABLE_LINUX_UUID=true

La solution était de repousser ce paramètre en commentaire, pour qu'il reprenne sa valeur par défaut, c'est à dire d'autoriser Grub à fonctionner "normalement", à l'aide des uuid. Pourquoi donc "disable uuid" s'est-il retrouvé sélectionné sur ma machine ? Ça restera un mystère. J'ai du mal à croire que ce soit le choix par défaut de Linux Mint (ici en version "Tricia"). Tant qu'il était interdit à Grub de générer son fichier de configuration en utilisant les uuid des partitions du SSD pour désigner au kernel la racine de son système de fichiers, la commande update-grub persistait évidement à inscrire /dev/sdc4 au lieu de 5352ab07-54c2-4dfa-ac47-c32455a6e1a6. On pouvait passer update-grub autant de fois qu'on voulait, ça ne corrigeait donc rien. C'est l'interdiction de l'utilisation des uuid dans le fichier /etc/default/grub qui était la vraie cause du problème. Avant le changement de carte mère, quand le BIOS énumérait les volumes dans le même ordre à chaque démarrage, ce problème potentiel restait invisible.

Dans l'espoir que ça serve à d'autres, je colle ci-dessous les manips pour lancer update-grub depuis un live-cd quelconque, pour "réparer" Grub sur une machine Linux Mint dont le système de fichiers est btrfs. On trouve beaucoup de tutoriaux en ligne pour lancer grub-update après un chroot dans un système de fichiers ext4; mais adapter la procédure à btrfs n'est pas spontanément évident. Sur cette machine, /boot/ n'est pas sur une partition séparée.

On part donc du système démarré en live-cd (ici LMDE6 lancé depuis un port USB).

> root at mint:~# ls -lah /mnt
> total 0
> drwxr-xr-x 2 root root   3 Sep 22  2023 .
> drwxr-xr-x 1 root root 180 Mar 31 20:32 ..
> 
> root at mint:~# mount -o subvol=@ /dev/sdc4 /mnt/

Avec un système de fichiers btrfs, c'est cette commande mount qui diffère un peu de l'habitude, le point de montage doit alors se faire sur le sous-volume "@" de la partition Linux Mint sur laquelle on veut régénérer la configuration de Gub.

On peut vérifier qu'on a correctement monté le système btrfs dans le système de fichiers de l'hôte, quand on retrouve bien grub.cfg là où on l'attendait.

> root at mint:~# ls -lah /mnt/boot/grub/grub.cfg
> -r--r--r-- 1 root root 8.2K Mar 31 18:41 /mnt/boot/grub/grub.cfg

Si ce fichier se trouvait ici,

> /mnt/@/boot/grub/grub.cfg

c'est qu'on aurait monté le volume btrfs depuis sa racine, et non depuis le sous-volume "@".

Classiquement, on attache cinq des pseudos fichiers du système hôte dans l'arborescence du volume qu'on vient de monter. Cette ligne trouvée sur le web est élégante et plus pratique que d'écrire cinq bind avec les risques d'erreurs par inattention.

> root at mint:~# for i in /dev /dev/pts/ /proc /sys /run; do mount -B $i /mnt/$i; done

Finalement, on place le système hôte dans l'arborescence du volume qu'on vient de monter.

> root at mint:~# chroot /mnt/

Je n'avais pas vraiment besoin de réinstaller Grub dans le MBR (la machine est BIOS, pas UEFI), seulement de régénérer la configuration de Grub. Mais réinstaller Grub ne fait pas de mal. Aucune de ces options n'était vraiment nécessaires, elles correspondent aux valeurs par défaut, mais ça permet d'expliciter ce qu'on fait. En particulier --recheck n'était pas utile, car Grub n'avait jamais généré de fichier devicemap sur cette machine.

> root at mint:/# grub-install --target=i386-pc --recheck --boot-directory=/boot/ /dev/sdc
> Installing for i386-pc platform.
> Installation finished. No error reported.

Et c'est là qu'on lance grub-update. Sur ma machine, voilà ce que ça m'a renvoyé.

> root at mint:/# update-grub
> Sourcing file `/etc/default/grub'
> Sourcing file `/etc/default/grub.d/50_linuxmint.cfg'
> Sourcing file `/etc/default/grub.d/60_mint-theme.cfg'
> Generating grub configuration file ...
> Found theme: /boot/grub/themes/linuxmint/theme.txt
> Found linux image: /boot/vmlinuz-4.15.0-101-generic
> Found initrd image: /boot/initrd.img-4.15.0-101-generic
> Found memtest86+ image: /@/boot/memtest86+.elf
> Found memtest86+ image: /@/boot/memtest86+.bin
>   WARNING: Failed to connect to lvmetad. Falling back to device scanning.
> grub-probe: error: cannot find a GRUB drive for /dev/sda1.  Check your device.map.
> Found Windows 7 on /dev/sdc1
> done

On peut aller vérifier la date de dernière modification et le contenu du fichier grub.cfg, pour se persuader que update-grub a bien travaillé sur le bon fichier.

> root at mint:/# ls -lah /boot/grub/grub.cfg
> -r--r--r-- 1 root root 8.3K Mar 31 18:59 /boot/grub/grub.cfg

Il reste ensuite à extraire le système hôte du système de fichiers du volume btrfs.

> root at mint:/# exit

Puis à détacher les cinq pseudos fichiers. Sur ma machine, il m'a fallu passer deux fois la même commande pour tous les décrocher. Voilà l'affichage que ça m'a renvoyé.

> root at mint:~# for i in /dev /dev/pts/ /proc /sys /run; do umount /mnt$i; done
> umount: /mnt/dev: target is busy.
> 
> root at mint:~# for i in /dev /dev/pts/ /proc /sys /run; do umount /mnt$i; done
> umount: /mnt/dev/pts/: not mounted.
> umount: /mnt/proc: not mounted.
> umount: /mnt/sys: not mounted.
> umount: /mnt/run: not mounted.

Un troisième passage a confirmé que la première "busy target" avait bien été décrochée elle aussi.

> root at mint:~# for i in /dev /dev/pts/ /proc /sys /run; do umount /mnt$i; done
> umount: /mnt/dev: not mounted.
> umount: /mnt/dev/pts/: not mounted.
> umount: /mnt/proc: not mounted.
> umount: /mnt/sys: not mounted.
> umount: /mnt/run: not mounted.

Ne reste plus qu'à démonter le volume sur lequel Grub vient d'être réparé, et à tenter de booter.

> root at mint:~# umount /mnt

Le kernel de cette machine est alors parvenu à monter le bon volume en racine, la machine a démarré normalement. Mais franchement, quand ce n'est pas du pro, on perd trop de temps à diagnostiquer et retrouver comment corriger ce genre de dysfonctionnements.

--
Frédéric Dumas
f.dumas at ellis.siteparc.fr

> Le 28 mars 2024 à 12:28, Philippe Strauss via gull <gull at forum.linux-gull.ch> a écrit :
> 
> Bonjour Frédéric,
> 
> Peux-tu poster le contenu de /boot/grub/grub.cfg?
> 
> Salutations.
> 
> 
> On 27.03.2024 19:01, Frederic Dumas via gull wrote:
>> Bonjour messieurs les experts,
>> 
>> Après un changement de carte mère, je parviens à booter une machine Linux Mint depuis son OS sur SSD interne, **à condition** de connecter à la machine un quelconque disque externe ext4 en USB. En l'absence de ce volume supplémentaire, le kernel avorte le démarrage, et me lâche dans Busybox avec le message d'erreur:
>> 
>>> alert! /dev/sdc4 does not exist.  Dropping to a shell!
>> Les volumes dans la fstab de la machine sont pourtant définis par leur UUID ou leur label, et non par leur nom dans la hierarchie /dev/:
>> 
>> 
>>> # <file system> <mount point>   <type>  <options>       <dump>  <pass>
>>> # / was on /dev/sda4 during installation
>>> UUID=5352ab07-54c2-4dfa-ac47-c32455a6e1a6 /               btrfs   defaults,subvol=@ 0       1
>>> # /home was on /dev/sda4 during installation
>>> UUID=5352ab07-54c2-4dfa-ac47-c32455a6e1a6 /home           btrfs   defaults,subvol=@home 0       2
>>> # swap was on /dev/sda3 during installation
>>> UUID=c68188a7-9ec4-4bdf-b909-894eced773d7 none            swap    sw              0       0
>>> LABEL=BigStore /mnt/BigStore exfat defaults,uid=1000,umask=000,x-gvfs-show 0 2
>>> LABEL=BiggerStore /mnt/BiggerStore exfat defaults,uid=1000,umask=000,x-gvfs-show 0 2
>> 
>> 
>> Sur cette machine, le système Linux Mint est effectivement installé sur la quatrième partition du SSD. Mais d'où peut venir que le kernel cherche son système de fichier obligatoirement sur /dev/sdc4, et non sur UUID=5352ab07-54c2-4dfa-ac47-c32455a6e1a6 ?
>> 
>> Le problème ne semble pas venir de Grub lui-même, puisque le kernel se lance bien. Pourtant, un peu au hasard, j'ai reconfiguré Grub et même réinstallé son bootloader MBR (le Bios n'est pas UEFI) [1]. Aucune amélioration.
>> 
>> Modifier les paramètres du BIOS ne change rien, bien que ce fut le cas pour d'autres sur les forums [2]. Le dysfonctionnement est facilement reproductible:
>> 
>>  - disque flash externe supplémentaire en USB = Linux Mint démarre le bureau Cinnamon;
>>  - disque flash externe absent = Linux Mint échoue dans Bysybox;
>> 
>> On dirait que dans le premier cas, le kernel étiquette le SSD comme /dev/sdc et le démarrage aboutit, et dans le second cas l'étiquette comme /dev/sdb, ce qui provoque l'échec. A priori, le nom du volume dans /dev/ ne devrait pourtant pas être significatif.
>> 
>> Je vous soumets donc la devinette.
>> 
>> Merci!
>> 
>> 
>> [1] http://logan.tw/posts/2015/05/17/grub-install-and-btrfs-root-file-system/
>> [2] https://forums.linuxmint.com/viewtopic.php?t=342476
>>     https://ostechnix.com/how-to-fix-busybox-initramfs-error-on-ubuntu/
>>     https://ubuntuforums.org/showthread.php?t=2472734
>> 
>> 
>> --
>> Frédéric Dumas
>> f.dumas at ellis.siteparc.fr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://forum.linux-gull.ch/pipermail/gull/attachments/20240409/500de81f/attachment-0001.html>