Toujours avec mon portable avec écran et clavier morts...
Lors de ma dernière session ssh, j'ai lancé un 'apt-get update' suivi
d'un 'apt-get dist-upgrade' qui a installé le noyau 5.3.0-42-generic...
Mais quand j'ai ribouté ce portable, il ne monte pas sur le réseau.
Donc je le branche sur ma téloche avec un clavier usb pour découvrir que
l'interface 'wlp5s0' n'apparaît pas dans la sortie de 'ifconfig -a'
(seule l'interface 'lo' apparaît).
Je profite de l'affichage de la téloche pour rebooter sur le noyau
4.16.0-41600-generic qui monte bien l'interface wlp5s0 et me permet
d'effectuer mes sauvegardes par ssh.
Que puis-je faire pour réveiller mon interface wifi avec ce nouveau
noyau ?
En 16 lignes Pascal Hambourg a écrit dans news:5e8d9c70$0$15193$ le mercredi, 08 avril 2020 à 11:42:07 :
Le 08/04/2020 à 10:55, dyrmak a écrit :
Là encore, dans les Mint Mate 19.3, la configuration network est liée à Xorg,
Peux-tu expliquer ? Je ne vois pas le rapport entre le réseau et Xorg.
c'est pas pour rien qu'ils inhibent l'utilisation des tty autres que celle sur laquelle Xorg se lance,
Et pour quelle raison, au juste ?
si ça se trouve, une téloche n'est pas suffissant pour que le network fonctionne
Là aussi il va falloir expliquer pourquoi.
Maintenant que le problème wifi semble résolu, ça a moins d'importance, mes tes questions sont pertinentes. Je ne voulais pas parler de dépendance de paquets, comme quand on veut supprimer un paquet et que d'autres paquets sont automatiquement supprimés. J'avais dans l'idée que l'ordinateur avait subi une dégradation accidentelle et que de ce fait son fonctionnement pouvait être imprévisible. Il y a plusieurs exemples de dégradation de système. Pour simplifier: Une dégradation purement accidentelle: celle subie par cet ordinateur. Une dégradation intentionnelle sous surveillance: Celle que j'ai provoquée dans ma Mint 19.3 . Et il y en a d'autres, comme celles provoquées par les bugs ou des virus Dans mon cas, sur une Mint 19.3, en parfait état de marche, j'installe bumblebee-nvidia afin de beneficier de l'usage de mes deux cartes graphiques, le programme bumblebee et ses dependances sont dans les dépôts et pourtant, [officiellement] les risques de dysfonctionnement sont bien réels. Une fois l'installation terminée, mon système est dégradé mais comme c'est intentionnel j'avais prévu une sauvegarde. Maintenant le système demande de rebooter pour bénéficier de l'usage des cartes graphiques.Malheureusement le boot finit sa course sur un écran noir et je ne peux pas basculer sur console tty, les ctrl-alt-Fx ne fonctionnent pas, le serveur dhcp du routeur n'a enregistré aucune demande et le système n'est pas accessible. Seule la combinason alt-sys-REISUB le renvoie vers un reboot. Alors que dois-je retenir ? .... Pas de X ==> pas de network et c'est cette dépendance que j'avais voulu évoquer. Évidemment, je ne peux pas calquer sa situation sur la mienne mais priver un système dégradé de son écran d'origine pouvait à mon sens produire des anomalies similaires. Pour ce qui me concerne, je suis sorti de ma dégradation sous surveillance, non sans mal il faut dire, j'ai optirun qui fonctionne avec nouveau et nvidia, mais malheureusement l'hibernation ne fonctionne pas. Le fichier pour libérer les tty est /etc/systemd/logind.conf ... Avec les tty bloquées, impossible de procéder à des analyses des logs et s'il est, admettons, difficile de faire fonctionner la gestion des deux cartes, il est particulièrement frappant que le terrain soit infesté de ruses pour précisement ne pas y arriver, c'est bien dommage. Sur les versions Mint 13 Mint 17.3 et dans Squeeze Wheezy Jessie où l'hibernation fonctionne ou a fonctionné, je n'ai jamais eu la curiosité de faire hiberner pendant qu'une ou plusieurs applications tournent sous optirun, faudrait voir.... Mais sauf Jessie qui démarre avec systemd toutes les autres ont SysV pour démarrer. dyrmak -- Se hace camino al andar ++++ --- ++++ Linux operating system ++++ --- ++++
En 16 lignes Pascal Hambourg a écrit
dans news:5e8d9c70$0$15193$426a74cc@news.free.fr
le mercredi, 08 avril 2020 à 11:42:07 :
Le 08/04/2020 à 10:55, dyrmak a écrit :
Là encore, dans les Mint Mate 19.3, la configuration network est liée
à Xorg,
Peux-tu expliquer ? Je ne vois pas le rapport entre le réseau et Xorg.
c'est pas pour rien qu'ils inhibent l'utilisation des tty
autres que celle sur laquelle Xorg se lance,
Et pour quelle raison, au juste ?
si ça se trouve, une
téloche n'est pas suffissant pour que le network fonctionne
Là aussi il va falloir expliquer pourquoi.
Maintenant que le problème wifi semble résolu, ça a moins
d'importance, mes tes questions sont pertinentes.
Je ne voulais pas parler de dépendance de paquets, comme
quand on veut supprimer un paquet et que d'autres paquets
sont automatiquement supprimés. J'avais dans l'idée que l'ordinateur
avait subi une dégradation accidentelle et que de ce fait
son fonctionnement pouvait être imprévisible.
Il y a plusieurs exemples de dégradation de système. Pour simplifier:
Une dégradation purement accidentelle: celle subie par cet ordinateur.
Une dégradation intentionnelle sous surveillance: Celle que j'ai
provoquée dans ma Mint 19.3 .
Et il y en a d'autres, comme celles provoquées par les bugs ou des virus
Dans mon cas, sur une Mint 19.3, en parfait état de marche, j'installe
bumblebee-nvidia afin de beneficier de l'usage de mes deux cartes graphiques,
le programme bumblebee et ses dependances sont dans les dépôts et pourtant,
[officiellement] les risques de dysfonctionnement sont bien réels.
Une fois l'installation terminée, mon système est dégradé mais comme
c'est intentionnel j'avais prévu une sauvegarde. Maintenant le
système demande de rebooter pour bénéficier de l'usage des cartes
graphiques.Malheureusement le boot finit sa course sur un écran noir et
je ne peux pas basculer sur console tty, les ctrl-alt-Fx ne
fonctionnent pas, le serveur dhcp du routeur n'a enregistré
aucune demande et le système n'est pas accessible.
Seule la combinason alt-sys-REISUB le renvoie vers un reboot.
Alors que dois-je retenir ? .... Pas de X ==> pas de network
et c'est cette dépendance que j'avais voulu évoquer.
Évidemment, je ne peux pas calquer sa situation sur la mienne
mais priver un système dégradé de son écran d'origine pouvait
à mon sens produire des anomalies similaires.
Pour ce qui me concerne, je suis sorti de ma dégradation sous
surveillance, non sans mal il faut dire, j'ai optirun qui fonctionne
avec nouveau et nvidia, mais malheureusement l'hibernation ne
fonctionne pas.
Le fichier pour libérer les tty est /etc/systemd/logind.conf ...
Avec les tty bloquées, impossible de procéder à des analyses des logs
et s'il est, admettons, difficile de faire fonctionner la gestion des
deux cartes, il est particulièrement frappant que le terrain soit
infesté de ruses pour précisement ne pas y arriver, c'est bien
dommage.
Sur les versions Mint 13 Mint 17.3 et dans Squeeze Wheezy Jessie où
l'hibernation fonctionne ou a fonctionné, je n'ai jamais eu
la curiosité de faire hiberner pendant qu'une ou plusieurs
applications tournent sous optirun, faudrait voir.... Mais sauf Jessie
qui démarre avec systemd toutes les autres ont SysV pour démarrer.
dyrmak
--
Se hace camino al andar
++++ --- ++++
Linux operating system
++++ --- ++++
En 16 lignes Pascal Hambourg a écrit dans news:5e8d9c70$0$15193$ le mercredi, 08 avril 2020 à 11:42:07 :
Le 08/04/2020 à 10:55, dyrmak a écrit :
Là encore, dans les Mint Mate 19.3, la configuration network est liée à Xorg,
Peux-tu expliquer ? Je ne vois pas le rapport entre le réseau et Xorg.
c'est pas pour rien qu'ils inhibent l'utilisation des tty autres que celle sur laquelle Xorg se lance,
Et pour quelle raison, au juste ?
si ça se trouve, une téloche n'est pas suffissant pour que le network fonctionne
Là aussi il va falloir expliquer pourquoi.
Maintenant que le problème wifi semble résolu, ça a moins d'importance, mes tes questions sont pertinentes. Je ne voulais pas parler de dépendance de paquets, comme quand on veut supprimer un paquet et que d'autres paquets sont automatiquement supprimés. J'avais dans l'idée que l'ordinateur avait subi une dégradation accidentelle et que de ce fait son fonctionnement pouvait être imprévisible. Il y a plusieurs exemples de dégradation de système. Pour simplifier: Une dégradation purement accidentelle: celle subie par cet ordinateur. Une dégradation intentionnelle sous surveillance: Celle que j'ai provoquée dans ma Mint 19.3 . Et il y en a d'autres, comme celles provoquées par les bugs ou des virus Dans mon cas, sur une Mint 19.3, en parfait état de marche, j'installe bumblebee-nvidia afin de beneficier de l'usage de mes deux cartes graphiques, le programme bumblebee et ses dependances sont dans les dépôts et pourtant, [officiellement] les risques de dysfonctionnement sont bien réels. Une fois l'installation terminée, mon système est dégradé mais comme c'est intentionnel j'avais prévu une sauvegarde. Maintenant le système demande de rebooter pour bénéficier de l'usage des cartes graphiques.Malheureusement le boot finit sa course sur un écran noir et je ne peux pas basculer sur console tty, les ctrl-alt-Fx ne fonctionnent pas, le serveur dhcp du routeur n'a enregistré aucune demande et le système n'est pas accessible. Seule la combinason alt-sys-REISUB le renvoie vers un reboot. Alors que dois-je retenir ? .... Pas de X ==> pas de network et c'est cette dépendance que j'avais voulu évoquer. Évidemment, je ne peux pas calquer sa situation sur la mienne mais priver un système dégradé de son écran d'origine pouvait à mon sens produire des anomalies similaires. Pour ce qui me concerne, je suis sorti de ma dégradation sous surveillance, non sans mal il faut dire, j'ai optirun qui fonctionne avec nouveau et nvidia, mais malheureusement l'hibernation ne fonctionne pas. Le fichier pour libérer les tty est /etc/systemd/logind.conf ... Avec les tty bloquées, impossible de procéder à des analyses des logs et s'il est, admettons, difficile de faire fonctionner la gestion des deux cartes, il est particulièrement frappant que le terrain soit infesté de ruses pour précisement ne pas y arriver, c'est bien dommage. Sur les versions Mint 13 Mint 17.3 et dans Squeeze Wheezy Jessie où l'hibernation fonctionne ou a fonctionné, je n'ai jamais eu la curiosité de faire hiberner pendant qu'une ou plusieurs applications tournent sous optirun, faudrait voir.... Mais sauf Jessie qui démarre avec systemd toutes les autres ont SysV pour démarrer. dyrmak -- Se hace camino al andar ++++ --- ++++ Linux operating system ++++ --- ++++
Pascal Hambourg
Le 11/04/2020 à 14:44, dyrmak a écrit :
En 16 lignes Pascal Hambourg a écrit dans news:5e8d9c70$0$15193$ le mercredi, 08 avril 2020 à 11:42:07 :
Le 08/04/2020 à 10:55, dyrmak a écrit :
Là encore, dans les Mint Mate 19.3, la configuration network est liée à Xorg,
Peux-tu expliquer ? Je ne vois pas le rapport entre le réseau et Xorg.
c'est pas pour rien qu'ils inhibent l'utilisation des tty autres que celle sur laquelle Xorg se lance,
Et pour quelle raison, au juste ?
si ça se trouve, une téloche n'est pas suffissant pour que le network fonctionne
Là aussi il va falloir expliquer pourquoi.
(élagage brutal dans les citations)
Malheureusement le boot finit sa course sur un écran noir et je ne peux pas basculer sur console tty, les ctrl-alt-Fx ne fonctionnent pas, le serveur dhcp du routeur n'a enregistré aucune demande et le système n'est pas accessible. Seule la combinason alt-sys-REISUB le renvoie vers un reboot. Alors que dois-je retenir ? .... Pas de X ==> pas de network et c'est cette dépendance que j'avais voulu évoquer.
Conclusion hâtive. Corrélation n'est pas causalité. J'ai une autre hypothèse qui me semble au moins aussi plausible : le système plante avant d'avoir configuré le réseau. (élagage brutal dans les citations)
Le fichier pour libérer les tty est /etc/systemd/logind.conf ... Avec les tty bloquées, impossible de procéder à des analyses des logs
Ça ne justifie toujours pas pourquoi les tty sont bloquées dans Mint, au contraire.
Le 11/04/2020 à 14:44, dyrmak a écrit :
En 16 lignes Pascal Hambourg a écrit
dans news:5e8d9c70$0$15193$426a74cc@news.free.fr
le mercredi, 08 avril 2020 à 11:42:07 :
Le 08/04/2020 à 10:55, dyrmak a écrit :
Là encore, dans les Mint Mate 19.3, la configuration network est liée
à Xorg,
Peux-tu expliquer ? Je ne vois pas le rapport entre le réseau et Xorg.
c'est pas pour rien qu'ils inhibent l'utilisation des tty
autres que celle sur laquelle Xorg se lance,
Et pour quelle raison, au juste ?
si ça se trouve, une
téloche n'est pas suffissant pour que le network fonctionne
Là aussi il va falloir expliquer pourquoi.
(élagage brutal dans les citations)
Malheureusement le boot finit sa course sur un écran noir et
je ne peux pas basculer sur console tty, les ctrl-alt-Fx ne
fonctionnent pas, le serveur dhcp du routeur n'a enregistré
aucune demande et le système n'est pas accessible.
Seule la combinason alt-sys-REISUB le renvoie vers un reboot.
Alors que dois-je retenir ? .... Pas de X ==> pas de network
et c'est cette dépendance que j'avais voulu évoquer.
Conclusion hâtive. Corrélation n'est pas causalité.
J'ai une autre hypothèse qui me semble au moins aussi plausible : le
système plante avant d'avoir configuré le réseau.
(élagage brutal dans les citations)
Le fichier pour libérer les tty est /etc/systemd/logind.conf ...
Avec les tty bloquées, impossible de procéder à des analyses des logs
Ça ne justifie toujours pas pourquoi les tty sont bloquées dans Mint, au
contraire.
En 16 lignes Pascal Hambourg a écrit dans news:5e8d9c70$0$15193$ le mercredi, 08 avril 2020 à 11:42:07 :
Le 08/04/2020 à 10:55, dyrmak a écrit :
Là encore, dans les Mint Mate 19.3, la configuration network est liée à Xorg,
Peux-tu expliquer ? Je ne vois pas le rapport entre le réseau et Xorg.
c'est pas pour rien qu'ils inhibent l'utilisation des tty autres que celle sur laquelle Xorg se lance,
Et pour quelle raison, au juste ?
si ça se trouve, une téloche n'est pas suffissant pour que le network fonctionne
Là aussi il va falloir expliquer pourquoi.
(élagage brutal dans les citations)
Malheureusement le boot finit sa course sur un écran noir et je ne peux pas basculer sur console tty, les ctrl-alt-Fx ne fonctionnent pas, le serveur dhcp du routeur n'a enregistré aucune demande et le système n'est pas accessible. Seule la combinason alt-sys-REISUB le renvoie vers un reboot. Alors que dois-je retenir ? .... Pas de X ==> pas de network et c'est cette dépendance que j'avais voulu évoquer.
Conclusion hâtive. Corrélation n'est pas causalité. J'ai une autre hypothèse qui me semble au moins aussi plausible : le système plante avant d'avoir configuré le réseau. (élagage brutal dans les citations)
Le fichier pour libérer les tty est /etc/systemd/logind.conf ... Avec les tty bloquées, impossible de procéder à des analyses des logs
Ça ne justifie toujours pas pourquoi les tty sont bloquées dans Mint, au contraire.
dyrmak
En 44 lignes Pascal Hambourg a écrit dans news:5e91c4d5$0$21601$ le samedi, 11 avril 2020 à 15:23:31 :
Le 11/04/2020 à 14:44, dyrmak a écrit :
En 16 lignes Pascal Hambourg a écrit dans news:5e8d9c70$0$15193$ le mercredi, 08 avril 2020 à 11:42:07 :
Le 08/04/2020 à 10:55, dyrmak a écrit :
Là encore, dans les Mint Mate 19.3, la configuration network est liée à Xorg,
Peux-tu expliquer ? Je ne vois pas le rapport entre le réseau et Xorg.
c'est pas pour rien qu'ils inhibent l'utilisation des tty autres que celle sur laquelle Xorg se lance,
Et pour quelle raison, au juste ?
si ça se trouve, une téloche n'est pas suffissant pour que le network fonctionne
Là aussi il va falloir expliquer pourquoi.
(élagage brutal dans les citations)
Malheureusement le boot finit sa course sur un écran noir et je ne peux pas basculer sur console tty, les ctrl-alt-Fx ne fonctionnent pas, le serveur dhcp du routeur n'a enregistré aucune demande et le système n'est pas accessible. Seule la combinason alt-sys-REISUB le renvoie vers un reboot. Alors que dois-je retenir ? .... Pas de X ==> pas de network et c'est cette dépendance que j'avais voulu évoquer.
Conclusion hâtive. Corrélation n'est pas causalité. J'ai une autre hypothèse qui me semble au moins aussi plausible : le système plante avant d'avoir configuré le réseau.
Tout à fait, mais la dégradation des deux cas avaient au moins cette fâcheuse coïncidence de perdre le réseau et dans le cas de remplacement de l'écran défectueux par une télé qui fonctionnait X ne plantait pas tout à fait ou pas du tout. Ça a été ma perception en tout cas.
Le fichier pour libérer les tty est /etc/systemd/logind.conf ... Avec les tty bloquées, impossible de procéder à des analyses des logs
Ça ne justifie toujours pas pourquoi les tty sont bloquées dans Mint, au contraire.
C'est toujours pareil pour moi, la fâcheuse tendance de me retrouver dans un trou noir, dans le passé, avec d'autres drivers de nvidia on pouvait s'en sortir sans trop de tracas, les tty étaient disponibles, ce n'est plus le cas maintenant, et je n'ai pas fait attention en fait, je ne sais même pas si dans ma sauvegarde, les tty n'étaient déjà plus disponibles. Mais alors c'est que tu dis m'intrigue, si on tombe dans un trou noir alors qu'on installe des programmes qui sont dans les depôts, les tty bloquées sont "une invitation" à ne pas les installer, sans esprit de polémique.... dyrmak -- A la hora de la ahora ++++ --- ++++ Linux operating system ++++ --- ++++
En 44 lignes Pascal Hambourg a écrit
dans news:5e91c4d5$0$21601$426a74cc@news.free.fr
le samedi, 11 avril 2020 à 15:23:31 :
Le 11/04/2020 à 14:44, dyrmak a écrit :
En 16 lignes Pascal Hambourg a écrit
dans news:5e8d9c70$0$15193$426a74cc@news.free.fr
le mercredi, 08 avril 2020 à 11:42:07 :
Le 08/04/2020 à 10:55, dyrmak a écrit :
Là encore, dans les Mint Mate 19.3, la configuration network est liée
à Xorg,
Peux-tu expliquer ? Je ne vois pas le rapport entre le réseau et Xorg.
c'est pas pour rien qu'ils inhibent l'utilisation des tty
autres que celle sur laquelle Xorg se lance,
Et pour quelle raison, au juste ?
si ça se trouve, une
téloche n'est pas suffissant pour que le network fonctionne
Là aussi il va falloir expliquer pourquoi.
(élagage brutal dans les citations)
Malheureusement le boot finit sa course sur un écran noir et
je ne peux pas basculer sur console tty, les ctrl-alt-Fx ne
fonctionnent pas, le serveur dhcp du routeur n'a enregistré
aucune demande et le système n'est pas accessible.
Seule la combinason alt-sys-REISUB le renvoie vers un reboot.
Alors que dois-je retenir ? .... Pas de X ==> pas de network
et c'est cette dépendance que j'avais voulu évoquer.
Conclusion hâtive. Corrélation n'est pas causalité.
J'ai une autre hypothèse qui me semble au moins aussi plausible : le
système plante avant d'avoir configuré le réseau.
Tout à fait, mais la dégradation des deux cas avaient au moins cette
fâcheuse coïncidence de perdre le réseau et dans le cas de remplacement
de l'écran défectueux par une télé qui fonctionnait X ne plantait pas
tout à fait ou pas du tout. Ça a été ma perception en tout cas.
Le fichier pour libérer les tty est /etc/systemd/logind.conf ...
Avec les tty bloquées, impossible de procéder à des analyses des logs
Ça ne justifie toujours pas pourquoi les tty sont bloquées dans Mint, au
contraire.
C'est toujours pareil pour moi, la fâcheuse tendance de me retrouver
dans un trou noir, dans le passé, avec d'autres drivers de nvidia on
pouvait s'en sortir sans trop de tracas, les tty étaient disponibles,
ce n'est plus le cas maintenant, et je n'ai pas fait attention en fait,
je ne sais même pas si dans ma sauvegarde, les tty n'étaient déjà plus
disponibles.
Mais alors c'est que tu dis m'intrigue, si on tombe dans un trou noir
alors qu'on installe des programmes qui sont dans les depôts, les tty
bloquées sont "une invitation" à ne pas les installer, sans esprit de
polémique....
dyrmak
--
A la hora de la ahora
++++ --- ++++
Linux operating system
++++ --- ++++
En 44 lignes Pascal Hambourg a écrit dans news:5e91c4d5$0$21601$ le samedi, 11 avril 2020 à 15:23:31 :
Le 11/04/2020 à 14:44, dyrmak a écrit :
En 16 lignes Pascal Hambourg a écrit dans news:5e8d9c70$0$15193$ le mercredi, 08 avril 2020 à 11:42:07 :
Le 08/04/2020 à 10:55, dyrmak a écrit :
Là encore, dans les Mint Mate 19.3, la configuration network est liée à Xorg,
Peux-tu expliquer ? Je ne vois pas le rapport entre le réseau et Xorg.
c'est pas pour rien qu'ils inhibent l'utilisation des tty autres que celle sur laquelle Xorg se lance,
Et pour quelle raison, au juste ?
si ça se trouve, une téloche n'est pas suffissant pour que le network fonctionne
Là aussi il va falloir expliquer pourquoi.
(élagage brutal dans les citations)
Malheureusement le boot finit sa course sur un écran noir et je ne peux pas basculer sur console tty, les ctrl-alt-Fx ne fonctionnent pas, le serveur dhcp du routeur n'a enregistré aucune demande et le système n'est pas accessible. Seule la combinason alt-sys-REISUB le renvoie vers un reboot. Alors que dois-je retenir ? .... Pas de X ==> pas de network et c'est cette dépendance que j'avais voulu évoquer.
Conclusion hâtive. Corrélation n'est pas causalité. J'ai une autre hypothèse qui me semble au moins aussi plausible : le système plante avant d'avoir configuré le réseau.
Tout à fait, mais la dégradation des deux cas avaient au moins cette fâcheuse coïncidence de perdre le réseau et dans le cas de remplacement de l'écran défectueux par une télé qui fonctionnait X ne plantait pas tout à fait ou pas du tout. Ça a été ma perception en tout cas.
Le fichier pour libérer les tty est /etc/systemd/logind.conf ... Avec les tty bloquées, impossible de procéder à des analyses des logs
Ça ne justifie toujours pas pourquoi les tty sont bloquées dans Mint, au contraire.
C'est toujours pareil pour moi, la fâcheuse tendance de me retrouver dans un trou noir, dans le passé, avec d'autres drivers de nvidia on pouvait s'en sortir sans trop de tracas, les tty étaient disponibles, ce n'est plus le cas maintenant, et je n'ai pas fait attention en fait, je ne sais même pas si dans ma sauvegarde, les tty n'étaient déjà plus disponibles. Mais alors c'est que tu dis m'intrigue, si on tombe dans un trou noir alors qu'on installe des programmes qui sont dans les depôts, les tty bloquées sont "une invitation" à ne pas les installer, sans esprit de polémique.... dyrmak -- A la hora de la ahora ++++ --- ++++ Linux operating system ++++ --- ++++
