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@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@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@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@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@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@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@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@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@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@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@mint:~# for i in /dev /dev/pts/ /proc /sys /run; do umount /mnt$i; done > umount: /mnt/dev: target is busy. > > root@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@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@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 [email protected] > Le 28 mars 2024 à 12:28, Philippe Strauss via gull <[email protected]> > 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 >> [email protected]
_______________________________________________ gull mailing list [email protected] https://forum.linux-gull.ch/mailman/listinfo/gull
