Re: 10/Buster --> 11/Bulleye
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.
Re: 10/Buster --> 11/Bulleye
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". sda1EFI sda2/ sda3swap 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
Re: 10/Buster --> 11/Bulleye
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
Re: 10/Buster --> 11/Bulleye
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=E7D4-2329 /boot/efi vfatumask=0077 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)
Re: 10/Buster --> 11/Bulleye
Le 28/09/2022 à 12:03, Alain Vaugham a écrit : Bonjour, Le Wed, 28 Sep 2022 11:07:17 +0200, Sébastien NOBILI 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 ?
Re: 10/Buster --> 11/Bulleye
Bonjour, Le Wed, 28 Sep 2022 11:07:17 +0200, Sébastien NOBILI 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
Re: 10/Buster --> 11/Bulleye
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=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=13784) 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
Re: 10/Buster --> 11/Bulleye
Le Tue, 27 Sep 2022 13:39:31 +0200, hamster 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
Re: 10/Buster --> 11/Bulleye
Le Tue, 27 Sep 2022 13:39:31 +0200, hamster 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
Re: 10/Buster --> 11/Bulleye
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 et faire un reboot de la machine rapidement.
Re: 10/Buster --> 11/Bulleye
Le Tue, 27 Sep 2022 10:54:53 +0200, hamster a écrit : > Le 27/09/2022 à 01:26, Alain Vaugham a écrit : > > Le Mon, 26 Sep 2022 22:00:10 +0200, > > hamster 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
Re: 10/Buster --> 11/Bulleye
Le 27/09/2022 à 01:26, Alain Vaugham a écrit : Le Mon, 26 Sep 2022 22:00:10 +0200, hamster 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).
Re: 10/Buster --> 11/Bulleye
Le Mon, 26 Sep 2022 22:00:10 +0200, hamster 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
Re: 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 ?
10/Buster --> 11/Bulleye
Bonjour la liste, 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. Une idée? -- Alain Vaugham Clef GPG : 0xDB77E054673ECFD2
