• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Kernel panic nach Kernel-Update unter openSUSE 13.2 [gelöst]

A

Anonymous

Gast
Hallo zusammen,

Ende des letzten Jahres habe ich auf einem neuen Server mit gespiegelter Festplatte openSUSE 13.2 installiert (mit Software-RAID und LVM, alles ext4) und alles lief wie es sollte. Jetzt habe ich das Kernel-Update durchgeführt, das mir angeboten wurde, also von Version 3.16.6.2 auf 3.16.7.7. Nach dem Neustart kam folgende Meldung:

error while loading shared libraries: libselinux.so.1: cannot open shares object file: No such file or directory
Kernel panic – not syncing: Attempted to kill init!

https://onedrive.live.com/?cid=e436...v=3&ithint=photo,jpg&authkey=!AP13xPA50IjTozE

(das ist nicht mein Screenshot, aber identisch bis auf die Kernelversion)

Das Booten des alten Kernels funktioniert, jeder andere (neuere) Kernel führt jedoch zur "panic". Interessanterweise auch der Kernel 3.16.6.2-default. Er funktioniert wirklich nur der originale 3.16.6.2-desktop.

Da in der Meldung ein Hinweis auf selinux steht, habe ich auch (erfolglos) versucht, dieses mittels Boot-Parameter zu deaktivieren (selinux=0).

Der Speicherort des Bootloaders ist der MBR (das war bei der Erstinstallation die einzig funktionierende Variante). Das ist (neben RAID und LVM) der einzige Unterschied zu 3 anderen Installationen, wo alles problemlos läuft.

Ich glaube nicht, dass das Problem mit kommenden Updates wieder verschwindet. Auch habe ich die Befürchtung, dass selbst eine Neuinstallation nichts bringen würde.

Kann mir jemand vielleicht ein Tipp geben?

Gruß
Michael
 
J

josef-wien

Ultimate Guru
Falls das Programm unter 13.2 noch funktioniert, für jede initrd:
Code: 
lsinitrd /boot/initrd-xxx | grep libselinux
Das Paket libselinux1 wird ja wohl noch installiert sein.
 
S

swannema

Member
Das Problem hatte ich auch, bei mir lag es an einem tmpfs Eintrag in der fstab. Nachdem ich diesen auskommentiert hatte, funktionierte das Kernel Update.
 
OP
A

Anonymous

Gast
Vielen Dank Ihr beiden! Also die Ausgabe von "lsinitrd /boot/initrd-xxx | grep libselinux" ist bei allen Kerneln leer, außer beim originalen, der funktioniert. Hier erscheint:

Code: 
-rwxr-xr-x   1 root     root       138792 Dec 12 13:19 lib64/libselinux.so.1

Kann mir jemand erklären, was hier falsch gelaufen sein könnte? Bei den anderen Installationen bin ich genauso vorgegangen und hier hat alles funktioniert.
 
OP
A

Anonymous

Gast
Danke für den Tipp, swannema!! Das ist tatsächlich noch ein Unterschied zu den bisherigen Installationen. Ich habe versucht, die /tmp-Partition also noexec zu mounten (nach http://www.cyberciti.biz/faq/linux-add-nodev-nosuid-noexec-options-to-temporary-storage-partitions/). Hier ein Auszug meiner fstab:

Code: 
/dev/vg_system/tmp	/tmp				ext4		acl,user_xattr,nodev,nosuid,noexec		1 2

/tmp				/var/tmp		none			rw,noexec,nosuid,nodev,bind				0 0
tmpfs			/dev/shm		tmpfs		defaults,nodev,nosuid,noexec					0 0

Zur Not kommentiere ich einfach alles aus bzw. teste, was funktioniert und was nicht. Aber hat jemand vielleicht eine Idee, wie ich etwas gezielter vorgehen kann?
 
S

swannema

Member
Die tmpfs Einträge in der fsab braucht man bei 13.2 nicht mehr, das wird automatisch erstellt.

So sieht das bei mir ohne fstab Eintrag aus:

Code: 
stefan@linux-tnbz:~> df -h | grep tmpfs
devtmpfs        7,9G       0  7,9G    0% /dev
tmpfs           7,9G       0  7,9G    0% /dev/shm
tmpfs           7,9G     11M  7,9G    1% /run
tmpfs           7,9G       0  7,9G    0% /sys/fs/cgroup
 
J

josef-wien

Ultimate Guru
Die fstab spielt hier überhaupt nicht mit. Einträge für tmpfs brauchst Du seit längerem nur dann, wenn Du abweichende Attribute festlegen oder zusätzliche tmpfs definieren möchtest. Den Schwachsinn
mrauh schrieb:
Code: 
/tmp            /var/tmp      none         rw,noexec,nosuid,nodev,bind            0 0
Zum Vergrößern anklicken....
solltest Du Dir abgewöhnen.

Das Problem könnte dracut sein. Welche Version ist bei Dir installiert? Was hast Du heute installiert (siehe /var/log/zypp/history)?
 
OP
A

Anonymous

Gast
Danke für die Vorschläge! Neustarten und testen kann ich erst morgen, wenn ich wieder im Büro bin.

Aktuell ist dracut 037-17.9.1 installiert, direkt nach der Installation war es wohl 037-17.6.1. Siehe hier:

Code: 
cat /var/log/zypp/history | grep dracut

2014-10-26 09:02:26|install|dracut|037-17.6.1|x86_64|root@opensuse|InstallationImage|59875e0dd1e343995b6b883e35600ff644ff8d607b1eae85ebf9264c2185a739|
2014-10-26 09:02:52|install|plymouth-dracut|0.9.0-1.1|x86_64|root@opensuse|InstallationImage|f701a397eb4ea47b71bd904a075e747478335d1dc1eb282220b81d47df8e6109|
# Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-3.16.6-2-desktop 3.16.6-2-desktop
2014-12-12 13:18:14|install|dracut|037-17.9.1|x86_64||repo-update|2f026fdb5618312b6fd157f410f2f45098f6b41d36531cf509b1c55c3860e384|
# Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-3.16.6-2-desktop 3.16.6-2-desktop
# Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-3.16.7-7-desktop 3.16.7-7-desktop
# Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-3.16.7-23.g99d827e-desktop 3.16.7-23.g99d827e-desktop
# Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-3.16.7-7-default 3.16.7-7-default
# Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-3.16.6-2-default 3.16.6-2-default

Es scheint so zu sein, dass alle initrd, die mit der neuen dracut-Version erstellt wurden, fehlerhaft sind. Aber auch die funktionierende initrd-3.16.6-2-desktop wurde (nochmal) von der neuen dracut-Version erstellt (Änderungsdatum der Datei ist: 12. Dez 13:19).
 
J

josef-wien

Ultimate Guru
Benenne die funktionierende initrd um, und erstelle sie neu. Wenn die neue Version die Bibliothek nicht enthält, muß irgendein geändertes Paket hineinspucken, aber zur Vorgangsweise von dracut kann ich nichts sagen. (Und wenn die Bibliothek dabei ist, dann müssen Hexen unterwegs sein.)
 
OP
A

Anonymous

Gast
Das ist alles sehr dubios. :???: Ich werde morgen mein Glück versuchen und berichten.
 
OP
A

Anonymous

Gast
Es funktionert!! Dank Eurer beiden Hinweise (fstab, dracut) habe ich es hinbekommen. Als erstes habe ich die letzten beiden Zeilen meiner fstab auskommentiert (siehe oben), neu gestartet, danach den aktuellen Kernel neu installiert. lsinitrd lieferte direkt das korrekte Ergebnis (die libselinux.so.1 war vorhanden) und ich konnte den neuen Kernel booten. Wenn /var/tmp nach /tmp gemounted ist, scheint die libselinux.so.1 nicht in die initrd geschrieben zu werden.

Vielen Dank nochmal an alle Beteiligten!
 
J

josef-wien

Ultimate Guru
Eine interessante Konstellation.

mrauh schrieb:
Wenn /var/tmp nach /tmp gemounted ist
Zum Vergrößern anklicken....
Mit Deinem fstab-Eintrag wird der Inhalt des Verzeichnisses /tmp (enthält Daten, die nach einem reboot nicht mehr gebraucht werden) zusätzlich unter /var/tmp zur Verfügung gestellt, d. h. der bisherige Inhalt des Verzeichnisses /var/tmp (enthält Daten, die auch nach einem reboot gebraucht werden) wird verdeckt und ist nicht mehr zugreifbar. dracut scheint (sagen wir es einmal so) unglücklich zu reagieren, wenn entweder Daten von /var/tmp benötigt werden und diese (durch das Verdecken) nicht mehr vorhanden sind, oder wenn /var/tmp bzw. /dev/shm für bestimmte Funktionen verwendet wird, die durch Deine Dateisystemattribute nicht ausgeführt werden können.

Ich schließe übrigens nicht aus, daß Deine Dateisystemattribute für /tmp irgendwann einmal Probleme verursachen können. Und ich stelle rein rhetorisch, nur zum Nachdenken und im Bewußtsein, daß jeder Vergleich hinkt, die Frage in den Raum, welchen Nutzen es bringt, einen Teil eines Maschendrahtzauns für Insekten unpassierbar zu machen.
 
OP
A

Anonymous

Gast
Danke für den Hinweis! Ich habe mir einen dicken Kommentar in meine fstab gemacht.
 
H

horstschulz

Newbie
hallo,
ich finde es intressant, wie mit dem fehlerbehafteten Kernelupdate 3.16.7-7-Desktop umgegangen wird, wenn der PC nicht mehr startet, Auch bin ich erleichtert, das ich mit diesem Problem nicht alleine bin.
Nur, ich bin kein Systemer und kann nicht so ohne weiteres nachvollziehen was da passiert, und wo und warum Einträge in Dateien geändert werden. Ich habe wichtige Daten auf mein PC, der Datenverlust wäre beim Systemcrash groß. Selbstverständlich habe ich immer eine Datensicherung, aber muß ich jetzt auch stündlich sichern.
Was habe ich für eine Alternative?
Keine Updates mehr?
Nur noch gezielte Updates und snapper vertrauen?
Nur noch Sicherheitsupdates, aber Finger weg wenn da das Wort Kernel auftaucht?
Für ein paar Tips wäre ich dankbar,
H. Schulz
 
J

josef-wien

Ultimate Guru
horstschulz schrieb:
fehlerbehafteten Kernelupdate 3.16.7-7-Desktop
Zum Vergrößern anklicken....
Wie kommst du darauf? In diesem Thema hat jemand durch eine von ihm selbst vorgenomme Änderung einer Konfigurationsdatei eine unglückliche Reaktion des Programms dracut herausgefunden. Mit dem Kernel selbst hat das nichts zu tun.

Gerade beim Kernel, bei Verschlüsselungsroutinen und bei allem, wo das Internet mitspielt, sind Aktualisierungen sinnvoll.
 
H

horstschulz

Newbie
nun, was soll ich darauf antworten?
es gibt ein Update nach Linux 3.16.7-7-Desktop,
Übernehme ich dieses, wird mir nur noch die Boot-Auswahlmaske angezeigt, booten oder die erweiterten Bootoptionen, aber nichts weiter passiert, wenn ich normales booten auswähle. es kommt nuch noch der Kasten mit dem Versionshinweis.
Dann keine Tastatureingaben, keine Maus, System hängt.
Weiter komme ich nur über die Recoverauswahl, sprich Wiederherstellung mit snapper.
Also daher meine Vermutung mit dem Kernel-Update

H. Schulz
 
H

horstschulz

Newbie
hallo,
hat sich alles erledigt,
das mit dem Kernel - Update nehme ich zurück.
Ich habe das System neu aufgesetzt, und alle Updates nachgeholt. Es sin keine weiteren Fehler aufgetreten.
;)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben