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: Grosse fatigue
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? >> 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". Ici ça ressemble à du scotch sur une jambe de >> bois car cela ne t'aidera pas à comprendre ce qu'il se passe >> derrière. >> >> Creuser les logs (un cron qui se lance? ton wm qui meurt/crashe?) serait >> sans doute plus pertinent, voire activer certains debugs sur certains >> progs. Après l'enable-linger peut aider à voir ce qu'il se passe et >> trouver le nœud du problème si c'est effectivement un programme qui >> meurt (puisque dans ce cas il mourra toujours mais le reste ne sera pas >> buté). > > Figure-toi qu'avant de poster ici, j'ai un peu creusé, parce que ça > fait plusieurs mois que le problème dure. J'utilise Debian depuis Potato > et, avant, j'utilisais RedHat. Je sais où chercher et où creuser. > > J'ai tout d'abord cru que c'était wdm le fautif, mais avec xdm ou gdm, > le résultat est strictement identique. J'ai mis la chose sur le dos de > wmaker, j'ai essayé xfce. Idem. KDE, itou. Gnome, je ne peux pas, je > suis allergique. Quand je dis que le résultat est identique, c'est une > fermeture de la session comme si j'avais normalement quitté la session > (jamais de crash violent), mais avec les shells restant actifs, > rattachés à systemd et qui passent dans un état bizarre (utilisation CPU > maximale). J'ai mis ça sur le dos de la carte graphique. J'ai changé la > carte AMD par une NVidia avec le même résultat. > > J'ai même réinstallé le système en totalité (sans soft proprétaire, que > du Debian pour commencer) parce que mon installation datait un petit > peu. Même résultat. Et ce ne sont pas des programmes aléatoires qui sont > arrêtés, mais la session X ou ypbind (jamais autre chose, lorsque > d'autres daemons sont arrêtés, c'est parce que ypbind est stoppé au > préalable, n'est pas redémarré par systemd et que le daemon en question > crashe parce qu'il n'a plus accès aux tables NIS). Tu vois, j'ai un peu > creusé le sujet. > > 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. > 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
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 ?
Re: carte son externe de qualité HIFI USB
je serais intéressé mais est-il possible de régler la balance sur l'entrée ligne (c'est pour numériser des vinyles en utilisant la sortie ligne de mon ampli donc après la correction RIAA) ? Je ne sais pas te répondre, j'enregistre en mono en plugant un xlr dans le focusrite . Je ne suis même pas certain de comprendre ta question. Peut-être sur un forum dédié ? a+ f. Sylvain.
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
Re: Grosse fatigue
raphael.rign...@gmail.com a écrit :
> Basile Starynkevitch a écrit :
>>
>> On 23/09/2022 09:41, BERTRAND Joël wrote:
>>> Bonjour à tous,
> Bonjour
>>>
>>> Ce matin, une fois de plus, systemd a cru bon tuer X et,
>>> incidemment, toutes les applications en cours (me contraignant à
>>> repartir de la sauvegarde de la nuit, je n'ai heureusement perdu
>>> qu'une heure de travail). Ce ne serait encore pas trop grave s'il ne
>>> s'arrêtait pas au milieu du chemin, tuant X mais surtout pas les
>>> terminaux de contrôles dépendants de X :
>>
>>
>> Une suggestion en rapport est peut-être d'utiliser et d'améliorer mon
>> https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.
>> c
>
> Merci, j'ai déjà ce qu'il faut, donc au pire, je perds quelques heures
> de boulot. Ce qui m'énerve surtout, c'est que durant 25 ans, je considérais
> Linux en général et Debian en particulier comme un OS stable, robuste et
> qu'on pouvait utiliser dans des configurations spéciales. Ce n'est plus le
> cas aujourd'hui et c'est bien dommage.
> ---
> Je suis d'accord, les évolutions mettent nos vieux neurones à rude épreuve.
> Je me suis moi-même cassé les dents sur une Ubuntu 22.04 en desktop pour des
> étudiants qui font un peu de dev python avec Spyder et de la bdd Mysql
> workbench. Le premier ne fonctionne même pas car le python système 3.10 est
> en avance sur le package de spyder compatible avec 3.9, et pour le deuxième,
> le paquet issu du site officiel d'Oracle plante avec wayland. Même Firefox en
> version snap n'est pas compatible avec des home directory en NFS en dehors du
> /home. J'ai donc viré snap et wayland et d'autres bidouilles pour contourner
> les problèmes sans être certain d'une bonne stabilité. Pour du LTS je
> m'attendait à mieux, c'est usant...
>
> Pour en revenir à Debian et tes problèmes avec systemd, soit continuer à
> lutter soit passer sur devuan.org. Ce fork n'a pas été créé sans raison, tu
> n'es donc pas seul dans cette galère.
Je sais bien. Toutes mes nouvelles installations sont faites sur Devuan
(quand il faut du Linux) ou carrément sur des NetBSD (serveurs) ou
FreeBSD (postes de travail), mais je gère aussi un historique existant
et des prérequis. Si j'ai encore ma machine de dev sous Debian, c'est
parce que j'utilise un soft propriétaire à peu près supporté sous
Debian. J'appelle (trop) régulièrement le support, si je leur dis
d'emblée que j'utilise autre chose que Debian ou RedHat, je connais déjà
leur réponse ("démerdez-vous !"). On peut le déplorer, mais c'est comme
ça, malheureusement.
Sinon, on ne va pas parler de Wayland tellement il y aurait de choses à
dire... On se demande si ce truc a été sérieusement testé, mais là n'est
pas le sujet du fil.
En fait, je ne suis pas contre les évolutions, mais les évolutions pour
les évolutions, surtout quand elles sont forcées et qu'elles apportent
leur lot de régressions dont un paquet est parfaitement connu,
m'énervent au plus haut point. C'est le cas de systemd, mais c'est aussi
le cas d'usrmerge et de wayland qui sont des bouts de code conçus et
poussés par des gens certainement très compétents dans leurs domaines
respectifs, mais qui n'ont jamais été confrontés à certains problèmes
que l'on vit tous les jours dans l'embarqué. Ou qui pour des raisons
politiques, ne veulent surtout pas les voir. Aujourd'hui, il y a 1710
"issues" ouvertes sur systemd dont certaines particulièrement cocasses !
Ça fait beaucoup pour un système d'init imposé.
RE: Grosse fatigue
Basile Starynkevitch a écrit : > > On 23/09/2022 09:41, BERTRAND Joël wrote: >> Bonjour à tous, Bonjour >> >> Ce matin, une fois de plus, systemd a cru bon tuer X et, >> incidemment, toutes les applications en cours (me contraignant à >> repartir de la sauvegarde de la nuit, je n'ai heureusement perdu >> qu'une heure de travail). Ce ne serait encore pas trop grave s'il ne >> s'arrêtait pas au milieu du chemin, tuant X mais surtout pas les >> terminaux de contrôles dépendants de X : > > > Une suggestion en rapport est peut-être d'utiliser et d'améliorer mon > https://github.com/bstarynk/misc-basile/blob/master/sync-periodically. > c Merci, j'ai déjà ce qu'il faut, donc au pire, je perds quelques heures de boulot. Ce qui m'énerve surtout, c'est que durant 25 ans, je considérais Linux en général et Debian en particulier comme un OS stable, robuste et qu'on pouvait utiliser dans des configurations spéciales. Ce n'est plus le cas aujourd'hui et c'est bien dommage. --- Je suis d'accord, les évolutions mettent nos vieux neurones à rude épreuve. Je me suis moi-même cassé les dents sur une Ubuntu 22.04 en desktop pour des étudiants qui font un peu de dev python avec Spyder et de la bdd Mysql workbench. Le premier ne fonctionne même pas car le python système 3.10 est en avance sur le package de spyder compatible avec 3.9, et pour le deuxième, le paquet issu du site officiel d'Oracle plante avec wayland. Même Firefox en version snap n'est pas compatible avec des home directory en NFS en dehors du /home. J'ai donc viré snap et wayland et d'autres bidouilles pour contourner les problèmes sans être certain d'une bonne stabilité. Pour du LTS je m'attendait à mieux, c'est usant... Pour en revenir à Debian et tes problèmes avec systemd, soit continuer à lutter soit passer sur devuan.org. Ce fork n'a pas été créé sans raison, tu n'es donc pas seul dans cette galère. Bon courage. RaphR
Re: carte son externe de qualité HIFI USB
Le 26/09/2022 à 09:25, Fab a écrit : Hello, Connaissez-vous une ou des cartes son USB reconnues par LINUX et produisant un son de qualité HIFI. Certaines personnes appellent aussi ce produit un DAC. Pour info, j'ai acheté il y a quelques temps un focusrite (https://focusrite.com/en/usb-audio-interface/scarlett/scarlett-4i4) pour 200€. Il me sert à faire des enregistrements pas trop dégueu à 2 pistes. Il a fonctionné presque normalement sur linux. Depuis, un driver a été construit et intégré au noyau: https://linuxmusicians.com/viewtopic.php?f=6=20669=c787b5fc194fd8c1cef6a5e285573f13=135 Quant à l'applicatif qui prend en charge tous les paramètres du focusrite, il a été créé également! https://github.com/geoffreybennett/alsa-scarlett-gui/blob/master/USAGE.md Bref, c'est tout nickel! a+ f. Bonjour, je serais intéressé mais est-il possible de régler la balance sur l'entrée ligne (c'est pour numériser des vinyles en utilisant la sortie ligne de mon ampli donc après la correction RIAA) ? Sylvain.
Re: Grosse fatigue
Pierre-Elliott Bécue a écrit : > > BERTRAND Joël wrote on 23/09/2022 at > 10:31:52+0200: > >> Pierre-Elliott Bécue a écrit : >>> Une ligne de log, quelque chose qui montre que systemd a bien tué X >>> et éventuellement pourquoi, ou bien on est juste sur yet another >>> mail de baseless FUD? >> >> Sep 23 08:49:31 hilbert systemd[1]: Stopping User Manager for UID 0... >> Sep 23 08:49:31 hilbert systemd[577146]: Activating special unit Exit >> the Session... >> Sep 23 08:49:31 hilbert systemd[577146]: Removed slice User Core >> Session Slice. >> Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Main User Target. >> Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Basic System. >> Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Paths. >> Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Sockets. >> Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Timers. >> Sep 23 08:49:31 hilbert systemd[577146]: Closed D-Bus User Message Bus >> Socket. >> Sep 23 08:49:31 hilbert systemd[577146]: Closed GnuPG network >> certificate management daemon. >> Sep 23 08:49:31 hilbert systemd[577146]: Closed Socket to launch >> DrKonqi for a systemd-coredump crash. >> Sep 23 08:49:31 hilbert systemd[577146]: Closed GCR ssh-agent wrapper. >> Sep 23 08:49:31 hilbert systemd[577146]: Closed GNOME Keyring daemon. >> ... >> Sep 23 08:49:31 hilbert systemd[577146]: Reached target Shutdown. >> Sep 23 08:49:31 hilbert systemd[577146]: Finished Exit the Session. >> Sep 23 08:49:31 hilbert systemd[577146]: Reached target Exit the Session. >> Sep 23 08:49:31 hilbert systemd[1]: user@0.service: Deactivated >> successfully. >> Sep 23 08:49:31 hilbert systemd[1]: Stopped User Manager for UID 0. >> Sep 23 08:49:31 hilbert systemd[1]: Stopping User Runtime Directory >> /run/user/0... >> Sep 23 08:49:31 hilbert systemd[1]: run-user-0.mount: Deactivated >> successfully. >> Sep 23 08:49:31 hilbert systemd[1]: user-runtime-dir@0.service: >> Deactivated successfully. >> Sep 23 08:49:31 hilbert systemd[1]: Stopped User Runtime Directory >> /run/user/0. >> Sep 23 08:49:31 hilbert systemd[1]: Removed slice User Slice of UID 0. >> ... > > 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. > 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". Ici ça ressemble à du scotch sur une jambe de > bois car cela ne t'aidera pas à comprendre ce qu'il se passe > derrière. > > Creuser les logs (un cron qui se lance? ton wm qui meurt/crashe?) serait > sans doute plus pertinent, voire activer certains debugs sur certains > progs. Après l'enable-linger peut aider à voir ce qu'il se passe et > trouver le nœud du problème si c'est effectivement un programme qui > meurt (puisque dans ce cas il mourra toujours mais le reste ne sera pas > buté). Figure-toi qu'avant de poster ici, j'ai un peu creusé, parce que ça fait plusieurs mois que le problème dure. J'utilise Debian depuis Potato et, avant, j'utilisais RedHat. Je sais où chercher et où creuser. J'ai tout d'abord cru que c'était wdm le fautif, mais avec xdm ou gdm, le résultat est strictement identique. J'ai mis la chose sur le dos de wmaker, j'ai essayé xfce. Idem. KDE, itou. Gnome, je ne peux pas, je suis allergique. Quand je dis que le résultat est identique, c'est une fermeture de la session comme si j'avais normalement quitté la session (jamais de crash violent), mais avec les shells restant actifs, rattachés à systemd
Re: Grosse fatigue
Basile Starynkevitch a écrit : > > On 23/09/2022 09:41, BERTRAND Joël wrote: >> Bonjour à tous, >> >> Ce matin, une fois de plus, systemd a cru bon tuer X et, incidemment, >> toutes les applications en cours (me contraignant à repartir de la >> sauvegarde de la nuit, je n'ai heureusement perdu qu'une heure de >> travail). Ce ne serait encore pas trop grave s'il ne s'arrêtait pas au >> milieu du chemin, tuant X mais surtout pas les terminaux de contrôles >> dépendants de X : > > > Une suggestion en rapport est peut-être d'utiliser et d'améliorer mon > https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c Merci, j'ai déjà ce qu'il faut, donc au pire, je perds quelques heures de boulot. Ce qui m'énerve surtout, c'est que durant 25 ans, je considérais Linux en général et Debian en particulier comme un OS stable, robuste et qu'on pouvait utiliser dans des configurations spéciales. Ce n'est plus le cas aujourd'hui et c'est bien dommage.
Re: carte son externe de qualité HIFI USB
Hello, Connaissez-vous une ou des cartes son USB reconnues par LINUX et produisant un son de qualité HIFI. Certaines personnes appellent aussi ce produit un DAC. Pour info, j'ai acheté il y a quelques temps un focusrite (https://focusrite.com/en/usb-audio-interface/scarlett/scarlett-4i4) pour 200€. Il me sert à faire des enregistrements pas trop dégueu à 2 pistes. Il a fonctionné presque normalement sur linux. Depuis, un driver a été construit et intégré au noyau: https://linuxmusicians.com/viewtopic.php?f=6=20669=c787b5fc194fd8c1cef6a5e285573f13=135 Quant à l'applicatif qui prend en charge tous les paramètres du focusrite, il a été créé également! https://github.com/geoffreybennett/alsa-scarlett-gui/blob/master/USAGE.md Bref, c'est tout nickel! a+ f.
