Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic: [DE] (gelöst) initramfs Problem  (Read 2563 times)

Offline ralfi

  • User
  • Posts: 389
[DE] (gelöst) initramfs Problem
« 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...

« Last Edit: 2019/01/14, 15:23:44 by piper »
Gruss, ralfi

Niveau sieht von unten oft wie Arroganz aus ...

Offline piper

  • User
  • Posts: 1.785
  • we are the priests ... of the temples of syrinx
Re: initramfs Problem
« Reply #1 on: 2019/01/04, 13:01:21 »
Can you boot to older/another kernel ?

https://wiki.debian.org/InitramfsDebug

Free speech isn't just fucking saying what you want to say, it's also hearing what you don't want to fucking hear

I either give too many fucks or no fucks at all, it's like I cannot find a middle ground for a moderate fuck distribution, it's like what the fuck

Offline ralfi

  • User
  • Posts: 389
Re: initramfs Problem
« Reply #2 on: 2019/01/04, 14:38:54 »
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...


Gruss, ralfi

Niveau sieht von unten oft wie Arroganz aus ...

Offline piper

  • User
  • Posts: 1.785
  • we are the priests ... of the temples of syrinx
Re: initramfs Problem
« Reply #3 on: 2019/01/04, 20:45:52 »
Next time it might be wise to mention that you are using zfs ;)
Free speech isn't just fucking saying what you want to say, it's also hearing what you don't want to fucking hear

I either give too many fucks or no fucks at all, it's like I cannot find a middle ground for a moderate fuck distribution, it's like what the fuck

Offline ralfi

  • User
  • Posts: 389
Re: initramfs Problem
« Reply #4 on: 2019/01/05, 08:47:57 »
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.
 
Gruss, ralfi

Niveau sieht von unten oft wie Arroganz aus ...

Offline ralfi

  • User
  • Posts: 389
Re: initramfs Problem
« Reply #5 on: 2019/01/09, 09:51:12 »
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...
Gruss, ralfi

Niveau sieht von unten oft wie Arroganz aus ...

Offline devil

  • Administrator
  • User
  • *****
  • Posts: 4.838

Offline ralfi

  • User
  • Posts: 389
Re: initramfs Problem
« Reply #7 on: 2019/01/11, 14:20:00 »
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 ...


Gruss, ralfi

Niveau sieht von unten oft wie Arroganz aus ...

Offline ralfi

  • User
  • Posts: 389
Re: initramfs Problem
« Reply #8 on: 2019/01/14, 09:34:37 »
und was noch schöner ist: mit systemd / udev 240.4 geht alles wieder wie es soll
Gruss, ralfi

Niveau sieht von unten oft wie Arroganz aus ...