openSUSE 13.1 wird zum "Evergreen"

Rain_Maker

Administrator
Teammitglied
Update von systemd und udev auf Version 210

Hier eine kleine Vorwarnung für Nutzer der Version 13.1, was die nächsten Tage sehr wahrscheinlich als Update vorliegen wird.

Die Pakete für systemd und udev werden wohl ein Update von 208 auf 210 erfahren, was eher untypisch für die Updatepolitik von openSUSE ist, da eigentlich bis auf wenige Ausnahmen (MozillaFirefox wäre an erster Stelle zu nennen) keine Updates mit neuer "Major"-Version erfolgen.

Einerseits habe ich hier ein paar "Heimatbräu"-Paketchen liegen, die ich jetzt endlich auch für 13.1 bauen könnte, da sie erst ab systemd 209 kompilieren, andererseits sind solche Eingriffe in die absoluten Kernkomponenten zumindest potentiell ein wenig kitzlig.

Das Update selbst liegt noch im Test-Repositorium, aber da ich nun mal neugierig bin ... nun ja.. wissen schon.

Einen Tipp muss ich hier schon mal los werden, die Paketstruktur hat sich ein wenig geändert, aus dem Hauptpaket "systemd" wurde das Unterpaket "systemd-bash-completion" abgekoppelt, weshalb hier zunächst mal die Autovervollständigung für systemctl &co nicht mehr wollten (die Programme selbst funktionierten natürlich noch).

Deshalb nach dem Update auf systemd/udev 210 noch ein

Code:
# zypper update systemd-bash-completion
laufen lassen und diese Funktionalität ist auch wieder da.

Wie gesagt, bisher liegt dieses Update noch nicht "offiziell vor", aber wenn alles normal läuft, dann wird dieses Update innerhalb der nächsten Tage in das offizielle Update-Repo wandern.

Bisher habe ich keine gravierenden Probleme durch das Update erkennen können, da aber auch die initial ramdisk beim Update von "udev" neu gebaut wurde, fehlt mir hier gerade noch der Reboot, den ich gleich jetzt nachholen werde.

//Edit:

OK, lief alles glatt. Netter Nebeneffekt, da meine Systeme ohne Bootsplash laufen, konnte ich eben sehen, wie in systemd 210 alles ein wenig "bunter" geworden ist, was die Meldungen beim Systemstart angeht.

Greetz,

RM
 

Rain_Maker

Administrator
Teammitglied
Anderes Verhalten von "systemctl enable/disable" seit Update - Sachdienliche Hinweise erbeten ...

Hoi,

Nach ein wenig Herumprobieren, ist mir dann doch etwas Seltsames aufgefallen, wo ich mir nicht so ganz sicher bin, ob ich da auf einen Bug, ein neues "Feature" (eher nicht, dazu später) oder nicht doch auf ein Updateproblem gestossen bin.

Worum geht es?

Mit der zuvor installierten Version 208 von systemd, sah die Ausgabe des Befehls zum Aktivieren/Deaktivieren eines Dienstes so aus:

Code:
systemctl disable sshd 
rm '/etc/systemd/system/multi-user.target.wants/sshd.service'

systemctl enable sshd 
ln -s '/usr/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.target.wants/sshd.service'
Selber Aufruf mit systemctl aus systemd-210 sieht so aus:

Code:
systemctl disable sshd

systemctl enable sshd
Wie man sieht, sieht man nichts, oder genauer gesagt, systemctl zeigt nicht mehr an, was es da gerade getan hat.

Nun ja, erster Gedanke war "da hat sich wohl was an der Syntax oder den Defaults geändert", aber die Manual Page zu systemctl sagt in beiden Versionen das hier:

Code:
-q, --quiet
           Suppress output to standard output in snapshot, is-active, is-failed, enable and disable.

--------------------- snip -------------

 enable NAME...
           Enable one or more unit files or unit file instances, as specified on the command
           line. This will create a number of symlinks as encoded in the "[Install]" sections
           of the unit files.

-------------------- snip -------------

This command will print the actions executed. This output may be suppressed by passing
           --quiet.
So sollte es also auch (denn diese Abschnitte sind identisch zu Version 208) unter systemd Version 210 so sein, dass die Aktionen des Verlinkens/Löschens auf der Kommandozeile ausgegeben werden (sofern man es nicht mit "--quiet" absichtlich unterdrückt), ist es aber scheinbar nicht.

Führe ich die Befehle mit systemctl in Version 208 mit dem Parameter "--quiet" aus, erhalte ich logischerweise auch den selben Output wie beim obigen Beispiel unter systemctl aus Version 210, aber ich muss eben explizit ansagen, dass ich keine Ausgabe haben will und einen Schalter, der die Ausgabe erzwingt (so etwas wie "--verbose") gibt es unter 210 nicht.

Also entweder ist die Funktion in 210 nicht mehr da, dann ist die Manual Page fehlerhaft, oder die Funktion ist noch da und wird nicht aufgerufen, was wiederum an einem Fehler im Programm selbst oder in meiner Konfiguration liegen kann.

Nächster Schritt war die Ausgabe auf einer Installation von openSUSE 42.1 (die systemd 210 von Hause aus mitbringt)auszuführen. Zufälligerweise habe ich eine solche Installation, die bei mir in einer virtuellen Maschine läuft.

Auch hier fehlt die Ausgabe was verlinkt bzw. gelöscht wurde, damit kann man zumindest ausschliessen, dass dieses Verhalten nur bei dem Update-Paket für 13.1 vorhanden ist, aber leider auch nicht mehr, denn die 42.1 habe ich mir durch ein Update aus dem laufenden System aus einer 13.1 geholt, es kann also auch sein, dass eine frische Installation von 42.1 (oder 13.2, die wurde auch mit systemd 210 ausgeliefert) dieses Problem nicht hat.

Daher mein Aufruf:

Wer hat eine Neuinstallation einer openSUSE 42.1 oder 13.2 und kann dieses Verhalten bestätigen (oder auch nicht)?

Warum gehe ich von einem Bug im Programm aus?

Suche ich im Binary aus Version 208 nach passenden Strings zu den entsprechenden Befehlen, dann finde ich das hier:

Code:
strings systemctl | grep -E 'ln \-s|rm\ '
ln -s '%s' '%s'
rm '%s'
Die Variable "%s" wird dabei zur Laufzeit durch die Dateinamen/Pfade ersetzt, was genau die oben gezeigte Ausgabe ergibt. Da diese Strings nur jeweils einmal gefunden werden, muss es sich auch um die Ausgabe bei "systemctl enable" handeln, wobei mir zusätzlich auch kein anderer Befehl für systemctl bekannt wäre, bei dem Symlinks gesetzt werden.

Sofern diese Funktion in systemctl aus Version 210 nicht mehr vorhanden ist, dürfte man diese Strings nicht mehr finden, oder?

Tja,

Code:
strings /usr/bin/systemctl | grep -E 'ln \-s|rm\ '
rm '%s'
ln -s '%s' '%s'
sie sind aber beide noch da, also vermute ich, dass da eine Funktionalität zwar noch vorhanden ist, sie aber aus irgendwelchen Gründen nicht aufgerufen wird.

Sachdienliche Hinweise nimmt ihre Polizeidienststelle ihr suseforum.de entgegen, Danke.

Greetz,

RM

//Edit:

Da dieses Unterforum für normale User "read-only" gesetzt ist, hat der Nutzer "Sauerland" seine Antwort

hier

gepostet.
 

Rain_Maker

Administrator
Teammitglied
systemctl hibernate, WARNING: no kernelfile matching the running kernel found - Workaround

Im Gegensatz zum letzten Beitrag bin ich mir hier nicht wirklich sicher, ob es sich um einen Bug oder eher um einen "corner case" handelt.

Ich verwende auf meiner 13.1 immer noch Grub in der Version 0.97 (grub-legacy), der Standardbootloader ist aber schon seit längerem Grub2, vielleicht hat es damit zu tun.

Beim Versuch mein System mittels

Code:
systemctl hibernate
in den Ruhezustand (suspend to DISK) zu versetzen, gab es eine Meldung, dass dies aufgrund fehlender Abhängigkeiten nicht möglich wäre.

Ein Blick in den zuständigen Dienst, genauer die Datei /usr/lib/systemd/system/systemd-hibernate.service zeigt Folgendes:

Code:
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Hibernate
Documentation=man:systemd-suspend.service(8)
DefaultDependencies=no
Requires=sleep.target
After=sleep.target
ConditionKernelCommandLine=resume

[Service]
Type=oneshot
ExecStart=/usr/bin/systemd-sleep-grub pre
ExecStart=/usr/lib/systemd/systemd-sleep hibernate
ExecStopPost=/usr/bin/systemd-sleep-grub post
Beim Aufruf von "journalctl -xn" wurde der Befehl "/usr/bin/systemd-sleep-grub pre" als Ursache der fehlenden Abhängigkeit genannt.

Abhängigkeit bedeutet hier "schlägt Befehl x fehl, dann wird Befehl x+1 nicht mehr ausgeführt, da der Erfolg des gesamten Dienstes nicht mehr gewährleistet ist".

Händisches Ausführen ergab

Code:
/usr/bin/systemd-sleep-grub pre
INFO: running prepare-grub
WARNING: no kernelfile matching the running kernel found
running kernel: '4.1.15-8-pae', probably booting kernel: '4.4.1-1.g283b562-pae'
Zunächst mal handelt es sich nur um eine Warnung und ja, beide Kernel sind bei mir installiert, es wird aber nur der neuste gefunden.

Witzigerweise erhielt ich diese Warnmeldung auch nach einem Reboot mit dem neusten installierten Kernel

Code:
/usr/bin/systemd-sleep-grub pre
INFO: running prepare-grub
WARNING: no kernelfile matching the running kernel found
running kernel: '4.4.1-1.g283b562-pae', probably booting kernel: '4.4.1-1.g283b562-pae'
was hier nicht eines gewissen Humors entbehrt und zur Krönung des Ganzen wurde hier zwar diese Meldung ausgespuckt, die Kiste legte sich aber ohne Probleme schlafen und wachte auch wieder auf.

//Nachtrag

Es gibt doch einen Unterschied in den ausgegebenen Meldungen beim Ausführen von "/usr/bin/systemd-sleep-grub pre", den ich wohl bei meinem ersten Test übersehen habe.

1) Kernel 4.4.1 (=neuster der installierten Kernel)

Code:
/usr/bin/systemd-sleep-grub pre ; echo $?
INFO: running prepare-grub
WARNING: no kernelfile matching the running kernel found
running kernel: '4.4.1-1.g283b562-pae', probably booting kernel: '4.4.1-1.g283b562-pae'
0
Die Warnung ist wirklich nur eine Warnung, der Rückgabewert ist 0 (=erfolgreich).

2) Kernel 4.1.15 (=nicht der neuste der installierten Kernel)

Code:
/usr/bin/systemd-sleep-grub pre ; echo $?
INFO: running prepare-grub
WARNING: no kernelfile matching the running kernel found
running kernel: '4.1.15-8-pae', probably booting kernel: '4.4.1-1.g283b562-pae'
ERROR: kernel version mismatch, cannot suspend to disk
7
Die Warnung ist immer noch nur eine Warnung, aber danach kommt eine Fehlermeldung und der Rückgabewert ist damit logischerweise ungleich 0 (=fehlgeschlagen), weshalb die weitere Ausführung abgebrochen wird.

Das erklärt dann auch das unterschiedliche Verhalten je nach Kernelversion und warum mein Workaround (Glückstreffer!) die richtige Idee war.

//Nachtrag Ende

Die Vermutung lag nahe, daß die Zeile "/usr/bin/systemd-sleep-grub pre" für den eigentlichen Vorgang des s2disk nicht zwingend notwendig ist, vermutlich hat sie eine ähnliche Funktion wie der Befehl "grubonce" bei Grub-legacy und wählt den laufenden Kernel aus, damit dieser beim Aufwachen automatisch und ohne Auswahlmenü gebootet wird, was bei s2disk Sinn macht, da man beim Aufwecken unbedingt den selben Kernel starten sollte, mit welchem das System auch schlafen gelegt wurde.

Da beim Aufwecken, nachdem das System mit dem neusten der installierten Kernel schlafen gelegt wurde, auch dieser Kernel automatisch ausgewählt und das System damit gestartet wurde, war es zumindest nicht ausgeschlossen, dass diese "fehlgeschlagene" Zeile keine wirklich negative Auswirkung hat.

Der Workaround für dieses Problem ist denkbar einfach und mit ein wenig "systemd-Magie" verbunden.

Als root kopiert man "/usr/lib/systemd/system/systemd-hibernate.service" nach "/etc/systemd/system/sytemd-hibernate.service" und ändert die problematische Zeile minimal ab:

Code:
ExecStart=-/usr/bin/systemd-sleep-grub pre
Das vorangestellte "-" bedeutet sinngemäß "führe den Befehl aus, aber selbst wenn dieser Befehl fehlschlägt, geht es trotzdem weiter" und genau das will ich hier ja haben.

Nun die Kiste mit dem älteren Kernel (4.1.15) gestartet und siehe da, ein "systemctl hibernate" läuft ohne Probleme durch, beim Aufwecken wird automatisch dieser Kernel ausgewählt und gestartet, also alles wie gehabt und erwünscht.

Wie gesagt, ob ich hier nur aufgrund meines etwas ungewöhnlichen Setups einen corner case erwischt habe, oder ob es sich wirklich um einen Bug handelt, ich weiß es nicht, aber sollte das Problem bei der Benutzung von Grub2 nicht mehr auftreten (ich werde das jetzt auf Grund meines an weiteren Stellen sehr "speziellen Setups" nicht testen), dann dürfte das wohl so sein.

//Nachtrag2 (11.02.2016):

Nach einem genaueren Blick in "/usr/bin/systemd-sleep-grub" (=bash script), sieht die Sache etwas klarer aus.

Das Script kümmert sich hauptsächlich um eine genauere Erkennung des laufenden Kernels, sofern GRUB2 als Bootloader verwendet wird, für andere (Grub-legacy, lilo, etc.) gibt es nur eine recht rudimentäre Unterstützung:

Code:
#############################################################################
# if we did not find a kernel (or BOOT_LOADER is not GRUB) check,
# if the running kernel is still the one that will (probably) be booted for
# resume (default entry in menu.lst or, if there is none, the kernel file
# /boot/vmlinuz points to.)
Tja, und da bei mir sowohl der default-Eintrag in der menu.lst als auch der symlink /boot/vmlinuz auf den gerade aktuellen Kernel 4.4.1 verweisen, klappt es mit diesem ohne Probleme, während es bei Verwendung eines anderen Kernels (übrigens der aus openSUSE 42.1) zu dieser "mismatch"-Meldung kommt und die Sache schief geht.

Dann findet man noch das hier

Code:
###### main()

if [ "$1" = pre ] ; then
                prepare-grub || exit 7
fi
if [ "$1" = post ] ; then
                grub-once-restore
fi
was den exit-Status 7 bei Fehlschlag erklärt.

In sofern, "Pech gehabt RM, klassischer corner case, damit musste leben mein Junge..." (und der Workaround ist ja nicht wirklich kompliziert).

Greetz,

RM
 

Rain_Maker

Administrator
Teammitglied
Kleine Vorwarnung: "untypisches" Kernelupdate

Wenn man in das Update-Test Repo für 13.1 schaut, findet sich dort ein Kernel in Version 3.12, was für openSUSE eher ungewöhnlich ist, denn die 13.1 kam mit einem 3.11 und normalerweise gibt es solche Updates mit Versionssprung nicht.

Der Grund dafür (und ich spekuliere hier) dürfte in der Tatsache liegen, daß SLE12 mit diesem Kernel ausgeliefert wurde und sich das relativ kleine Team des Evergreenprojektes mit der Verwendung eines auf SLE12 basierenden Kernels zumindest eine große Baustelle vom Hals schafft, um deren Sicherheitsupdates man sich dann nicht mehr selbst kümmern muss.

Zudem ist die 3.12er Serie eine mit Long-Time-Support, was den Aufwand der Distributoren weiter verringert, da weniger Patches zurück portiert werden müssen.

Wer externe Kernelmodule benutzt (proprietäre Grafikkartentreiber fallen einem da zuerst ein), sollte bei diesem Update zweimal prüfen, ob es auch passende Kernelmodule für diesen 3.12er gibt, ältere Pakete für 3.11 werden mit an Sicherheit grenzender Wahrscheinlichekeit _nicht_ funktionieren.

Greetz,

RM
 

Rain_Maker

Administrator
Teammitglied
"Geliefert wie bestellt"

Eigentlich könnte ich ja jetzt "angeben" und sagen "Da war meine Glaskugel wohl gut geputzt":

http://www.linux-club.de/forum/viewtopic.php?f=89&t=121047

Genau das vorhergesagte Problem und mit genau einem der Kandidaten, an die man zuerst denkt (proprietärer nvidia-Treiber).

Aber wenn man genau hinsieht, dann entstand dieser Thread samt Lösung sogar kurz vor meiner obigen "Warnung", auch wenn ich (Indianerehrenwort!) erst heute Morgen drüber gestolpert bin.

Und wenn man dann noch einmal hinsieht, dann dürfte dem geneigten Leser der Helfer auch sehr bekannt vorkommen.

Oder mit anderen Worten, ein gewisser Linuxbenutzer aus dem Sauerland (den wir hier auch kennen) hat das Problem dort schon gelöst, bevor ich hier davor warnen konnte.

Hut ab...

Greetz,

RM

P.S. Ich nutze zwar hier meine NVidia-RPMS der Marke Eigenbau und kann nur spekulieren, aber ich vermute die "offiziellen" RPMs enthalten eine Post-Installationsroutine, die das Kernelmodul "nvidia.ko" passend zum laufenden Kernel baut, weshalb dieser Trick mit Deinstallieren/Neuinstallieren geholfen hat.
 

Rain_Maker

Administrator
Teammitglied
32bit und (kein) Pepper Flash

Mehr um der "Chronistenpflicht" zu genügen, denn neu ist diese Nachricht nicht, wer eine 13.1 (und 13.2, deshalb passt es hier nicht so 100%ig rein) als 32Bit-Installation nutzt, kann kein pepper-flash mehr nutzen, da Google keine 32Bit-pakete mehr für Chrome anbietet.

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/FoE6sL-p6oU

oder

http://www.pro-linux.de/news/1/23027/chrome-fuer-linux-32-bit-versionen-vor-dem-aus.html

oder

https://startpage.com/do/search?cmd=process_search&cat=web&query=Chrome+Linux+32+Bit&language=deutsch&no_sugg=1&ff=&abp=-1&nj=1

Kurz zusammengefasst:

- Chrome für 32 Bit gibbet nich mehr

- Chromium wird es weiter geben, aber ohne Flash (da PepperFlash proprietärer Bestandteil vom nicht mehr existenten Chrome für 32 Bit war)

- Wer einen anderen, NPAPI-fähigen Browser(z.B. Firefox) mit PepperFlash und freshplayerplugin verwendet, hat damit auch verloren, man kann dort allerdings (wenn man denn will) Flash 11.2.x verwenden.

Wer schon immer Flash los werden wollte, hat jetzt die beste Gelegenheit dazu.

Nutzer von 64Bit-Systemen sind nicht betroffen.

Greetz,

RM
 

Rain_Maker

Administrator
Teammitglied
Um allen Nutzern die Möglichkeit zu geben, hier zu antworten, wurde der Thread verschoben.

Ich möchte allerdings darum bitten, _keine_ Hilfeanfragen zu stellen sondern diesen Thread für Ankündigungen/Tipps/Hinweise zu nutzen, die 13.1 Evergreen betreffen.

Für Hilfeanfragen haben wir entsprechende Unterforen, bitte diese benutzen.

Sollte sich aus einem Thread mit einer Hilfeanfrage etwas ergeben, das hier als Tipp/Trick/Workaround/Warnung hinein passt, dann kann dies immer noch nachträglich mit einer kurzen Zusammenfassung (+ Link auf den entsprechenden Thread) erfolgen.

Greetz,

RM
 

Sauerland

Member
Das Problem mit dem Nvidia Treiber ist nach einem Kernel-Update wieder vorhanden, daher hier nur einmal kurz erklärt, wie man das Problem beheben kann:
Starte im Failsafe Modus des neuen Kernels.
Starte die Softwareverwaltung
Deinstalliere alle Nvidia Pakete
Installieren alle Nvidia Pakete
Boote normal mit neuen Kernel

Es gibt natürlich auch noch andere Möglichkeiten, die man hier nicht unbedingt besprechen muss.
 
Oben