Il ne m'est plus possible d'utiliser une console TTY
sur un serveur Mint19.1..... Quand je bascule sur les
consoles TTY 1,2 ...etc, je peux y introduire
l'ID utilisateur, mais ensuite le password va trop trop
vite, ne me laisse pas le temps d'entrer le password
et s'affole trois fois de suite pour finalement
me présenter l'invite de login et recommencer son
petit jeux de cache-cache.
Si j'arrive mais seulement si j'y arrive à introduire le password
à la vitesse "grand V" celui-ci est accepté
et la session peut commencer ;[ .... Mais
un <sudo ls> me demande le password à la vitesse "grand V"
Si depuis une autre machine j'établis une connexion
ssh les invites login/mot de passe se déroulent sans
problème. Un <sudo ls> se déroule normalement à la bonne vitesse.
Si au bureau Mate j'ouvre un terminal
et je fais <sudo ls>, tout se déroule normalement à la bonne vitesse.
Et c'est bien la première fois que je me dis ma foi Mate
Mint nous mène en bateau.
Maintenant, d'où ceci peut provenir ? Cette installation
de Mint 19.1 est toute récente, c'est à peine si j'ai
basculé sur console pour y faire
un dpkg-reconfigure console-setup,
suivi d'une installation gpm.
La même manip sur un serveur 17.3 ne pose aucun problème...
Si vous avez un conseil une idée... D'avance je vous remercie.
dyrmak
--
Más te quisiera, más te amo yo
++++ --- ++++
Linux operating system
++++ --- ++++
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sergio
Le 28/02/2019 à 18:44, dyrmak a écrit :
Bonjour, bonsoir! Il ne m'est plus possible d'utiliser une console TTY sur un serveur Mint19.1..... Quand je bascule sur les consoles TTY 1,2 ...etc, je peux y introduire l'ID utilisateur, mais ensuite le password va trop trop vite, ne me laisse pas le temps d'entrer le password et s'affole trois fois de suite pour finalement me présenter l'invite de login et recommencer son petit jeux de cache-cache.
Bizarre... Je viens d'essayer et ça marche ! LM 19.1 MATE 64 bits. Pas de messages d'erreurs parasites sur la console qui trouble la saisie du login ? -- Serge http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 28/02/2019 à 18:44, dyrmak a écrit :
Bonjour, bonsoir!
Il ne m'est plus possible d'utiliser une console TTY
sur un serveur Mint19.1..... Quand je bascule sur les
consoles TTY 1,2 ...etc, je peux y introduire
l'ID utilisateur, mais ensuite le password va trop trop
vite, ne me laisse pas le temps d'entrer le password
et s'affole trois fois de suite pour finalement
me présenter l'invite de login et recommencer son
petit jeux de cache-cache.
Bizarre... Je viens d'essayer et ça marche !
LM 19.1 MATE 64 bits.
Pas de messages d'erreurs parasites sur la console qui trouble la saisie du login ?
--
Serge http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Bonjour, bonsoir! Il ne m'est plus possible d'utiliser une console TTY sur un serveur Mint19.1..... Quand je bascule sur les consoles TTY 1,2 ...etc, je peux y introduire l'ID utilisateur, mais ensuite le password va trop trop vite, ne me laisse pas le temps d'entrer le password et s'affole trois fois de suite pour finalement me présenter l'invite de login et recommencer son petit jeux de cache-cache.
Bizarre... Je viens d'essayer et ça marche ! LM 19.1 MATE 64 bits. Pas de messages d'erreurs parasites sur la console qui trouble la saisie du login ? -- Serge http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
dyrmak
En 21 lignes Sergio a écrit dans news:5c7820e9$0$15484$ le jeudi, 28 février 2019 à 18:56:57 :
Bizarre... Je viens d'essayer et ça marche ! LM 19.1 MATE 64 bits. Pas de messages d'erreurs parasites sur la console qui trouble la saisie du login?
LM19.1 MATE 32bits Sur la console tout est normal, jusqu'au moment de la saisie du mot de passe, mais je viens de regarder le syslog: Feb 28 19:00:13 palmita systemd[1]: : Service has no hold-off time, scheduling restart. Feb 28 19:00:13 palmita systemd[1]: : Scheduled restart job, restart counter is at 4. Voilà pour le moment dyrmak -- ¿ De quién fue la culpa ? No sé de la suerte ++++ --- ++++ Linux operating system ++++ --- ++++
En 21 lignes Sergio a écrit
dans news:5c7820e9$0$15484$426a74cc@news.free.fr
le jeudi, 28 février 2019 à 18:56:57 :
Bizarre... Je viens d'essayer et ça marche !
LM 19.1 MATE 64 bits.
Pas de messages d'erreurs parasites sur la console qui trouble la saisie du
login?
LM19.1 MATE 32bits
Sur la console tout est normal, jusqu'au moment
de la saisie du mot de passe, mais je viens de regarder le syslog:
Feb 28 19:00:13 palmita systemd[1]: getty@tty1.service: Service has no
hold-off time, scheduling restart.
Feb 28 19:00:13 palmita systemd[1]: getty@tty1.service: Scheduled
restart job, restart counter is at 4.
Voilà pour le moment
dyrmak
--
¿ De quién fue la culpa ? No sé de la suerte
++++ --- ++++
Linux operating system
++++ --- ++++
En 21 lignes Sergio a écrit dans news:5c7820e9$0$15484$ le jeudi, 28 février 2019 à 18:56:57 :
Bizarre... Je viens d'essayer et ça marche ! LM 19.1 MATE 64 bits. Pas de messages d'erreurs parasites sur la console qui trouble la saisie du login?
LM19.1 MATE 32bits Sur la console tout est normal, jusqu'au moment de la saisie du mot de passe, mais je viens de regarder le syslog: Feb 28 19:00:13 palmita systemd[1]: : Service has no hold-off time, scheduling restart. Feb 28 19:00:13 palmita systemd[1]: : Scheduled restart job, restart counter is at 4. Voilà pour le moment dyrmak -- ¿ De quién fue la culpa ? No sé de la suerte ++++ --- ++++ Linux operating system ++++ --- ++++
denis.paris
Le 28/02/2019 à 18:44, dyrmak a écrit :
Bonjour, bonsoir! Il ne m'est plus possible d'utiliser une console TTY sur un serveur Mint19.1..... Quand je bascule sur les consoles TTY 1,2 ...etc, je peux y introduire l'ID utilisateur, mais ensuite le password va trop trop vite, ne me laisse pas le temps d'entrer le password et s'affole trois fois de suite pour finalement me présenter l'invite de login et recommencer son petit jeux de cache-cache. Si j'arrive mais seulement si j'y arrive à introduire le password à la vitesse "grand V" celui-ci est accepté et la session peut commencer ;[ .... Mais un <sudo ls> me demande le password à la vitesse "grand V" Si depuis une autre machine j'établis une connexion ssh les invites login/mot de passe se déroulent sans problème. Un <sudo ls> se déroule normalement à la bonne vitesse. Si au bureau Mate j'ouvre un terminal et je fais <sudo ls>, tout se déroule normalement à la bonne vitesse. Et c'est bien la première fois que je me dis ma foi Mate Mint nous mène en bateau. Maintenant, d'où ceci peut provenir ? Cette installation de Mint 19.1 est toute récente, c'est à peine si j'ai basculé sur console pour y faire un dpkg-reconfigure console-setup, suivi d'une installation gpm. La même manip sur un serveur 17.3 ne pose aucun problème... Si vous avez un conseil une idée... D'avance je vous remercie. dyrmak
Ça ressemble à mon problème que j'ai signalé le 1/2/2019 sous le titre "Problème TTY suite à mise à jour xubuntu 18-04 fin janvier 2019". C'est apparu avec le noyau 4.15.0-45-generic avec xubuntu 18-04. Ce sujet n'avait d'ailleurs pas donné lieu à beaucoup de commentaires, je pensais être seul au monde avec ce problème. En effet, sous une console TTY je peux rentrer le user, puis le système se met à boucler et à rendre la main au bout de quelques secondes sans donner l'occasion de rentrer le mot de passe. J'attends la mise à jour suivante du noyau.
Le 28/02/2019 à 18:44, dyrmak a écrit :
Bonjour, bonsoir!
Il ne m'est plus possible d'utiliser une console TTY
sur un serveur Mint19.1..... Quand je bascule sur les
consoles TTY 1,2 ...etc, je peux y introduire
l'ID utilisateur, mais ensuite le password va trop trop
vite, ne me laisse pas le temps d'entrer le password
et s'affole trois fois de suite pour finalement
me présenter l'invite de login et recommencer son
petit jeux de cache-cache.
Si j'arrive mais seulement si j'y arrive à introduire le password
à la vitesse "grand V" celui-ci est accepté
et la session peut commencer ;[ .... Mais
un <sudo ls> me demande le password à la vitesse "grand V"
Si depuis une autre machine j'établis une connexion
ssh les invites login/mot de passe se déroulent sans
problème. Un <sudo ls> se déroule normalement à la bonne vitesse.
Si au bureau Mate j'ouvre un terminal
et je fais <sudo ls>, tout se déroule normalement à la bonne vitesse.
Et c'est bien la première fois que je me dis ma foi Mate
Mint nous mène en bateau.
Maintenant, d'où ceci peut provenir ? Cette installation
de Mint 19.1 est toute récente, c'est à peine si j'ai
basculé sur console pour y faire
un dpkg-reconfigure console-setup,
suivi d'une installation gpm.
La même manip sur un serveur 17.3 ne pose aucun problème...
Si vous avez un conseil une idée... D'avance je vous remercie.
dyrmak
Ça ressemble à mon problème que j'ai signalé le 1/2/2019 sous le titre
"Problème TTY suite à mise à jour xubuntu 18-04 fin janvier 2019". C'est
apparu avec le noyau 4.15.0-45-generic avec xubuntu 18-04. Ce sujet
n'avait d'ailleurs pas donné lieu à beaucoup de commentaires, je pensais
être seul au monde avec ce problème.
En effet, sous une console TTY je peux rentrer le user, puis le système
se met à boucler et à rendre la main au bout de quelques secondes sans
donner l'occasion de rentrer le mot de passe. J'attends la mise à jour
suivante du noyau.
Bonjour, bonsoir! Il ne m'est plus possible d'utiliser une console TTY sur un serveur Mint19.1..... Quand je bascule sur les consoles TTY 1,2 ...etc, je peux y introduire l'ID utilisateur, mais ensuite le password va trop trop vite, ne me laisse pas le temps d'entrer le password et s'affole trois fois de suite pour finalement me présenter l'invite de login et recommencer son petit jeux de cache-cache. Si j'arrive mais seulement si j'y arrive à introduire le password à la vitesse "grand V" celui-ci est accepté et la session peut commencer ;[ .... Mais un <sudo ls> me demande le password à la vitesse "grand V" Si depuis une autre machine j'établis une connexion ssh les invites login/mot de passe se déroulent sans problème. Un <sudo ls> se déroule normalement à la bonne vitesse. Si au bureau Mate j'ouvre un terminal et je fais <sudo ls>, tout se déroule normalement à la bonne vitesse. Et c'est bien la première fois que je me dis ma foi Mate Mint nous mène en bateau. Maintenant, d'où ceci peut provenir ? Cette installation de Mint 19.1 est toute récente, c'est à peine si j'ai basculé sur console pour y faire un dpkg-reconfigure console-setup, suivi d'une installation gpm. La même manip sur un serveur 17.3 ne pose aucun problème... Si vous avez un conseil une idée... D'avance je vous remercie. dyrmak
Ça ressemble à mon problème que j'ai signalé le 1/2/2019 sous le titre "Problème TTY suite à mise à jour xubuntu 18-04 fin janvier 2019". C'est apparu avec le noyau 4.15.0-45-generic avec xubuntu 18-04. Ce sujet n'avait d'ailleurs pas donné lieu à beaucoup de commentaires, je pensais être seul au monde avec ce problème. En effet, sous une console TTY je peux rentrer le user, puis le système se met à boucler et à rendre la main au bout de quelques secondes sans donner l'occasion de rentrer le mot de passe. J'attends la mise à jour suivante du noyau.
dyrmak
En 30 lignes dyrmak a écrit dans news: le jeudi, 28 février 2019 à 19:08:01 :
En 21 lignes Sergio a écrit dans news:5c7820e9$0$15484$ le jeudi, 28 février 2019 à 18:56:57 :
Bizarre... Je viens d'essayer et ça marche ! LM 19.1 MATE 64 bits. Pas de messages d'erreurs parasites sur la console qui trouble la saisie du login?
LM19.1 MATE 32bits Sur la console tout est normal, jusqu'au moment de la saisie du mot de passe, mais je viens de regarder le syslog: Feb 28 19:00:13 palmita systemd[1]: : Service has no hold-off time, scheduling restart. Feb 28 19:00:13 palmita systemd[1]: : Scheduled restart job, restart counter is at 4. Voilà pour le moment
.... Et il y a du nouveau.... Le fait d'avoir un système entièrement sous systemd rend les interprétations un poil plus énigmatiques, mais les messages sont bien déclenchés par le login TTY qui échoue. Normalement sous TTY l'attente du mot de passe est de 60 secondes, là clairement : grep TIMEOUT /etc/login.defs LOGIN_TIMEOUT 60 C'est la même défition chez Jessie-Debian ce qui dédouanerait le programme login, alors j'allais examiner mon bash_history pour enlever un à un les dernières modifications, supprimer ou même arrêter gpm suffit à faire disparaître l'anomalie... Quelque part c'est bien un bug de la distribution, ou des distributions dérivées Debian. Je pense donc que ceux qui n'ont pas gpm, s'ils l'installent ils vont tomber sur le bug.... dyrmak -- Se hace camino al andar ++++ --- ++++ Linux operating system ++++ --- ++++
En 30 lignes dyrmak a écrit
dans news:slrnq7g8s3.4dn.dyrmak@quelite.terre
le jeudi, 28 février 2019 à 19:08:01 :
En 21 lignes Sergio a écrit
dans news:5c7820e9$0$15484$426a74cc@news.free.fr
le jeudi, 28 février 2019 à 18:56:57 :
Bizarre... Je viens d'essayer et ça marche !
LM 19.1 MATE 64 bits.
Pas de messages d'erreurs parasites sur la console qui trouble la saisie du
login?
LM19.1 MATE 32bits
Sur la console tout est normal, jusqu'au moment
de la saisie du mot de passe, mais je viens de regarder le syslog:
Feb 28 19:00:13 palmita systemd[1]: getty@tty1.service: Service has no
hold-off time, scheduling restart.
Feb 28 19:00:13 palmita systemd[1]: getty@tty1.service: Scheduled
restart job, restart counter is at 4.
Voilà pour le moment
.... Et il y a du nouveau....
Le fait d'avoir un système entièrement sous systemd rend les
interprétations un poil plus énigmatiques, mais les messages
getty@tty1.service sont bien déclenchés par le login TTY
qui échoue. Normalement sous TTY l'attente du mot de passe
est de 60 secondes, là clairement :
grep TIMEOUT /etc/login.defs
LOGIN_TIMEOUT 60
C'est la même défition chez Jessie-Debian ce qui dédouanerait
le programme login, alors j'allais examiner mon bash_history
pour enlever un à un les dernières modifications, supprimer
ou même arrêter gpm suffit à faire disparaître
l'anomalie... Quelque part c'est bien un bug de la distribution,
ou des distributions dérivées Debian.
Je pense donc que ceux qui n'ont pas gpm, s'ils l'installent
ils vont tomber sur le bug....
dyrmak
--
Se hace camino al andar
++++ --- ++++
Linux operating system
++++ --- ++++
En 30 lignes dyrmak a écrit dans news: le jeudi, 28 février 2019 à 19:08:01 :
En 21 lignes Sergio a écrit dans news:5c7820e9$0$15484$ le jeudi, 28 février 2019 à 18:56:57 :
Bizarre... Je viens d'essayer et ça marche ! LM 19.1 MATE 64 bits. Pas de messages d'erreurs parasites sur la console qui trouble la saisie du login?
LM19.1 MATE 32bits Sur la console tout est normal, jusqu'au moment de la saisie du mot de passe, mais je viens de regarder le syslog: Feb 28 19:00:13 palmita systemd[1]: : Service has no hold-off time, scheduling restart. Feb 28 19:00:13 palmita systemd[1]: : Scheduled restart job, restart counter is at 4. Voilà pour le moment
.... Et il y a du nouveau.... Le fait d'avoir un système entièrement sous systemd rend les interprétations un poil plus énigmatiques, mais les messages sont bien déclenchés par le login TTY qui échoue. Normalement sous TTY l'attente du mot de passe est de 60 secondes, là clairement : grep TIMEOUT /etc/login.defs LOGIN_TIMEOUT 60 C'est la même défition chez Jessie-Debian ce qui dédouanerait le programme login, alors j'allais examiner mon bash_history pour enlever un à un les dernières modifications, supprimer ou même arrêter gpm suffit à faire disparaître l'anomalie... Quelque part c'est bien un bug de la distribution, ou des distributions dérivées Debian. Je pense donc que ceux qui n'ont pas gpm, s'ils l'installent ils vont tomber sur le bug.... dyrmak -- Se hace camino al andar ++++ --- ++++ Linux operating system ++++ --- ++++
dyrmak
En 53 lignes denis.paris a écrit dans news:5c78677b$0$31434$ le jeudi, 28 février 2019 à 23:58:03 :
Ça ressemble à mon problème que j'ai signalé le 1/2/2019 sous le titre "Problème TTY suite à mise à jour xubuntu 18-04 fin janvier 2019". C'est apparu avec le noyau 4.15.0-45-generic avec xubuntu 18-04. Ce sujet n'avait d'ailleurs pas donné lieu à beaucoup de commentaires, je pensais être seul au monde avec ce problème. En effet, sous une console TTY je peux rentrer le user, puis le système se met à boucler et à rendre la main au bout de quelques secondes sans donner l'occasion de rentrer le mot de passe. J'attends la mise à jour suivante du noyau.
Et ban voilà la source du problème ! J'ai ( maintenant j'avais ) ce noyau 4.15.0-45-generic, je viens de remplacer ce noyau par un 32bits que j'avais compilé pour Knoppix8.2 et du coup tout est ok maintenant, enfin presque.... actuellement à cause de ce bug, le serveur est mis en quarantaine par blockhosts: sudo /sbin/iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination blockhosts all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination blockhosts all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain blockhosts (2 references) target prot opt source destination DROP all -- palmita.terre anywhere On surveillera les mises à jour du noyau distribution... Merci à tous. dyrmak -- En un lugar del este de los mares del este ++++ --- ++++ Linux operating system ++++ --- ++++
En 53 lignes denis.paris a écrit
dans news:5c78677b$0$31434$426a34cc@news.free.fr
le jeudi, 28 février 2019 à 23:58:03 :
Ça ressemble à mon problème que j'ai signalé le 1/2/2019 sous le titre
"Problème TTY suite à mise à jour xubuntu 18-04 fin janvier 2019". C'est
apparu avec le noyau 4.15.0-45-generic avec xubuntu 18-04. Ce sujet
n'avait d'ailleurs pas donné lieu à beaucoup de commentaires, je pensais
être seul au monde avec ce problème.
En effet, sous une console TTY je peux rentrer le user, puis le système
se met à boucler et à rendre la main au bout de quelques secondes sans
donner l'occasion de rentrer le mot de passe. J'attends la mise à jour
suivante du noyau.
Et ban voilà la source du problème ! J'ai ( maintenant j'avais ) ce
noyau 4.15.0-45-generic, je viens de remplacer ce noyau par
un 32bits que j'avais compilé pour Knoppix8.2 et du coup
tout est ok maintenant, enfin presque.... actuellement
à cause de ce bug, le serveur est mis en quarantaine par blockhosts:
En 53 lignes denis.paris a écrit dans news:5c78677b$0$31434$ le jeudi, 28 février 2019 à 23:58:03 :
Ça ressemble à mon problème que j'ai signalé le 1/2/2019 sous le titre "Problème TTY suite à mise à jour xubuntu 18-04 fin janvier 2019". C'est apparu avec le noyau 4.15.0-45-generic avec xubuntu 18-04. Ce sujet n'avait d'ailleurs pas donné lieu à beaucoup de commentaires, je pensais être seul au monde avec ce problème. En effet, sous une console TTY je peux rentrer le user, puis le système se met à boucler et à rendre la main au bout de quelques secondes sans donner l'occasion de rentrer le mot de passe. J'attends la mise à jour suivante du noyau.
Et ban voilà la source du problème ! J'ai ( maintenant j'avais ) ce noyau 4.15.0-45-generic, je viens de remplacer ce noyau par un 32bits que j'avais compilé pour Knoppix8.2 et du coup tout est ok maintenant, enfin presque.... actuellement à cause de ce bug, le serveur est mis en quarantaine par blockhosts: sudo /sbin/iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination blockhosts all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination blockhosts all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain blockhosts (2 references) target prot opt source destination DROP all -- palmita.terre anywhere On surveillera les mises à jour du noyau distribution... Merci à tous. dyrmak -- En un lugar del este de los mares del este ++++ --- ++++ Linux operating system ++++ --- ++++
denis.paris
Le 01/03/2019 à 11:10, dyrmak a écrit :
Et ban voilà la source du problème ! J'ai ( maintenant j'avais ) ce noyau 4.15.0-45-generic, je viens de remplacer ce noyau par un 32bits que j'avais compilé pour Knoppix8.2 et du coup tout est ok maintenant, enfin presque.... actuellement à cause de ce bug, le serveur est mis en quarantaine par blockhosts:
J'ai gardé un noyau précédent, le 4.15.0-43, et mes consoles TTY sont alors de nouveau disponibles. Je n'ai pas vraiment consacré beaucoup de temps pour résoudre ce problème mais omme les noyaux évoluent assez vite, je pense qu'avec la 4.15.0-46 cela devrait être réparé. Note que mon dysfonctionnement est un peu différent du tien, mais clairement c'est l'application TTY qui est impactée par la version actuelle du noyau.
Le 01/03/2019 à 11:10, dyrmak a écrit :
Et ban voilà la source du problème ! J'ai ( maintenant j'avais ) ce
noyau 4.15.0-45-generic, je viens de remplacer ce noyau par
un 32bits que j'avais compilé pour Knoppix8.2 et du coup
tout est ok maintenant, enfin presque.... actuellement
à cause de ce bug, le serveur est mis en quarantaine par blockhosts:
J'ai gardé un noyau précédent, le 4.15.0-43, et mes consoles TTY sont
alors de nouveau disponibles. Je n'ai pas vraiment consacré beaucoup de
temps pour résoudre ce problème mais omme les noyaux évoluent assez
vite, je pense qu'avec la 4.15.0-46 cela devrait être réparé. Note que
mon dysfonctionnement est un peu différent du tien, mais clairement
c'est l'application TTY qui est impactée par la version actuelle du noyau.
Et ban voilà la source du problème ! J'ai ( maintenant j'avais ) ce noyau 4.15.0-45-generic, je viens de remplacer ce noyau par un 32bits que j'avais compilé pour Knoppix8.2 et du coup tout est ok maintenant, enfin presque.... actuellement à cause de ce bug, le serveur est mis en quarantaine par blockhosts:
J'ai gardé un noyau précédent, le 4.15.0-43, et mes consoles TTY sont alors de nouveau disponibles. Je n'ai pas vraiment consacré beaucoup de temps pour résoudre ce problème mais omme les noyaux évoluent assez vite, je pense qu'avec la 4.15.0-46 cela devrait être réparé. Note que mon dysfonctionnement est un peu différent du tien, mais clairement c'est l'application TTY qui est impactée par la version actuelle du noyau.
dyrmak
En 14 lignes denis.paris a écrit dans news:5c7930ae$0$3554$ le vendredi, 01 mars 2019 à 14:16:30 :
Note que mon dysfonctionnement est un peu différent du tien, mais clairement c'est l'application TTY qui est impactée par la version actuelle du noyau.
C'est effrayant qu'il en soit ainsi, un problème rélatif aux TTY est quelque chose qui fout tout par terre, surtout si on n'en a jamais rencontré, mais le fait que ça ne concerne que les noyaux est plutôt rassurant, personnellement je n'y avais pas pensé. dyrmak -- Por no irse de bruces ++++ --- ++++ Linux operating system ++++ --- ++++
En 14 lignes denis.paris a écrit
dans news:5c7930ae$0$3554$426a74cc@news.free.fr
le vendredi, 01 mars 2019 à 14:16:30 :
Note que
mon dysfonctionnement est un peu différent du tien, mais clairement
c'est l'application TTY qui est impactée par la version actuelle du noyau.
C'est effrayant qu'il en soit ainsi, un problème rélatif aux TTY est
quelque chose qui fout tout par terre, surtout si on n'en a jamais
rencontré, mais le fait que ça ne concerne que les noyaux est plutôt
rassurant, personnellement je n'y avais pas pensé.
dyrmak
--
Por no irse de bruces
++++ --- ++++
Linux operating system
++++ --- ++++
En 14 lignes denis.paris a écrit dans news:5c7930ae$0$3554$ le vendredi, 01 mars 2019 à 14:16:30 :
Note que mon dysfonctionnement est un peu différent du tien, mais clairement c'est l'application TTY qui est impactée par la version actuelle du noyau.
C'est effrayant qu'il en soit ainsi, un problème rélatif aux TTY est quelque chose qui fout tout par terre, surtout si on n'en a jamais rencontré, mais le fait que ça ne concerne que les noyaux est plutôt rassurant, personnellement je n'y avais pas pensé. dyrmak -- Por no irse de bruces ++++ --- ++++ Linux operating system ++++ --- ++++
denis.paris
Le 01/03/2019 à 15:21, dyrmak a écrit :
En 14 lignes denis.paris a écrit dans news:5c7930ae$0$3554$ le vendredi, 01 mars 2019 à 14:16:30 :
Note que mon dysfonctionnement est un peu différent du tien, mais clairement c'est l'application TTY qui est impactée par la version actuelle du noyau.
C'est effrayant qu'il en soit ainsi, un problème rélatif aux TTY est quelque chose qui fout tout par terre, surtout si on n'en a jamais rencontré, mais le fait que ça ne concerne que les noyaux est plutôt rassurant, personnellement je n'y avais pas pensé. dyrmak
Pour info suite à la mise à jour vers le noyau 4.15.0-46-generic, mes consoles TTY sont de nouveau opérationnelles, peut-être que cette version réglera ton problème également.
Le 01/03/2019 à 15:21, dyrmak a écrit :
En 14 lignes denis.paris a écrit
dans news:5c7930ae$0$3554$426a74cc@news.free.fr
le vendredi, 01 mars 2019 à 14:16:30 :
Note que
mon dysfonctionnement est un peu différent du tien, mais clairement
c'est l'application TTY qui est impactée par la version actuelle du noyau.
C'est effrayant qu'il en soit ainsi, un problème rélatif aux TTY est
quelque chose qui fout tout par terre, surtout si on n'en a jamais
rencontré, mais le fait que ça ne concerne que les noyaux est plutôt
rassurant, personnellement je n'y avais pas pensé.
dyrmak
Pour info suite à la mise à jour vers le noyau 4.15.0-46-generic, mes
consoles TTY sont de nouveau opérationnelles, peut-être que cette
version réglera ton problème également.
En 14 lignes denis.paris a écrit dans news:5c7930ae$0$3554$ le vendredi, 01 mars 2019 à 14:16:30 :
Note que mon dysfonctionnement est un peu différent du tien, mais clairement c'est l'application TTY qui est impactée par la version actuelle du noyau.
C'est effrayant qu'il en soit ainsi, un problème rélatif aux TTY est quelque chose qui fout tout par terre, surtout si on n'en a jamais rencontré, mais le fait que ça ne concerne que les noyaux est plutôt rassurant, personnellement je n'y avais pas pensé. dyrmak
Pour info suite à la mise à jour vers le noyau 4.15.0-46-generic, mes consoles TTY sont de nouveau opérationnelles, peut-être que cette version réglera ton problème également.
dyrmak
En 20 lignes denis.paris a écrit dans news:5c7ea6bb$0$19253$ le mardi, 05 mars 2019 à 17:41:31 :
Pour info suite à la mise à jour vers le noyau 4.15.0-46-generic, mes consoles TTY sont de nouveau opérationnelles, peut-être que cette version réglera ton problème également.
On me l'a proposé ce matin! Tout va bien maintenant! dyrmak -- Cuando los faros del Ouesan les dicen ....¡ Aléjense de mí ! ... ¡ Aléjense de mí ! .... ¡ Aléjense de mí ! .... ++++ --- ++++ Linux operating system ++++ --- ++++
En 20 lignes denis.paris a écrit
dans news:5c7ea6bb$0$19253$426a74cc@news.free.fr
le mardi, 05 mars 2019 à 17:41:31 :
Pour info suite à la mise à jour vers le noyau 4.15.0-46-generic, mes
consoles TTY sont de nouveau opérationnelles, peut-être que cette
version réglera ton problème également.
On me l'a proposé ce matin!
Tout va bien maintenant!
dyrmak
--
Cuando los faros del Ouesan les dicen ....¡ Aléjense de mí ! ... ¡ Aléjense de mí !
.... ¡ Aléjense de mí ! ....
++++ --- ++++
Linux operating system
++++ --- ++++
En 20 lignes denis.paris a écrit dans news:5c7ea6bb$0$19253$ le mardi, 05 mars 2019 à 17:41:31 :
Pour info suite à la mise à jour vers le noyau 4.15.0-46-generic, mes consoles TTY sont de nouveau opérationnelles, peut-être que cette version réglera ton problème également.
On me l'a proposé ce matin! Tout va bien maintenant! dyrmak -- Cuando los faros del Ouesan les dicen ....¡ Aléjense de mí ! ... ¡ Aléjense de mí ! .... ¡ Aléjense de mí ! .... ++++ --- ++++ Linux operating system ++++ --- ++++
