Siduction Forum
Siduction Forum => Software - Support => Topic started by: ralfi on 2019/01/04, 10:17:50
-
Hallo siducties allesamt,
ich habe seit gestern ein - zumindest für mich kniffliges - Problem beim Kernel Start meines PCs. Der Startvorgang fällt nach mehrfacher "Running /scripts/local-block ..."-Meldung in die initramfs Shell und ab da scheint sich der Rechner "aufgehangen" zu haben, d.h. er nimmt auch keine Tastatureingaben mehr an und ich muss die Kiste hart ausschalten.
Was habe ich bisher versucht um das Problem zu analysieren?
Ein Start von einem Live-Stick (SystemRescueCd wie auch siduction-18.x) funktioniert fehlerfrei. Dies scheint die Vermutung zu stützen, dass es sich nicht um einen Hardwarefehler handelt. Nach Start vom USB-Stick arbeitet der Rechner auch stundenlang vollkommen problemlos.
Auch habe ich vor erstmaligen Auftreten dieses Fehlers keinen Wechsel der Festplatte, der Partitionskonfiguration oder des Filesystems vorgenommen.
Also habe ich versucht, den Startvorgang selbst und die initrd zu debuggen. Dazu habe ich - wie im siduction Handbuch beschrieben - eine chroot Umgebung erstellt um die Boot-Partition zuzugreifen. Dies funktioniert ebenfalls tadellos. Mit Hilfe von update-initramfs habe ich dann die initrd's versucht zu "behandeln". Ich habe sie testweise einem Update unterzogen, sie gelöscht und mit dem "verify"-Parameter neu erstellen lassen - nüx hilft. Für alle Kernel bei jedem Neustart das oben angeführte Symptom.
Dabei ist mir besonders müsterjös, dass ich beim Rückfall in die initramfs Shell kein Tastatur Treiber geladen wird und sich das System scheinbar echt richtig "aufhängt".
Deshalb möchte ich hier folgende Fragen stellen:
- Kann das jemand nachvolllziehen oder mir einen Tipp geben?
- Kann man in einer chroot Umgebung ein initram Filesystem neu erstellen?
- Wie kann man das Erstellen der initrd "debuggen" (mal abgesehen vom "-v" Parameter von update-initramfs)?
- Kann man in der chroot Umgebung mal die initramfs Pakete löschen und sie neu installieren?
Danke im voraus für alle Tipps. Und nein, ich möchte die Kiste nicht neu installieren...
-
Can you boot to older/another kernel ?
https://wiki.debian.org/InitramfsDebug
-
Hi piper,
no, but it seems to me there is really a problem with initramfs creation or update after d-u.
Last hour i use siduction-patience-18.3-cinnamon to do a fresh new install from iso to the same partition where the old install was located. Install will finished and start will succeded. After this i do a full d-u (no modifikation of packages) which works fine but after this the install of *every* new kernel (try with 4.[17,18,19].9-towo Kernels) will fail after reboot...
Looking in /boot/ show me that the initrd from the iso install (4.16) will be untouched and this kernel is the only one who works fine... It seems to me the initrd which are failed could not be decrompressed or something like this...
-
Next time it might be wise to mention that you are using zfs ;)
-
Moin piper, i do not using zfs for my bootfs - and not crypt, mdadm and lvm - and IMHO the initrd file will not be touch (looking at the date/time-stamp) after install zfs.
-
Es ist wirklich schon ein sehr komisches Verhalten und vielleicht doch Hardware / BIOS / Firmware bedingt. Denn trotz vielfältiger ähnlicher Installationen auf physischen wie virtuellen Systemen hat scheinbar bisher nur meine Kiste ein derartiges Problem. Nun ja...
-
Habe heute folgendes gefunden, könnte passen: https://bbs.archlinux.org/viewtopic.php?id=243253
und:
https://www.reddit.com/r/archlinux/comments/ae41zy/systemd_240_is_apparently_making_some_systems/
-
Nach ausführlicher Lektüre der Links und einem "Probelauf" in einer VM kann ich bestätigen, dass sich das Problem durch die Installation der Pakete
libnss-myhostname
libnss-mymachines
libnss-systemd
libpam-systemd
libsystemd0
libudev1
systemd
systemd-container
systemd-coredump
systemd-sysv
udev
in der Version 239-5.6 aus dem siduction Repo fixen lässt. Ich habe diese Pakete heruntergeladen mit einem "dpkg -i *" installiert. Danach funktioniert das Booten des entsprechenden Kernels.
Auch die allerneuesten Pakete aus udev 240-3 von heute führen bei mir zum Aufhängen beim Starten des jeweiligen Kernels.
Ursache ist vermutlich eine fehlerhafte Modifikation des Initram Filesystems. Anders als von mir ursprünglich beschrieben findet diese nämlich beim D-U über den initramfs Trigger durchaus statt - vermutlich war ich da kurzzeitig erblindet - und führt dann dazu das der Kernel nicht mehr startet. Und weil ich das am 3.1. als ich dieses Problem hier schilderte offensichtlich nicht bemerkte führte dann ein ebenso kraftvolles wie sinnfreies "update-initramfs" für *alle* installierten Kernel dazu dass meine Kiste überhaupt nicht mehr startete.
Als Vorsichtsmaßnahme ist also zusätzlich zu empfehlen sich die Dateien eines lauffähigen Kernels einfach mal in ein anderes Verzeichnis zu kopieren.
Vielen Dank an alle die sich hier bemühten ...
-
und was noch schöner ist: mit systemd / udev 240.4 geht alles wieder wie es soll