# [gelöst] Login wieder auf Notebook und PC

## ManfredB

Hallo zusammen,

gestern habe ich die unstable und systemd Instalationen aktualisiert:

kde-plasma wurde hauptsächlich installiert.

Sowohl bei meinen BuildPkg-Installationen mit Original-Paketen

als auch bei den mit binpkgs aktualisierten Installationen

lande ich nicht mehr auf dem Desktop.

Ich habe eingestellt: autologin

nutze xdm mit der Einstellung sddm

rc-update add xdm default

Bisher bin ich immer problemlos auf dem Desktop gelandet.

Doch seit diesem Update ist es aus.

Frage: was ist da passiert mit plasma?

Gentoo-stable (von da aus schreibe ich) hat keine Probleme.

Irgendetwas blockiert den Zugang zum Desktop.

Nur was?

Gruß

ManfredLast edited by ManfredB on Fri Jun 19, 2020 7:52 am; edited 2 times in total

----------

## ManfredB

Hier eine Info:

/var/log/sddm.log

```

[05:52:35.131] (II) HELPER: [PAM] Starting...

[05:52:35.131] (II) HELPER: [PAM] Authenticating...

[05:52:35.148] (II) HELPER: [PAM] Preparing to converse...

[05:52:35.148] (II) HELPER: [PAM] Conversation with 1 messages

[05:52:35.148] (WW) HELPER: [PAM] authenticate: Module is unknown

[05:52:35.148] (II) HELPER: [PAM] returning.

[05:52:35.148] (WW) DAEMON: Authentication error: "Module is unknown"

[05:52:35.148] (II) HELPER: [PAM] Ended.

[05:52:35.149] (WW) DAEMON: Auth: sddm-helper exited with 1

[05:53:28.321] (WW) DAEMON: Signal received: SIGTERM

[05:53:28.321] (II) DAEMON: Display server stopping...

[05:53:28.329] (II) DAEMON: Display server stopped.

[05:53:28.329] (II) DAEMON: Running display stop script  "/usr/share/sddm/scripts/Xstop"

```

Auffallend:

Authentication error: "Module is unknown"

authenticate: Modules is unknown

Von welchem Modul ist da die Rede?

bzw. Was ist de Grund für Display server stopping?

Gruß

Manfred

----------

## franzf

Könnte sein, dass du hiervon betroffen bist:

https://archives.gentoo.org/gentoo-user/message/c9049d796bb90a5cc5e44c76d6eaa97b

Lösungen gibts hier:

https://archives.gentoo.org/gentoo-user/message/c4ef4168eda4eb948773f5103aa5a6e5

Falls du aktuell gar nicht mehr eingeloggt bist hast du ein Problem, dann heißt es LIVE-CD + chroot.

----------

## ManfredB

Herzlichen Dank für diese schnelle Antwort.

Ich war nahe am Verzweifeln, aber habe ich beruhigt, weil ich weiß,

daß in unstable und systemd immer wieder einmal Hürden auftauchen,

die in diesem Falle deiner Hilfe überwunden sind.

Gruß

Manfred

----------

## ManfredB

Leider ist die Hürde doch nicht überwunden.

Wenn ich das richtig verstanden habe, war die Anleitung versehen mit der Bemerkung,

die pambase-Installation vor dem Logout durchzuführen.

Doch da ich mich schon längst aus dem aktualisierten System ausgeloggt hatte,

ist die nachträgliche Änderung erfolglos geblieben.

Fazit: Neuinstallation....

oder gibt es vielleicht doch noch einen passenden Trick?

Gruß

Manfred

----------

## franzf

 *ManfredB wrote:*   

> Doch da ich mich schon längst aus dem aktualisierten System ausgeloggt hatte,
> 
> ist die nachträgliche Änderung erfolglos geblieben.

 

Was bitte meinst du damit? Du hast die Änderung (USE-Flag? oder MAKEOPTS?) durchgeführt aber du kannst dich immer noch nicht einloggen?

Oder bist du erst gar nicht so weit gekommen, weil du dich eben nicht mehr einloggen kannst?

Falls letzteres: Wie bereits oben geschrieben:

Live-CD booten und via chroot in die Installation gehen. Das sollte eigentlich immer funktionieren.

Dann kannst du die Installation reparieren.

Ist schneller und einfacher als Neuinstallation, die du sowieso eigentlich niemals nie brauchen solltest wenn du nicht riesen Mist baust (z.B. rm -rf / xD)

----------

## ManfredB

Ich habe die Änderung auf tty durchgeführt, da ich mich nicht mehr einloggen konnte.

Die Änderung von pambase hat geklappt, aber ich vermute, daß durch vorherige Integration von passwdqc irgendwelche Daten so geändert wurden, daß sich zB an der /var/log/sddm.log - was ich angezeigt habe,

nichts geändert hat.

Ich bin gerade dabei, eine Gentoo-Version (unstable) zu aktualisieren, habe vorher aber

in der package.use pambase -passwdqc eingetragen, natürlich genauer als ich es hier beschrieben habe.

Übrigens: was ich hier schreibe, findet an meinem PC statt, wo dasselbe Problem besteht.

Eine unstable-Version hat die letzten Updates noch nicht bekommen, die lasse ich jetzt durchlaufen,

pambase wird ohne passwdqc installiert.

Gruß

Manfred

----------

## ManfredB

So, jetzt kommt der Hammer!

Auf der von mir beschriebenen unstable-Version, auf die ich mich noch einloggen konnte,

weil die großen Updates noch nicht durchgeführt waren, habe ich zuerst pambase -passwdqc in package.use

eingetragen.

Dann pambase installiert, dazu wurde pam installiert.

Danach lief das Update mit an die 190 Paketen.

In aller Ruhe habe ich das Update durchlaufen lassen, danach reboot.

Kein Login mehr.

Fazit: es kann nicht allein an pambase liegen, sonst müsste der Login doch gelingen.

In sddm.log stehen wieder die Meldungen über Module unbekannt.

Die Frage, die sich mir hier stellt: welches Modul ist da gemeint?

Und warum ist es unbekannt?

Das verstehe, wer will, ich verstehe es nicht.

Und was mich nun richtig ärgert, daß der Login trotz der Vorsichtsmaßnahme nicht funktioniert,

Seltsam genug.

Aber ich werde trotzdem akzeptieren, daß wir uns damit in der unstable-Umgebung befinden,

das Wort drückt genau das aus.

Ich werde also im Moment nur noch die stable-Versionen nutzen können,

auch wenn das - was ich hier schreibe - von einer noch nicht aktualisierten unstable-Version kommt.

Auf ein Update werde ich vorerst verzichten, um nicht dasselbe Problem der Login-Sperre zu bekommen.

Gruß

Manfred

----------

## asturm

Wenn du ohnehin schon weißt, dass bei PAM das Problem liegt, dann einfach pam und pambase update aufschieben bzw. wieder downgraden.

----------

## franzf

Bist du dir sicher, dass du nicht nur ein emerge @preserved-rebuild übersehen hast?

Versuch es mal auf einem der betroffenen Systeme.

Vielleicht auch noch gleich ein revdep-rebuild, wenn du schon gechrooted hast.

Und noch gleich einen neuen emerge --sync + emerge -uDNavt @world.

Wer weiß, vielleicht ist es ja gar nicht DIESES Problem.

In jedem Fall wird es wahrscheinlich nicht durch eine unstable-Neuinstallation gelöst werden, wenn jetzt schon mehrere Systeme betroffen sind  :Wink: 

----------

## mike155

Unstable ist unstable. Wer unstable wählt, sollte auch mit Fehlern umgehen können. Also: Fehlerursache suchen (und am besten auch eine Lösung) und Bug-Report auf https://bugs.gentoo.org schreiben.

Ansonsten: das System auf stable lassen und über package.accept_keywords die paar Pakete auswählen, von denen man wirklich die aktuelle (unstable) Version braucht.

----------

## ManfredB

Ihr habt beide vollkommen recht: unstable ist es nicht stable.

Ich habe inzwischen einen Verdacht:

Die neueste Version von pambase (auch wenn -passwdqc eingestellt ist) verursacht nach meinem Eindruck

die Einstellungen in sddm-log mit dem unbekannten Modul.

Mit der vorherigen Version von pambase war das nicht der Fall.

Fazit für mich: ich werde diese neueste Version per package.mask ausbremsen,

das wird auch die vorherige Version von pam betreffen.

Wenn das richtig ist, erscheint es mir besser, diesen Schritt zu wählen als mich mit pambase

und passwdqc zu beschäftigen.

Genau das werde ich testen, und zwar in der noch funktionierenden Version von unstable gentoo.

Sollte es damit klappen, melde ich micht wieder.

Gruß

Manfred

----------

## Tyrus

Hallo Manfred.

Heute gab es auch für mich ein Update bei sys-libs/pam wobei da die stable Version betroffen ist.

```

[I] sys-libs/pam

     Verfügbare Versionen:   1.3.1-r2 1.3.1_p20200128-r1 ~1.4.0-r1 {audit berkdb +cracklib debug +filecaps nis +pie selinux split-usr static-libs ABI_MIPS="n32 n64 o32" ABI_RISCV="lp64 lp64d" ABI_S390="32 64" ABI_X86="32 64 x32"}

     Installierte Versionen: 1.3.1_p20200128-r1(12:13:42 18.06.2020)(berkdb cracklib filecaps pie split-usr -audit -debug -nis -selinux -static-libs ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64" ABI_X86="32 64 -x32")

     Startseite:             https://github.com/linux-pam/linux-pam

     Beschreibung:           Linux-PAM (Pluggable Authentication Modules)

```

Also ich hatte vorher 1.3.1-r2. Die neue Version 1.3.1_p20200128-r1 funktioniert. Ich hab jetzt extra sogar mal ein Reboot getestet. Das klappt soweit.

Dazu ein Log:

```

[12:21:45.934] (II) DAEMON: Initializing...

[12:21:45.937] (II) DAEMON: Starting...

[12:21:45.937] (II) DAEMON: Logind interface found

[12:21:45.937] (II) DAEMON: Adding new display on vt 7 ...

[12:21:45.938] (II) DAEMON: Loading theme configuration from ""

[12:21:45.938] (II) DAEMON: Display server starting...

[12:21:45.938] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -auth /var/run/sddm/{2b9c2789-b233-4c9d-a4e8-96e4b8929014} -background none -noreset -displayfd 17 -seat seat0 vt7

[12:21:47.095] (II) DAEMON: Setting default cursor

[12:21:47.103] (II) DAEMON: Running display setup script  "/usr/share/sddm/scripts/Xsetup"

[12:21:47.119] (II) DAEMON: Display server started.

[12:21:47.119] (II) DAEMON: Socket server starting...

[12:21:47.120] (II) DAEMON: Socket server started.

[12:21:47.120] (II) DAEMON: Loading theme configuration from ""

[12:21:47.120] (II) DAEMON: Greeter starting...

[12:21:47.121] (II) DAEMON: Adding cookie to "/var/run/sddm/{2b9c2789-b233-4c9d-a4e8-96e4b8929014}"

[12:21:47.126] (II) HELPER: [PAM] Starting...

[12:21:47.126] (II) HELPER: [PAM] Authenticating...

[12:21:47.126] (II) HELPER: [PAM] returning.

[12:21:47.131] (II) DAEMON: Greeter session started successfully

[12:21:47.297] (II) DAEMON: Message received from greeter: Connect

[12:21:58.470] (II) DAEMON: Message received from greeter: Login

[12:21:58.470] (II) DAEMON: Reading from "/usr/share/xsessions/plasma.desktop"

[12:21:58.470] (II) DAEMON: Reading from "/usr/share/xsessions/plasma.desktop"

[12:21:58.470] (II) DAEMON: Session "/usr/share/xsessions/plasma.desktop" selected, command: "/usr/bin/startplasma-x11"

[12:21:58.483] (II) HELPER: [PAM] Starting...

[12:21:58.483] (II) HELPER: [PAM] Authenticating...

[12:21:58.484] (II) HELPER: [PAM] Preparing to converse...

[12:21:58.484] (II) HELPER: [PAM] Conversation with 1 messages

[12:21:58.488] (II) HELPER: [PAM] returning.

[12:21:58.488] (II) DAEMON: Authenticated successfully

[12:21:58.536] (II) HELPER: [PAM] Closing session

[12:21:58.537] (II) HELPER: [PAM] Ended.

[12:21:58.537] (II) DAEMON: Auth: sddm-helper exited successfully

[12:21:58.537] (II) DAEMON: Greeter stopped.

[12:21:58.611] (II) HELPER: Starting: "/usr/share/sddm/scripts/Xsession \"/usr/bin/startplasma-x11\""

[12:21:58.619] (II) HELPER: Adding cookie to "/home/mithrandir/.Xauthority"

[12:21:58.646] (II) DAEMON: Session started

```

Könntest du eventuell mal das ganze Log betreffened des Vorgangs zum start von sddm zeigen. Du hattest nur einen Ausschnit.

Ein Hinweis/Frage - da du unstable nutzt nehme ich an du hast auch für kde-plasma/plasma-workspace ein Update bekommen oder?  Zu dem Paket gehört "/usr/bin/startplasma-x11". Frage wird das Binary ausgeführt?

Ich habe hier dazu auch die Unstable aktiv:

```

[I] kde-plasma/plasma-workspace

     Verfügbare Versionen:   (5) 5.18.5-r1^t (~)5.19.1^t [m]**5.19.49.9999*l^t[1] [m]**9999*l^t[1]

       {appstream +calendar debug geolocation gps +handbook qalculate qrcode +semantic-desktop systemd telemetry test}

     Installierte Versionen: 5.19.1(5)^t(12:29:50 17.06.2020)(appstream calendar handbook qalculate qrcode semantic-desktop -debug -geolocation -gps -systemd -telemetry -test)

     Startseite:             https://kde.org/plasma-desktop

     Beschreibung:           KDE Plasma workspace

```

Achja und sys-auth/pambase nutze ich wie beim pam die stable Version - da hat sich aber heute im Gegensatz zu sys-libs/pam nix geändert.

```

[I] sys-auth/pambase

     Verfügbare Versionen:   20190402^b ~20191128^b ~20200304^b ~20200617^b {caps consolekit +cracklib debug elogind minimal mktemp +nullok pam_krb5 pam_ssh (+)passwdqc securetty selinux +sha512 systemd}

     Installierte Versionen: 20190402^b(16:46:44 10.06.2020)(cracklib elogind nullok sha512 -consolekit -debug -minimal -mktemp -pam_krb5 -pam_ssh -passwdqc -securetty -selinux -systemd)

     Startseite:             https://github.com/gentoo/pambase

     Beschreibung:           PAM base configuration files

```

Das Useflag ist ausgeschhaltet - was das Plus in Klammern bedeutet muss ich gerade raten - wenn ich "equery u sys-auth/pambase"  abfrage bekomme ich zum Useflag:

```

[...]

 + + cracklib   : Enable pam_cracklib module on system authentication stack. This produces warnings when changing password to something easily

                  crackable. It requires the same USE flag to be enabled on sys-libs/pam or system login might be impossible.

[...]

 - - passwdqc   : Enable pam_passwdqc module on system auth stack for password quality validation. This is an alternative to pam_cracklib producing

                  warnings, rejecting or providing example passwords when changing your system password. It is used by default by OpenWall

                  GNU/*/Linux and by FreeBSD.

```

Frage ist bei dir Useflag: cracklib aktiv? Für mich hört es sich so an als ob du eins von beiden brauchst? Also bei beiden Pam Paketen.

Was mir auffällt ist - die unstable Version von sys-libs/pam - also Version 1.4.0-r1 gar keins der Useflag mehr kennt:

```

* sys-libs/pam

     Verfügbare Versionen: 

[...]

       ~    1.4.0-r1

               KEYWORDS:     ~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~riscv ~s390 ~sparc ~x86 ~amd64-linux ~x86-linux

               IUSE:         audit berkdb debug +filecaps nis +pie selinux split-usr static-libs ABI_MIPS="n32 n64 o32" ABI_RISCV="lp64 lp64d" ABI_S390="32 64" ABI_X86="32 64 x32"                                                                                                                     

               DEPEND        virtual/libcrypt:=[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] >=virtual/libintl-0-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] audit? ( >=sys-process/audit-2.2.2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] ) berkdb? ( >=sys-libs/db-4.8.30-r1:=[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] ) selinux? ( >=sys-libs/libselinux-2.2.2-r4[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] ) nis? ( >=net-libs/libtirpc-0.2.4-r2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] )                                                                                           

               RDEPEND:      ${DEPEND} filecaps? ( sys-libs/libcap ) virtual/tmpfiles

               PDEPEND:      >=sys-auth/pambase-20200616

               BDEPEND:      dev-libs/libxslt sys-devel/flex sys-devel/gettext virtual/pkgconfig >=app-portage/elt-patches-20170815 || ( >=sys-devel/automake-1.16.1:1.16 >=sys-devel/automake-1.15.1:1.15 ) >=sys-devel/autoconf-2.69 >=sys-devel/libtool-2.4 filecaps? ( sys-libs/libcap )            

               SRC_URI:      https://github.com/linux-pam/linux-pam/archive/v1.4.0.tar.gz -> pam-1.4.0.tar.gz https://dev.gentoo.org/~zlogene/distfiles/sys-libs/pam/pam-1.4.0-doc.tar.xz                                                                                                               

               EAPI:         7

[...]

```

Während die neuste Unstable von sys-auth/pambase - Version 20200617 - nur noch ein Useflag - passwdqc - von beiden kennt. Also da ist nur cracklib weggefallen ...

```

* sys-auth/pambase

     Verfügbare Versionen: 

[...]

       ~    20200617  ^b

               KEYWORDS:     ~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~riscv ~s390 ~sparc ~x86 ~amd64-linux ~x86-linux

               IUSE:         caps consolekit debug elogind minimal mktemp +nullok pam_krb5 pam_ssh +passwdqc securetty selinux +sha512 systemd

               REQUIRED_USE: ?? ( consolekit elogind systemd )

               DEPEND        app-arch/xz-utils app-portage/portage-utils

               RDEPEND:      >=sys-libs/pam-1.4.0 consolekit? ( sys-auth/consolekit[pam] ) elogind? ( sys-auth/elogind[pam] ) mktemp? ( sys-auth/pam_mktemp ) pam_krb5? ( >=sys-libs/pam-1.4.0 sys-auth/pam_krb5 ) caps? ( sys-libs/libcap[pam] ) pam_ssh? ( sys-auth/pam_ssh ) passwdqc? ( sys-auth/passwdqc ) selinux? ( sys-libs/pam[selinux] ) sha512? ( >=sys-libs/pam-1.4.0 ) systemd? ( sys-apps/systemd[pam] )                                      

               SRC_URI:      https://github.com/gentoo/pambase/archive/pambase-20200617.tar.gz

               EAPI:         7

[...]

```

Edit:

Also was ich sagen will - wenn du passwdqc deaktivierst bei pambase fehlt da auch cracklib (Useflag weg). Du kannst dich also gar nicht authentifizieren, wenn beides weg ist. (Erstmal nur ne Vermutung - muss noch in das Ebuild schauen). Du solltest eventuell bei sys-auth/pambase aber auch bei sys-libs/pam wenn du da die neuste unstable nutzt das Useflag passwdqc kontrollieren und aktivieren. Es muss bei beiden aktiv sein.

Sollte das nicht gehen würde ich sys-auth/pambase-20200617 hart maskieren unter /etc/portage/package.mask/.

Dann wird das weniger aktuelle unstable genommen: sys-auth/pambase-20200304. Und da ist das Useflag cracklib noch vorhanden. Damit sollte es wahrscheinlich gehen. Aber kontrolliere besser das beide Pam-Pakete das Useflag cracklib dann anhaben und das Useflag passwdqc deaktiviert ist.

Also eins von beiden geht dann hoffentlich.

Edit-2:

Da ich es nicht selber aktiv hab - mir ist grade entgangen - natürlich hat sys-libs/pam-1.4.1 keins der beiden Useflags mehr. Dann kannste nur versuchen es mit cracklib bei sys-auth/pambase-20200304 aktiviert zu testen. Wenn das auch fehlschlägt würde ich auch noch sys-libs/pam-1.4.1 hart maskieren. Dann geht es auf die sys-libs/pam-1.3.1_p20200128-r1 zurück. Die hat dann das Useflag noch.

Edit-3:

Ein Blick in das Ebuild von sys-libs/pam-1.4.1 zeigt das dort cracklib explizit deaktiviert wird. Also ohne Useflag-Steuerung.

```

multilib_src_configure() {

   # Do not let user's BROWSER setting mess us up. #549684

   unset BROWSER

   # Disable automatic detection of libxcrypt; we _don't_ want the

   # user to link libxcrypt in by default, since we won't track the

   # dependency and allow to break PAM this way.

   export ac_cv_header_xcrypt_h=no

   local myconf=(

      CC_FOR_BUILD="$(tc-getBUILD_CC)"

      --with-db-uniquename=-$(db_findver sys-libs/db)

      --with-xml-catalog="${EPREFIX}"/etc/xml/catalog

      --enable-securedir="${EPREFIX}"/$(get_libdir)/security

      --includedir="${EPREFIX}"/usr/include/security

      --libdir="${EPREFIX}"/usr/$(get_libdir)

      --exec-prefix="${EPREFIX}"

      --disable-prelude

      --disable-cracklib

      --disable-tally

      --disable-tally2

      --disable-doc

      --disable-regenerate-docu

      --disable-Werror

      $(use_enable audit)

      $(use_enable berkdb db)

      $(use_enable debug)

      $(use_enable nis)

      $(use_enable pie)

      $(use_enable selinux)

      $(use_enable static-libs static)

      --enable-isadir='.' #464016

      )

   ECONF_SOURCE="${S}" econf "${myconf[@]}"

}

```

Weiterhin verlangt diese Version:

```

PDEPEND=">=sys-auth/pambase-20200616"

```

Das bedeutet das das wohl nicht mit sys-auth/pambase-20200304 funktioniert. 

Wenn also das Useflag passwdqc bei sys-auth/pambase-20200617 deaktiviert ist, hast du quasi beide Authentisierungsmöglichkeiten abgeschaltet. Daher gehts wohl dann nicht?

Frage ist braucht sys-libs/pam-1.4.1 eine Aktivierung von passwdqc? Aus dem Ebuild kann ich dazu nichts entnehmen. pambase hat es - aber es geht ja nicht bei dir wenns aktiviert wird.

Wahrscheinlich musst du beide Pakte wie oben schon gesagt hart maskieren. Dann kannste da ja mal absichtlich statt cracklib (also deaktivieren) das  Useflag passwdqc einstellen. Also wird ja langfristig wie es ausschaut cracklib dann ganz ersetzen sowieso. (Also das pambase ist ja weiterhin unstable Version nach dem Maskieren. Aber estmal spricht nix gegen die Alternativ-Version)

Edit.4:

Ich mach mal nen Selbstttest und geh jetzt mal auch auf das Useflag passwdqc. Also mit unstable sys-auth/pambase-20200304. Sag dann Bescheid ...  :Wink: 

----------

## Tyrus

Zum Selbssttest - hab was gefunden.

Es wird auch sys-auth/passwdqc-1.3.0 installiert das zeigt:

```

[...]

 * To activate pam_passwdqc use pam_passwdqc.so instead

 * of pam_cracklib.so in /etc/pam.d/system-auth.

 * Also, if you want to change the parameters, read up

 * on the pam_passwdqc(8) man page.

>>> sys-auth/passwdqc-1.3.0 merged.

>>> Regenerating /etc/ld.so.cache...

```

Frage hast du in /etc/pam.d/system-auth geschaut?

Wurde bei mir automatisch umgestellt anscheinend aber ich erwähne es.

```

luthien ~ # cat /etc/pam.d/system-auth

auth            required        pam_env.so 

auth            required        pam_unix.so try_first_pass likeauth nullok 

auth            optional        pam_permit.so

account         required        pam_unix.so 

account         optional        pam_permit.so

password        required        pam_passwdqc.so min=8,8,8,8,8 retry=3

password        required        pam_unix.so try_first_pass use_authtok nullok sha512 shadow 

password        optional        pam_permit.so

-session        optional        pam_elogind.so

session         required        pam_limits.so 

session         required        pam_env.so 

session         required        pam_unix.so 

session         optional        pam_permit.so

```

Ok jetzt das Reboot. Dann schreib ich nochmal ...  :Wink: 

Edit:

Also das klappt alles soweit. Bin jetzt auf:

```

[I] sys-auth/pambase

     Verfügbare Versionen:   20190402^b ~20191128^b (~)20200304^b ~20200617^b {caps consolekit +cracklib debug elogind minimal mktemp +nullok pam_krb5 pam_ssh (+)passwdqc securetty selinux +sha512 systemd}

     Installierte Versionen: 20200304^b(15:30:39 18.06.2020)(elogind nullok passwdqc sha512 -caps -consolekit -cracklib -debug -minimal -mktemp -pam_krb5 -pam_ssh -securetty -selinux -systemd)

     Startseite:             https://github.com/gentoo/pambase

     Beschreibung:           PAM base configuration files

[I] sys-libs/pam

     Verfügbare Versionen:   1.3.1-r2 1.3.1_p20200128-r1 ~1.4.0-r1 {audit berkdb +cracklib debug +filecaps nis +pie selinux split-usr static-libs ABI_MIPS="n32 n64 o32" ABI_RISCV="lp64 lp64d" ABI_S390="32 64" ABI_X86="32 64 x32"}

     Installierte Versionen: 1.3.1_p20200128-r1(15:51:33 18.06.2020)(berkdb filecaps pie split-usr -audit -cracklib -debug -nis -selinux -static-libs ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64" ABI_X86="32 64 -x32")

     Startseite:             https://github.com/linux-pam/linux-pam

     Beschreibung:           Linux-PAM (Pluggable Authentication Modules)

```

cracklib ist bei beiden deaktiviert.

passwdqc ist bei pambase aktiviert.

Ich gehe jetzt auf beiden Paketen testweise auf das aktuellste unstable. An den Useflags muss ich ja nix mehr ändern. Dann der nächste Edit ...

Edit-2:

Also das geht bei mir auch. Keine Probleme. Das Log von sddm sieht unverändert aus.

Stand jetzt:

```

[I] sys-auth/pambase

     Verfügbare Versionen:   20190402^b (~)20191128^b (~)20200304^b (~)20200617^b {caps consolekit +cracklib debug elogind minimal mktemp +nullok pam_krb5 pam_ssh (+)passwdqc securetty selinux +sha512 systemd}

     Installierte Versionen: 20200617^b(16:12:26 18.06.2020)(elogind nullok passwdqc sha512 -caps -consolekit -debug -minimal -mktemp -pam_krb5 -pam_ssh -securetty -selinux -systemd)

     Startseite:             https://github.com/gentoo/pambase

     Beschreibung:           PAM base configuration files

[I] sys-libs/pam

     Verfügbare Versionen:   1.3.1-r2 1.3.1_p20200128-r1 (~)1.4.0-r1 {audit berkdb +cracklib debug +filecaps nis +pie selinux split-usr static-libs ABI_MIPS="n32 n64 o32" ABI_RISCV="lp64 lp64d" ABI_S390="32 64" ABI_X86="32 64 x32"}

     Installierte Versionen: 1.4.0-r1(16:12:14 18.06.2020)(berkdb filecaps pie split-usr -audit -debug -nis -selinux -static-libs ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64" ABI_X86="32 64 -x32")

     Startseite:             https://github.com/linux-pam/linux-pam

     Beschreibung:           Linux-PAM (Pluggable Authentication Modules)

```

Bleibt die Frage @Manfred, wie deine /etc/pam.d/system-auth ausschaut wenn du das Useflag passwdqc setzt?Last edited by Tyrus on Thu Jun 18, 2020 2:30 pm; edited 1 time in total

----------

## ManfredB

Kurz und bündig:

Folgende Pakete sind bei mir nun installiert:

sys-libs/pam-1.3.1_p20200128-r1

sys-auth/pambase-20200304

Das gesamte Update von kde-frameworks und kde-plasma und einige wenige kde-apps

hat nun per binpkgs stattgefunden, noch weitere 10 Pakete original

```

app-arch/zip-3.0-r3

x11-apps/bdftopcf-1.1

dev-lang/python-3.9.0_beta3:3.9

sys-devel/bison-3.6.4

dev-scheme/guile-2.2.6:12/2.2-1

app-text/docbook-xsl-ns-stylesheets-1.79.1

sys-devel/autogen-5.18.16-r1

media-libs/glew-2.2.0:0/2.2

dev-cpp/mm-common-1.0.0

dev-libs/plasma-wayland-protocols-1.0

```

Wenn dieses letzte Update erfolgt ist, werde ich das System neu starten und dann sehen, ob ich richtig gehandelt habe.

Gruß

Manfred

----------

## ManfredB

Das System ist neu gestartet und ich befinde mich nach wenigen Sekunden wieder auf dem Desktop.

Genau das habe ich mir gewünscht und bleibe vorerst dabei.

Gruß

Manfred

P.S. Vielen Dank für die konstruktive Begleitung auf diesem etwas schwierigen Weg auf der unstable-Linie.

Hier nun als Nachtrag der Ausschnitt aus der sddm.log:

```

[16:28:01.011] (II) DAEMON: Starting...

[16:28:01.011] (II) DAEMON: Logind interface found

[16:28:01.012] (II) DAEMON: Adding new display on vt 7 ...

[16:28:01.014] (II) DAEMON: Loading theme configuration from ""

[16:28:01.014] (II) DAEMON: Display server starting...

[16:28:01.014] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -auth /var/run/sddm/{337d3fa6-3e53-432d-b3e7-6a3048b7d285} -background none -noreset -displayfd 17 -seat seat0 vt7

[16:28:01.500] (II) DAEMON: Setting default cursor

[16:28:01.507] (II) DAEMON: Running display setup script  "/usr/share/sddm/scripts/Xsetup"

[16:28:01.509] (II) DAEMON: Display server started.

[16:28:01.509] (II) DAEMON: Reading from "/usr/share/xsessions/plasma.desktop"

[16:28:01.510] (II) DAEMON: Reading from "/usr/share/xsessions/plasma.desktop"

[16:28:01.510] (II) DAEMON: Session "/usr/share/xsessions/plasma.desktop" selected, command: "/usr/bin/startplasma-x11"

[16:28:01.511] (II) DAEMON: Adding cookie to "/var/run/sddm/{337d3fa6-3e53-432d-b3e7-6a3048b7d285}"

[16:28:01.528] (II) HELPER: [PAM] Starting...

[16:28:01.528] (II) HELPER: [PAM] Authenticating...

[16:28:01.529] (II) HELPER: [PAM] Preparing to converse...

[16:28:01.529] (II) HELPER: [PAM] Conversation with 1 messages

[16:28:01.529] (II) HELPER: [PAM] returning.

[16:28:01.532] (II) DAEMON: Authenticated successfully

[16:28:01.595] (II) HELPER: Starting: "/usr/share/sddm/scripts/Xsession \"/usr/bin/startplasma-x11\""

[16:28:01.600] (II) HELPER: Adding cookie to "/home/manbla/.Xauthority"

[16:28:01.605] (II) DAEMON: Session started

```

Genau so soll es sein.Last edited by ManfredB on Thu Jun 18, 2020 2:37 pm; edited 1 time in total

----------

## Tyrus

Super das freut mich.  :Smile: 

Kannst du trotzdem nochmal das eix zu den zwei Pam-Paketen hier angeben. Mich würde interessieren welche Useflag du da jetzt hast.

Und dann vielleicht auch kurz wie deine /etc/pam.d/system-auth ausschaut?

----------

## ManfredB

Hier sind sie:

```

I] sys-auth/pambase

     Verfügbare Versionen:   20190402^b (~)20191128^b{tbz2} (~)20200304^b{tbz2} [m](~)20200618^b {caps consolekit +cracklib debug elogind minimal mktemp +nullok pam_krb5 pam_ssh (+)passwdqc securetty selinux +sha512 systemd}

     Installierte Versionen: 20200304^b{tbz2}(20:14:16 23.04.2020)(cracklib elogind nullok sha512 -caps -consolekit -debug -minimal -mktemp -pam_krb5 -pam_ssh -passwdqc -securetty -selinux -systemd)

     Startseite:             https://github.com/gentoo/pambase

     Beschreibung:           PAM base configuration files

sys-libs/pam

     Verfügbare Versionen:   1.3.1-r2 1.3.1_p20200128-r1{tbz2} [m](~)1.4.0-r1{tbz2} {audit berkdb +cracklib debug +filecaps nis +pie selinux split-usr static-libs ABI_MIPS="n32 n64 o32" ABI_RISCV="lp64 lp64d" ABI_S390="32 64" ABI_X86="32 64 x32"}

     Installierte Versionen: 1.3.1_p20200128-r1{tbz2}(14:08:09 18.06.2020)(berkdb cracklib filecaps pie split-usr -audit -debug -nis -selinux -static-libs ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64" ABI_X86="64 -32 -x32")

     Startseite:             https://github.com/linux-pam/linux-pam

     Beschreibung:           Linux-PAM (Pluggable Authentication Modules)

```

```

cat /etc/pam.d/system-auth

auth            required        pam_env.so 

auth            required        pam_unix.so try_first_pass likeauth nullok 

auth            optional        pam_permit.so

account         required        pam_unix.so 

account         optional        pam_permit.so

password        required        pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 

password        required        pam_unix.so try_first_pass use_authtok nullok sha512 shadow 

password        optional        pam_permit.so

-session        optional        pam_elogind.so

session         required        pam_limits.so 

session         required        pam_env.so 

session         required        pam_unix.so 

session         optional        pam_permit.so

```

Gruß

Manfred

----------

## ManfredB

Ich habe meine Gentoo-Installationen fast alle wiederbelebt.

Wie ich vorgegangen bin?

Start des Systems, Ende beim Einloggen. Kurzerhand auf tty runter.

emerge --unmerge sys-auth/pambase sys-libs/pam

Danach

emerge "=sys-auth/pambase-20200304"

sys-libs/pam wird automatisch die Version 1.3.1_~ mitinstalliert.

Nach reboot komme ich wieder auf den Desktop.

Einfach, aber wirksam.

Gruß

Manfred

----------

## Tyrus

Hallo Manfred.

Es wurde jetzt das Build von x11-misc/sddm angepasst. Aber ohne Versionssprung!

Nicht grade schön. Weil ich bin auf der alten Version sddm-0.18.1-r1. Und in der neuen ist es abgeändert sodas sys-libs/pam-1.3.1_p20200128-r1 genommen werden muss.

Portage meckert jetzt bei mir und verweigert das Update von sddm. Nicht schlimm ist nur eine skipped Warnung.

Aber die beiden ganz aktuellen Pam Pakete laufen bei mir seit dem Selbsttest von gestern (siehe oben).

Der Witz ist es gibt aber zwei noch neuere Versionen mit den zwei Pam-Paketen. Beide unstable. Die sollen jetzt installiert werden. Hab sie mir ansehen und werd sie mal ausprobieren jetzt. 

Wenn das klappt ist die neue x11-misc/sddm mit der unveränderten Versionsnummer aber Schuld das in deinem System die Pam-Pakte auf dem Stand bleiben wo du jetzt stehst. Also du kannst theoretisch die harten Maskierungen entfernen.

Details zur Änderung in sddm-0.18.1-r1:

```

diff /var/db/pkg/x11-misc/sddm-0.18.1-r1/sddm-0.18.1-r1.ebuild /usr/portage/x11-misc/sddm/sddm-0.18.1-r1.ebuild 

1c1

< # Copyright 1999-2019 Gentoo Authors

---

> # Copyright 1999-2020 Gentoo Authors

37c37

<       pam? ( sys-libs/pam )

---

>       pam? ( <=sys-libs/pam-1.3.1_p20200128-r1 )

```

Wenn ich die neuen Versionen der beiden Pam-Pakete bei mir nutzen kann, werde ich die alte Version von sddm-0.18.1-r1 wohl in mein lokales Overlay nehmen *grins*

Schreib nachher im Edit was draus geworden ist.

Edit:

Also das Update läuft jetzt auch ohne Probleme. Allerdings haben sich noch ein paar Dinge geändert.

Erstmal mein Stand:

x11-misc/sddm-0.18.1-r1 kommt jetzt aus den lokalen Overlay und ist auf dem alten Stand der alle Versionen von sys-libs/pam zulässt. Das ist Grundvoraussetzung damit der Rest von portage akzeptiert wird.

Dann gab es erstmal eine Änderung des verwendeten passwdqc-Paketes. 

Vorher lag es hier: sys-auth/pam_passwdqc

Jetzt verwende ich: sys-auth/passwdqc

Das alte ist wohl nur als Übergang (stub) im Gentoo-Baum.

Dazu eix:

```

* sys-auth/pam_passwdqc

     Verfügbare Versionen:   1.3.0

     Startseite:             http://www.openwall.com/passwdqc/

     Beschreibung:           Stub ebuild to help migrate to newer package name

[I] sys-auth/passwdqc

     Verfügbare Versionen:   1.3.0 (~)1.4.0 {pam utils}

     Installierte Versionen: 1.4.0(16:02:19 19.06.2020)

     Startseite:             http://www.openwall.com/passwdqc/

     Beschreibung:           Password strength checking library (and PAM module)

```

Ich bin da jetzt auch auf der unstable Version 1.4.0 von sys-auth/passwdqc. 

Dazu läuft jetzt sys-auth/pambase-20200618 und sys-libs/pam-1.4.0-r2. Die sind beide unstable und werden auch nur genuzt wenn man das EBuild von x11-misc/sddm vorher angepasst hat.

Dazu auch nochmal eix:

```

[I] sys-auth/pambase

     Verfügbare Versionen:   20190402^b (~)20191128^b (~)20200304^b (~)20200618^b {caps consolekit +cracklib debug elogind minimal mktemp +nullok pam_krb5 pam_ssh (+)passwdqc securetty selinux +sha512 systemd}

     Installierte Versionen: 20200618^b(13:52:06 19.06.2020)(elogind nullok passwdqc sha512 -caps -consolekit -debug -minimal -mktemp -pam_krb5 -pam_ssh -securetty -selinux -systemd)

     Startseite:             https://github.com/gentoo/pambase

     Beschreibung:           PAM base configuration files

[I] sys-libs/pam

     Verfügbare Versionen:   1.3.1-r2 1.3.1_p20200128-r1 (~)1.4.0-r2 {audit berkdb +cracklib debug +filecaps nis +pie selinux split-usr static-libs ABI_MIPS="n32 n64 o32" ABI_RISCV="lp64 lp64d" ABI_S390="32 64" ABI_X86="32 64 x32"}

     Installierte Versionen: 1.4.0-r2(13:39:24 19.06.2020)(berkdb filecaps pie split-usr -audit -debug -nis -selinux -static-libs ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64" ABI_X86="32 64 -x32")

     Startseite:             https://github.com/linux-pam/linux-pam

     Beschreibung:           Linux-PAM (Pluggable Authentication Modules)

```

Pam benutzt jetzt kein sys-libs/cracklib mehr - bisher hat das (bei mir) keine Probleme gemacht. Ich denke das das bald auch als stable so kommen wird.

Edit-2:

@Manfred:

Wenn du willst kannst du aber auch schon auf Useflag 'passwdqc' mit der Version 20200304 von  sys-auth/pambase umstellen und Useflag 'cracklib' deaktivieren (dito sys-libs/pam). Ich bin gestern auch diesen Zwischenschritt gegangen. Wenn das klappt bist du schon weiter und hast die Umstellung bei cracklib schon, wenn demnächst für sddm alle Versionen vom pam wieder freigegeben werden. Dann ist das nur noch ein "normales" Update.

Also ich würde das mal auf einem System bei dir austesten - wenn du mal etwas Zeit hast. Eigentlich sollte das funktionieren.

----------

## ManfredB

Bei mir sieht es so aus:

```

[I] x11-misc/sddm

     Verfügbare Versionen:   [M]0.15.0 0.18.1-r1^t{tbz2} {consolekit elogind +pam systemd test}

     Installierte Versionen: 0.18.1-r1^t{tbz2}(16:45:57 26.01.2020)(pam systemd -consolekit -elogind -test)

     Startseite:             https://github.com/sddm/sddm

     Beschreibung:           Simple Desktop Display Manager

```

Ehrlich gesagt, kapiere ich überhaupt nicht, warum bei mir der Login versperrt war.

Diese komplizierten Verbindungen und Abhängigkeiten bringen mich völlig durcheinander - ehrlich gesagt.

Gruß

Manfred

----------

## Tyrus

Hallo Manfred.

Es geht bei dieser ganzen Änderung wohl darum das man das Modul für Pam das die Passwort-Qualität sicherstellt, geändert hat. Bislang läuft das noch über cracklib (bzw es ist wahlweise möglich). Es wird auf aber nun ausschließlich auf das Modul passwdqc umgestellt.

Dabei sind sie vielleicht etwas zu schnell vorgegangen und es gab wohl Probleme weswegen das EBuild von sddm so geändert wurde das der Stand den du jetzt aktiv hast von portage verwendet wird. Also die Änderung ist erstmal von den Maintainern selber blockiert worden.

Ich hab gestern mitgetestet. Dabei hatte ich aber noch den alten Stand von sddm. Es gab heute dann das Update (beim Syncen)- allerdings ohne das die Versionsnummer sich geändert hat. Man bemerkt es deswegen weniger einfach.

Gestern musstest du das harte Maskieren benutzen was die zu neuen Pakete ausgeklammert hat. Heute würden die durch das Update bei sddm nicht mehr von Portage genommen auch ohne die harte Maskierung bei dir.

Alles gut soweit bei dir. 

Du benutzt jetzt aber immer noch das alte Verfahren mit cracklib.  Da die neuen Versionen die jetzt noch unstable sind und die durch die Änderung bei sddm auch im Augenblick nicht benutzt werden aber auf jeden Fall cracklib nicht mehr anbieten diese Versionen aber irgendwann auch ins stabile System kommen werden (ist meine Vermutung), wirst du früher oder später auch umstellen müssen. 

Die beiden Pam-Pakete in der Version wie du sie jetzt hast haben beide die Möglichkeit jetzt schon passwdqc zu nutzen und cracklib zu deaktivieren. Du kannst also im Augenblick den Zeitpunkt bei der Umstellung selber so legen das sich das nicht unbedingt mit anderen (großen) Updates überschneidet. Also ich meine nur die Useflag-Änderung. Den Rest (also was ich noch gemacht habe, Versionsupgrade) kannste ruhig so lassen bei. Das passiert dann später ohne Probleme wenn du dann schon kein cracklib mehr hast.

Ist nur ein Gedanke.

Und hoffe ich habe es nochmal besser zusammengefasst. Sonst einfach fragen was dir noch unklar ist.

-----------

Warum das gesperrt war bei dir. Reine Vermutung von mir aber ich nehme an das du als du das probiert hast keine Änderung in  /etc/pam.d/system-auth  bekommen hast. Beim mir kam das automatisch (ausserdem gabs am Ende des Emerge von dem zusätzlichen Paket für passwdqc eine Info dazu da mal zu schauen). Weiss aber nicht ob das auch passiert wenn man den Wechsel ohne Zwischenschritte macht, wie bei mir gestern. Ich habe weiter oben meine /etc/pam.d/system-auth schonmal gezeigt. Achte da einfach drauf das du dann da drin den neuen Eintrag für pam_passwdqc hast statt dem für cracklib.

Wie gesagt ist nur meine Vermutung.

----------

## ManfredB

Meine /etc/pam.d/system-auth sieht exakt genauso aus wie bei dir.

Angenommen ich teste es nun auch mit den allerneuesten pambase und pam-Programmen,

dann dürfte es wohl auch kein Problem mehr geben - so hoffe ich jedenfalls.

Gruß

Manfred

----------

## Tyrus

Du hast geschrieben:

```

[...]

password        required        pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 

[...]

```

also da wird cracklib genommen.

Ich hab da jetzt:

```

[...]

password        required        pam_passwdqc.so min=8,8,8,8,8 retry=3

[...]

```

Die neuesten Versionen kannst du nicht testen ohne das x11-misc/sddm pam wieder für die neueren Versionen erlaubt. Wenn du das machen willst helf ich dir aber gerne, dann musst du aber das EBuild anpassen.

Was ich bisher meinte ist das du einfach nur die Useflags bei den Versionen die du jetzt schon nutzt von Pam auf passwdqc umschaltest.

----------

## ManfredB

Wenn ich das bisher richtig verstanden habe,

ist offensichtlich x11-misc/sddm die Hauptbremse bei mir.

Ich habe mal das ebuild dieses Programms geöffnet und nach pam gesucht.

Das taucht da mehrmals auf.

Seltsam nur, daß bei mir dieses Programm bisher nicht auf den Stand, den du mir gezeigt hast,

aktualisiert wurde.

Oder kann es sogar sein, daß es deshalb nicht aktualisiert wurde, weil ich noch die älteren Pakete

sys-auth/pambase und sys-libs/pam nutze?

Übrigens wurde bei mir nach

emerge --ask --depclean

das Paket passwdqc deinstalliert.

Müsste ich das also wieder installieren?

Aber es bleibt ja wohl noch bei der Blockade von x11-misc/sddm.... oder?

Gruß

Manfred

P.S. ich habe eben mal kurz eix passwdqc durchgeführt.

Es gibt da 2 Pakete:

pam_passwdqc und passwdqc

```

eix passwdqc

* sys-auth/pam_passwdqc

     Verfügbare Versionen:   1.3.0

     Startseite:             http://www.openwall.com/passwdqc/

     Beschreibung:           Stub ebuild to help migrate to newer package name

* sys-auth/passwdqc

     Verfügbare Versionen:   1.3.0 (~)1.4.0{tbz2} {pam utils}

     Startseite:             http://www.openwall.com/passwdqc/

     Beschreibung:           Password strength checking library (and PAM module)

```

----------

## Tyrus

Hallo Manfred.

Wegen der Frage zu sddm. Wenn du den Gentoo-Baum regelmässig syncronisierst solltest du das EBuild von sddm haben wie es auch bei mir vorliegt. Nochmal geändert (also zurückgeändert) hat sich da nix - habe eben gesysnct.

Ich zeige dir mal den Anfang daraus hier kurz:

```

# Copyright 1999-2020 Gentoo Authors

# Distributed under the terms of the GNU General Public License v2

EAPI=7

PLOCALES="ar bn ca cs da de es et fi fr hi_IN hu is it ja kk ko lt lv nb nl nn pl pt_BR pt_PT ro ru sk sr sr@ijekavian sr@ijekavianlatin sr@latin sv tr uk zh_CN zh_TW"

inherit cmake l10n systemd user

DESCRIPTION="Simple Desktop Display Manager"

HOMEPAGE="https://github.com/sddm/sddm"

SRC_URI="https://github.com/${PN}/${PN}/releases/download/v${PV}/${P}.tar.xz"

LICENSE="GPL-2+ MIT CC-BY-3.0 CC-BY-SA-3.0 public-domain"

SLOT="0"

KEYWORDS="amd64 ~arm arm64 ~ppc64 x86"

IUSE="consolekit elogind +pam systemd test"

RESTRICT="!test? ( test )"

REQUIRED_USE="?? ( elogind systemd )"

BDEPEND="

        dev-python/docutils

        >=dev-qt/linguist-tools-5.9.4:5

        kde-frameworks/extra-cmake-modules:5

        virtual/pkgconfig

"

RDEPEND="

        >=dev-qt/qtcore-5.9.4:5

        >=dev-qt/qtdbus-5.9.4:5

        >=dev-qt/qtdeclarative-5.9.4:5

        >=dev-qt/qtgui-5.9.4:5

        >=dev-qt/qtnetwork-5.9.4:5

        >=x11-base/xorg-server-1.15.1

        x11-libs/libxcb[xkb]

        consolekit? ( >=sys-auth/consolekit-0.9.4 )

        elogind? ( sys-auth/elogind )

        pam? ( <=sys-libs/pam-1.3.1_p20200128-r1 )

        systemd? ( sys-apps/systemd:= )

        !systemd? ( sys-power/upower )

"

DEPEND="${RDEPEND}

        test? ( >=dev-qt/qttest-5.9.4:5 )

"

PATCHES=(

        "${FILESDIR}/${PN}-0.12.0-respect-user-flags.patch"

        "${FILESDIR}/${PN}-0.18.0-Xsession.patch" # bug 611210

        "${FILESDIR}/${PN}-0.18.0-sddmconfdir.patch"

        # fix for groups: https://github.com/sddm/sddm/issues/1159

        "${FILESDIR}/${P}-revert-honor-PAM-supplemental-groups.patch"

        "${FILESDIR}/${P}-honor-PAM-supplemental-groups-v2.patch"

        # fix for ReuseSession=true

        "${FILESDIR}/${P}-only-reuse-online-sessions.patch"

        # TODO: fix properly

        "${FILESDIR}/${PN}-0.16.0-ck2-revert.patch" # bug 633920

)

[...]

```

Die entscheidene Zeile ist:

```

        pam? ( <=sys-libs/pam-1.3.1_p20200128-r1 )

```

Damit mein ich den Eintrag unter RDEPEND.

Da wird sichergestellt das die neueste Version von sys-libs/pam also Version sys-libs/pam-1.4.0-r2 nicht verwendet wird. Vor zwei Tagen war da keine Einschränkung da stand dann nur pam? ( sys-libs/pam ). Deswegen wurde damals bei dir die zu neue Version von sys-libs/pam von Portage berücksichtigt. Und deswegen hattest du die dann hart maskiert als Lösung. Zumindest zeigte mir das dein eix als alles funktioniert hat.

Wenn du jetzt die ganz neuen Pakete wieder nutzen willst wie bei mir musst du die Änderung in x11-misc/sddm die Seitens der Maintainer gemacht wurde selber wieder zurücknehmen. Ich habe das so gemacht das ich dazu den Ebuild in mein lokales Overlay gelegt habe.

----

Zu deiner zweiten Frage. Wenn du jetzt auf cracklib stehst von den Useflags her aber dabei die Versionen sys-libs/pam-1.3.1_p20200128-r1 und sys-auth/pambase-20200304 einsetzt wird das passwdqc nicht gebraucht. Das du das Paket hattest wird daran liegen, das du vor zwei Tagen, als der Fehler aufgetreten das Paket geladen hast weil Portage das verlangt hatte. 

Depclean hat es jetzt gelöscht weil es aktuell gemäss deiner Useflags nicht benötigt wird. Die stehen ja jetzt (noch) auf cracklib.

----

Wegen der zwei Pakete zu passwdqc.

sys-auth/pam_passwdqc ist ein Stub. Die Deskription sagt: 

 *Quote:*   

> 
> 
> Stub ebuild to help migrate to newer package name
> 
> 

 

Das ist nicht mehr im Einsatz. Die Version ist bei mir gestern getauscht worden gegen die zweite sys-auth/passwdqc. Also es gab da ein erneutes Update auf die zwei Pam-Pakete die jetzt nicht den Stub benutzen sondern sys-auth/passwdqc.

Von dem Paket gibt es eine stable Version 1.3.0  und eine unstable Version 1.4.0. Ich habe beide getestet. Erst die stable und danach bin ich auf unstable hochgegangen. 

---

Soweit sogut.

Wenn du das auch ganz durchspielen willst wäre meine Bitte auf deinem aktuellen Stand zuerst nur die Useflags auf passwdqc umstellen und cracklib deaktvieren. Danach erstmal das Rebuild und dann testen.

Sollte das nicht funktionieren kannst du dann leicht zurück gehen.

Wenn das funktioniert, dann eventuell so du willst, das EBuild von sddm anpassen, sodas du die neuen Version der zwei Pam-Pakete auch nutzen kannst.

----------

## ManfredB

Ich habe es jetzt verstanden.

Nur an einem Punkt bin ich unsicher: Ebuild von x11-misc/sddm ändern.

Wie ich das machen kann/soll, ist mir nicht klar.

Sicher: die Zeile, die du da angesprochen hast, ist der Kern, die müsste anders aussehen.

Ich habe mal versucht, da das USEFLAG zu ändern: -pam passwdqc,

doch das hat nicht geklappt. Ist sicher auch der falsche Weg.

Wenn man an einem Ebuild in dem repo-Verzeichnis etwas ändert,

muss - da erinnere ich mich ganz schwach dran, weil es für mich schon ewig lange her ist -

ein Befehl eingegeben werden, der die Änderung speichert, wenn ich das richtig in Erinnerung habe,

Wie der Befehl heisst/hiess, weiß ich nicht mehr.

Aber ich bin sehr vorsichtig mit solchen Eingriffen, weil ich die Konsquenzen nicht einschätzen kann.

Dank deiner ausführlichen Beschreibung wäre es sicher ein Weg, doch zum Ziel zu gelangen.

Gruß

Manfred

----------

## Tyrus

Erstmal zu x11-misc/sddm.

Da kannst du nur pam ausschalten über das Useflag. Aber das würde ich nicht machen und wäre auch keine Lösung.

Die Useflags sind korrekt da. Der Ebuild muss aber geändert werden.

Und keine Ahnung welches Kommando du meinst, aber ich würde nicht verhindern das das Ebuild beim syncen so aufgespielt wird wie es im Repository Gentoo auch vorliegt. Dann siehst du auch wenn das nochmal wieder geändert wird aber die Versionsnummer sich erneut nicht ändert (so ne Art stille Änderung *grinshust* die bemerkt man schlecht). Aber trotzdem hast du den Ebuild lokal auf deiner  Maschine vorliegen.

Es ist zwar etwas aufwendiger aber da lohnt sich ein lokales Overlay. Das sorgt dann dafür das statt des Ebuilds aus dem Gentoo-Repository dein Ebuild aus dem lokalen Overlay genommen wird. So schwer ist das nicht das einzurichten. Können wir gerne machen. Das kannst du später auch selber für andere minimalen Eingriffe in Ebuilds nutzen oder sogar selber mal Ebuilds entwickeln für Software die bisher keine Ebuilds im Gentoo-Repo hat.

Aber bevor du damit anfängst versuch bitte erst nur den Wechsel des Useflags bei den Pam-Paketen in der Version wie du sie jetzt hast. Wenn das danach alles noch funktioniert können wir den lokalen Overlay gerne anlegen zusammen.

Edit:

Ich hänge nochmal mein eix für x11-misc/sddm hier dran:

```

[I] x11-misc/sddm

     Verfügbare Versionen:   [M]0.15.0 0.18.1-r1^t 0.18.1-r1^t[3] [m]**9999*l^t[2] {consolekit elogind +pam systemd test}

     Installierte Versionen: 0.18.1-r1^t[3](16:10:28 19.06.2020)(elogind pam -consolekit -systemd -test)

     Startseite:             https://github.com/sddm/sddm

     Beschreibung:           Simple Desktop Display Manager

[1] "kde" /var/lib/layman/kde

[2] "qt" /var/lib/layman/qt

[3] "luthien-overlay" /usr/local/portage

```

Da siehst du auch das ich zweimal Version 0.18.1-r1 habe. Die zweite hat als Zusatz das [3]. Und dann unten als Erklärung dazu zeigt eix das auch sauber an das es das lokale Overlay ist.

----------

## ManfredB

Nun habe ich den Test durchgeführt.

Vorgang:

USE="-cracklib passwdqc" emerge --ask sys-auth/pambase

Dazu wurden installiert: pam_passwdqc und passwdqc

USE="-cracklib" emerge --ask sys-libs/pam

Vorsichtshalber habe ich noch eingegeben:

emerge -avuDN world

Da wurden beide Pakete wieder zurückgesetzt.

Das habe ich per n abgelehnt

Und nun kommt der Hammer:

Ich starte das System neu, warte ab, ob ich auf den Desktop gelange,

erst erschien nur wieder der Mauspfeil in der Mitte, nach wenigen Augenblicken beginnt

der Login (autologin).

Ich lande wieder auf dem Desktop.

Habe ich das nun dem Zusatz-Paket pam_passwdqc zu verdanken?

Oder warum klappt es diesmal?

Gruß

Manfred

----------

## Tyrus

Hallo Manfred.

Ja ich habe den Verdacht das man den Zwischenschritt durchführen sollte.

Weil dadurch wird deine /etc/pam.d/system-auth korrekt angepasst. Und da wird der Fehler wohl gewesen sein vermutlich, als du das vor drei Tagen versucht hast.

Wenn alles klappt, kannst du wenn du willst dann die Useflag-Änderung in package.use dauerhaft eintragen.

Wenn wir jetzt weitermachen, würde sobald du für Pam die Version 1.4.0-r2 verwendest dann der stub sys-auth/pam_passwdqc-1.3.0 nicht mehr gebraucht und es würde ganz auf sys-auth/passwdqc alleine gewechselt. 

Das ist ok - das ist bei mir auch so, der Stub hat seine Aufgabe erfüllt und wird nicht mehr gebraucht.

Wenn du willst, können wir gerne jetzt x11-misc/sddm über ein lokales Overlay ändern, damit du die zwei ganze neuen Versionen der Pam-Pakete auch von Portage bekommst.

Ich würde dann erst erklären wie du den Overlay anlegst.

Aber sag kurz Bescheid vorher. Danke.Last edited by Tyrus on Sun Jun 21, 2020 8:17 am; edited 1 time in total

----------

## ManfredB

Nur kurz:

Ich hatte die Änderungen bereits in /etc/portage/package,use/package.use eingetragen.

Und jetzt bin ich echt platt:

Ich habe in einigen Schritten folgendes gemacht:

USE="-pam passwdqc" emerge --ask x11-misc/sddm

Aus /etc/portage/package.mask/package.mask die neuesten Versionen von sys-auth/pambase und sys-libs/pam entfernt.

Nun emerge -avuDN world

Die beide neuesten Versionen werden installiert.

Neustart (in Gedanken sehe ich schon wieder Desktop-Blockierung.

Umso mehr bin ich erstaunt, daß ich problemlos auf dem Desktop gelandet bin.

Das hat mich nun doch erstaunt, aber du hast mich dazu ermutigt.

Danke noch einmal für die intensive Hilfe

Gruß

Manfred

----------

## Tyrus

Gut sofern du den Overlay anlegen willst musst du dir erst kurz Gedaken machen an welcher Stelle du den im Gentoo-Baum anlegen möchtest.

Ich habe da /usr/local/portage gewählt. 

Dazu zwei Infos. 

Zum ersten werden unter /usr/local keine Pakete aus dem Gentoo-Repo installiert. Das ist wirklich nur für eigene Sachen die maschienenabhängig sein können liegen da bei mir. Dazu gehören auch die veränderten oder ganz neuen EBuilds.

Und als zweites verfolge ich damit das "alte" Namensschema - früher lagen die Ebuilds unter /usr/portage - jetzt wurde die Position ja geändert - was ich aber nicht gemacht habe und auch solange das fehlerfrei bleibt nicht ändern wollte.

Also du kannst dir natürlich eine Position auch unter /var suchen.So ähnlich dann wie das auch Layman macht unter /var/lib ...

Wenn du den Overlay dann anlegen willst musst du zuerst unter/etc/portage/repos.conf eine Konfigurationsdatei für dein lokales Overlay anlegen. Bei mir heisst das einfach local.conf.

Der Inhalt sieht so aus:

```

[luthien-overlay]

location = /usr/local/portage

masters = gentoo

auto-sync = no

priority=1000

```

Also location musst du selber anpassen. 

Zu priority eine Erklärung kurz. Der Wert sorgt dafür das bei Paketen wie jetzt x11-misc/sddm wenn die Version absolut identisch ist z.B. mit dem Paket aus dem Gentoo-Repo dann das Paket aus dem lokalen Overlay genommen wird. Also Gentoo hat da eine kleine Priorität. Weiss aus dem Kopf nicht welcher Wert da gesetzt ist. Aber 1000 reicht hier ...  :Wink: 

Dann noch [luthien-overlay] da steht der Name des Overlays zwischen den Klammern wie du ihn an anderer Stelle nochmal brauchst.

Also bei mir heisst der Rechner luthien. Aber du bist da frei wie du das Overlay benennen willst.

---

Edit - hab grade erst deinen Edit gesehen ...  *grins*

Manfred Useflag Pam auszuschalten für sddm geht zwar - aber dann verwendet sddm auch kein Pam mehr. und ja dann werden die neustens Versionen von pam geholt. Aber der Grund ist das es andere Pakete gibt die auch Pam nutzen und die keine Einschränkungen haben die neusten zu benutzen wie sddm. sddm nutzt aber kein Pam mehr. Das würde ich nicht machen. Sddm läuft auch fehlerfrei mit der Änderung bei mir. Du musst aber das Ebuild anpassen.Last edited by Tyrus on Sun Jun 21, 2020 8:53 am; edited 1 time in total

----------

## asturm

Was genau wird hier versucht zu lösen?

----------

## ManfredB

So, ich habe das alles eingerichtet. 

/usr/local/portage

/etc/portage/repos.conf/local.conf

Was muss ich nun tun?

Gruß

Manfred

----------

## Tyrus

@asturm:

Es geht darum die Blockade in sddm was pam angeht zurückzunehmen:

```

pam? ( <=sys-libs/pam-1.3.1_p20200128-r1 ) 

```

Vor drei tagen stand da noch:

```

pam? ( sys-libs/pam ) 

```

Darauf kann Manfred jetzt zurück. Das läuft bei mir auch sauber. Er hat ja jetzt schon bestätigt das der Wechsel weg von cracklib hin zu passwdqc bei den Useflags klappt.

----------

## asturm

Die Restriktion ist korrekt und sollte dort bleiben.

Wer helfen will, soll -r2 testen (zur Sicherheit nach einem emerge --sync).

----------

## Tyrus

@Manfred:

Du musst jetzt erst ein Verzeichnis unter /usr/locale/portage anlegen das heisst "profile".

Da drin liegt eine Datei die repo_name heisst:

```

luthien-overlay

```

Da rein schreibste dann den Namen des Repos nochmal wie in local.conf auch benutzt.

@asturm:

Ich habe das doch schon seit vorgestern auch in der neuen Version "-r2" in Gebrauch bei mir selber - lies einfach den Thread weiter oben. Hatte das da auch beschrieben. Bisher gibts keine Probleme.

----------

## asturm

Das ist schön, und macht das Anlegen eines local overlays unnötig.

----------

## Tyrus

@Manfred:

Dann gibts noch eine Datei layout.conf im Verzeichnis /usr/local/portage/metadata. Also das Verzeichnis musste auch anlegen.

Die sieht so aus:

```

masters = gentoo

```

@asturm:

Also nur zum Abgleich ich meine sys-libs/pam-1.4.0-r2 und die wird für sddm berücksichtigt. weil der schränkt da noch ein. Bei mir läuft das sddm aber ohne Probleme damit.

----------

## asturm

Nein.

```
$ grep sys-libs/pam x11-misc/sddm/sddm-0.18.1-r2.ebuild 

        pam? ( sys-libs/pam )
```

----------

## ManfredB

Zunächst noch einmal zurück:

Ich habe noch einmal einen kleinen Schriit zurückgemacht:

x11-misc/sddm sollte wieder pam bekommen,

dazu musste noch einmal pam und pambase in package.mask unterbringen.

Nachdem das geklappt hat. ist sddm wieder auf dem alten Stand.

Problem nun: die beiden neuesten Pakete lassen sich nicht mehr installieren,

genau wegen pam in x11-misc/sddm

```

(sys-libs/pam-1.4.0-r2:0/0::gentoo, ebuild scheduled for merge) USE="berkdb filecaps pie (split-usr) -audit -debug -nis (-selinux) -static-libs" ABI_X86="(64) -32 (-x32)" conflicts with

    <=sys-libs/pam-1.3.1_p20200128-r1 required by (x11-misc/sddm-0.18.1-r1:0/0::gentoo, installed) USE="elogind pam -consolekit -systemd -test" ABI_X86="(64)"

```

Also haben meine Schritte alles wieder rückgängig gemacht.

Das kommt davon, wenn ich einfach etwas tue, was so nicht vorgesehen war - falsche Gedanken, die mich verführt haben.

Jetzt muss ich erst einmal eine Pause einlegen, sonst komme ich noch völlig aus dem Ruder....

Gruß

Manfred

----------

## Tyrus

@asturm:

Arghs . Das neue ebuild ist aber jetzt wirklich ganz frisch da. Danke - da hab ich dein Bezug zu "-r2" falsch verstanden.

Das ist aber (noch) hart maskiert. Ok jetzt hab ichs verstanden. Danke dir. Die Version hab ich nicht im Einsatz - weil ich es schon vor zwei Tagen umgestellt hatte.

@Manfred:

Dann musst du nicht unbedingt mehr das Overlay anlegen lokal. Kannst du aber trotzdem einrichten unabhängig für später. Also weil du jetzt schon angefangen hast und vielleicht schon fast fertig bist damit ...

Du musst dann einfach die harte Maskierung aufheben damit x11-misc/sddm-0.18.1-r2 genommen wird.

Das geht dann über /etc/portage/package.unmask.

Zum Beispiel so:

```

=x11-misc/sddm-0.18.1-r2

```

Dann wird das freigegeben ohne das du noch was machen musst über ein lokales Overlay.

Edit:

Die harten Maskierungen für die zwei Pam-Pakete brauchst du gar nicht mehr. Dafür wurde ja extra die Einschränkung bei x11-misc/sddm bis zur Version 0.18.1-r1 was pam angeht eingeführt. Vor drei Tagen war die nötig.Jetzt gehts ohne.

Edit-2:

 *Quote:*   

> 
> 
> Problem nun: die beiden neuesten Pakete lassen sich nicht mehr installieren,
> 
> 

 

Keine Panik. Du hast durch das Abschalten des Useflag 'Pam' (was nicht die beste Idee war) die ganz neuen Versionen von Pam reingeholt (über andere Pakete die auch Pam nutzen) und das wird dann zurückgesetzt wenn du das Useflag für sddm wieder nutzt auf die kleineren Versionen. Sobald du, wie asturm darauf hingewiesen hat, für das hart maskierte Ebuild für sddm in der Version 0.18.1-r2 die Maskierung aufhebst, wird kein Downgrade mehr gemacht. Und der Overlay ist dann auch nicht mehr nötig.

Und sorry falls es dich verwirrt hat. Das mit dem neuen maskierten Ebuild zu sddm hab ich bis eben gerade auch nicht gewusst.

Edit-3:

@Manfred:

Nur der Vollständigkeit halber. Damit portage x11-misc/sddm-0.18.1-r2 wirklich verwendet musst du neben der harten Maskierung auch das unstable freigeben eventuell. Also dann über /etc/portage/package.accept_keywords.

Ich stelle da auch gerade drauf um.

Edit-4:

```

[I] x11-misc/sddm

     Verfügbare Versionen:   [M]0.15.0 0.18.1-r1^t 0.18.1-r1^t[2] {M}(~)0.18.1-r2^t [m]**9999*l^t[1] {consolekit elogind +pam systemd test}

     Installierte Versionen: 0.18.1-r2^t(12:09:59 21.06.2020)(elogind pam -consolekit -systemd -test)

     Startseite:             https://github.com/sddm/sddm

     Beschreibung:           Simple Desktop Display Manager

```

Also das neue Ebuild 0.18.1-r2 von sddm läuft jetzt auch hier und bisher keine Probleme mit sddm. Login verläuft fehlerfrei.

----------

## ManfredB

Fortschritt:

Ich habe eben x11-misc/sddm-0.18.1-r2 installiert,

nach emerge -avuDN world

werden folgende Pakete installiert:

```

>>> Emerging (1 of 3) sys-libs/pam-1.4.0-r2::gentoo

>>> Installing (1 of 3) sys-libs/pam-1.4.0-r2::gentoo

>>> Emerging (2 of 3) sys-auth/passwdqc-1.4.0::gentoo

>>> Installing (2 of 3) sys-auth/passwdqc-1.4.0::gentoo

>>> Emerging (3 of 3) sys-auth/pambase-20200618::gentoo

>>> Installing (3 of 3) sys-auth/pambase-20200618::gentoo

```

Nun bin ich sehr gespannt, ob ich nach reboot wieder auf dem Desktop lande.

Gruß

Manfred

----------

## ManfredB

Erfolg!

Nach reboot lande ich sehr schnell auf dem Desktop (schnell wegen SSD).

Vielen herzlichen Dank an die geduldige Begleitung auf meinem etwas komplizierten Weg,

der nun nicht mehr kompliziert ist.

Gruß

Manfred

----------

## ManfredB

Eben mache ich auf meinem Notebook wieder mal ein Update,

da taucht x11-misc/0.1.18-r3 auf ohne irgendeinen Eingriff auf package.mask.

Gruß

Manfred

----------

## Tyrus

@Manfred: Freut mich das es jetzt alles geklappt hat.  :Smile: 

@nochmal neuer Ebuild:

Das ist inhaltlich exakt der gleiche Ebuild wie x11-misc/0.18.1-r2 (hab getestet mit diff *grins*). Also Unterschied ist da, das die harte Maskierung weg ist. Schaut doch gut aus ... *grins*

BTW - schau mal hier: https://packages.gentoo.org/packages/x11-misc/sddm

Danke @asturm für die schnelle Vereinfachung.

----------

## ManfredB

Eins ist mir noch aufgefallen.

Nach diesem Update wollte ich mal eben über zattoo einen Bericht anschauen.

Sobald ich auf Fullscreen umgeschaltet habe, fing es am oberen Bildrand plötzlich an zu flimmern,

das hatte ich vorher nicht.

Ob es mit den von uns hier behandelten Problemen zusammenhängen kann, weiß ich nicht,

aber es war schon sehr auffällig.

Ich bin dann kurz auf die ZDF-Seite gegangen und habe da irgendeinen Film angeklickt,

auch da nach Fullscreen dieses merkwürdige Flimmern am oberen Rand.

Dazu muss ich noch erwähnen, daß ich hier mit gentoo-kernel-bin und nouveau-Treiber arbeite,

bei den Distributionen, die den nvidia-Treiber nutzen, habe ich es noch nicht testen können,

werde ich aber noch tun.

Gruß

Manfred

----------

## Tyrus

Hallo Manfred.

Also wenn ich im firefox auf den Livestream vom ZDF schaue im Vollscreen hab ich da kein Flackern. Also hab hier nvidia-drivers.

Aber ich glaube nicht das das mit Pam zusammenhängt.

Ein

```

equery d sys-libs/pam

 * These packages depend on sys-libs/pam:

app-admin/sudo-1.8.31 (pam ? sys-libs/pam)

app-emulation/virtualbox-6.1.10-r1 (pam ? sys-libs/pam)

dev-db/mariadb-10.4.12 (pam ? sys-libs/pam:0)

dev-db/postgresql-12.2 (pam ? sys-libs/pam)

dev-libs/cyrus-sasl-2.1.27-r3 (pam ? >=sys-libs/pam-0-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])

dev-libs/libpwquality-1.4.2 (pam ? sys-libs/pam)

dev-vcs/cvs-1.12.12-r12 (pam ? sys-libs/pam)

gnome-base/gnome-keyring-3.34.0 (pam ? sys-libs/pam)

kde-plasma/kscreenlocker-5.19.1 (pam ? sys-libs/pam)

kde-plasma/kwallet-pam-5.19.1 (sys-libs/pam)

mail-mta/postfix-3.5.1 (pam ? sys-libs/pam)

net-ftp/lftp-4.8.4-r1 (socks5 ? sys-libs/pam)

net-mail/mailbase-1.5-r1 (pam ? sys-libs/pam)

net-misc/openssh-8.1_p1-r3 (pam ? sys-libs/pam)

net-print/cups-2.3.3-r1 (pam ? sys-libs/pam)

net-proxy/dante-1.4.1-r2 (pam ? sys-libs/pam)

net-vpn/openvpn-2.4.9 (pam ? sys-libs/pam)

sys-apps/busybox-1.31.1-r2 (pam ? sys-libs/pam)

sys-apps/kbd-2.2.0-r2 (pam ? sys-libs/pam)

sys-apps/openrc-0.42.1 (pam ? sys-libs/pam)

sys-apps/shadow-4.8-r4 (pam ? sys-libs/pam:0)

sys-apps/util-linux-2.35.2 (pam ? sys-libs/pam)

sys-auth/elogind-243.7 (pam ? sys-libs/pam)

sys-auth/pambase-20200618 (>=sys-libs/pam-1.4.0)

                          (pam_krb5 ? >=sys-libs/pam-1.4.0)

                          (selinux ? sys-libs/pam[selinux])

                          (sha512 ? >=sys-libs/pam-1.4.0)

sys-auth/passwdqc-1.4.0 (sys-libs/pam)

sys-auth/polkit-0.116-r1 (pam ? sys-libs/pam)

sys-auth/realtime-base-0.1 (sys-libs/pam)

sys-libs/libcap-2.26-r2 (pam ? sys-libs/pam[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])

sys-process/cronie-1.5.4-r1 (pam ? sys-libs/pam)

x11-misc/sddm-0.18.1-r3 (pam ? sys-libs/pam)

```

beinhaltet nichts aus dem Videobereich das Pam nutzen würde bei mir.

----------

## ManfredB

Alles klar,

ich habe eben eine andere Gentoo-Installation aktualisiert, da ist das Flimmern nicht aufgetreten.

Also ist bei der Flimmer-Distri irgendetwas anderes im Dunkeln,

aber das ist nun eben mal so.

Danke jedenfalls für die Klarstellung.

Gruß

Manfred

----------

