initrd entpacken/packen

[Knogle]

Ich grüße euch liebe Community.
Momentan bringe ich Parted Magic auf PXE mit NFS Support zum laufen.
Dabei habe ich zuvor die alte initrd angepasst, und wieder gepackt --> NFS Läuft, leider jedoch USB Treiber nicht reingepackt was nun nervt.
Deshalb wollte ich nun paar Tage später ran, jedoch kriege ich das Ding nicht mehr zum laufen wenn ich das wieder packe.
Ich nehme die vorhandene modifizierte laufenden initrd.img und entpacke diese nach diesem Tutorial.
https://access.redhat.com/solutions/24029
Dann packe ich diese ohne Anpassungen vorzunehmen, dann geht sie aufeinmal nicht mehr.
Woran liegt das? Habe ich irgendeinen Schritt vergessen? Leider geht meine .bash_history nicht mehr weit genug zurück, jedoch habe ich mich an das Tutorial gehalten, und auch selbst ein Tutorial geschrieben.
Interessant ist: Die gepackte Datei ist auch eine LZMA Datei (gepackt unter Kernel 5.3).
Die Datei die ich damals vor 1 Woche nach diesem Tutorial gepackt habe ist jedoch eine XZ format Datei! Beim gleichen Befehl! ( Kernel 5.4.0 rc4)
Aber gibt es einen sicheren Weg die zu entpacken und wieder zu packen?
Bekomme beim entpacken --> packen einer funktionierenden initrd.img die Meldung: VFS: Unable to mount root fs on unknown-block.
Gibt es irgendwie Tools um eine initrd fuer ein Fremdsystem zu bauen? (Bearbeite die initrd.img auf einem Debian 5.3.0 System, laufen sollen diese als PXE Image auf einem Debian 4.19 System. Image Version sollte auch 5.3 sein)
Habe nun extra keine Bilder angehangen, so wie von niemand gewünscht.

[ren22]

vielleicht so ?

Code: Alles auswählen

#!/bin/sh

if [ -d "repack" ]; then
    rm -rf repack
fi
mkdir -p repack
cd repack
cp ../initrd.gz .
gunzip initrd.gz
cpio -idv < initrd
rm -f initrd
echo "extracting initrd done"

Code: Alles auswählen

#!/bin/sh

cd repack || exit 2
find | cpio -o -H newc | gzip -2 > ../initrd.gz
cd ..
rm -rf repack
echo "recompressing initrd done"

ohne das ich mir dein ganzen Text durchgelesen habe, solltest Du erstmal die initrd im gängigen gzip format belassen, wenn ichmich jetzt nicht irre, denn der Kernel muss ja beim booten die Fähigkeit besitzten auch das Kompressionformat zu lesen und das ist meist das gzip fomat, je nach dem wie dein Kernel gebaut , mit welchen Optionen ...

Grüsse

[Knogle]

Danke dir, leider hat das auch nicht geklappt. Habe herausgefunden dass die initrd < 128MB sein muss damit es klappt, jedoch ist meine vor dem Entpacken schon 125MB, und nachher auf 148MB. Daher muss ich mal schauen wie ich die besser gepackt kriege

[MSfree]

Daher muss ich mal schauen wie ich die besser gepackt kriege

Mich wundert, daß die initrd bei dir überhaupt so groß ist, die normale initrd unter Buster ist so um die 35MB auf meinem Rechner, unter Jessie und Stretch sind sie sogar unter 20MB.

gzip -9 statt gzip -2 packt mit einer höheren Kompression. Ob das aber dein Problem löst, glaube ich nicht.

[Knogle]

Daher muss ich mal schauen wie ich die besser gepackt kriege

Mich wundert, daß die initrd bei dir überhaupt so groß ist, die normale initrd unter Buster ist so um die 35MB auf meinem Rechner, unter Jessie und Stretch sind sie sogar unter 20MB.

gzip -9 statt gzip -2 packt mit einer höheren Kompression. Ob das aber dein Problem löst, glaube ich nicht.

Ja das nervt mich gerade auch. Die XZ gepackte ist 32MB gross. Aber irgendwie klappt es dennoch nicht.
Sonst schmeiss ich mal wieder den 5.4.0 rc4+ Kernel drauf und mache das unter einem dort laufenden System (so habe ich es vor 1 Woche gemacht) Ich weiss nicht, irgendwas scheint wohl kapott zu sein wenn ich das Ding entpacke, oder wieder packe.
ggf. kann ich sonst mal meine initrd.img hochladen.

https://repo.openknogle.eu/initrd.img.bak

Diese ist 28MB gross und klappt so wie sie ist. (Das ist diese welche von mir erfolgreich modifiziert wurde zuvor, aber wo es jetzt nicht mehr klappt die auch nur zu entpacken / packen ohne dass diese kaputt geht)

[MSfree]

Du schreibst, daß die initrd kleiner 128MB sein muß. Woher hast du die Information?
Ist es sicher, daß sich die 128MB auf die gepackte Größe beziehen? Oder ist damit die entpackte Größe gemeint?
Gibt es vielleicht eine Option, mit der man beim Kernel bauen die Größe der initrd festlegen kann?

[Knogle]

Du schreibst, daß die initrd kleiner 128MB sein muß. Woher hast du die Information?
Ist es sicher, daß sich die 128MB auf die gepackte Größe beziehen? Oder ist damit die entpackte Größe gemeint?
Gibt es vielleicht eine Option, mit der man beim Kernel bauen die Größe der initrd festlegen kann?

Habe das in einem Forum gelesen wo sich der Post auf Kernel Version 2.6.x bezieht. Leider findet man zu dem Thema fast garnichts.
Werde mal schauen ob ich was in den Optionen finde, kann aber nicht sein dass die 32MB initrd es dann auch nicht mehr tut.

[MSfree]

Leider findet man zu dem Thema fast garnichts.

Deshalb hatte ich ja gefragt

Eventuell ist das hier für dich ja auch interessant:

https://unix.stackexchange.com/question ... our-kernel

Dabei geht es genau um dein Problem. Die selbst compilierten Kernelmodule haben noch ihre Symbolinformationen, die man nur braucht, wenn man den Kernel debuggen will. Die kann man von den .ko-Dateie mit dem strip-Befehl entfernern. Das soll die Module ca. Faktor 10 kleiner machen.

[Knogle]

Werde mir das mal anschauen!
Kommt man bei nem Kernel Panic und Live System eigentlich irgendwie an die Syslogs ran? Würde mich interessieren warum das Ding genau Crasht.

[MSfree]

Ich weiß nicht, ob man in deiner Situation noch sinnvolle Informationen aus dem gecrashten System bekommt. Wenn, dann mit SysReq:

https://en.wikipedia.org/wiki/Magic_SysRq_key

[Knogle]

Hallo! Bin weiter gekommen.
Habe die Aufloesung als Kernel Boot Parameter angegeben, und nun kann ich so sehen woran es liegt.
Angeblich ist das LZMA korrupt!
Hier habe ich mal das Bild hochgeladen

Gepackt habe ich es mal auf 2 verschiedenen Systemen, bei beiden das gleiche Problem. Werde jetzt mal unter eine Fedora Rawhide Live CD probieren.

https://repo.openknogle.eu/grub/Virtual ... _21_30.png

[MSfree]

Habe die Aufloesung als Kernel Boot Parameter angegeben, und nun kann ich so sehen woran es liegt.
Angeblich ist das LZMA korrupt!

Ich bin da auch ein wenig überfordert. Aber, wenn du die Ramdisk mit

Code: Alles auswählen

find | cpio -o -H newc | gzip -2 > ../initrd.gz

packts, ist das nunmal im gzip-Format. Der Kernel scheint aber LZMA zu erwarten.
Erstell doch erstmal eine unkomprimierte Ramdisk mit cpio:

Code: Alles auswählen

find | cpio -o -H newc > ../initrd.cpio

Danach kannst du die cpio-Datei mit unterschiedlichen Kompressoren packen, z.B. mit lzma:

Code: Alles auswählen

lzma -z -c  ../initrd.cpio > ../initrd.cpio.lzma

und gib dann diese .lzma-Datei dem Kernel als Ramdisk zu fressen.

[Knogle]

Habe beide Varianten schon probiert.
Habe den Kernel auch mit allen Dateitypen konfiguriert fuer die initrd.
Sonst muss ich mal bei Stackexchange fragen.

Ich packe gerade in einer VM in Fedora die initrd.img aber das ist schon gut ne Stunde am machen..

//EDIT:
Deine Variante klappt!!
Das Interessante: In Fedora Rawhide klappt die Variante aus dem Tutorial, unter meinem Debian 5.3er Kernel aber nicht. Wenn ichs in Fedora packe ist es nicht korrupt, unter Debian schon. Eigenartig.
Eigentlich sollten deine beiden Befehle ja das gleiche machen wie

Code: Alles auswählen

find . 2>/dev/null | cpio -c -o | xz -9 --format=lzma > /boot/new.img

Ich habe daher aus deinem Vorschlag folgenden Einzeiler konzipiert, der klappt auch so ganz gut.

Code: Alles auswählen

find | cpio -o -H newc | lzma -z -c  > ../initrd.img

Leider komme ich jedoch mit einer Eigenbau initrd nicht weiter, weswegen ich gerne die von Ubuntu Live 19.10 nehmen wuerde. (Da klappt das mit dem Maus/Keyboard Support)
Wenn ich GParted vom Netzwerk Boote habe ich da ebenfalls keinen Maus Support unter Gnome als auch Tastatur nicht.
Habe jedoch die jeweiligen initrds als Muster fuer meine genommen.
Jedoch ist die Ubuntu initrd ganz komisch gepackt, und ich kriege die nicht entpackt unter Debian 4.19, schon verschiedene Kommandos probiert.
Ist folgendes Format:

Code: Alles auswählen

file initrd
initrd: ASCII cpio archive (SVR4 with no CRC)