OS: Firmware Update auf CF-Card

In Deiner Beschreibung ist die Funktion des Bootloaders etwas wirr (das 
ist das Ding, das das OS startet, nicht etwas, was vom OS gestartet 
wird), aber deine Annahmen, wie man ein unter XPe laufendes 
Windows-Programm aktualisieren kann (durch Austauschen der Exe-Datei) 
sind korrekt.

Das Verzeichnis, in dem diese Datei liegt, darf natürlich dann nicht vom 
FBWF geschützt sein (sonst ließe sich die Datei nicht überschreiben).

Die Exe-Datei darf aber beim Austauschen nicht in Verwendung sein, was 
sich aber lösen lässt. Das OS (bzw. das, was Du mit "Bootloader" 
vermutlich meinst) kopiert beim Starten die auszuführende Datei vom 
Verzeichnis X in das Verzeichnis Y und ruft sie aus dem Verzeichnis Y 
auf. So kann die Datei im Verzeichnis X zur Laufzeit durch eine andere 
ersetzt werden, die dann beim nächsten Systemstart automatisch 
ausgeführt wird.

Um nicht bei jedem Systemstart (unnötig) zu kopieren, kann auch als 
erster Schritt ein Vergleich der Dateien in den Verzeichnissen X und Y 
erfolgen und nur bei Unterschieden das Kopieren angestoßen werden. An 
dieser Stelle lässt sich auch ein Überprüfungsmechanismus einbauen; im 
Verzeichnis X liegt zusätzlich zur eigentlichen Exe-Datei noch eine 
Prüfsummendatei, die beim Update durch den Anwender ebenfalls dorthin 
kopiert wird.

Der Kopiervorgang wird nur durchgeführt, wenn die Prüfsumme der Datei 
der in der Prüfsummendatei entspricht.

Gewiss, Du musst irgendeinen Mechanismus nutzen, damit das 
Betriebssystem noch was anderes tut als darauf zu warten, daß Du ihm 
sagst, was es zu tun hat.

Aber der Begriff "Bootloader" hat eine eindeutige und komplett andere 
Bedeutung - das ist ein Stückchen Firmware, ähnlich dem BIOS im PC, das 
in Embedded-Systemen nach dem Reset über eine Schnittstelle einen 
Programmdownload ermöglicht. Das ist z.B. die BSL-Schnittstelle im 
MSP430, oder SAM-BA bei ARMen von Atmel.

Ein "normales" Windows startet als letztes entweder den Login-Prozess, 
der darauf wartet, daß sich ein Benutzer interaktiv anmeldet, oder (bei 
automatischer Anmeldung) den Explorer als "Shell", der in diesem Fall 
das Startmenü und die Taskleiste darstellt, sowie den restlichen 
Desktop.

Das lässt sich ersetzen, in der Registry gibt es (irgendwo unter 
SessionManager) einen Eintrag, welcher Prozess nach erfolgter 
Benutzeranmeldung auszuführen ist.

(Details kann ich Dir im Moment nicht beschreiben, da hier gerade kein 
Windows-Rechner ist).

Das funktioniert bei XPe genauso, je nach Umfang der zum Image gepackten 
Komponenten.

Und das ist die Stelle, an der Du Deinen "Programmstarter" einbauen 
kannst, der sich dann so verhalten kann, wie von mir weiter oben 
beschrieben.

Nein, das war bei der Anwendung, für die ich XPe verwendet habe, kein 
Thema. Das waren Stand-alone-Systeme ohne Internetanbindung, und für ein 
Softwareupdate wurden manuell neue Dateien auf die enthaltenen CF-Karten 
kopiert.

Ist auch schon ein paar Jahre her.

Johannes schrieb:

> Suche ich einfach auf der CF-Card nach der Programm-Exe und ersetze
> diese durch die neue? Und gibt es hier z.B. auch Schutzmaßnahmen wie man
> eine kurrupte Datei erkennt (falls beim Ersetzen der Exe ein Fehler
> passiert - z.B. User trennt das Gerät vom Strom); so dass dieses Datei
> beim nächsten Start nicht automatisch geladen wird vom Bootloader?

Was willst Du updaten können - nur die Applikation oder auch das 
Betriebssystem selber? Was machst Du, wenn die Festplatte in Deiner 
Maschine hinüber ist?

Die radikale Lösung lautet Imaging. Du hast ein Mustersystem. Davon 
ziehst Du ein Festplattenimage. Leere Blöcke (nur mit 0 gefüllt) kannst 
Du dabei überspringen. (vorher Platte mit sdelete -c c: säubern, sdelete 
ist Teil der Sysinternals Suite). Dann bootfähige Cd oder Image machen 
mit einem FreeDOS, einem DOS-Imagetool und Deiner Imagedatei. User zieht 
sich das Image, packt es auf ein bootfähiges Medium und bootet den Kiosk 
von diesem Medium. Den Rest macht dann Dein Imagetool.

Bei Einzeldateien:
Pfad und CRC der zu ersetzenden Dateien speichern, dann weißt Du sicher, 
dass Du die richtigen Dateien hast und kannst die ersetzen.
Bei weiteren Updates muss der User entweder alle älteren Updates 
nacheinander anwenden, oder Du musst eine Liste mit den CRCs aller 
Vorversionen mitführen.

fchk

Johannes schrieb:
> Frank K. schrieb:
>> Was willst Du updaten können - nur die Applikation oder auch das
>>
>> Betriebssystem selber?
>
> Sowohl als auch; bei kleineren Updates nur die eigentliche Applikation
> und bei größeren (falls auch mal Erneuerungen im OS) anstehen, natürlich
> das komplette Image.
>
> 1) komplettes Image:
> Wenn ich als Filesystem NTFS verwende, müsste ich auf eine bootfähige CF
> Card verzichten können, oder? Ist glaub ich nur bei FAT32 ein Thema.

Wieso? Wenn User das Filesystem geschrottet hat und die Kiste nicht mehr 
hochfährt, was macht User dann? Dummes Gesicht. Und weiter?

> Der
> User würde das Image z.B. auf einen USB-Stick packen. Mit "Imagetool"
> meinst du ein kleines Programm, welches anschließend die Daten (das
> Image) auf die CF kopiert und anschließend einen Reset durchführt, so
> dass der FBA gestartet wird um das Image zu installieren?

Nein. Du mußt immer damit rechnen, daß User die Kiste kaputtspielt. 
Sprich: Von der eingebauten Platte/SSD bootet das Teil nicht mehr. Dann 
muss User in der Lage sein, die Kiste wieder hochzuziehen, und dafür 
braucht er ein bootfähiges Bootmedium mit einem Plattenimage. Auf dem 
Bootmedium des Users ist dann ein Programm darauf, das das Image vom 
Bootmedium auf die Platte schreibt, und zwar sektorweise, ohne Rücksicht 
auf Filesystem oder Partitionen oder sonstwas.

Machst DU das nicht, hast Du nachher Servicefälle.


> 2) nur Applikation:
> Macht es hier z.B. Sinn eine MSI-Datei zu verwenden, und in diese die
> eigentliche Exe-Datei und eine Prüfsumme CRC zu packen? Der User sollte
> lediglich zu Beginn das Verzeichnis bzw. die Datei auswählen und
> anschließend auf Update klicken (mehr nicht!). Danach muss alles von
> allein laufen ohne User-Eingaben etc.

Kannst Du machen. Dann muß Deine Anwendung aber als MSI regelgerecht 
installiert worden sein, und was Du dann verteilst, sind dann keine .msi 
Dateien, sondern .msp Dateien, bei denen der Windows Installer prüft, ob 
da vorher schon das zugehörige .msi installiert ist.

> Frank K. schrieb:
>> Bei weiteren Updates muss der User entweder alle älteren Updates
>> nacheinander anwenden, oder Du musst eine Liste mit den CRCs aller
>> Vorversionen mitführen.
>
> irgendwie steh ich da graf auf`m schlauch; also schön wäre es, wenn der
> user nicht alle älteren Updates nacheinander installieren muss, sondern
> nur das letzte. Ein CRC gibt doch erst einmal darüber Auskunft, dass die
> Datei zu dem der CRC gehört, der Prüfsumme entspricht und somit nicht
> ausgetauscht worden ist

genau. Wenn die Datei aber in früheren Updates schon einmal geändert 
worden ist, dann weißt Du erstmal nicht ob User da schon ein Update 
installiert hat und wenn ja welches. Daher brauchst Du in diesem Fall 
eine Liste mit den CRCs alle möglichen Vorversionen.

> ; allerdings gibt es jetzt noch den Fall, dass
> eine ganz andere Datei als Applikation herangezogen wird mit dem
> dazugehörigen CRC.

Wenn ein Updater für eine App gestartet werden sollte, die nicht 
installiert ist, sollte er die zu updatenden Dateien gar nicht finden, 
oder?

Deine Idee, die Applikation als .msi zu installieren und anschließend 
nur noch .msp's rauszugeben, ist gut. Da sorgt nämlich der 
Windows-Installer dafür, daß das idiotensicher ist. Vorausgesetzt 
natürlich, daß der Windows Installer im XPE Image enthalten ist.

fchk

Johannes schrieb:
> Frank K. schrieb:
>> Bootmedium des Users ist dann ein Programm darauf, das das Image vom
>> Bootmedium auf die Platte schreibt, und zwar sektorweise, ohne Rücksicht
>> auf Filesystem oder Partitionen oder sonstwas.
>
> Kennst du bereits ein solches Programm? Schließlich hat ja jeder dieses
> Problem;

Ghost, DriveImage, ... der Markt ist voll davon, aber Du brauchst was, 
was keine GUI hat und automatisch abläuft und unter DOS - ich würde da 
ganz stumpf was selber schreiben. So schwer ist das nicht. INT13 läßt 
grüßen.

> Frank K. schrieb:
>> genau. Wenn die Datei aber in früheren Updates schon einmal geändert
>> worden ist, dann weißt Du erstmal nicht ob User da schon ein Update
>> installiert hat und wenn ja welches.
>
> ok, dann hatte ich das zuvor falsch verstanden; im Prinzip muss ich
> vorneweg wissen, welche Version bereits auf dem System vom User
> vorhanden ist und anhand dessen kann / wird dann entschieden ob das
> aktuelle Update installiert werden kann oder nicht. Dann sollte es auch
> so gehn, dass auf dem System selbst eine Datei .txt oder ähnliches
> existiert, in der die aktuelle Firmware Version etc. abgespeichert ist
> und im MSI File existierit ebenfalls eine Datei, die die Voraussetzungen
> für die Installation beinhaltet -> beide vergleichen und entscheiden ob
> das Update durchgeführt werden soll oder nicht?

Das sind zu viele Vorbedingungen, als das das zuverlässig laufen wird. 
Was machst Du, wenn User die Versionsdatei löscht, weil "wird ja nicht 
benutzt"? Der einzige Weg ist, daß Du Dir Deine Dateien anschaust und 
daraus ableiten kannst, ob die (a) gültig und (b) aktuell ist.


> Frank K. schrieb:
>> Wenn ein Updater für eine App gestartet werden sollte, die nicht
>> installiert ist, sollte er die zu updatenden Dateien gar nicht finden,
>> oder?
>
> Hatte es mir so vorgestellt, das der User zu Beginn selbst den Ort
> angeben kann wo sich die Updater-Datei befindet (z.B. in einem
> Verzeichnis von einem USB-STick); eine .msi Datei besitzen ja jetzt
> mehrere Applikationen so dass ich da noch nicht selektieren kann, dass
> nur meine .msi Datei angezeigt wird; d.h. das muss zu Beginn des
> Installations-Prozesses irgendwie überprüft werden können? Gibt es da
> einschlägige Vorgehensweisen?

Die von MS für diesen Zweck vorgesehene Vorgehensweise ist die 
Verwendung eines .msi *allein für die Erstinstallation(!)* und 
anschließend nur noch .msp's für Updates. Ansonsten gibt das Bruch, wenn 
die Applikation wieder ordnungsgemäß deinstalliert oder reinstalliert 
werden soll, weil die Datenbanken des Windows Installers sonst nicht mit 
aktualisiert werden.

> Frank K. schrieb:
>> Deine Idee, die Applikation als .msi zu installieren und anschließend
>> nur noch .msp's rauszugeben, ist gut. Da sorgt nämlich der
>> Windows-Installer dafür, daß das idiotensicher ist.
>
> Denn Windows-Installer (hab ich mir bis jetzt noch nicht so genau
> angeschaut) wird wahrscheinlich auch so zu konfigurieren sein, dass nur
> ein Fortschrittsbalken angezeigt wird und nicht mehr. So dass keine
> weiteren Usereingaben etc. möglich sind bzw. von nöten sind.

Genau.

Wenn Du .msp-Dateien erzeugst, brauchst Du Dich um nichts weiter zu 
kümmern, das macht der Windows Installer für Dich.

Johannes schrieb:

> Hab heut mal versucht nach Informationen zu suchen bezüglich des Bootens
> von USB-Stick. Also den Stick ansich bootfähig für DOS zu machen, hat
> geklappt. Hab hier erstmal das HP-Tool verwendet. Anschließend befinden
> sich dann die Dateien: Command.com, IO.sys und MSDOS.sys auf dem Stick.
>
> Kann man auch einen bootfähigen USB-Stick mit NTFS erstellen?

Nein, bzw nicht so einfach. Denk dran, Du bootest ein DOS, und dos kann 
das nicht.

> Dann hab ich gelesen wird anscheinend die Datei "Autoexec.bat", die man
> selbst erstellen kann, automatisch vom DOS-System beim Booten gestartet.

> D.h. innerhalb so einer Batch-Datei müsste ich dann zuerst die CF-Card
> formatieren und ebenfalls wieder bootfähig machen? Bis jetzt mach ich
> das immer über das Windows-Tool, welches ebenfalls über die CMD
> gestartet wird.
>
> Und anschließend muss der eigentliche Inhalt von dem USB-Stick auf die
> CF-Card kopiert werden.
>
> xcopy sourcepath destinationpath /e
>
> Danach einfach einen Reset durchführen und den FBA von CF-Card starten?

... und schon hast Du die langen Dateinamen verloren, denn die kennt DOS 
auch nicht. Merkst Du jetzt, warum ich nicht von dateiweisem Kopieren,
sondern von sektorweisem Kopieren schrieb? Da ist es nämlich egal, was 
DOS kann und was nicht, denn stumpf Sektoren auf eine Platte schreiben, 
das kann es.