Re: 10/Buster --> 11/Bulleye
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
Reply to: