Unbootbar: OOM?

Moin,

ich hab ein System mit nur 128 MB RAM. Die Installation von Stretch lief schon unter Zuhilfenahme eines temporären Fileswaps, klappte dann aber anstandslos.

Nach Aktualisierung von Stretch zu Buster (Kernel 4.9.0-9 zu 4.19.0-5) kann ich nicht mehr booten / nicht den neuen Kernel. Mit dem alten klappt es.

Der Panic-Stack legt für mich nahe, dass der Arbeitsspeicher vielleicht nicht ausreicht?

Bildschirmfoto 2019-07-29 um 07.58.57.png

Ich bin ehrlich: Ich hab von der Thematik nicht so viel Ahnung. Es ist ja bestimmt so, dass zu diesem Zeitpunkt der swap noch nicht zur Verfügung steht.

Kann es sein dass der Kernel "zu groß" ist, um gebootet zu werden?

Welche Optionen habe ich das dennoch hinzubekommen?

Ich bin bereit a) zu lernen, b) mein System zu schrotten.

-rw-r--r--  1 root root 3.3M Jul 19 10:45 System.map-4.19.0-5-amd64
-rw-r--r--  1 root root 3.1M Jul 19 13:41 System.map-4.9.0-9-amd64
-rw-r--r--  1 root root 202K Jul 19 10:45 config-4.19.0-5-amd64
-rw-r--r--  1 root root 183K Jul 19 13:41 config-4.9.0-9-amd64
drwxr-xr-x  5 root root 4.0K Jul 28 14:50 grub
-rw-r--r--  1 root root  25M Jul 28 14:52 initrd.img-4.19.0-5-amd64
-rw-r--r--  1 root root  18M Jul 28 12:36 initrd.img-4.9.0-9-amd64
-rw-r--r--  1 root root 5.0M Jul 19 10:45 vmlinuz-4.19.0-5-amd64
-rw-r--r--  1 root root 4.1M Jul 19 13:41 vmlinuz-4.9.0-9-amd64

Zitat von vmk

Oh noch ein Thread zu dem Thema "Debian + [Ram]-Verbrauch". Ist das Problem debianspezifisch?

Haha, stimmt. Da war die Tage einiges hier.

Hab ich nicht ausprobiert, da ich nur debian nutze.

Aber in alter Hecke29-Manier habe ich das Problem auch selbst gelöst

So pi-mal-Daumen weiß ich, dass beim booten ein temporäres Filesystem geladen wird ("initramfs"), auf dem dann Dinge getan werden (Treiber laden etc.) und als letztes quasi das eigentliche rootfs mounted und daran dann "übergibt" (Leute, ich weiß das nicht so genau, interessiere mich zwar dafür, aber brauch sowas halt selten).

Hab ich mir also gedacht: Na, wenn ich mir die Dateien unter /boot Anschaue ist "initrd" mit 25 MB neu (zu 18 MB vorher) ja recht groß: Vielleicht ist das initramfs zu groß.

Also hab ich die Konfigurationsdateien unter /etc/initramfs-tools mal ein bisschen angeguckt und ein MODULES=most gefunden mit der Anmerkung, dass das einfach pauschal "viele" Module in das initramfs einbaut und die Einstellung MODULES=dep nur die, die er glaubt zu brauchen. Das also umgestellt auf dep und backup_initramfs auf yes

Dann mit update-initramfs -u -k 4.19.0-5-amd64 für den neuen Kernel ein neues initramfs erstellt, das nunmehr statt 25MB nur 7MB hat und voila: Er bootet wieder durch

Was auch wiedermal meine Lieblingserkenntnis von Linux untermauert: "everything in linux is a file"

Zitat von H6G

Unix.

Verzeihung. Ich merke: Heute ist der Tag an dem ich einiges lerne. Next-Up: POSIX

Zitat von H6G

Das wichtigste darin ist das /init File.

Da dein Link auf ein Alpine führt hab ich einfach mal mein initrd.img-4.19.0-5-amd64 in gzip -d gestopft, dann mit einem Tool namens cpio (wieder was neues) "entpackt" und schau mich grade in /init um. Ist auf jeden Fall nochmal next-Level