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 bien
Re: Grosse fatigue
Thomas Parmelan a écrit : > Le samedi 24 septembre 2022 à 22:35, d'après > Pierre-Elliott Bécue : > >> BERTRAND Joël wrote on 23/09/2022 at >> 10:31:52+0200: >> >>> Sep 23 08:49:31 hilbert systemd[1]: Stopping User Manager for UID 0... > [...] >> Il y a une façon d'éviter que systemd ferme une session en cas de fin de >> tous les programmes interactifs d'un utilisateur, via "loginctl >> enable-linger $username". > > Question naïve, mais qui me turlupine à vous lire tous les deux : si je > comprends bien, la session graphique est lancée sous l'identité de root > (ce qui est rarement une idée géniale, mais c'est un autre débat). Absolument pas. La session est ouverte en tant qu'utilisateur standard authentifié par ypbind. J'interdis par configuration le login root en graphique. Il n'y a pas d'utilisateur "non système" dans les /etc/passwd des postes de travail. Ça permet à un utilisateur d'ouvrir n'importe quelle poste de travail (et ces postes de travail sont interchangeables. En cas de panne, on échange une machine, ce qui permet à l'utilisateur de continuer à travailler comme avant). > Par > défaut l'utilisateur root est exclu du système de "lingering", mais cela > vaudrait peut-être le coup de vérifier de ce côté : > > - dans /etc/systemd/logind.conf, est-ce que KillExcludeUsers est > positionné explicitement (et dans ce cas il faut s'assurer que > "root" est bien listé dedans) ? > > - le problème est-il reproductible par un autre utilisateur ? Tous les utilisateurs normaux des machines diskless sur le réseau en question ont les mêmes problèmes. En revanche, j'ai l'impression qu'un poste bien particulier ne pose pas de souci particulier. À la différence des autres, ce poste n'est utilisé que pour des appels vidéo et n'a pas de swap configuré (donc, a priori, une charge réseau plus faible, le swap étant en iSCSI sur les autres machines).
Re: Grosse fatigue
Le samedi 24 septembre 2022 à 22:35, d'après Pierre-Elliott Bécue : > BERTRAND Joël wrote on 23/09/2022 at > 10:31:52+0200: > > > Sep 23 08:49:31 hilbert systemd[1]: Stopping User Manager for UID 0... [...] > Il y a une façon d'éviter que systemd ferme une session en cas de fin de > tous les programmes interactifs d'un utilisateur, via "loginctl > enable-linger $username". Question naïve, mais qui me turlupine à vous lire tous les deux : si je comprends bien, la session graphique est lancée sous l'identité de root (ce qui est rarement une idée géniale, mais c'est un autre débat). Par défaut l'utilisateur root est exclu du système de "lingering", mais cela vaudrait peut-être le coup de vérifier de ce côté : - dans /etc/systemd/logind.conf, est-ce que KillExcludeUsers est positionné explicitement (et dans ce cas il faut s'assurer que "root" est bien listé dedans) ? - le problème est-il reproductible par un autre utilisateur ? -- Thomas Parmelan
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: Grosse fatigue
Pierre-Elliott Bécue a écrit : > Salut, > > BERTRAND Joël wrote on 26/09/2022 at > 09:44:54+0200: > >> Pierre-Elliott Bécue a écrit : >>> >>> BERTRAND Joël wrote on 23/09/2022 at >>> 10:31:52+0200: [snip] >>> >>> Ok, donc systemd ne tue pas X. systemd met un terme à la session de >>> root. La raison est que systemd détermine au moment où il le fait que le >>> dernier processus interactif (c'est-à-dire contrôlé par un utilisateur) >>> a terminé, et par défaut dans ce cas, il clos la session, et termine >>> donc tout programme lancé depuis cette session (logique, ça évite que >>> des trucs traînent ad-vitam comme résidus d'une session interactive). >>> >>> Dans la mesure où tu as a priori une session graphique qui tourne, c'est >>> effectivement surprenant, mais il est possible (vu que tu ne postes que >>> les logs qui t'intéressent, qui ne sont pas forcément les logs >>> pertinents) que ta session utilisateur meure pour une raison ou une >>> autre et qu'en conséquence, systemd considère qu'il n'y a plus aucun >>> programme interactif qui tourne. >> >> Il n'y a rien d'autre anormal avant cela, mais tu n'es pas contraint de >> me croire. Ce matin, d'ailleurs, je réveille ma machine (écrans en >> veille) pour constater une fois de plus que la session avait été tuée et >> que wdm n'était même plus actif. J'ai la flemme d'aller rechercher dans >> deux jours de logs pour trouver toujours le même message après des >> lignes tout à fait normales. >> >> Au passage, ça m'a fait exactement la même chose sur la machine de ma >> femme (dans la même configuration diskless) jusqu'au jour où j'en ai eu >> tellement marre que je lui ai installé un FreeBSD. Sauf que moi, je ne >> peux pas, j'ai un bout de soft propriétaire qui ne tourne que sous Linux. > > Très bien, mais as-tu, par exemple, unattended-upgrades ou équivalent > qui tourne ? As-tu un needrestart d'installé qui redémarrerait des > services agressivement en cas d'upgrade via un unattended-upgrades like? Non et non. J'ai déjà indiqué ça plus haut. Ce genre de chose merdoie allègrement en nfs root (il faut plusieurs heures pour un paquet comme TeXlive et ça engorge le réseau et le serveur nfs, c'est donc désactivé par défaut). >> Il n'y a pas de cron foireux, j'ai naturellement vérifié. ypbind tourne >> directement rattaché à init, donc ici à systemd et s'il y a un truc qui >> est stable, c'est bien ypbind. Quand je le lance dans une console, il >> récupère un signal 15 du père (ici systemd) > > Sauf si tu fais des trucs spécifique, en lançant ypbind dans une > console, c'est elle qui est parent de ypbind. À moins que ypbind se > détache mais dans ce cas tu ne devrais plus avoir de stdout/stderr. Je ne fais rien de spécifique (ypbind -dn). >> et c'est pour cela qu'il s'arrête. Ça peut mettre deux ou trois jours, >> plus encore, mais ce signal 15 du père finit TOUJOURS par >> arriver. Quand il est lancé en daemon, il n'y a strictement rien comme >> information pertinente dans les logs. Mais vu qu'il s'arrête en >> interactif sur un signal 15, je te file mon billet que c'est >> exactement la même chose lorsqu'il est en tâche de fond. La question >> est de savoir pourquoi systemd envoie un signal au processus en >> question. Dernière chose, j'ai installé Devuan avec le même ypbind sur >> un vieux portable dans la même configuration nis (mais avec un init >> SysV qui fonctionne et qui fait juste ce qu'on lui demande). Aucun >> problème. Ce n'est donc pas ypserv qui est en faute mais le père de >> ypbind (sinon, ypbind se baugerait aussi sur le portable en >> question). Je te l'accorde, c'est peut-être une interaction de systemd >> avec tout autre chose qui fait que la conséquence est un arrêt de >> ypbind. Mais ce quelque chose ne laisse dans ce cas aucune trace dans >> les logs. > > Et systemd est plutôt verbeux, donc c'est peu probable que ça soit lui > tout seul. > >> On est bien d'accord que ypbind n'a aucune raison de se prendre un >> signal 15 si X se bauge lui-même vu que ypbind n'est pas lancé dans la >> session X. On est bien d'accord que ce n'est pas ypbind qui s'envoie à >> lui-même un signal 15. >> >> Reste le problème des shells tournant dans des xterm. La session X est >> tuée, certes, mais tous les shells entrent dans un état bizarre >> lorsqu'ils sont rattachés à... systemd (parce que, là encore, j'ai >> vérifié les PPID). Et, naturellement, ce n'est pas un bug non plus. >> C'est juste un comportement non maîtrisé. Chose surprenante, le fait que >> les xterms soient tués par la fin de la session X ne tue pas les shells >> dépendants (?!). > > Bon, déjà tu as totalement mis de côté ma solution à base > d'enable-linger pour creuser. > > Ensuite, tu peux aussi installer auditd, et tracker tous les syscalls > dont les signaux envoyés. Ça te permettrait de savoir qui envoie de > SIGTERM. Voir plus loin pourquoi c'est inapplicable (encore une fois, je ne t'ai pas attendu, ça fait de lo
