[Fli4l_dev] fli4l 3.9.0-r30484 Tests am OPT_HD

[Helmut Backhaus]

Moin Christoph!
Keine Angst, ich ignoriere Dich nicht!

Am 30.03.2014 21:08, schrieb Christoph Schulz:
 > Hallo!
 >
 > Helmut Backhaus schrieb:
 >
 >> Hallo,
 >> wie versprochen hier einige Anmerkungen zu den gewünschten Tests.
 >
 > Super!
 >
 >> Statt der CF habe ich nun auch noch einen USB Stick versucht, dass hat
 >> aber nicht funktioniert. Als Bootmedium ging es, die Installation lief
 >> auch durch, aber ein Booten von diesem Stick wurde abgebrochen da die
 >> Bootpartition nicht gemountet werden konnte.
 >
 > Gibt es irgendwelche Meldungen, die du uns mitteilen könntest? Oder ein
 > Verweis auf ein Bildschirmfoto?

Ja ne, dass war mir klar, dass das kommt. Im Moment müsste ich es 
abtippen oder wirklich ein Foto machen. Aber mir ist so, als wenn es 
eine Möglichkeit gab, ein Bootlog einzuschalten. Ich bin der Meinung, 
dass es dieser Parameter war:
DEBUG_STARTUP='yes'

Dann wurde eine Datei boot.txt, boot.log oder so ähnlich nach / oder 
/boot geschrieben. Aber ich finde dann nur eine Datei
/boot/persistent/boot_upd.log und da steht nicht wirklich etwas drin.

Ich überlege aber auch gerade, ob mir eine serielle Konsole weiterhilft. 
Ich glaube schon!
Das werde ich gleich mal Testen.

 >
 >> Nächster Test war nun CF 2 GB als Bootmedium und eine HD 40 GB (ATA) als
 >> Installationsmedium.
 >> [...]
 >> Hierbei ist mir aufgefallen, dass nach dem hdinsall.sh ja ein
 >> Remoteupdate gemacht wird (so habe ich es oben gemacht) und dann erst
 >> der Reboot erfolgen soll.
 >

Also, zunächst einmal, dieses Verhalten führt ja zu keinem Datenverlust!
Man muss das Update nur noch einmal wiederholen, bzw. gleich nach dem 
Reboot machen.

 > Richtig. Das gilt allgemein aber nur für Bootmedium != 
Installationsmedium.

Nur das Update landet *_NICHT_* da wo es hin soll, müsste!
Richtig?

 > Ich habe jetzt die Dokumentation nicht gelesen, evtl. besteht da
 > Verbesserungsbedarf.

Dabei möchte ich ja gern helfen, dass ich dabei nun zum exzessivem 
Tester geworden bin ist nun mal so. Wenn es meine Zeit erlaubt, mache 
ich das gern!
Ich hoffe nur, dass nicht irgendwann der Tag kommt an dem Du bereust 
mich danach gefragt zu haben. Ich kann bei so etwas ziemlich penetrant 
sein. Wenn es zu schlimm wird, einfach sagen, ich kann das ab! :-))

 > Der Punkt ist: Wird eine Festplatte bzw. ein
 > "Festplatten-artiges" Speichermedium mit mkfli4l vorbereitet und dann am
 > fli4l umpartitioniert, ist ein Remote-Update nicht _zwingend_ nötig, weil
 > die Boot-Dateien und dort im Image die Festplattentreiber für den Boot-
 > Vorgang ja schon vorhanden sind und augenscheinlich funktionieren. 
Falls man
 > jedoch auf ein _anderes_ Medium installiert und z.B. von CD bootet, 
dann ist
 > das _nicht_ der Fall (das Installationsmedium ist leer), und man braucht
 > _zwingend_ ein Remote-Update, welches dann den Kernel und die nötigen
 > Archive aufspielt.
 >

OK, soweit verstanden, aber warum wird an der Stelle wieder das 
Bootmedium gemountet und die Daten aus dem Ram wieder dort hingeschrieben?

 >> Bei dieser Vorgehensweise, wird dass Update
 >> auf das *_BOOTMEDIUM_* geschrieben! Auf der erstellten HD ist dann
 >> weiterhin die "hdinstall Variante" die von der CF kopiert wurde. Ein
 >> erneutes Remoteupdate (nach dem Reboot) schafft hier Abhilfe.
 >> Habe ich da etwas aus der Doku falsch verstanden?
 >
 > Nein, das ist ein Fehler. Ich werde ihn für den nächsten Tarball
 > korrigieren. Das Problem ist, dass wenn /boot vorher eingehängt war, 
es nach
 > der Installation auch wieder eingehängt wird, und zwar _immer so, wie es
 > vorher war_. Das ist aber bei einer Installation, bei der Bootmedium !=
 > Installationsmedium ist, Quatsch. Das muss ich noch korrigieren.
 >

Ah, dann vergiss die Frage von oben. Ich wollte schon mit den 
Berechtigungen Testen und mal sehen, was passiert. Also:
MOUNT_BOOT='rw'                # mount boot device (floppy): ro, rw, no


 >> @Christoph:
 >>
 >> Magst Du das hier noch einmal etwas genauer beschreiben:
 >> -->
 >> gefüllte Datenträger, Datenträger mit nur einer Boot-
 >> Partition, verschiedene Partitionsgrößen... mir fällt da vieles ein ;-)
 >> <--
 >>
 >> Zum Teil habe ich das ja wohl schon gemacht, aber Das mit "nur einer
 >> Boot-Partition" und "vieles" ist mir nicht ganz klar. :-)
 >
 > Nun ja, die Idee war, dass man im Preboot-Kontext (Bootmedium =
 > Installationsmedium) auch Datenträger fürs erste Booten verwendet, die
 > tatsächlich mehr als eine Partition haben (und wo die anderen Partitionen
 > dann auch tatsächlich zerstört werden).
 >

Ah, ok auf die Idee war ich noch gar nicht gekommen. Das werde ich dann 
auch noch mal Testen. Ich kann aber noch nicht versprechen, wann ich 
dazu kommen. Ich hoffe am Wochenende.

OK, so weit erst mal. Noch eine schöne Woche!!


-- 
Gruß,
Helmut