Password root for maintenance

Demande d'aide : c'est ici.
Répondre
Avatar de l’utilisateur
Tachyon
Membre
Membre
Messages : 138
Inscription : 11 janv. 2017, 14:39
Status : Hors-ligne

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?
marcastro
Membre actif
Membre actif
Messages : 734
Inscription : 22 avr. 2016, 12:05
Localisation : variable
Status : Hors-ligne

peut être la commande shutdown -h now ?
Mais rien de semblable sur ma sid sinon d'autres problèmes liés au pilote nvidia.
sur le forum depuis 2007.
sid et bookworm avec xfce
Avatar de l’utilisateur
piratebab
Site Admin
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à.
hybridemoineau
Membre
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 ?
Avatar de l’utilisateur
Tachyon
Membre
Membre
Messages : 138
Inscription : 11 janv. 2017, 14:39
Status : Hors-ligne

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 ?
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?
Avatar de l’utilisateur
Grhim
Membre très actif
Membre très actif
Messages : 1389
Inscription : 30 mai 2016, 01:00
Localisation : kekparr'par'là
Status : Hors-ligne

Tachyon 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?
voir viewtopic.php?t=378

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]
mais en ligne numero 403

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
hybridemoineau
Membre
Membre
Messages : 390
Inscription : 24 avr. 2016, 15:34
Status : Hors-ligne

Grhim a écrit : 30 juin 2018, 17:57
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]
mais en ligne numero 403

Code : Tout sélectionner

root       403  0.0  0.1  48236  4508 ?        Ss   16:28   0:00 /lib/systemd/systemd-udevd --daemon
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).

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
Et voici les paquets dont dépend libpam-systemd

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
s'il y en a un qui tousse, tout le monde s'enrhume...

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)
Avatar de l’utilisateur
Tachyon
Membre
Membre
Messages : 138
Inscription : 11 janv. 2017, 14:39
Status : Hors-ligne

merci pour ses explications dés plus claire , je regarde tout ça se soir et reviens vers vous pour la mise la suite !!
Avatar de l’utilisateur
Tachyon
Membre
Membre
Messages : 138
Inscription : 11 janv. 2017, 14:39
Status : Hors-ligne

voici le retour console de tes commande chez moi :

Code : Tout sélectionner

~$ apt-cache rdepends systemd | grep pam
  libpam-systemd
  libpam-systemd
 |libpam-cgfs
  libpam-systemd
  libpam-systemd
 |libpam-cgfs
puis

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
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 ?
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)
comment je dois proceder ?
hybridemoineau
Membre
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).

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
On voit que la version de buster est antérieure.

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
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:

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
Pour permettre à nouveau leur MAJ, il suffira de remplacer "hold" par "unhold"
Répondre