10/Buster --> 11/Bulleye

Le 26/09/2022 Í  16:28, Alain Vaugham a écrit :

Ensuite j'ai voulu récupérer certains fichiers du disque initial
1T/Buster.
- J'ai donc monté ce disque Buster, choisi de booter sur le 4T/Bulleye
et recopié mes fichiers.

Attends, le disque buster tu l'a branché comme un disque externe en USB
ou bien tu a mis les deux disques dans l'ordi ?

T'a copié quoi exactement comme fichiers ?

Le Mon, 26 Sep 2022 22:00:10 +0200,
hamster <hamster@suna.fdn.fr> a écrit :

Le 26/09/2022 Í  16:28, Alain Vaugham a écrit :
> Ensuite j'ai voulu récupérer certains fichiers du disque initial
> 1T/Buster.
> - J'ai donc monté ce disque Buster, choisi de booter sur le
> 4T/Bulleye et recopié mes fichiers.

Attends, le disque buster tu l'a branché comme un disque externe en
USB ou bien tu a mis les deux disques dans l'ordi ?

Non, pas d'USB. J'ai mis les deux disques en même temps sur l'ordi. Ce
sont des Serial ATA.
L'UEFI permet de mettre une priorité sur celui sur lequel on veut
booter. Cela marche très bien avec un disque S-ATA et une clef Tails.

T'a copié quoi exactement comme fichiers ?

Mes propres productions pour continuer Í  les utiliser sous Bulleye : de
l'ascii, du pdf, du png, de l'ods, de l'odt, du bash, du sql, mes clefs
gpg/keepass/ssh... rien d'agressif.



--
Alain Vaugham
Clef GPG : 0xDB77E054673ECFD2

Le 27/09/2022 Í  01:26, Alain Vaugham a écrit :

Le Mon, 26 Sep 2022 22:00:10 +0200,
hamster <hamster@suna.fdn.fr> a écrit :

Le 26/09/2022 Í  16:28, Alain Vaugham a écrit :

Ensuite j'ai voulu récupérer certains fichiers du disque initial
1T/Buster.
- J'ai donc monté ce disque Buster, choisi de booter sur le
4T/Bulleye et recopié mes fichiers.

Attends, le disque buster tu l'a branché comme un disque externe en
USB ou bien tu a mis les deux disques dans l'ordi ?

Non, pas d'USB. J'ai mis les deux disques en même temps sur l'ordi. Ce
sont des Serial ATA.
L'UEFI permet de mettre une priorité sur celui sur lequel on veut
booter. Cela marche très bien avec un disque S-ATA et une clef Tails.

T'a copié quoi exactement comme fichiers ?

Mes propres productions pour continuer Í  les utiliser sous Bulleye : de
l'ascii, du pdf, du png, de l'ods, de l'odt, du bash, du sql, mes clefs
gpg/keepass/ssh... rien d'agressif.

Heu, désolé mais je suis autant le bec dans l'eau que toi. Je sais pas
t'aider sur ce coup.

Si j'etais a ta place, faute d'arriver a comprendre, je tenterais des
trucs bourrins :
- booter sur une clef USB, faire un chroot sur le disque 4T et
reinstaller GRUB
- si ca marche toujours pas, refaire l'install en partant de zero (et en
croisant les doigts pour que ca marche).

Le Tue, 27 Sep 2022 10:54:53 +0200,
hamster <hamster@suna.fdn.fr> a écrit :

Le 27/09/2022 Í  01:26, Alain Vaugham a écrit :
> Le Mon, 26 Sep 2022 22:00:10 +0200,
> hamster <hamster@suna.fdn.fr> a écrit :
>
>> Le 26/09/2022 Í  16:28, Alain Vaugham a écrit :
>>> Ensuite j'ai voulu récupérer certains fichiers du disque initial
>>> 1T/Buster.
>>> - J'ai donc monté ce disque Buster, choisi de booter sur le
>>> 4T/Bulleye et recopié mes fichiers.
>>
>> Attends, le disque buster tu l'a branché comme un disque externe en
>> USB ou bien tu a mis les deux disques dans l'ordi ?
>
> Non, pas d'USB. J'ai mis les deux disques en même temps sur l'ordi.
> Ce sont des Serial ATA.
> L'UEFI permet de mettre une priorité sur celui sur lequel on veut
> booter. Cela marche très bien avec un disque S-ATA et une clef
> Tails.
>
>
>> T'a copié quoi exactement comme fichiers ?
>
> Mes propres productions pour continuer Í  les utiliser sous
> Bulleye : de l'ascii, du pdf, du png, de l'ods, de l'odt, du bash,
> du sql, mes clefs gpg/keepass/ssh... rien d'agressif.

Heu, désolé mais je suis autant le bec dans l'eau que toi. Je sais
pas t'aider sur ce coup.

Si j'etais a ta place, faute d'arriver a comprendre, je tenterais des
trucs bourrins :
- booter sur une clef USB, faire un chroot sur le disque 4T et
reinstaller GRUB
- si ca marche toujours pas, refaire l'install en partant de zero (et
en croisant les doigts pour que ca marche).

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


--
Alain Vaugham
Clef GPG : 0xDB77E054673ECFD2

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.

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

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
mount /dev/sda3 /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

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

Ensuite le chroot proprement dit :
chroot /mnt/racine /bin/bash
La le prompt est différent, c'est donc qu'on est dans le système chrooté.

Toujours dans le cas d'un système EFI, il faut monter la partition EFI
sur /boot/efi :
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.

On peut alors reinstaller grub :
grub-install /dev/sda
update-grub

Démonter tout ce qui a été monté dans le chroot :
umount /boot/efi
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

Sortir du chroot avec :
exit

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

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.

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 n'en demandais pas tant!
Mais je vais en profiter ;-)
Je vais m'y mettre ce soir.


--
Alain Vaugham
Clef GPG : 0xDB77E054673ECFD2

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

Bonjour,

Le 2022-09-28 02:02, Alain Vaugham a écrit :

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é.

Tu n'aurais pas une partition /var séparée sur ton système (sur le
disque dur) ?

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 ne pense pas. `rbind` (que je ne connaissais pas, j'utilise toujours
`bind`)
fait :

Remonter une sous-arborescence et tous les sous-montages possibles
ailleurs

La différence est donc la récursivité.

Si tu veux faire la même chose que `rbind` avec `bind`, il va falloir le
faire
en plusieurs étapes pour chacun des montages "sous" `/proc` :

# mount | grep proc
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs
(rw,relatime,fd),pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino784)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc
(rw,nosuid,nodev,noexec,relatime)

Donc :
mount -o bind /proc /mnt/racine/proc/
mount -o bind /proc/sys/fs/binfmt_misc
/mnt/racine/proc/sys/fs/binfmt_misc

Mais dans ton cas, `binfmt_misc` ne devrait pas être utile, donc le
premier `mount`
devrait suffire.

Sébastien

Bonjour,

Le Wed, 28 Sep 2022 11:07:17 +0200,
Sébastien NOBILI <s-liste-debian-user-french@pipoprods.org> a écrit :

Tu n'aurais pas une partition /var séparée sur ton système (sur le
disque dur) ?

Oui, c'est exact.


Pour ce qui est de la récursivité de bind par rapport Í  rbind, je te
remercie pour le détail de la démarche.
Je conserve tout cela précieusement pour m'y reporter lorsque je me
mettrais Í  nouveau sur l'usage de chroot.

Pour l'instant, bien que cela me tente d'avancer sur le chroot, je ne
vais pas prendre le risque de ne plus pouvoir booter sur la Buster. Je
vais juste me contenter d'installer en priorité Bulleye sur cette
machine et m'accommoder de l'imperfection de son BIOS/UEFI.


--
Alain Vaugham
Clef GPG : 0xDB77E054673ECFD2

Le 28/09/2022 Í  12:03, Alain Vaugham a écrit :

Bonjour,

Le Wed, 28 Sep 2022 11:07:17 +0200,
Sébastien NOBILI <s-liste-debian-user-french@pipoprods.org> a écrit :

Tu n'aurais pas une partition /var séparée sur ton système (sur le
disque dur) ?

Oui, c'est exact.

Dans ce cas il faut le monter une fois dans le chroot, au meme moment ou
tu monte la partoche EFI. Si tu avais fait mount -a ca l'aurait fait. Et
bien sur le démonter avant de quitter le chroot.

Est-ce qu'il y a d'autres subtilités de ton install que tu nous a pas
encore dites ?