Suite mise à jour debian sid, mon système ne s'éteint plus , je suis obliger de faire un hard shutdown. J'ai essayé de passer par la console en root : shutdown now
Mais la étrangement au moment où les ligne défilé afin de s'éteindre une ligne me demande mon pass root, la ligne est le titre de ce sujet.
Le pc ne s'éteint pas puis reviens sur slim
Par contre je peux l'éteindre avec une pression du bouton marche arrêt ..
Cela parle à quelqu'un?
Password root for maintenance
- piratebab
- Site Admin
- Messages : 5872
- Inscription : 24 avr. 2016, 18:41
- Localisation : sud ouest
- Status : Hors-ligne
Toutes les commandes sont en fait des alias (poweroff par exemple). Si une ne fonctionne pas, les autres non plus.
Normalement seul root à le droit d'éteindre la machine. Il délègue ensuite ce droit aux utilisateurs courant, il me semble via sudo.
Regarde de ce coté là.
Normalement seul root à le droit d'éteindre la machine. Il délègue ensuite ce droit aux utilisateurs courant, il me semble via sudo.
Regarde de ce coté là.
-
- Membre
- Messages : 390
- Inscription : 24 avr. 2016, 15:34
- Status : Hors-ligne
Y a t-ileu une MAJ de systemd ? C'est lui qui gère l'alim (ne l'utilisant pas, j'ai dû passer par une manip de sudo, qui ne semble pas nécessaire sinon).
Edit: ou de pam ?
Edit: ou de pam ?
- Tachyon
- Membre
- Messages : 138
- Inscription : 11 janv. 2017, 14:39
- Status : Hors-ligne
suggestion très intéressante, merci, je regarde mais je pense que c'est bien systemd , comment règle-t-on le souci si c'est bien systemd qui gère le shutdown?hybridemoineau a écrit : Y a t-ileu une MAJ de systemd ? C'est lui qui gère l'alim (ne l'utilisant pas, j'ai dû passer par une manip de sudo, qui ne semble pas nécessaire sinon).
Edit: ou de pam ?
- Grhim
- Membre très actif
- Messages : 1389
- Inscription : 30 mai 2016, 01:00
- Localisation : kekparr'par'là
- Status : Hors-ligne
voir viewtopic.php?t=378Tachyon a écrit : 30 juin 2018, 12:52
suggestion très intéressante, merci, je regarde mais je pense que c'est bien systemd , comment règle-t-on le souci si c'est bien systemd qui gère le shutdown?
sinon par exemple sur mon systeme
Code : Tout sélectionner
root 1 0.0 0.0 16016 2016 ? Ss 16:28 0:01 init [2]
Code : Tout sélectionner
root 403 0.0 0.1 48236 4508 ? Ss 16:28 0:00 /lib/systemd/systemd-udevd --daemon
Debian Stable + Testing -.- Parrot OS - Kali Exegol -.- Raspberry IPFire
-
- Membre
- Messages : 390
- Inscription : 24 avr. 2016, 15:34
- Status : Hors-ligne
Attention, la ligne avec udevd ne signifie pas que systemd est actif, mais que la librairie libsystemd0 est utilisée. J'ai cette ligne sur mon système, sans avoir systemd d'installé, et il n'y a pas moyen de faire tourner Debian sans cette librairie, trop de paquets dépendent d'elle (c'est Devuan qui essaie de s'en débarasser, mais sans y être encore totalement parvenu).Grhim a écrit : 30 juin 2018, 17:57
sinon par exemple sur mon systeme
mais en ligne numero 403Code : Tout sélectionner
root 1 0.0 0.0 16016 2016 ? Ss 16:28 0:01 init [2]
Code : Tout sélectionner
root 403 0.0 0.1 48236 4508 ? Ss 16:28 0:00 /lib/systemd/systemd-udevd --daemon
Du coup, si systemd est installé, c'est lui qui gère l'alim (c'est-à-dire les droits, gérés par pam, pour l'alim), et ce même si on utilise systemV -nit pour le démarrage (car c'est tout ce que systemVinit prétend faire, et on peut l'en remercier: il démarre et ne se lie pas aux protocole des droits utilisateurs).
En effet, voici les paquets de pam qui dépendent de systemd
Code : Tout sélectionner
root@vogue:/home/stef# apt-cache rdepends systemd | grep pam
|libpam-cgfs
libpam-systemd
|libpam-cgfs
Code : Tout sélectionner
root@vogue:/home/stef# apt-cache rdepends libpam-systemd
libpam-systemd
Reverse Depends:
pulseaudio
xserver-xorg-core
network-manager
galliumos-desktop
galliumos-core
xserver-xorg-core
systemd
pulseaudio
flatpak
systemd
|needrestart
flatpak
xserver-xorg-core
xfce4-session
xfce4-power-manager
urfkill
udisks2
systemd
|python-jarabe
sddm
pulseaudio
policykit-1
openssh-server
network-manager
|needrestart
|lightdm
gpg-agent
dirmngr
gnome-settings-daemon
gnome-session-bin
gdm3
flatpak
dbus-user-session
argyll
systemd
gnupg-agent
dirmngr
flatpak
argyll
xserver-xorg-core
xfce4-session
xfce4-power-manager
wmshutdown
urfkill
udisks2
systemd
|python-jarabe
sddm
profile-sync-daemon
|libpolkit-qt5-1-1
|libpolkit-qt-1-1
policykit-1
openssh-server
network-manager
|needrestart
lxsession
|lightdm
gnupg-agent
dirmngr
gnome-settings-daemon
gnome-session-bin
gdm3
flatpak
dbus-user-session
Si sytemd n'est pas installé, alors on ne peut pas gérer l'alim de la machine sans être root, ou sans inclure un utilisateur standard dans sudo, avec droit d'utilisation de usr/sbin/halt, etc.
Si sytemd est planté en sid, c'est ce que je tenterais en attendant: compléter sudoers, et si ça ne marche toujours pas, revenir à une version antérieure de systemd ou pam (si possible)
- Tachyon
- Membre
- Messages : 138
- Inscription : 11 janv. 2017, 14:39
- Status : Hors-ligne
voici le retour console de tes commande chez moi :
puis
que devrais-je faire ensuite ?
j'utilise slim au lieu de sddm, cela fonctionerait-il mieux avec sddm vu que kdm n'est plus dans les depots ?
Code : Tout sélectionner
~$ apt-cache rdepends systemd | grep pam
libpam-systemd
libpam-systemd
|libpam-cgfs
libpam-systemd
libpam-systemd
|libpam-cgfs
Code : Tout sélectionner
$ apt-cache rdepends libpam-systemd
libpam-systemd
Reverse Depends:
argyll
systemd
argyll
gnupg-agent
dirmngr
flatpak
xserver-xorg-core
xfce4-session
xfce4-power-manager
urfkill
udisks2
systemd
|python-jarabe
sddm
policykit-1
openssh-server
network-manager
|needrestart
|lightdm
gnupg-agent
dirmngr
gnome-settings-daemon
gnome-session-bin
gdm3
flatpak
dbus-user-session
argyll
xserver-xorg-core
systemd
pulseaudio
network-manager
xserver-xorg-core
xfce4-session
xfce4-power-manager
wmshutdown
urfkill
udisks2
systemd
|python-jarabe
sddm
pulseaudio
profile-sync-daemon
|libpolkit-qt5-1-1
|libpolkit-qt-1-1
policykit-1
openssh-server
network-manager
|needrestart
lxsession
|lightdm
gpg-agent
dirmngr
gnome-settings-daemon
gnome-session-bin
gdm3
flatpak
dbus-user-session
j'utilise slim au lieu de sddm, cela fonctionerait-il mieux avec sddm vu que kdm n'est plus dans les depots ?
comment je dois proceder ?hybridemoineau a écrit : Si sytemd est planté en sid, c'est ce que je tenterais en attendant: compléter sudoers, et si ça ne marche toujours pas, revenir à une version antérieure de systemd ou pam (si possible)
-
- Membre
- Messages : 390
- Inscription : 24 avr. 2016, 15:34
- Status : Hors-ligne
Je réglerai d'abord ton problème de dist-upgrade, pour lequel je ne me sens pas compétent vu qu'il est pas mal question de KDE que je n'utilise pas.
viewtopic.php?f=8&t=1508
Une fois la maj faite, pour rétrograder les versions de systemd et de libpam-systeld il faudrait procéder comme suit - mais c'est curieurx que tu sois le seul à avoir le problème, il faudrait que quelqu'un d'autre en sid donne les versions fonctionnelles qu'il utilise de ces deux paquets (et puis, les résusltats de apt-cache rdepends sont les mêms pour tout le monde, vu que la commande passe par les index des paquets, et ne liste donc pas les paquets seulement installés).
On voit que la version de buster est antérieure.
Même chose pour libpam-systemd, qui suit les mêmes numéros de version que systemd pour les branches de debian.
Comme libpam-systemd dépend de systemd, en mettant systemd à une version antérieure, libpam-systemd devrait suivre. D'où, d'abord en mode simulation:
si la simulation donne de bons résultats, il faut relancer la commande sans le -s de -st
Puis bloquer les MAJ de ces deux paquets, si c'étaient bien eux la source du problème:
Pour permettre à nouveau leur MAJ, il suffira de remplacer "hold" par "unhold"
viewtopic.php?f=8&t=1508
Une fois la maj faite, pour rétrograder les versions de systemd et de libpam-systeld il faudrait procéder comme suit - mais c'est curieurx que tu sois le seul à avoir le problème, il faudrait que quelqu'un d'autre en sid donne les versions fonctionnelles qu'il utilise de ces deux paquets (et puis, les résusltats de apt-cache rdepends sont les mêms pour tout le monde, vu que la commande passe par les index des paquets, et ne liste donc pas les paquets seulement installés).
Code : Tout sélectionner
# apt-cache policy systemd
systemd:
Installé : (aucun)
Candidat : 237-3~bpo9+1
Table de version :
239-5 -1
10 http://httpredir.debian.org/debian sid/main amd64 Packages
238-5 -1
90 http://httpredir.debian.org/debian buster/main amd64 Packages
237-3~bpo9+1 100
100 http://httpredir.debian.org/debian stretch-backports/main amd64 Packages
232-25+deb9u3 -1
500 http://httpredir.debian.org/debian stretch-updates/main amd64 Packages
232-25+deb9u2 -1
500 http://deb.debian.org/debian stretch/main amd64 Packages
Code : Tout sélectionner
# apt-cache policy libpam-systemd
libpam-systemd:
Installé : (aucun)
Candidat : 232-25+deb9u3
Table de version :
239-5 10
10 http://httpredir.debian.org/debian sid/main amd64 Packages
238-5 90
90 http://httpredir.debian.org/debian buster/main amd64 Packages
237-3~bpo9+1 100
100 http://httpredir.debian.org/debian stretch-backports/main amd64 Packages
232-25+deb9u3 500
500 http://httpredir.debian.org/debian stretch-updates/main amd64 Packages
232-25+deb9u2 500
500 http://deb.debian.org/debian stretch/main amd64 Packages
Comme libpam-systemd dépend de systemd, en mettant systemd à une version antérieure, libpam-systemd devrait suivre. D'où, d'abord en mode simulation:
Code : Tout sélectionner
# aptitude install -st buster systemd
si la simulation donne de bons résultats, il faut relancer la commande sans le -s de -st
Puis bloquer les MAJ de ces deux paquets, si c'étaient bien eux la source du problème:
Code : Tout sélectionner
aptitude hold systemd libpam-systemd