Beiträge von kafe

  • LEAP 15.0: "Falscher Digest" bei Installation neuer Pakete und bei Update

    Ich habe seit gestern (23.03.2019) Abend reproduzierbar die Fehlermeldung "Falscher Digest", wenn ich Pakete installieren möchte.
    Beispiele: glibc-32bit, ebenso das Update von libpackagekit
    Das ist nach einer LEAP 15.0 - Neuinstallation (Paketquellen wurden nicht geändert).


    Zum Test, ob es an der Installation liegt, habe ich bei einem zweiten Rechner (ebenfalls LEAP 15.0), wo dieselben Versionen der Pakete klaglos installiert sind, in der YasT-Softwareverwaltung diese Pakete auf "erzwungenes Update" gesetzt und dabei tritt der Fehler "Falscher Digest" hier auch auf.
    Kann es sein, dass an den Repositories bei OpenSuse was faul ist?

  • Nach Aktualisierung am 04.05.2018 funktioniert kwallet bzw. pam_kwallet nicht mehr

    Hallo zusammen,


    ich hatte heute das Problem, das kwallet den Dienst verweigerte und damit auch KMail nicht auf die Konten zugreifen konnte.
    Ich hatte die Verwendung von pam_kwallet konfiguriert, so dass beim Login die kwallet automatisch geöffnet wurde (siehe unten).


    Da bei der letzten Benutzung noch alles funktionierte und ich als letztes ein Online-Update gemacht habe, habe ich im Snapper-Modul von Yast nach die betreffenden vorher-nachher-Snapshots nach verdächtigen Änderungen gesucht.
    Siehe da, es wurden geändert: /etc/xdg/autostart/pam_kwallet_init.desktop und /lib64/security/pam_kwallet5.so.
    Ich habe jetzt die beiden Dateien aus dem Snapshot zurückgeholt und alles funktioniert scheinbar wieder.


    Ist das Problem schon bekannt - Gibt es Aussagen der Entwickler dazu?


    Bekomme ich andere Probleme mit den alten Files?


    Ich freue mich auf Eure Hinweise!



    ==============
    Hier meine Konfigurationsänderungen, um beim Login kwallet zu öffnen:


    in /etc/pam.d/login hinzugefügt:
    session optional pam_kwallet5.so auto_start


    in /etc/pam.d/passwd hinzugefügt:
    auth optional pam_kwallet5.so kdehome=.local/share


    in /etc/pam.d/sddm hinzugefügt:
    auth optional pam_kwallet5.so kdehome=.local/share
    session optional pam_kwallet5.so auto_start

  • openSUSE 13.1 hängt für >1 min beim booten

    Habe das Problem gelöst, indem ich das System mit abgezogenem USB-Kartenleser neu installiert habe. Ich weiß zwar nun nicht, ob das wirklich die Ursache war, aber es bleibt jetzt so, den Kartenleser brauche ich sowieso nie.
    Danke an alle, die vesucht haben zu helfen!

  • openSUSE 13.1 hängt für >1 min beim booten

    So, habe jetzt mal den Networkmanager aktiviert. Die 20s des erwähnten ifup-Bugs habe ich damit schon mal gewonnen:


    Code
    troubi@troubi:~> sudo systemd-analyze blame
	1min 31.535s systemd-udev-settle.service                                                                                                                   	
      	1.502s mysql.service                                                                                                                                 	
       	551ms xdm.service                                                                                                                                   	
       	171ms home.mount                                                                        
        [...]


    Danke, Sauerland! :thumbup:


    Nun würde ich noch gern herausbekommen, worauf der systemd-udev-settle.service so lange wartet -- hat jemand eine Idee?

  • openSUSE 13.1 hängt für >1 min beim booten

    Zitat

    1. Hast Du Dein Netzwerk mit ifup/Yast eingerichtet?

    Hm, ich habe, glaube ich, nichts vom Standardvorschlag abweichendes getan. Ich werd mal morgen probieren, auf den Networkmanager umzustellen, um die 20s zu gewinnen. Bleibt noch die 1min für das udev-settle.


    Code
    troubi@troubi:~> systemctl status systemd-udev-settle.service                                                                                                  	
systemd-udev-settle.service - udev Wait for Complete Device Initialization                                                                                     	
   Loaded: loaded (/usr/lib/systemd/system/systemd-udev-settle.service; static)                                                                                	
   Active: active (exited) since Sa 2013-12-14 13:44:39 CET; 11min ago                                                                                         	
 	Docs: man:udev(7)                                                                                                                                         	
       	man:systemd-udevd.service(8)                                                                                                                        	
  Process: 310 ExecStart=/usr/bin/udevadm settle (code=exited, status=0/SUCCESS)                                                                               	
 Main PID: 310 (code=exited, status=0/SUCCESS)


    Gibt es eine Möglichkeit, udev auf die Finger zu gucken, womit es sich so lange aufhält?


    Ich hatte bei der Installation einen im Gehäuse eingebauten Kartenleser dran, hab den aber zwischenzeitlich abgezogen, weil ich ihn schon im Verdacht hatte. Ebenso einen USB-RS232-Wandler. Es sind jetzt nur noch die Funktastatur und der TV-Tuner dran. Letzteren hatte ich zum Test auch schon mal weggelassen, ohne Erfolg.
    dmesg |grep usb scheint erstmal nichts verdächtiges zu zeigen, oder?

  • openSUSE 13.1 hängt für >1 min beim booten

    äähm, 13.1 - die 13.2 war ein Tippfehler.
    Es ist eine Neuinstallation auf die neu eingebaute SSD (/dev/sdb1). Der Rechner ist mein Media-PC im Wohnzimmer und läuft seit etlicher Zeit (Stichwort SuSE 11.2, auf /dev/sda2) mit mythtv recht stabil. Nun will ich ihn mit der SSD auf Trab bringen und dabei auch ein neues OS verwenden - SuSE 13.1 als Evergreen-Version kommt mir da ganz gelegen. Zur Zeit läuft die 11.2 sozusagen als "Produktivsystem" und wenn ich die 13.1 soweit habe, wird der Standard-Booteintag im GruB umgeschaltet - soweit der Plan. Die /home - Partition mit den Daten (/dev/sda3) verwende ich für beide Systeme gemeinsam, aber mit verschiedenen Usern.


    So, und hier die Ausgaben:


  • openSUSE 13.1 hängt für >1 min beim booten

    Hallo Leute,
    ich habe mich entschlossen, auf einem Rechner die 13.1 zu probieren, leider mit mäßigem Erfolg. Mein erstes Problem: Nachdem systemd die ersten Aufgaben in wenigen Sekunden abgearbeitet hat, bleibt der Bootvorgang ca. 1 min hängen. DIe letzte Ausgabe auf dem Bootscreen ist:

    Code
    reached target soundcard

    , danach passiert eine Weile nichts, dann kommt die Meldung

    Code
    starting Plymouth boot screen

    und die Bestätigung

    Code
    started Plymouth boot screen

    , dann passiert wieder eine Weile nichts, und dann rauscht der Rest durch und wenige Sekunden später habe ich meinen Loginmanager.


    Ich habe bisher keine Ursache für die Verzögerung gefunden und suche nun Rat.


    Folgende Nachforschungen habe ich angestellt:

    • Code
      systemctl status

      zeigt keine Fehler, alle services sind mit einem grünen 'active' versehen

    • dmesg gibt mir den einzigen Hinweis, da ein Zeitsprung zwischen 6,35s und 97s auftritt:


      Eine Suche nach der gpio_ich-Meldung, die vor der Pause kommt, förderte nichts kritisches zu Tage.

    meine Hardware:

    • Motherboard: Gigabyte Technology Co., Ltd. H55N-USB3/H55N-USB3, BIOS F4 07/06/2010
    • Prozessor: Core i3 540 @ 3,07GHz
    • 4GB RAM, 2TB HDD (Western Digital WD20EARS), 32GB SSD (SanDisk SDSSDRC0)
      Auf der HDD ist eine SUSE 11.2, die gut läuft; die SUSE 13.2 befindet sich auf der SSD und nutzt die /home - Partition auf der HDD mit.
    • Grafikkarte: nvidia GeForce 220GT (mit dem nouveau-Treiber)

    Wäre schön, wenn jemand eine Idee hätte, wo ich weiterforschen kann!