Le Tue, 27 Sep 2022 13:39:31 +0200,
hamster <
hamster@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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)