Boot-Schleife nach automatischen Updates

[nobody31]

Hi,

ich habe heute nach 2-wöchiger PC-Pause die vorgeschlagenen Updates installieren lassen und hänge nun in einer Boot-Schleife fest.
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]

Fehlermeldungen in irgendeiner Form wären nützlich.

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

Code: Alles auswählen

journalctl --list-boots

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

Code: Alles auswählen

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]

Wenn ich das versuche bekomme ich die Meldung:

Code: Alles auswählen

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]

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: Alles auswählen

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

Und von:

Code: Alles auswählen

/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: Alles auswählen

journalctl --all

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

Gruß,

R

[Marci2]

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]

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]

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]

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: Alles auswählen

df -h
ls -ltar /boot

[mike321]

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]

Bei mir sieht das so aus:

Code: Alles auswählen

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: Alles auswählen

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: Alles auswählen

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]

Ihr seid nicht die Einzigen.
https://forums.opensuse.org/showthread. ... s-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]

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

[Jägerschlürfer]

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

[revealed]

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]

Hallo nobody31,

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

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: 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.

Viel Erfolg und viele Grüße

susejunky

[nobody31]

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]

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

Was genau meinst du damit?

[revealed]

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]

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]

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: Alles auswählen

systemctl restart systemd-journald

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

Code: Alles auswählen

journalctl --list-boots
journalctl -b -10

Läuft der Dienst?

Code: Alles auswählen

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