Après avoir installé Bulleye, la machine UEFI sur laquelle
tournait Buster, refuse de booter sur Bulleye.
Ce qui a été fait:
A l'origine il y avait un disque de 1T sur lequel tournait uniquement
Buster. Pas de partition Windows.
- J'ai démonté ce disque.
- J'ai monté un disque de 4T qui avait été vérifié avec badblocks et
formaté sur une seule partition GPT avant d'y installer
debian-11.2.0-amd64-netinst.
- La machine avait été rebootée/éteinte plusieurs fois pour être sÍ»r
que l'installation était solide.
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.
N'ayant plus besoin du disque 1T/Buster et considérant que Bulleye
était solidement installé, je l'ai démonté.
Maintenant, bien que le disque 4T/Bulleye soit visible dans l'interface
UEFI, celle-ci refuse de booter sur lui. Si je remonte le 1T/Buster
alors seul le disque 1T/Buster est autorisé Í booter.
Au niveau de la Compatibility Support Module j'ai tenté différentes
configurations (Active/Auto/Disabled) mais sans résultat. C'est pareil
pour le Secure Boot (Autres SE/Windows) que le démarrage rapide soit
désactivé ou pas.
Seul le disque Buster est accepté par l'interface UEFI.
J'imagine que c'est un problème de clefs UEFI.
Les sources que j'ai suivies:
https://debian-facile.org/doc:install:uefi
https://debian-facile.org/doc:materiel:secure-boot
https://fr.wikipedia.org/wiki/UEFI#Lancement_s.C3.A9curis.C3.A9_.28secure_boot.29
Le tuto Debian Facile ne me semble pas correspondre au cas pour
lequel je viens vers vous car il n'y avait pas de partition Windows Í
préserver.
Concernant une recherche sur la version de l'interface UEFI
H97M-E Bios Ver.0334 IntelCore i3-4130 cela ne m'a mené que sur des
soucis avec Windows.
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?
L'ordre n'a aucune importance.
Chez moi j'ai fait: mount -o rbind /proc /mnt/racine/proc J'ai eu un refus: /proc is not a block device
Bien sur que /proc n'est pas un fichier bloc : c'est un dossier. Si il te dit ca c'est qu'il attendait un fichier bloc, or précisément l'option bind ou rbind est la pour lui dire que le truc a monter n'est pas un fichier bloc. A mon avis t'a du faire une faute de frappe quand tu a tapé "rbind". Ou alors t'a mis un espace insécable a la place d'un espace quelque part dans ta commande, par exemple entre le "-o" et le "rbind". En tout cas la réponse qu'il t'a faite montre qu'il a réagi comme si tu n'avait pas tapé l'option rbind.
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
Pour ce que j'en ai compris, l'option rbind est nécessaire pour /dev, pas pour /proc ni pour /sys. Mais comme j'en suis pas sur je continue a la taper partout. A mon avis ce que tu a fait est tout a fait valide.
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.
Comme déja relevé par sebastien (merci a lui) il ne pouvait pas trouver ce dossier vu que la partoche var n'était pas montée. mount -a peut aussi avoir du bon. update-grub ayant échoué, il est normal que grub ne fonctionne pas.
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.
Tu avait utilisé l'option bind sur /proc mais bien l'option rbind sur /dev. Donc tu aurait du avoir dev/pts. Ou alors c'est que tu a mal recopié ce que tu a fait quand tu a rédigé ton mail. Ou alors c'est une subtilité que je ne comprend pas. La, l'ordre a de l'importance : il faut démonter racine/dev/pts avant de démonter racine/dev, et il faut démonter racine/dev racine/proc et racine/sys avant de démonter racine. Tu peux démonter racine/proc et racine/sys quand tu veux du moment que c'est avant de démonter racine.
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.
C'est sage. Mais y'a quand meme au fond de moi une petite voix qui me dit que c'est dommage parce que tu y est presque.
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.
Ou en le branchant en USB en tant que disque externe après avoir démarré le système.
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.
Non, tu y est presque. Je t'incite a perseverer, meme si c'est pas sur cette machine, parce que c'est très pratique et efficace pour réparer grub. Je m'en sert aussi pour changer un mot de passe sur une machine ou j'ai perdu le mot de passe : je chroote, j'ai un terminal administrateur, je n'ai plus qu'a faire passwd. Je m'en sert aussi pour passer une machine du mode legacy au mode UEFI : - Je passe le bios en mode UEFI. - Je met un nouveau disque que je formatte avec une table de partitions GPT et avec une partiton EFI formattée en FAT32 avec les drapeaux boot et esp - Je copie le système de l'ancien disque au nouveau disque. - Je rajoute les lignes qui vont bien dans /mnt/racine/etc/fstab : # /boot/efi was on /dev/sda1 during installation UUIDçD4-2329 /boot/efi vfat umask 77 0 1 en adaptant l'UUID et /dev/sdxx - Je chroote. - Je fais : mkdir /boot/efi chmod 775 /boot/efi mount /boot/efi apt update apt remove grub-pc grub-common apt install grub-efi-amd64 grub-install /dev/sdx update-grub Et hop, j'ai un grub-efi-amd64 fonctionnel. (bien sur l'inverse marche aussi)
Le 28/09/2022 Í 02:02, Alain Vaugham a écrit :
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?
L'ordre n'a aucune importance.
Chez moi j'ai fait:
mount -o rbind /proc /mnt/racine/proc
J'ai eu un refus: /proc is not a block device
Bien sur que /proc n'est pas un fichier bloc : c'est un dossier.
Si il te dit ca c'est qu'il attendait un fichier bloc, or précisément
l'option bind ou rbind est la pour lui dire que le truc a monter n'est
pas un fichier bloc.
A mon avis t'a du faire une faute de frappe quand tu a tapé "rbind". Ou
alors t'a mis un espace insécable a la place d'un espace quelque part
dans ta commande, par exemple entre le "-o" et le "rbind".
En tout cas la réponse qu'il t'a faite montre qu'il a réagi comme si tu
n'avait pas tapé l'option rbind.
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
Pour ce que j'en ai compris, l'option rbind est nécessaire pour /dev,
pas pour /proc ni pour /sys. Mais comme j'en suis pas sur je continue a
la taper partout. A mon avis ce que tu a fait est tout a fait valide.
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.
Comme déja relevé par sebastien (merci a lui) il ne pouvait pas trouver
ce dossier vu que la partoche var n'était pas montée. mount -a peut
aussi avoir du bon.
update-grub ayant échoué, il est normal que grub ne fonctionne pas.
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.
Tu avait utilisé l'option bind sur /proc mais bien l'option rbind sur
/dev. Donc tu aurait du avoir dev/pts. Ou alors c'est que tu a mal
recopié ce que tu a fait quand tu a rédigé ton mail. Ou alors c'est une
subtilité que je ne comprend pas.
La, l'ordre a de l'importance : il faut démonter racine/dev/pts avant de
démonter racine/dev, et il faut démonter racine/dev racine/proc et
racine/sys avant de démonter racine. Tu peux démonter racine/proc et
racine/sys quand tu veux du moment que c'est avant de démonter racine.
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.
C'est sage. Mais y'a quand meme au fond de moi une petite voix qui me
dit que c'est dommage parce que tu y est presque.
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.
Ou en le branchant en USB en tant que disque externe après avoir démarré
le système.
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.
Non, tu y est presque. Je t'incite a perseverer, meme si c'est pas sur
cette machine, parce que c'est très pratique et efficace pour réparer grub.
Je m'en sert aussi pour changer un mot de passe sur une machine ou j'ai
perdu le mot de passe : je chroote, j'ai un terminal administrateur, je
n'ai plus qu'a faire passwd.
Je m'en sert aussi pour passer une machine du mode legacy au mode UEFIÂ :
- Je passe le bios en mode UEFI.
- Je met un nouveau disque que je formatte avec une table de partitions
GPT et avec une partiton EFI formattée en FAT32 avec les drapeaux boot
et esp
- Je copie le système de l'ancien disque au nouveau disque.
- Je rajoute les lignes qui vont bien dans /mnt/racine/etc/fstab :
# /boot/efi was on /dev/sda1 during installation
UUIDçD4-2329 /boot/efi vfat umask 77 0 1
en adaptant l'UUID et /dev/sdxx
- Je chroote.
- Je fais :
mkdir /boot/efi
chmod 775 /boot/efi
mount /boot/efi
apt update
apt remove grub-pc grub-common
apt install grub-efi-amd64
grub-install /dev/sdx
update-grub
Et hop, j'ai un grub-efi-amd64 fonctionnel. (bien sur l'inverse marche
aussi)
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?
L'ordre n'a aucune importance.
Chez moi j'ai fait: mount -o rbind /proc /mnt/racine/proc J'ai eu un refus: /proc is not a block device
Bien sur que /proc n'est pas un fichier bloc : c'est un dossier. Si il te dit ca c'est qu'il attendait un fichier bloc, or précisément l'option bind ou rbind est la pour lui dire que le truc a monter n'est pas un fichier bloc. A mon avis t'a du faire une faute de frappe quand tu a tapé "rbind". Ou alors t'a mis un espace insécable a la place d'un espace quelque part dans ta commande, par exemple entre le "-o" et le "rbind". En tout cas la réponse qu'il t'a faite montre qu'il a réagi comme si tu n'avait pas tapé l'option rbind.
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
Pour ce que j'en ai compris, l'option rbind est nécessaire pour /dev, pas pour /proc ni pour /sys. Mais comme j'en suis pas sur je continue a la taper partout. A mon avis ce que tu a fait est tout a fait valide.
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.
Comme déja relevé par sebastien (merci a lui) il ne pouvait pas trouver ce dossier vu que la partoche var n'était pas montée. mount -a peut aussi avoir du bon. update-grub ayant échoué, il est normal que grub ne fonctionne pas.
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.
Tu avait utilisé l'option bind sur /proc mais bien l'option rbind sur /dev. Donc tu aurait du avoir dev/pts. Ou alors c'est que tu a mal recopié ce que tu a fait quand tu a rédigé ton mail. Ou alors c'est une subtilité que je ne comprend pas. La, l'ordre a de l'importance : il faut démonter racine/dev/pts avant de démonter racine/dev, et il faut démonter racine/dev racine/proc et racine/sys avant de démonter racine. Tu peux démonter racine/proc et racine/sys quand tu veux du moment que c'est avant de démonter racine.
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.
C'est sage. Mais y'a quand meme au fond de moi une petite voix qui me dit que c'est dommage parce que tu y est presque.
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.
Ou en le branchant en USB en tant que disque externe après avoir démarré le système.
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.
Non, tu y est presque. Je t'incite a perseverer, meme si c'est pas sur cette machine, parce que c'est très pratique et efficace pour réparer grub. Je m'en sert aussi pour changer un mot de passe sur une machine ou j'ai perdu le mot de passe : je chroote, j'ai un terminal administrateur, je n'ai plus qu'a faire passwd. Je m'en sert aussi pour passer une machine du mode legacy au mode UEFI : - Je passe le bios en mode UEFI. - Je met un nouveau disque que je formatte avec une table de partitions GPT et avec une partiton EFI formattée en FAT32 avec les drapeaux boot et esp - Je copie le système de l'ancien disque au nouveau disque. - Je rajoute les lignes qui vont bien dans /mnt/racine/etc/fstab : # /boot/efi was on /dev/sda1 during installation UUIDçD4-2329 /boot/efi vfat umask 77 0 1 en adaptant l'UUID et /dev/sdxx - Je chroote. - Je fais : mkdir /boot/efi chmod 775 /boot/efi mount /boot/efi apt update apt remove grub-pc grub-common apt install grub-efi-amd64 grub-install /dev/sdx update-grub Et hop, j'ai un grub-efi-amd64 fonctionnel. (bien sur l'inverse marche aussi)
Alain Vaugham
Bonjour, Le Wed, 28 Sep 2022 15:11:24 +0200, hamster a écrit :
Non, tu y est presque. Je t'incite a perseverer, meme si c'est pas sur cette machine, parce que c'est très pratique et efficace pour réparer grub.
J'ai installé Bulleye sur un autre disque. Cela m'a permis de préserver le disque de 4T sur lequel je vais pouvoir, grÍ¢ce aux conseils que je trouve ici, continuer mon expérience de chroot. Je m'y remet ce soir. -- Alain Vaugham Clef GPG : 0xDB77E054673ECFD2
Bonjour,
Le Wed, 28 Sep 2022 15:11:24 +0200,
hamster <hamster@suna.fdn.fr> a écrit :
Non, tu y est presque. Je t'incite a perseverer, meme si c'est pas
sur cette machine, parce que c'est très pratique et efficace pour
réparer grub.
J'ai installé Bulleye sur un autre disque. Cela m'a permis de préserver
le disque de 4T sur lequel je vais pouvoir, gr͢ce aux conseils que je
trouve ici, continuer mon expérience de chroot.
Je m'y remet ce soir.
Bonjour, Le Wed, 28 Sep 2022 15:11:24 +0200, hamster a écrit :
Non, tu y est presque. Je t'incite a perseverer, meme si c'est pas sur cette machine, parce que c'est très pratique et efficace pour réparer grub.
J'ai installé Bulleye sur un autre disque. Cela m'a permis de préserver le disque de 4T sur lequel je vais pouvoir, grÍ¢ce aux conseils que je trouve ici, continuer mon expérience de chroot. Je m'y remet ce soir. -- Alain Vaugham Clef GPG : 0xDB77E054673ECFD2
Alain Vaugham
Le Fri, 30 Sep 2022 11:48:42 +0200, Alain Vaugham a écrit :
Bonjour, Le Wed, 28 Sep 2022 15:11:24 +0200, hamster a écrit :
Non, tu y est presque. Je t'incite a perseverer, meme si c'est pas sur cette machine, parce que c'est très pratique et efficace pour réparer grub.
J'ai installé Bulleye sur un autre disque. Cela m'a permis de préserver le disque de 4T sur lequel je vais pouvoir, grÍ¢ce aux conseils que je trouve ici, continuer mon expérience de chroot. Je m'y remet ce soir.
Bonjour, Cette fois-ci, grÍ¢ce Í tes conseils, la mise Í jour de grub a réussi. Depuis ce matin j'ai un disque qui semble être constamment accepté par le BIOS/UEFI. Au préalable, cela a été laborieux. J'ai réinstallé deux fois. Même le disque pour lequel j'avais vérifié la solidité de ses redémarrages a fini par être refusé par ce BIOS/UEFI. Je suis incapable de recréer le défaut. Je n'ai donc eu d'autre choix que de réussir Í mettre Í jour le grub, donc d'utiliser chroot. Par précaution j'ai fait une installation "tout dans une seule partition". sda1 EFI sda2 / sda3 swap Les montages, le chroot et la mise Í jour de grub n'ont pas généré d'erreur. Il y a eu un démontage qui n'a pas pu se faire: umount /mnt/racine/sys : Target is busy. En regardant j'ai vu que la cible c'était sur la clef USB du System Rescue. Je n'ai pas cherché Í comprendre, comme ce n'était que du démontage avant un reboot, j'ai rebooté. Je croise les doigts maintenant pour que cette config tienne. Je laisse quelques jours avant de refaire une install cette fois-ci avec une /var séparée. Pour ça, j'ai gardé tes conseils ainsi que ceux de Sébastien.
Est-ce qu'il y a d'autres subtilités de ton install que tu nous a pas encore dites ?
Non, je ne pense pas que ce soit des subtilités. J'aime bien avoir - une partition que pour les logs, - une pour un user (moi) - une tmp en RAM J'aime bien aussi avoir de la place disponible sur le disque au cas o͹ j'aurai besoin d'ajouter brutalement une partition. Est-ce que les deux montages ci-dessous seraient des subtilités? tmpfs /tmp tmpfs defaults,size=1g 0 0 192.168.33.128:/mnt/nfs_labas /mnt/nfs_ici nfs defaults 0 2 Merci beaucoup encore pour le coup de pouce. -- Alain Vaugham Clef GPG : 0xDB77E054673ECFD2
Le Fri, 30 Sep 2022 11:48:42 +0200,
Alain Vaugham <alain@vaugham.com> a écrit :
Bonjour,
Le Wed, 28 Sep 2022 15:11:24 +0200,
hamster <hamster@suna.fdn.fr> a écrit :
> Non, tu y est presque. Je t'incite a perseverer, meme si c'est pas
> sur cette machine, parce que c'est très pratique et efficace pour
> réparer grub.
J'ai installé Bulleye sur un autre disque. Cela m'a permis de
préserver le disque de 4T sur lequel je vais pouvoir, grÍ¢ce aux
conseils que je trouve ici, continuer mon expérience de chroot.
Je m'y remet ce soir.
Bonjour,
Cette fois-ci, grÍ¢ce Í tes conseils, la mise Í jour de grub a réussi.
Depuis ce matin j'ai un disque qui semble être constamment accepté par
le BIOS/UEFI.
Au préalable, cela a été laborieux. J'ai réinstallé deux fois.
Même le disque pour lequel j'avais vérifié la solidité de ses
redémarrages a fini par être refusé par ce BIOS/UEFI. Je suis incapable
de recréer le défaut.
Je n'ai donc eu d'autre choix que de réussir Í mettre Í jour le grub,
donc d'utiliser chroot.
Par précaution j'ai fait une installation "tout dans une seule
partition".
sda1 EFI
sda2 /
sda3 swap
Les montages, le chroot et la mise Í jour de grub n'ont pas généré
d'erreur.
Il y a eu un démontage qui n'a pas pu se faire:
umount /mnt/racine/sys : Target is busy.
En regardant j'ai vu que la cible c'était sur la clef USB du System
Rescue. Je n'ai pas cherché Í comprendre, comme ce n'était que du
démontage avant un reboot, j'ai rebooté.
Je croise les doigts maintenant pour que cette config tienne. Je laisse
quelques jours avant de refaire une install cette fois-ci avec une /var
séparée. Pour ça, j'ai gardé tes conseils ainsi que ceux de Sébastien.
Est-ce qu'il y a d'autres subtilités de ton install que tu nous a pas
encore dites ?
Non, je ne pense pas que ce soit des subtilités. J'aime bien avoir
- une partition que pour les logs,
- une pour un user (moi)
- une tmp en RAM
J'aime bien aussi avoir de la place disponible sur le disque au cas o͹
j'aurai besoin d'ajouter brutalement une partition.
Est-ce que les deux montages ci-dessous seraient des subtilités?
tmpfs /tmp tmpfs defaults,size=1g 0 0
192.168.33.128:/mnt/nfs_labas /mnt/nfs_ici nfs defaults 0 2
Le Fri, 30 Sep 2022 11:48:42 +0200, Alain Vaugham a écrit :
Bonjour, Le Wed, 28 Sep 2022 15:11:24 +0200, hamster a écrit :
Non, tu y est presque. Je t'incite a perseverer, meme si c'est pas sur cette machine, parce que c'est très pratique et efficace pour réparer grub.
J'ai installé Bulleye sur un autre disque. Cela m'a permis de préserver le disque de 4T sur lequel je vais pouvoir, grÍ¢ce aux conseils que je trouve ici, continuer mon expérience de chroot. Je m'y remet ce soir.
Bonjour, Cette fois-ci, grÍ¢ce Í tes conseils, la mise Í jour de grub a réussi. Depuis ce matin j'ai un disque qui semble être constamment accepté par le BIOS/UEFI. Au préalable, cela a été laborieux. J'ai réinstallé deux fois. Même le disque pour lequel j'avais vérifié la solidité de ses redémarrages a fini par être refusé par ce BIOS/UEFI. Je suis incapable de recréer le défaut. Je n'ai donc eu d'autre choix que de réussir Í mettre Í jour le grub, donc d'utiliser chroot. Par précaution j'ai fait une installation "tout dans une seule partition". sda1 EFI sda2 / sda3 swap Les montages, le chroot et la mise Í jour de grub n'ont pas généré d'erreur. Il y a eu un démontage qui n'a pas pu se faire: umount /mnt/racine/sys : Target is busy. En regardant j'ai vu que la cible c'était sur la clef USB du System Rescue. Je n'ai pas cherché Í comprendre, comme ce n'était que du démontage avant un reboot, j'ai rebooté. Je croise les doigts maintenant pour que cette config tienne. Je laisse quelques jours avant de refaire une install cette fois-ci avec une /var séparée. Pour ça, j'ai gardé tes conseils ainsi que ceux de Sébastien.
Est-ce qu'il y a d'autres subtilités de ton install que tu nous a pas encore dites ?
Non, je ne pense pas que ce soit des subtilités. J'aime bien avoir - une partition que pour les logs, - une pour un user (moi) - une tmp en RAM J'aime bien aussi avoir de la place disponible sur le disque au cas o͹ j'aurai besoin d'ajouter brutalement une partition. Est-ce que les deux montages ci-dessous seraient des subtilités? tmpfs /tmp tmpfs defaults,size=1g 0 0 192.168.33.128:/mnt/nfs_labas /mnt/nfs_ici nfs defaults 0 2 Merci beaucoup encore pour le coup de pouce. -- Alain Vaugham Clef GPG : 0xDB77E054673ECFD2
hamster
Le 01/10/2022 Í 23:34, Alain Vaugham a écrit :
Il y a eu un démontage qui n'a pas pu se faire: umount /mnt/racine/sys : Target is busy. En regardant j'ai vu que la cible c'était sur la clef USB du System Rescue.
Heu, c'est curieux. Personnellement j'utilise l'option "docache" de systemrescue, comme ca il commence par copier le système dans la RAM, puis il boote sur l'image qui est dans la RAM. Comme ca la clef n'est plus utilisée et tu peux la débrancher. Les performances sont bien meilleures et en plus, c'est parfois pratique de liberer une prise USB.
Est-ce qu'il y a d'autres subtilités de ton install que tu nous a pas encore dites ?
Non, je ne pense pas que ce soit des subtilités. J'aime bien avoir
Ah, désolé de mon vocabulaire. Je n'ai pas pensé a quoi que ce soit de dévalorisant en utilisant ce mot. Alors je reformule : est-ce qu'il y a d'autres trucs que tu nous a pas encore dits ?
- une partition que pour les logs, - une pour un user (moi) - une tmp en RAM J'aime bien aussi avoir de la place disponible sur le disque au cas o͹ j'aurai besoin d'ajouter brutalement une partition. Est-ce que les deux montages ci-dessous seraient des subtilités? tmpfs /tmp tmpfs defaults,size=1g 0 0 192.168.33.128:/mnt/nfs_labas /mnt/nfs_ici nfs defaults 0 2
Pour que le chroot fonctionne, il faut que le système ait tout ses morceaux. Tu peux comparer ca a un organisme : pour qu'il soit vivant il faut qu'il ait tous ses organes. Quand tu fais un chroot, c'est le noyau de systemrescue qui fonctionne, donc le noyau du système sur lequel tu chroote n'est pas utilisé. Par contre il faut que le système ait accès a tous ses dossiers et fichiers système. Il n'y a pas besoin de /home pour reinstaller grub parce que c'est une commande qui ne manipule rien dans ce dossier, mais pour d'autres commandes ca pourrait etre necessaire. Il y a besoin de tous les autres dossiers système, y compris la partoche dédiée aux logs et /tmp. Mais /tmp est juste un espace dans lequel des fichiers temporaires pourront etres écrits et il peut tout a fait etre vide au démarrage. Donc tu peux très bien ne rien monter sur le dossier /tmp : ainsi les éventuels fichiers temporaires générées par les commandes que tu exécute seront écrits directement dans le dossier /tmp, c'est a dire dans la partition racine. Dans ce cas je te conseille d'aller supprimer tout le contenu de /mnt/racine/tmp après etre sorti du chroot, pour éviter d'avoir des fichiers temporaires obsolètes qui trainent pour rien dans ce dossier. Par contre un dossier distant NFS n'est pas un dossier du système, donc y'a pas besoin de le monter pour que le système fonctionne. De facon générale tout ce qui est monté dans /mnt et dans /média ne fait pas partie du système, vu que c'est précisément des dossiers dédiés au montage de trucs exterieurs au système.
Le 01/10/2022 Í 23:34, Alain Vaugham a écrit :
Il y a eu un démontage qui n'a pas pu se faire:
umount /mnt/racine/sys : Target is busy.
En regardant j'ai vu que la cible c'était sur la clef USB du System
Rescue.
Heu, c'est curieux.
Personnellement j'utilise l'option "docache" de systemrescue, comme ca
il commence par copier le système dans la RAM, puis il boote sur l'image
qui est dans la RAM. Comme ca la clef n'est plus utilisée et tu peux la
débrancher. Les performances sont bien meilleures et en plus, c'est
parfois pratique de liberer une prise USB.
Est-ce qu'il y a d'autres subtilités de ton install que tu nous a pas
encore dites ?
Non, je ne pense pas que ce soit des subtilités. J'aime bien avoir
Ah, désolé de mon vocabulaire. Je n'ai pas pensé a quoi que ce soit de
dévalorisant en utilisant ce mot. Alors je reformule : est-ce qu'il y a
d'autres trucs que tu nous a pas encore dits ?
- une partition que pour les logs,
- une pour un user (moi)
- une tmp en RAM
J'aime bien aussi avoir de la place disponible sur le disque au cas o͹
j'aurai besoin d'ajouter brutalement une partition.
Est-ce que les deux montages ci-dessous seraient des subtilités?
tmpfs /tmp tmpfs defaults,size=1g 0 0
192.168.33.128:/mnt/nfs_labas /mnt/nfs_ici nfs defaults 0 2
Pour que le chroot fonctionne, il faut que le système ait tout ses
morceaux. Tu peux comparer ca a un organisme : pour qu'il soit vivant il
faut qu'il ait tous ses organes.
Quand tu fais un chroot, c'est le noyau de systemrescue qui fonctionne,
donc le noyau du système sur lequel tu chroote n'est pas utilisé. Par
contre il faut que le système ait accès a tous ses dossiers et fichiers
système.
Il n'y a pas besoin de /home pour reinstaller grub parce que c'est une
commande qui ne manipule rien dans ce dossier, mais pour d'autres
commandes ca pourrait etre necessaire.
Il y a besoin de tous les autres dossiers système, y compris la partoche
dédiée aux logs et /tmp. Mais /tmp est juste un espace dans lequel des
fichiers temporaires pourront etres écrits et il peut tout a fait etre
vide au démarrage. Donc tu peux très bien ne rien monter sur le dossier
/tmp : ainsi les éventuels fichiers temporaires générées par les
commandes que tu exécute seront écrits directement dans le dossier /tmp,
c'est a dire dans la partition racine. Dans ce cas je te conseille
d'aller supprimer tout le contenu de /mnt/racine/tmp après etre sorti du
chroot, pour éviter d'avoir des fichiers temporaires obsolètes qui
trainent pour rien dans ce dossier.
Par contre un dossier distant NFS n'est pas un dossier du système, donc
y'a pas besoin de le monter pour que le système fonctionne. De facon
générale tout ce qui est monté dans /mnt et dans /média ne fait pas
partie du système, vu que c'est précisément des dossiers dédiés au
montage de trucs exterieurs au système.
Il y a eu un démontage qui n'a pas pu se faire: umount /mnt/racine/sys : Target is busy. En regardant j'ai vu que la cible c'était sur la clef USB du System Rescue.
Heu, c'est curieux. Personnellement j'utilise l'option "docache" de systemrescue, comme ca il commence par copier le système dans la RAM, puis il boote sur l'image qui est dans la RAM. Comme ca la clef n'est plus utilisée et tu peux la débrancher. Les performances sont bien meilleures et en plus, c'est parfois pratique de liberer une prise USB.
Est-ce qu'il y a d'autres subtilités de ton install que tu nous a pas encore dites ?
Non, je ne pense pas que ce soit des subtilités. J'aime bien avoir
Ah, désolé de mon vocabulaire. Je n'ai pas pensé a quoi que ce soit de dévalorisant en utilisant ce mot. Alors je reformule : est-ce qu'il y a d'autres trucs que tu nous a pas encore dits ?
- une partition que pour les logs, - une pour un user (moi) - une tmp en RAM J'aime bien aussi avoir de la place disponible sur le disque au cas o͹ j'aurai besoin d'ajouter brutalement une partition. Est-ce que les deux montages ci-dessous seraient des subtilités? tmpfs /tmp tmpfs defaults,size=1g 0 0 192.168.33.128:/mnt/nfs_labas /mnt/nfs_ici nfs defaults 0 2
Pour que le chroot fonctionne, il faut que le système ait tout ses morceaux. Tu peux comparer ca a un organisme : pour qu'il soit vivant il faut qu'il ait tous ses organes. Quand tu fais un chroot, c'est le noyau de systemrescue qui fonctionne, donc le noyau du système sur lequel tu chroote n'est pas utilisé. Par contre il faut que le système ait accès a tous ses dossiers et fichiers système. Il n'y a pas besoin de /home pour reinstaller grub parce que c'est une commande qui ne manipule rien dans ce dossier, mais pour d'autres commandes ca pourrait etre necessaire. Il y a besoin de tous les autres dossiers système, y compris la partoche dédiée aux logs et /tmp. Mais /tmp est juste un espace dans lequel des fichiers temporaires pourront etres écrits et il peut tout a fait etre vide au démarrage. Donc tu peux très bien ne rien monter sur le dossier /tmp : ainsi les éventuels fichiers temporaires générées par les commandes que tu exécute seront écrits directement dans le dossier /tmp, c'est a dire dans la partition racine. Dans ce cas je te conseille d'aller supprimer tout le contenu de /mnt/racine/tmp après etre sorti du chroot, pour éviter d'avoir des fichiers temporaires obsolètes qui trainent pour rien dans ce dossier. Par contre un dossier distant NFS n'est pas un dossier du système, donc y'a pas besoin de le monter pour que le système fonctionne. De facon générale tout ce qui est monté dans /mnt et dans /média ne fait pas partie du système, vu que c'est précisément des dossiers dédiés au montage de trucs exterieurs au système.
