[gelöst] Kein Bootmenü mehr und systemd - Problem

Mein System: openSUSE Tumbleweed 13.2 64bit KDE

Seit einem Update vor ein paar Tagen wird kein Boot-Menü mehr angezeigt, es lässt sich nur das 'Default-Betriebssystem' booten.
Es sieht so aus, als ob irgend etwas im systemd - System durcheinander geraten ist.

Die Ausgabe von journalctl -b liefert u.a. folgendes:

..
.. systemd-journal(580): Permanent journal is using 1.3G (max allowed 3.9G, trying to leave 4.0G free of 37.7G available → current limit 3.9G).
.. systemd-journal(580): Time spent on flushing to /var is 2.256421s for 1014 entries.
.. systemd-journald(113): Received SIGTERM from PID 1 (systemd).
.. systemd(1): RTC configured in localtime, applying delta of 120 minutes to system time.
.. systemd-sysv-generator(384): Overwriting existing symlink /run/systemd/generator.late/pppoe.service with real service
.. systemd-sysv-generator(384): Overwriting existing symlink /run/systemd/generator.late/halt.local.service with real service
.. systemd-sysv-generator(384): Overwriting existing symlink /run/systemd/generator.late/rpmconfigcheck.service with real service
.. systemd-sysv-generator(384): Overwriting existing symlink /run/systemd/generator.late/xsp2.service with real service
.. systemd-sysv-generator(384): Overwriting existing symlink /run/systemd/generator.late/after.local.service with real service
.. systemd-sysv-generator(384): Overwriting existing symlink /run/systemd/generator.late/raw.service with real service
.. systemd-sysv-generator(384): Overwriting existing symlink /run/systemd/generator.late/nfs.service with real service
.. systemd-sysv-generator(384): Overwriting existing symlink /run/systemd/generator.late/local.service with real service
.. systemd-sysv-generator(384): Overwriting existing symlink /run/systemd/generator.late/esound.service with real service
.. systemd-sysv-generator(384): Overwriting existing symlink /run/systemd/generator.late/cycle.service with real service
.. systemd-sysv-generator(384): Overwriting existing symlink /run/systemd/generator.late/apparmor.service with real service
.. systemd-sysv-generator(384): Overwriting existing symlink /run/systemd/generator.late/cifs.service with real service
.. systemd(1): Found dependency on sysinit.target/start
.. systemd(1): Breaking ordering cycle by deleting job cycle.service/start
.. systemd(1): Job cycle.service/start deleted to break ordering cycle starting with sysinit.target/start
.. systemd(1): Stopped Switch Root.
.. systemd(1): Cannot find unit for notify message of PID 113.
.. systemd(1): systemd-journald.service has no holdoff time, scheduling restart.
.. systemd(1): Listening on Journal Socket (/dev/log).
...
.. systemd(1): Mounted Debug File System.
...skipping...
.. systemd(1): Found ordering cycle on sysinit.target/start
.. systemd(1): Found dependency on cycle.service/start
.. systemd(1): Found dependency on basic.target/start
.. systemd(1): Found dependency on sockets.target/start
.. systemd(1): Found dependency on dbus.socket/start
.. systemd(1): Found dependency on sysinit.target/start
.. systemd(1): Breaking ordering cycle by deleting job cycle.service/start
.. systemd(1): Job cycle.service/start deleted to break ordering cycle starting with sysinit.target/start
.. systemd(1): Started First Boot Wizard.
.. systemd(1): Mounted Configuration File System.
...


Wie es für mich aussieht, wird der job cycle.service aufgrund einer nicht erfüllbaren Abhängigkeit von sysinit.target abgebrochen. Damit wird wohl auch das Skript /etc/init.d/boot.cycle nicht ausgeführt, das das Bootmenü zur Anzeige bringen würde.

Also mit systemd kenne ich mich noch überhaupt nicht aus. Ich habe zwar viel in /etc/systemd herumgesucht und google bemüht, aber mir ist leider nicht klar geworden wo genau es nun hakt.

Ich wäre sehr froh, wenn jemand einen Tipp für mich hätte wie man das Problem gelöst kriegt.

Dir is schon klar, daß systemd mit dem Bootloader genau Null zu tun hat?
Zu diesem Zeitpunkt gibts noch kein init.

Vielen Dank für deine Antwort.

Ne sorry, war mir nicht klar.
Jedenfalls ist das Bootmenü zeitgleich mit dem Auftauchen dieser systemd - Probleme verschwunden. Und das dort protokollierte Beenden des cycle.service schien für mich mit der /etc/init.d/boot.cycle (die wiederum was mit grub zu tun hat) zusammen zu passen. (Das war ein gaaaanz großer Anflug geister Umnachtung. Natürlich startet der Bootmanager den Init-Prozess, und nicht umgekehrt. Kann mich da nur über mich selber wundern ....)
Aber du hast recht, das Beenden des cycle.service hatte trotzdem nichts mit dem Verschwinden des Bootmenüs zu tun, denn inzwischen konnte ich mit einem grub2-mkconfig -o /boot/grub2/grub.cfg das Bootmenü wieder reaktiviert.
Die Probleme mit systemd bestehen aber leider immer noch.

Wie kriegt man diese zyklische Abhängigkeit gelöst?

leanUX schrieb:

/etc/init.d/boot.cycle

Zum Vergrößern anklicken....

Der Dienst ist dazu da, bei einem unbeaufsichtigten Server mit Hilfe von GRUB Legacy eine Endlos-Bootschleife zu verhindern (Details können der Dokumentation im Paket bootcycle entnommen werden). Ein Dienst cycle.service ist mir noch nicht untergekommen (was vielleicht daran liegt, daß ich kein 13.2. habe).

josef-wien schrieb:

Ein Dienst cycle.service ist mir noch nicht untergekommen (was vielleicht daran liegt, daß ich kein 13.2. habe).

Zum Vergrößern anklicken....

Evtl. gibt es denn tatsächlich nicht, ich habe das lediglich aus der systemd-Meldung Job cycle.service/start deleted abgeleitet.

Wird jemand aus den systemd - Messages schlau und weiß wie man diese zyklische Abhängigkeit auflösen kann?

Diese zyklische Abhängigkeit habe ich jetzt gelöst, indem ich die Datei /etc/init.d/boot.cycle gelöscht (bzw. in ein zip-Archiv gepackt) habe.
Nachdem ein manuelles Durchsuchen in /usr/lib/systemd/ bzw. /etc/systemd den per journalctl -b angemeckerten Zirkelbezug nicht aufgespürt hatte, deutete für mich alles auf die boot.cyle - Datei als Schuldige hin.

In diesem Zug ist dann auch gleich die zweimal (da zwei unterschiedliche Festplattenpartitionen betreffende) auftretende Boot-Nachricht
A start job is running for udev wait for Complete Device Initialization
incl. einer jeweils damit einhergehenden mehrsekündigen Verzögerung verschwunden.

Ich markiere das Thema dann mal als gelöst.

leanUX schrieb:

Datei /etc/init.d/boot.cycle gelöscht

Zum Vergrößern anklicken....

Sinnvoller wäre, das Paket bootcycle zu enfernen. Außerdem würde ich sagen, daß es einen systemd-Service geben muß, der diese Datei aufruft, deren Abwesenheit ihn aber nicht stört.

josef-wien schrieb:

Sinnvoller wäre, das Paket bootcycle zu enfernen. Außerdem würde ich sagen, daß es einen systemd-Service geben muß, der diese Datei aufruft, deren Abwesenheit ihn aber nicht stört.

Zum Vergrößern anklicken....

Danke für den Tipp!
Ich habe das Paket bootcycle deinstalliert (wobei /etc/init.d/boot.cycle die entscheidende Datei dieses Pakets ist).

Mir sieht es danach aus, als ob systemd diese Datei nur aufruft, weil sie an entsprechender Stelle existiert. Daher denke ich kann man sie auch gefahrlos löschen ohne systemd-Seiteneffekte zu befürchten.