Hi !

Nachdem jetzt praktisch alle enigma2 Images bereits OE 1.5 basierend sind und damit auch unionfs verwenden wollte ich mit Euch mal die Funktionsweise des init binary auf /boot/bin diskutieren.

Schließlich macht das die eigentliche arbeit während dem booten das squashfs wieder mit dem delta durch den unionfs mount zusammenzuführen.

Daher wäre das auch der perfekte Platz um echtes Multibooten zu machen, bzw. so wie das binary derzeit arbeitet habt Ihr eigentlich das echte Multibooten wieder unterbunden

Grund ist, dass das binary wenn man sich den sourcode anschaut gnadenlos hardcoded /dev/mtdblock/3 also das root vom Flash mountet. Selbst wenn man über eine autorun.bat auf einer FAT Partition auf CF karte den Kernel bootet und dort auch die entsprechenden bin und lib directories hätte so wie thowi's Multiboot es tut, so wird dadurch eigentlich wieder dieser wenn auch kleine Teil des Flashes reingeschummelt.

Wobei das eigentlich völlig unnötig ist, man müsste ja nur den root= parameter aus dem autorun.bat file auswerten (was der Kernel sowieso tut)

Wäre es daher möglich das entsprechend anzupassen ?

Wenn Ihr wollt kann ich das auch machen, aber ich würde dann auch noch einen rootdir= parameter für die autorun.bat implementieren um auch booten von einem subdirectory auf dem jeweiligen root device zu gestatten.

Weil statt dann mühsam im Barry Allen mit chroot den init prozess auf einem Subdirectory einzusperren wäre es wesentlich eleganter das gleich durch entsprechendes mounten des subdirectories für das unionfs genau in diesem init binary zu erledigen.

Bitte um Feedback zu meinen Wünschen/Vorschlägen, und vieleicht auch um Aufklärung falls ich wie schon so oft was falsch verstanden habe.

LG
gutemine

Hi !

Eigentlich 2x daneben

Also ich habe schon seit fast Anbeginn der OE 1.5 Images den Barry Allen so implementiert das er per default das squashfs auch auf der CF Karte behält, und es gab bis jetzt keine Klagen deswegen. Erstens weil es dann weniger Platz braucht und du das image dann wieder als nfi file sichern kannst ohne mühsam das squashfs wieder zurückzurechnen - obwohl Barry Allen das auch kann (nur dauert es eine 3/4h)

Damit bleibt das unionfs auf CF Karte auch erhalten und keiner merkt einen Unterschied. Eigentlich läuft dann unionfs sogar 2x - einmal vom Flash während dem booten durch /boot/bin/init und nochmal von meinem bainit script das dann das squshfs und delta auf CF Karte zusammenmountet und mit chroot das init des images anwirft.

Dadurch hast du aber eigentlich 3 x init am laufen (von /boot/bin/init, dann als bainit shellscript und dann noch das init des images, mit 2 x chroot bzw. pivot_root - manchmal wundere ich mich selber das es funktioniert)

Und Multiboot kopiert wenn es von FAT auf Cf Karte bootet natürlich brav auch /boot/bin und /boot/lib in die FAT partition, was aber eigentlich nutzlos ist weil das init von boot es eben nicht benutzen kann - weswegen ich beim Multiboot auch immer noch das squashfs auf der CF Karte wegwerfen muss.

Daher würde es schon SINN machen das init auf /boot/bin nur um die paar codezeilen cleverer zu machen.

Wobei es eben 2 Sachen sind die ich mir wünschen würde:

1)

Wenn man im /boot/bin/init nicht fix /dev/mtdboot/3 mounten würde
sondern falls ein autorun.bat existiert so wie es gehören würde von dort das root= holen und auf /mnt/flash mountet (kernel macht das ja auch), dann könnte Multiboot auch von CF Kartenpartitionen OE 1.5 Images mit squashfs booten.

Ich denke wenigstens das würde sinn machen, weil dem secondstage loader das booten von FAT zu gestatten und dann aber wieder vom init den Flash zu mounten ist einfach ein Wiederspruch in sich.

2)

Wenn man auch noch einen rootdir= parameter im autorun.bat haben kann und dann einfach das mount vom squashfs aufs loopddevice und dann das vom unionfs um das directory aus diesem Parameter ergänzt (natürlich nur wenn der parameter und das entsprechende directory existiert), dann brauch sich Multiboot auch nicht mit den 14 Partionen auf CF karte quälen die nur das Handling fuchtbar kompliziert machen. UND es ist kein chroot mehr nötig, was das Leben auch um vieles leichter machen würde !

Dann würde ich einfach in den Barry Alllen support von /boot von FAT auf Cf Karte booten einbauen (für Leute die vom Flash gar nichts booten wollen) und Multiboot könnte endlich sterben !

Also um es kurz zu machen - nur ein paar codezeilen für Euch und viele neue Möglichkeiten die die derzeitigen Leiden des Multibooten auf der 7025 DEUTLICH reduzieren würden

LG
gutemine

ja das Ihr root=boot vergewaltigt habt hat mich anfangs schockiert bis ich verstanden habe warum Ihr es Euch auf diese Art einfacher gemacht habt (ich habe auch mit ramfs experimentiert und das ist einfach pervers es erst unnötig zu befüllen und dann wegzuschnmeissen wenn in /dev/mtdblock/2 ja eh jede Menge unbenutzter Platz ist).

Und genau das /boot kann man auch problemlos auf FAT haben damit das autorun.bat greift da ja nur eine handvoll files dafür benötigt werden.

Und ja, theoretisch könnte man dann das squashfs auch in /boot auf das FAT der CF Karte dazuschmeissen aber soweit würde ich gar nicht gehen(abfragen in code ob eines da ist und das dann verwenden kann man natürlich - wäre dann noch flexibler). Das squashfs file und das delta directory würden schön brav im rootdir= bleiben um den mount befehl im init simpel zu lassen - es würde enfach ins unionfs von /boot/mnt/flash/rootdir gemountet und das delta von /boot/mnt/squashfs/rootdir und schon wäre die Multiboot Welt viel schöner. Und wenn kein rootdir= angegeben ist bleibt eh alles wie es ist.

Du hast aber schon recht, dass der gesparte Platz bei den heutigen CF Kartenpreise kein Grund wäre squashfs zu behalten.

Es ist also eigentlich das Sichern der CF Images in ein nfi file das es sinnvoll macht das squashfs trotzdem zu behalten. Weil für das Rückrechnen des squashfs ist die CPU einfach furchbar schwach, wer wartet schon gerne eine 3/4h. Ich hatte beide Varianten im Barry Allen ausprobiert und auch implementiert und alle waren froh wie das squashfs behalten wurde.

Und das unionfs ist nicht so viel overhead das es wirklich wehtun würde, nur eben unötig 2x starten ist nicht so toll.

Wäre also nett wenn Ihr als ersten Schritt mal die Verwendung des ROOT_DEV einbaut (dann wäre Multiboot glücklich) und wenn das klappt ein ROOT_DIR für die automount.bat (dann wäre Barry Allen glücklich).

Danke Euch im voraus für ein boottool 1.1 ipk !

LG
gutemine

Kleiner Update:

Ich habe halt mal Wally West die FAT Erweiterung zum Barry Allen in den Test geschickt, damit Ihr besser seht was ich gerne hätte.

Der Wally West macht es aber noch konventionell solange kein neues init da ist. Damit hat man weitehin /dev/mtdblock/3 vom Flash am Hals nur um das loopdevice und den squashfs und unionfs Treiber zu laden - kernel und alle anderen Treiber kommen vom Image auf CF im /media/ba/ba/imagename directory des ext3 über ein zweites chroot.

Sobald es ein /boot/bin/init gäbe das auf root=/dev/sda2 (=2. Partiton auf Cf karte in EXT3 - die erste ist ja /boot als FAT) und /rootdir=/ba/imagename reagieren würde (also auf /mnt/flash das /dev/sda1 mounten würde und dann /mnt/flash/ba/imagename als quelle für squashfs und delta fürs unionfs verwenden würde) könnte ich es mit ein paar codezeilen im Wally West entsprechend umstellen und wir hätten echtes Multibooten auch wieder mit OE 1.5 Images).

Ohne rootdir= parameter müsste man dann halt wieder mit /dev/sda5..17 arbeiten so wie beim Multiboot - was auch besser wäre als es jetzt ist.

LG
gutemine