[Fli4l_dev] fli4l 3.9.0-r30484 Tests am OPT_HD

[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?

> 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.

Richtig. Das gilt allgemein aber nur für Bootmedium != Installationsmedium. 
Ich habe jetzt die Dokumentation nicht gelesen, evtl. besteht da 
Verbesserungsbedarf. 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.

> 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.

> @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).


Danke und Gruß,
-- 
Christoph Schulz
[fli4l-Team]