Boot-Schleife nach automatischen Updates

nobody31 · 15 Aug. 2015

Hi,

ich habe heute nach 2-wöchiger PC-Pause die vorgeschlagenen Updates installieren lassen und hänge nun in einer Boot-Schleife fest. :schockiert:
Die Version 3.16.7-24 lässt sich nicht starten, weder im Desktop- noch im Recovery-Modus.

Die Version 3.16.7-21 dagegen startet normal.

Wie stelle ich das ab, bzw. wie lässt sich das in Ordnung bringen???

Vielen Dank für die Unterstützung vorweg!

revealed · 15 Aug. 2015

Fehlermeldungen in irgendeiner Form wären nützlich.

Eventuell kannst du eben mit dem Kernel den du starten kannst die log hersuchen:

Code:

journalctl --list-boots

Und diese log wo der Problemkern gestartet wird dann aufrufen, beipielsweise:

Code:

journalctl -b -10

Wenn beispielweise der Startvorgang vor 10 versuchen war. Erkennst du ja an der Uhrzeit usw. welche Zahl du eintragen müsstest.

Und da drin suchen, wo er hängt.

Gruß,

R

nobody31 · 17 Aug. 2015

Wenn ich das versuche bekomme ich die Meldung:

Code:

linux-nycq:~ # journalctl -b -2
Failed to look up boot -2: Cannot assign requested address

Bei der ersten Eingabe werden 2 Startzeiten angezeigt.

Ach ja, Fehlermeldungen bekomme ich nicht.
Nach Auswahl des zu startenden Systems erfolgt der sich ständig wiederholende Neustart.

revealed · 17 Aug. 2015

Failed to look up boot -2: Cannot assign requested address

Das macht mich gerade fertig. Was soll man ohne Fehlermeldungen tun?

1. Eventuell könntest du nochmal den einen Kernel booten bis in der Schleife ankommt.
2. Dann den anderen Kernel booten der funktioniert und die Ausgabe von:
Achtung hier hatte ich mich vorhin vertippt:

Code:

grep /var/log/Xorg.0.log.old

Und von:

Code:

/sbin/lspci -nn | grep VGA

organisieren?

Schleife klingt wie desktop geht dauernd an, stürzt ab und versuchts wieder ....
Oder bekommst du konstant den Splash angezeigt?

Hast du irgendwas umgestellt, dass nicht mehr im journal geloggt wird oder so? Wo ist dein boot log?
Funktioniert:

Code:

journalctl --all

?
Hast du dich als root angemeldet um die Ausgaben zu holen? Falls nein, bitte nachreichen.

Gruß,

R

Marci2 · 19 Aug. 2015

Hallo Leute,

ich habe das selbe Problem: Aktuell habe ich Einträge im Bootloader für 3.16.7-21 und 3.16.7.24. Die beiden Einträge mit 3.16.7-24, also sowohl die Desktop- als auch die Widerherstellungsversion starten nicht. Es sieht aus, als wäre die initrd kaputt. Die Frage ist nun, wie kann ich die initrd für 3.16.7-24 neu bauen, wenn ich das System mit dem 3.16.7-21 gestartet habe? Ein Updaten mit zypper behauptet, mein System wäre aktuell (mit 3.16.7-21 gestartet).

Über den Eintrag mit dem 3.16.7-21 kann ich auch das Desktopsystem ganz normal starten.

Werde nun mal über das Installationsmedium starten und schauen, ob ich dann weiterkomme.

Aber nochmal: Bei mir ist es so, dass der Rechner _sofort_ nach Anzeige, dass die initrd geladen wird, neu startet. Ich denke nicht, dass das ein Problem mit dem X-Server ist. Ich komme ja nichtmal bis zur Konsole.
Mit den logs ist's schwierig. Ich kann nichts finden, was mich weiterbringt. Welche Ausgaben wäre für die Experten hier wichtig?

Bin für alle Ideen offen und bedanke mich schonmal für eure Mithilfe.

Gruß

Marcus

Marci2 · 19 Aug. 2015

Sooo, also ich habe jetzt mal in YaST den 24er-Kernel deinstalliert. Im Bootmenü gibt es dann nur noch den 21er, und der startet (auch mit Desktop) normal. Beim nächsten Hochfahren ist alles prima, es kommt dann irgend wann eine Update-Nachricht für den 24er-Kernel. Update nochmal durchgeführt, und beim Booten wieder dasselbe Problem. Ich habe jetzt einfach den 24-Kernel über YaST nochmal deinstalliert und werde vorerst die Update-Meldung für den 24er-Kernel ignorieren.
Irgend etwas scheint mit dem 24er-Kernel nicht in Ordnung zu sein. Mal abwarten, Hauptsache, mein System startet wieder zuverlässig.
Trotzdem wäre es schon interessant, was da schiefgeht, den offensichtlich läuft ja der 24er bei den meisten Leuten problemlos.

Gruß

Marcus

nobody31 · 19 Aug. 2015

Was mir grad einfällt, obwohl ich nicht denke es hat was damit zu tun, ich habe auf der Windows-Seite (Win7 Pro) versucht, auf Win 10 Pro upzudaten; das schlug aber fehl.

Ansonsten ist nichts von mir verändert worden.
Seit wann gibt es denn den 24-Kernel eigentlich??

gehrke · 19 Aug. 2015

Solange Du keine Logs postest, kann man nur raten. Ist denn noch genug Kapazität auf der Boot-Partition frei, um den Kernel und die InitRamdisk zu schreiben?
Poste bitte mal die Ausgabe von:

Code:

df -h
ls -ltar /boot

mike321 · 19 Aug. 2015

Nabend!

Bei mir taucht dieses Problem auch auf nach dem Update von Kernel 3.16.7-21 auf 3.16.7-24,direkt nach der System Auswahl bei Grub2 startet das System wieder neu wenn ich den 24 Kernel nehme beim 21 läuft der Rechner wieder normal hoch.habe auch erstmal den Kernel wieder deinstalliert.

LogFiles poste ich morgen

mike

gehrke · 20 Aug. 2015

Bei mir sieht das so aus:

Code:

gehrke@j3:~> ls -l /boot/*3.16.7-24*
-rw-r--r-- 1 root root   148309  7. Aug 14:18 /boot/config-3.16.7-24-desktop
-rw-r--r-- 1 root root 10405444 17. Aug 07:46 /boot/initrd-3.16.7-24-desktop
-rw-r--r-- 1 root root   309437  7. Aug 16:35 /boot/symvers-3.16.7-24-desktop.gz
-rw-r--r-- 1 root root      516  7. Aug 16:35 /boot/sysctl.conf-3.16.7-24-desktop
-rw-r--r-- 1 root root  3003177  7. Aug 16:11 /boot/System.map-3.16.7-24-desktop
-rw-r--r-- 1 root root  6668759  7. Aug 16:46 /boot/vmlinux-3.16.7-24-desktop.gz
-rw-r--r-- 1 root root  5685608  7. Aug 18:39 /boot/vmlinuz-3.16.7-24-desktop

Code:

gehrke@j3:~> uname -a
Linux j3.gehrke.local 3.16.7-24-desktop #1 SMP PREEMPT Mon Aug 3 14:37:06 UTC 2015 (ec183cc) x86_64 x86_64 x86_64 GNU/Linux

Der entsprechende Teil aus /boot/grub2/grub.cfg:

Code:

menuentry 'openSUSE' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-<xxx>
' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt 
        insmod ext2
        set root='hd0,gpt1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 --hint='hd0,gpt1'  <xxx>
        else
          search --no-floppy --fs-uuid --set=root <xxx>
        fi
        echo    'Loading Linux 3.16.7-24-desktop ...'
        linux   /vmlinuz-3.16.7-24-desktop root=UUID=<xxx>  ${extra_cmdline}  resume=/dev/system/swap splash=silent quiet showopts
        echo    'Loading initial ramdisk ...'
        initrd  /initrd-3.16.7-24-desktop
}

Jägerschlürfer · 20 Aug. 2015

Ihr seid nicht die Einzigen.
https://forums.opensuse.org/showthread.php/509190-After-update-computer-does-not-boot

Schaut euch das hier einmal an und prüft, ob euer Rechner am gleichen Punkt hängt und folgt dort einmal den Anweisungen,...

nobody31 · 20 Aug. 2015

Mein Schul-Englisch ist schon etwas eingerostet, so ca. 50 Jahre. :???:

ps:

Jägerschlürfer · 21 Aug. 2015

wieso lässt du es dir dann nicht übersetzen? Gibt doch genug Möglichkeiten im Netz,... oder auch persönliche Ansprechpartner,...

revealed · 21 Aug. 2015

Was mir grad einfällt, obwohl ich nicht denke es hat was damit zu tun, ich habe auf der Windows-Seite (Win7 Pro) versucht, auf Win 10 Pro upzudaten; das schlug aber fehl.

.... eine ganz verwinkelte Idee.... hast du fastboot aktiviert?

Gruß,

R

susejunky · 23 Aug. 2015

Hallo nobody31,

nobody31 schrieb:
Mein Schul-Englisch ist schon etwas eingerostet, so ca. 50 Jahre. :???: ps:

ohne geprüft zu haben, ob die zitierte Lösung zu Deinem Problem passt, hier eine kurze Zusammenfassung in deutscher Sprache:

Die Lösung bestand darin, den Kernel 3.16.7-21-desktop zu starten (das geht natürlich nur, wenn dieser auf Deinem System noch vorhanden ist) und dann die Datei "initrd-3.16.7-24-desktop" neu zu erstellen.

Das kann man als Administrator mit

Code:

dracut -f --kver 3.16.7-24

--kver ermöglicht es, eine initrd-Datei gezielt für eine bestimmte Kernelversion zu erstellen
-f erzwingt die Erstellung einer initrd-Datei, wenn bereits eine (ggf. fehlerhafte) vorhanden ist.

Vielleicht hilft Dir das weiter.

Viel Erfolg und viele Grüße

susejunky

nobody31 · 28 Aug. 2015

Das kann man als Administrator mit

Code: Alles auswählen
dracut -f --kver 3.16.7-24

--kver ermöglicht es, eine initrd-Datei gezielt für eine bestimmte Kernelversion zu erstellen
-f erzwingt die Erstellung einer initrd-Datei, wenn bereits eine (ggf. fehlerhafte) vorhanden ist.

Vielleicht hilft Dir das weiter.

Hat leider nichts gebracht, aber Danke für den Tip.

nobody31 · 28 Aug. 2015

revealed schrieb:
Was mir grad einfällt, obwohl ich nicht denke es hat was damit zu tun, ich habe auf der Windows-Seite (Win7 Pro) versucht, auf Win 10 Pro upzudaten; das schlug aber fehl.

Zum Vergrößern anklicken....

.... eine ganz verwinkelte Idee.... hast du fastboot aktiviert?

Gruß,

R

Was genau meinst du damit?

revealed · 28 Aug. 2015

Dieser Fall, wo Windows in s2disk gegangen ist, weswegen Linux bei aktiviertem fastboot (BIOS /UEFI) nicht mehr starten wollte? Könnte man ja kurz versuchen. Kurz ins BIOS, fastboot aus und go. Falls es nich hilft, kann manns ja auch kurz wieder umstellen.

Und wo du sagst, dass da mit Win10 was nich geklappt hatte, -- man weiss ja nicht was -- es könnte immerhin sein. Das wär aber ein ziemlich krasser Glückstreffer dann.

Gruß,

R

PS.: Was machen wir denn noch bei dir? Du hast ja jetz schon einige Tage ausfall, oder?
PPS.: Wobei aber dein alter Kernel dann eigentlich au nich starten dürfte.... (bei dem Einfall).

Eine Idee wäre eventuell auch den alten funktionierenden starten, dann den neuen fehlerhaften nochmal entfernen und die installation des neueren erneut wiederholen Nach vorigem Neustart. (Würd ich mal probieren). Vielleicht löst das auch alles. Und ist hier an der Stelle auch irgendwie doof ohne irgendwelche konkrete Fehlermeldungen. Für mich zumindest.

Und sag doch bitte nochmal kurz, was für eine Grafikkarte / Treiber?

nobody31 · 31 Aug. 2015

Kurz ins BIOS, fastboot aus und go.

Das hat leider nichts gebracht.

Und sag doch bitte nochmal kurz, was für eine Grafikkarte / Treiber?

Modell: nVidia GT216 [GeForce GT 220]
Treiber: nouveau

Werde dann mal den neuen Kernel deinstallieren. Danke.

revealed · 31 Aug. 2015

Treiber: nouveau

Das löst dann schonmal meine Frage nach der Xorg.0.log --- da fällt eine Treiberneusintallation dann flach quasi. Der sollte out of the box laufen.

Dann Neustart mit dem alten und nochmal probieren?

Dann hab ich noch was gefunden zu:

Failed to look up boot -1: Cannot assign requested address

Falls es nicht klappen sollte, könnten wir da nochmal schauen. Wenn es jetzt zwischenzeitlich funktioniert.... Ich hoffe, dass jetzt dein neuer Kernel als auch logging funktionieren... dann wird der Punkt überflüssig.

Ich schreib das einfach mal nieder, was ich da schauen würde:
- Du verwendest in diesem Szenario wo du den neuen Kernel startest und das journal mit Fehlermeldung abfragen möchtest, aber nicht "rsyslog"?
- Falls du nicht rsyslog verwendest, hilft ein:

Code:

systemctl restart systemd-journald

Gefolgt von der Abfrage des Log? Wo du die "id eines bootvorganges wählst mit dem neuen?

Code:

journalctl --list-boots
journalctl -b -10

Läuft der Dienst?

Code:

systemctl status systemd-journald

Die Ausgabe sollte "active (running)" beinhalten.

Und wenn du auf rsyslog umgestellt haben solltest, dann bringt es eher nichts das journal abzufragen. Dann wäre es eher Sinnvoll in /var/log nachzusehen.

Gruß,

R

Boot-Schleife nach automatischen Updates

nobody31

revealed

nobody31

revealed

Marci2

Marci2

nobody31

gehrke

Administrator

mike321

gehrke

Administrator

Jägerschlürfer

Moderator

nobody31

Jägerschlürfer

Moderator

revealed

susejunky

Moderator

nobody31

nobody31

revealed

nobody31

revealed