RootFS: von Compressed zu Uncompressed

[embert (Gast)]

Hallo,


mir ist der ganze Linux Boot-Prozess noch nicht ganz klar, und vorallem 
die verschiedenen Varianten ein Root-Filesystem zu laden verwirren mich.

Fangen wir bei meinem aktuellen Fall an:

Mein Embedded-System wird von dem Hersteller mit einem Linux-Image, 
devicetree.dtb und uramdisk.cpio.gz ausgeliefert.

Nachdem ich die uramdisk.cpio.gz um Programme & Libs erweitert habe, ist 
dieses plötzlich zu groß ist und kann nicht mehr richtig geladen werden.
Zur Lösung müsste ich wohl den Kernel neu bauen und BLK_DEV_RAM_SIZE 
größer setzen. (Angeblich kann man das auch über U-Boot Prompt 
erreichen, aber das hat bei mir nicht funktioniert.)

Wie dem auch sei, ich finde die Sache mit dem komprimierten RootFS sehr 
umständlich und ich würde gerne auf ein unkomprimiertes Dateisystem 
wechseln.
Ich kenne das so, dass auf einer FAT-Partition Boot-Dateien, Linux-Image 
und Devicetree sind, und auf einer EXTx befinden das Linux Dateisystem 
in unkomprimierter Form.

Und jetzt brauche ich Hilfe: Was muss ich wo ändern, damit beim Boot das 
unkomprimierte Dateisystem erkannt und geladen wird?

[Lukey S. (lukey3332)]

Müssen die zusätzlichen Programme und Libs unbedingt in der initrd sein? 
Oder ist das nen System komplett ohne "festes" Dateisystem auf ner 
eigenen partition?(Wie es bei vielen Routern der Fall ist)

[Wurzel (Gast)]

root=/foo/bar in der kernel cmdline

[c.m. (Gast)]

auf x86 systemen:

1. der bootloader (grub z.b.) lädt den kernel UND eine initial ramdisk 
(initrd, gerne .gz, oder .cpio) in den speicher.
2. der kernel wird gestartet, und über parameter weiß er wo seine initrd 
ist (kernel boot parameter).
3. der kernel reserviert speicher, um die initrd zu entpacken - das 
entpackte image darf nicht größer sein wie im kernel "einkompiliert" 
angegeben.
4. der kernel führt in der entpackten ramdisk init aus, das wiederum 
diverse startskripte (z.b. lade kernel module die nötig sind um 
massenspeicher zu erkennen)
5. der kernel sollte die restliche hardware erkannt haben, und wechselt 
über "pivot-root" in das echte root-filesystem (festplatte) - von da aus 
wird normal weiter gestartet.

[c.m. (Gast)]

noch was:

das ganze ramdisk-geraffel kann man sich sparen, wenn man in den kernel 
die treiber für die speicherhardware (ide/scsi/sata-controller) fest 
einkompiliert.
habe ich bei gentoo damals(tm) immer so gemacht.

bis ich dann verschlüsselte root-dateisysteme haben wollte… da gehts 
dann wieder nicht ohne /boot partition und initrd.

[Jim M. (turboj)]

c.m. schrieb:
> das ganze ramdisk-geraffel kann man sich sparen, wenn man in den kernel
> die treiber für die speicherhardware (ide/scsi/sata-controller) fest
> einkompiliert.

Der OP redet von U-Boot. Das verwendet man üblicherweise auf nicht-X86 
Plattformen, die nur selten IDE/SATA haben.

Außerdem will man dort das RootFS nicht vom lahmen Flash ausführen,
der für ein unkomprimiertes Rootfs oftmals noch zu klein ist.

Ohne weitergehende Infos vom OP über die Hardware ist das also nicht 
zielführend.

[embert (Gast)]

c.m. schrieb:
> 4. der kernel führt in der entpackten ramdisk init aus, das wiederum
> diverse startskripte (z.b. lade kernel module die nötig sind um
> massenspeicher zu erkennen)

Gut, hab das soweit verstanden.

Die Ramdisk.gz ständig zu vergrößern ist also gar nicht der bevorzugte 
Weg, sondern man sollte tatsächlich sein eigenes Rootfs 
"nebendranlegen", nicht?

Kann ich jetzt einfach eine zweite Partition in ext4 Format erstellen?
Wird die automatisch erkannt, oder muss ich da noch was in /etc/init* 
(oder so) ändern?