Le Tue, 27 Sep 2022 13:39:31 +0200, hamster <hams...@suna.fdn.fr> a écrit :
> Le 27/09/2022 à 12:24, Alain Vaugham a écrit : > > Avant de réinstaller - juste pour le fun - j'aimerai bien mettre un > > peu les mains dans le camboui pour apprendre à chrooter un disque. > > Je ne l'ai jamais fait. Apparemment c'est une occasion. Si en plus > > ça règle le problème alors bingo. > > > > Je vais suivre ce tuto: > > https://www.linuxtricks.fr/wiki/chrooter-un-systeme-linux > Ca a l'air bien, mais c'est pas exactement comme ca que je fais. > Alors je vais aussi te dire comment je fais. Je me suis grandement > inspiré de > https://www.system-rescue.org/disk-partitioning/Repairing-a-damaged-Grub/ > > D'abord il faut booter sur un système live avec le meme nombre de > bits : on ne choote pas sur un systeme 64 bits avec un noyau 32 bits > et vice versa. Si le système sur lequel tu veux chrooter est 64 bits, > alors il te faut booter sur un système live qui a un noyau 64 bits. > Perso, j'aime bien SystemRescue pour faire ce genre de trucs mais une > autre distrib live fera aussi très bien l'affaire. Pour une réponse rapide: cela ne s'est pas passé comme cela aurait pû se passer. Voulant suivre à la lettre ton tuto j'ai donc créé une clef USB avec SystemRescue 9.04-amd64 dessus afin d'être cohérent avec l'installation fautive du disque 4T qui avait été installé avec debian-11.2.0-amd64-netinst. Voici le retour que ça a donné. > Mettons que le disque sur lequel tu veux chrooter soit /dev/sda avec : > - une partition EFI /dev/sda1 > - une partition swap /dev/sda2 > - une partition système /dev/sda3 > - une partition home /dev/sda4 Chez moi c'était : - une partition EFI /dev/sda1 - une partition swap /dev/sda4 - une partition système /dev/sda2 - une partition home /dev/sda6 > Pour reinstaller grub on a pas besoin ni de la swap ni de home. Je > monte donc la partition système dans un dossier dédié dans le > dossier /mnt : mkdir /mnt/racine Pareil chez moi : mkdir /mnt/racine > mount /dev/sda3 /mnt/racine Chez moi : mount /dev/sda2 /mnt/racine > Je monte les dossiers /dev /sys et /proc sur les dossiers > correspondants du systeme a chrooter : > mount -o rbind /proc /mnt/racine/proc > mount -o rbind /dev /mnt/racine/dev > mount -o rbind /sys /mnt/racine/sys Est-ce que l'ordre est important? dev, sys, proc ou proc, dev, sys? Chez moi j'ai fait: mount -o rbind /proc /mnt/racine/proc J'ai eu un refus: /proc is not a block device et le conseil de regarder le dmesg. Là, la dernière ligne disait qu'il n'avait pas trouvé quelque chose.Je n'ai pas noté. > Dans le cas d'un système avec EFI, donc avec grub-efi-amd64 a la > place de grub-pc, il faut utiliser l'option rbind et non pas bind > sinon grub plante. Pour plus de détails voir par la : > https://unix.stackexchange.com/questions/693101/reinstall-grub-grub-install-warning-efi-variables-are-not-supported-on-this-s Je suis donc allé voir ce lien. Après avoir parcouru toute la discussion j'avoue qu'avec mes compétences actuelles ne pas avoir retenu grand'chose. Plus tôt que d'en rester là, j'ai tenté avec bind. mount -o bind /proc /mnt/racine/proc N'ayant reçu aucun message d'erreur, j'ai continué : mount -o rbind /dev /mnt/racine/dev mount -o rbind /sys /mnt/racine/sys > Ensuite le chroot proprement dit : > chroot /mnt/racine /bin/bash Pareil chez moi. Pas de plainte non plus. > La le prompt est différent, c'est donc qu'on est dans le système > chrooté. Pareil ici. Le prompt a changé. Toujours pas de message d'erreur. > Toujours dans le cas d'un système EFI, il faut monter la partition > EFI sur /boot/efi : > mount /dev/sda1 /boot/efi Pareil ici. J'étais dans le système chrooté et pas de message d'erreur non plus. mount /dev/sda1 /boot/efi > On peut aussi faire plus simplement mount -a, ce qui va monter tout > ce qui est dans le fstab, y compris la partition EFI et avec les > bonnes options. Attention par contre ca va monter d'autres trucs, a > commencer par /home et il faudra penser a les démonter avant de > sortir du chroot. Alors je ne mounte pas le contenu de la fstab. Cela m'évitera d'éventuelles perturbations. > On peut alors reinstaller grub : > grub-install /dev/sda Pareil chez moi : grub-install /dev/sda Pas d'erreur > update-grub Pareil chez moi : update-grub Mais là : erreur. mkdir: cannot create directory /var/lib/os-prober/mount No such file or directory Ce message a été répliqué cinq fois. J'ai hésité à lui créer le répertoire qui lui manquait. Je me suis dit que si grub-install s'était bien passé alors ce devait certainement être la dernière version. Donc je n'ai pas créé le répertoire manquant. J'ai poursuivi. J'avoue ne pas avoir eu l'idée de vérifier la version du Grub fraîchement installé. > Démonter tout ce qui a été monté dans le chroot : > umount /boot/efi Pareil chez moi : umount /boot/efi Aucun message d'erreur > ainsi que les autres trucs éventuellement montés. > Ou plus simplement : > umount -a > J'aime bien vérifier que tout s'est bien démonté avec : > mount Pareil ici et pas de message d'erreur > Sortir du chroot avec : > exit Pareil. La sortie s'est faite sans erreur > Démonter tout ce qui a été monté, attention a cause de l'option rbind > il faut faire dans l'ordre : > umount /mnt/racine/dev/pts > umount /mnt/racine/dev > umount /mnt/racine/proc > umount /mnt/racine/sys > umount /mnt/racine Chez moi, peut-être à cause l'utilisation de bind au lieu de rbind je n'avais pas le dev/pts J'ai donc démonté dans l'ordre : umount /mnt/racine/dev umount /mnt/racine/proc umount /mnt/racine/sys umount /mnt/racine Aucune erreur ici non plus. > Si t'a des problèmes pour démonter : > umount -d -f -l <point montage récalcitrant> > et faire un reboot de la machine rapidement. Les démontages étant correctement réalisés, j'ai rebooté rapidement : reboot Comme j'avais laissé la clef SystemsRecue en place, c'est sur elle que la machine a booté. J'ai éteint, retiré la clef USB et rallumé. Résultat: dans l'interface UEFI je voyais bien le disque de 4T mais impossible de faire booter la machine dessus. Toujours la même situation qu'avant la tentative de refaire le Grub. Maintenant je suis incapable de dire si c'est à cause de l'usage de bind au lieu de rbind que je dois attribuer l'échec de la mise à jour de Grub en environnement chrooté. Je suis encore plus incapable de dire pourquoi cette machine persévère à booter sur le dernier disque ayant booté avec succès après une extinction. J'imagine que son BIOS/UEFI ne doit pas être très propre. Cela me fait craindre qu'une prochaine tentative de booter sur un disque/une clef risquerait peut-être de ne plus permettre le boot sur le disque initial d'1T sur lequel il y a la Buster. Là, ce serait un très gros boulot pour moi que de tout remettre en ordre de marche. Je ne vais donc pas prendre d'éventuels risques à partir de maintenant. Comme de toutes façons il me faudra un jour passer sur Bulleye je vais réinstaller le disque de 4T. Mais cette fois-ci, j'ai retenu la leçon: ne pas mettre deux disques bootables simultanément sur cette machine. Je récupérerai mes fichiers de la Buster d'origine plus tard en les mettant au préalable sur un montage réseau ou sur un disque sans OS. Finalement je suis vraiment très content d'avoir pu faire mes premiers pas dans l'usage de chroot. Je sais que j'ai encore beaucoup à faire pour y être un peu mieux à l'aise. Je savais à quoi ça servait mais pas du tout comment ça s'articulait. Cela faisait des années que ça me démangeait. Faute de temps pour explorer la multitude de tutos menant à des échecs en série, c'était vite fait de ne pas persister et de revenir sur les priorités du moment. Merci beaucoup pour m'avoir donné ce coup de pouce. -- Alain Vaugham Clef GPG : 0xDB77E054673ECFD2
