[Fli4l_dev] Probleme beim ?==?utf-8?Q?Erstellen von USB-Bootmediu?==?utf-8?Q?m

[Christoph Schulz]

Hallo!

Klaus Dreier schrieb am So, 09 August 2015 14:58
> Hallo zusammen,
> 
> wenn ich einen USB-Stick formatiere bzw. auf einem bereits
> formatierten (und von z.B. r36861 verwendeten Stick)  schlicht die
> Dateien lösche, dann bekomme ich in beiden Fällen bei r40784 via
> mkfli4l.bat einen Fehler, wenn ich nach dem build via autoit3 (Windows
> 7 Maschine) die Dateien übertragen lasse als Teil vom Erstellen:
> "Error writing to disk (HD-pre-install)!". Abbruch. Log file sagt
> nicht mehr aus. Die Dateien wurden aber im build-Ordner erstellt. Wenn
> ich sie einfach von Hand rüber kopiere, bootet der Stick nicht,
> obwohl die Dateien kopiert wurden.


Könnte eine Regression im Rahmen von FFL-1454 und FFL-1444 sein. Ich
habe das neue AutoIt unter Windows XP ausprobiert, da ging die
Installation auf ein Bootmedium ohne Probleme, wenn man mkfli4l.bat
unter einem Benutzerkonto mit Administrationsrechten gestartet hat.
Windows 7 und neuer kann ich leider zur Zeit nicht testen.

Zitat:
> Faktisch also kann ich mit r40784 kein (USB-)Boot-Medium erstellen.
> Denn: wenn ich via r36861 z.B. ein funktionierendes Boot-Medium
> erstelle und dann mittels mkfli4l.bat von r40784 einen Build laufen
> lasse, dann gibt es zwar keine Fehlermeldung mehr und die Dateien
> werden übertragen (sieht man u.a. am timestamp), jedoch gibt es beim
> Booten ganz komische Geschichten: erstens das USB-Problem (siehe
> anderen Thread) und zweitens meldet sich fli4l dann als die auf der
> HDD installierte Version r36861, jedoch mit dem 4.1.3-Kernel usw
> (bootet definitv nicht von HD, denn die ist deaktiviert im Bios bzw.
> ein Mal sogar abgehängt). Hinzu kommt, wenn ich eine barebone r40784
> ohne OPT-HD etc auf den Stick baue, dann will er trotzdem die HDD
> einbinden - wo bitte bekommt er denn die Idee? Irgendwo also liegen da
> alte Daten auf dem Stick von der r36861. Beim Erstellen jedenfalls
> läuft gewaltig was falsch.
> 
> Was könnte hier sein?


Wenn die Platte ausgehängt ist, kann der Kernel sicherlich nicht auf
alte Images zugreifen. Das würde somit bedeuten, dass dein Bootmedium
eben nicht ordentlich erstellt wurde. Alles andere ergibt keinen Sinn.
Was meinst du mit "meldet sich fli4l dann als die auf der HDD
installierte Version r36861"? Geht es dir um den Prompt in der Shell?
Die Versionsnummer ist Teil des OPT-Archivs, während der Kernel Teil
des RootFS-Archives ist. Sind diese beiden Archive wirklich aktuell? Und
ist die Platte beim Booten wirklich ausgehängt? Ein Deaktivieren im
BIOS ist u.U. nicht sehr sicher, wenn der Linux-Kernel den Chipsatz
kennt, weil der Kernel ja am BIOS vorbei operiert. Und wenn du eine Typ
B-Installation mit eigenständiger opt-Partition nutzt und das
opt-Archiv vom Bootmedium nicht entpackt wird (weil es fehlt, korrupt
ist o.ä.), dann nutzt du automatisch die beim letzten erfolgreichen
HD-Boot entpackte Fassung unter /opt. Das würde dieses Mischmasch (alte
Versionsnummer, neuer Kernel) erklären.


Viele Grüße,

-- 
Christoph Schulz
[fli4l-Team]