[Info] Boot Manager für 7490

Edit:
Ich habe jetzt einen Bericht erhalten, daß bei einer 7490 mit originaler Firmware 06.05 die Umschaltung zwischen den zwei Partitionen noch nicht benutzt wird. Das würde dann auch erklären, warum das vorher nie aufgefallen ist und es sonst noch niemand zur Umschaltung auf das letzte System verwendet hat. Eine ähnliche Meldung liegt für die 7362SL ja auch vor. Das gibt der Vermutung, AVM würde das im Zuge des Auto-Update bei den Boxen, wo der Flash-Speicher für "Hot-Flash" ausreichend groß ist, Zug um Zug einführen, wieder neue Nahrung.

tl;dr:
Umschalten zwischen den zwei letzten installierten Firmware-Versionen bei einer 7490 mit einem Shell-Skript
- einfaches Hin- und Herschalten zwischen verschiedenen Firmware-Ständen
- Sichern von Einstellungen des laufenden Systems getrennt von den Einstellungen des Systems in der anderen Partition
- optionale (und anpassbare) Wiederherstellung der Einstellungen des alternativen Systems bei der Umschaltung, praktisch zwei "Sätze" von Einstellungen
Außer dem Skript werden keine zusätzlichen Binaries benötigt.

Im Rahmen von Tests der 7490 ist nun auch ein Shell-Skript entstanden, mit dem man die 7490 zwischen zwei installierten System umschalten kann. So läßt sich dann z.B. bei einem Freetz-Image die Frage, ob ein bestimmtes Problem mit originaler AVM-Firmware auch auftritt, auch mal auf die Schnelle klären und der Test einer neuen Laborversion erfordert auch bei "Nichtgefallen" nicht unbedingt ein Downgrade mit Werksreset und allem, was sonst dazu gehört.

Dazu muß man nur das Skript irgendwie auf die Box bringen und ausführbar machen, um sinnvollerweise schon im "alten" System das erste Mal die Einstellungen zu sichern.

Selbstverständlich braucht man auch einen Shell-Zugang zur Box, um es zu benutzen (SSH oder Telnet).

Das Skript steht unter http://www.yourfritz.de/bootmanager_7490.tgz als tar-Archiv bereit, wer lieber eine sofort ausführbare Variante will, kann dafür die URL http://www.yourfritz.de/bootmanager_7490 benutzen. Die Hash-Werte für das Skript sind (auch in der Datei checksums im tar-File noch einmal enthalten):

Code:

MD5: 05569228d0d014501ae4fbe0664e30ef
SHA-1: 18167e49f9b0e9b7d3f426a9498a30bac16a214b
SHA-256: c97cf58c6928ce6130312c4582bee5e870fe770a09cec34c2eef9bbbe7ea16e7
SHA-512: 5ef020d1196dbfee0f6abc5aadc8bcb4f6d32610f3f6a5a61244efcd0be6e01ebe08fc0276f51e15b2dd6311239d76bcfe3f7e64ee4e10246dfa40ce84418b1c
SHA3-256: 6cebb85c434736730da8ca9d959498945098a9b124d9242518fd574fb02eb161
SHA3-512: d3c85d833eb455186ac442771154fc075dd87b35301da589da47c384df941266a3b4a2358ab2f01fd98e10005fb27770543b334d7d200a141a8fa5807db1210e

und für das tar-File - wenn man das gesondert prüfen will:

Code:

MD5: 4efac7102605fb1cd56f7ce9e837de0b
SHA-1: 01f6c00fb327dd27265aad3ebf103f5781e3efa3
SHA-256: a9cb4175e2daff4cba01d8251d2a71aa39e736c266011dda64388fd5a76d1ec5
SHA-512: f72ab8e05f9e5db7e2e658cb836d58825a7f62598183e1be024e09cfebbf3aaa6c7227996df01a8f3de2d7f95a948a23f97c228cf4e499663238d1dce1187857
SHA3-256: 564cedc7759278641b1ac9d689180ade026be374a40e94b26a9065095dcee04b
SHA3-512: a18228ccfad53eda6ecf75d155be749a991a4f496578c31c48d7b31dcf0562ec8a81674d43e1a49d6c9642abc0e8661afbefdf0bddc8848d0a4aa40da3d745b7

[EDIT] 14.02.2016:
Der ganze Aufwand mit dem Hash-Code bringt nur etwas, wenn den auch jemand verifiziert ... nach dem Umzug zu GitHub (https://github.com/PeterPawn/YourFritz/tree/master/bootmanager) kann man das dort lesen und die eigene Datei von meinem Server mit der bei GitHub veröffentlichten vergleichen. Bis ich eine Möglichkeit zum Signieren solcher Sachen gefunden habe (mit den Tools, die das FRITZ!OS on-board hat), fällt der Hash-Aufwand ersatzlos weg.
[/EDIT]

Für ganz eilige - die auf die Kontrolle des Hash-Wertes verzichten wollen (nicht empfohlen) - wäre das dann z.B. dieser Einzeiler:

Verwendung:
Bevor man das Skript auf einem neuen System benutzt, empfehle ich den Aufruf von "bootmanager_7490 test", um das Vorhandensein aller vom Skript erwarteten Kommandos in der AVM-Firmware zu verifizieren und den generellen Aufbau der MTD-Partitionierung zu prüfen. Nur wenn dabei keine Problem auftreten, stimmen die im Skript getroffenen Annahmen. Sollte das auf einer 7490 nicht der Fall sein, bin ich sehr an den genauen Ergebnissen für die betreffende FRITZ!Box interessiert.

Ansonsten einfach ohne Parameter starten und die Ausgaben auf der Konsole lesen. Zuerst wird die Version des laufenden Systems ermittelt und angezeigt, genau wie die dafür verwendeten Flash-Partitionen und der Hash-Wert des root-Filesystems. Mit diesem Hash-Wert wird auch gleichzeitig die Zuordnung von gesicherten Einstellungen zu einer Firmware-Version vorgenommen, d.h. das Skript unterstützt den automatischen Austausch von Einstellungen nur dann, wenn dieser Hash-Wert mit dem als Teil des Dateinamens einer Sicherungsdatei hinterlegten übereinstimmt. Was jeder darüber hinaus mit den gesicherten Einstellungen anfangen kann oder will - oder ob er sie auch bloß vom Skript wie angeboten löschen läßt, wenn die Zuordnung nicht mehr paßt - ist jenseits des Horizonts dieses Beitrags.
Anschließend wird das System in der alternativen Partition untersucht und angezeigt und das beim nächsten Booten der Box zu verwendende System ermittelt. Das wird in aller Regel das aktuell auch laufende System sein, es sein denn, man hätte bereits vorher eine Umschaltung ohne zwischenzeitlichen Neustart vorgenommen und wollte es sich nun anders überlegen.
Dann bietet das Skript in Abhängigkeit von der vorgefundenen Umgebung folgende Möglichkeiten:

1. Erneutes Untersuchen des laufenden Systems (falls man es nicht mehr auf dem Schirm hat oder nach dem Erstellen eines Backups der Einstellungen nützlich)
2. Neues Untersuchen des alternativen System (s.o. zu den Gründen)
3. Neue Anzeige des als nächstes zu ladenden Systems (das kann auch - s.u. zu "quit" und "exit" - ein anderer Wert sein, als er im System in diesem Moment eingestellt ist)
4. Einfache Umschaltung des Systems auf den anderen Wert, der aktuelle Wert wurde beim Start angezeigt oder bei 3.
5. Umschaltung auf das alternative System (deshalb steht diese Auswahl auch nur zur Verfügung, wenn noch das laufende System das "aktive" ist) und Austausch der Einstellungen
6. Erstellen eines Backup-Archivs der Einstellungen des laufenden Systems und Ablage dieser Datei im Wrapper-FS
7. Beenden ohne Speichern der Auswahl bei 4./5. (quit)
8. Speichern der Änderungen bei 4./5. (exit)

Das Speichern der Auswahl des nächsten zu ladenden Systems (Punkt 4 und 5) ist zunächst einmal "virtuell", erst beim Beenden mit "w" (das ist Punkt 8) wird die Änderung in der Box wirklich ausgeführt.

Bei Punkt 5 ist es ein wenig komplizierter. Dabei werden die Einstellungen des laufenden Systems "virtualisiert" und die Einstellungen des alternativen Systems an die richtigen Stellen in der Box geschrieben, damit sie beim nächsten Neustart für das andere System dann auch verfügbar sind.
Das führt dann dazu, daß weitere Änderungen von Einstellungen im laufenden System nicht mehr an die richtigen Stellen gespeichert werden, sie würden ja ansonsten die Einstellungen für das andere System wieder überschreiben.
Die "Rücknahme" dieser Virtualisierung der Einstellungen ist mir als "automatische Aktion" nicht sicher genug, daher führt das Skript nach der einmaligen Auswahl von Punkt 5 keine weiteren Änderungen am System mehr aus. Genauer formuliert: Es werden keine Backups mehr erstellt und auch das "Wiederherstellen" der Einstellungen des aktuellen Systems ist nicht implementiert. In dieser Situation bringt dann nur ein manuelles Ändern (die "Virtualisierung" beschreibe ich noch) oder ein Neustart die Box wieder in einen definierten Zustand.

Das Skript fragt lieber einmal mehr nach, als eine unbeabsichtigte Entscheidung oder eine versehentlich gedrückte Taste zu einer ungewollten Änderung des Systems werden zu lassen. Wenn das jemanden stört, kann er es gerne für sich ändern.

Sichern/Wiederherstellen von Einstellungen:
Beim Sichern von Einstellungen werden nicht nur die Dateien (eigentlich die char-Devices mit Minor-IDs des TFFS-Device) gesichert, die in /var/flash sichtbar sind (für die also das entsprechende Device angelegt wurde), das Skript geht die Minor-IDs der Reihe nach durch und sichert so auch Einstellungen, die von AVM beim Export nicht berücksichtigt werden (z.B. von der Box erzeugte Zertifikate für SSL-Verbindungen). Bei welcher ID diese sequentielle Suche startet und wo sie endet, wird im Skript in den Zeilen
in tffs_minminor und tffs_maxminor festgelegt. Hier steht auch, welche "Dateien" nicht gesichert werden sollen (in tffs_ignore_back -> 95 und 96 sind die Dateien panic und crash.log, 87 sollte man vielleicht noch hinzufügen). Alle anderen Nodes im TFFS die irgendwelche Daten enthalten, werden in das Backup aufgenommen. Wenn für den Node ein Dateiname in /var/flash existiert, erfolgt die Sicherung unter diesem Namen, ansonsten wird als Dateiname "tffs.<minor>" gewählt. Das fertige Backup-Archiv wird in das Wrapper-Filesystem des aktiven Systems kopiert. Verwaiste Backup-Archive (s. Bemerkungen zum Hash-Wert des rootfs weiter oben) können bei der Anzeige des betreffenden Systems einzeln gelöscht werden.
Bei Wiederherstellen der Einstellungen für die andere Systemversion werden dann auch nicht blind alle Dateien aus dem Backup wieder geschrieben. Gerade solche Einstellungen/Statistiken wie die Anrufliste, die Nutzungsdauer mit dem verbrauchten Volumen, das Telefonbuch und die diversen Telefoneinstellungen ändern sich i.d.R. zwischen zwei Versionen des FRITZ!OS nur wenig bis gar nicht und speziell bei der Verwendung zur Umschaltung zwischen AVM- und Freetz-Version zum Vergleich der Unterschiede ist das Wiederherstellen z.B. eine alten Anrufliste ja eher Blödsinn. Daher kann in der Variablen "tffs_ignore_set" festgelegt werden, welche TFFS-Nodes beim Restore ignoriert werden sollen. Von mir wurden da folgende Dateien eingetragen:

Das "Virtualisieren" der Einstellungen beim Austausch (Punkt 5 weiter oben) erfolgt durch den Ersatz des normalerweise unter /var/flash liegenden NAND-Flashs (/dev/mtdblock4) durch eine weitere tmpfs-Partition, nachdem diese entsprechend präpariert wurde. Dazu wird nach deren Erzeugung für jede bisher unter /var/flash sichtbare Datei in Abhängigkeit von ihrem Typ eine Kopie in diesem tmpfs erzeugt, bei c-Devices durch mknod für das Device am neuen Ort, bei Symlinks und regulären Files jeweils durch Kopieren. Unterverzeichnisse unter /var/flash werden ignoriert. Dann wird das Backup durchsucht und für jede wiederherzustellende Datei wird die Kopie im tmpfs erst einmal entfernt (unabhängig, ob es sich um eine Datei, einen Link oder ein Device handelt), damit wird - wenn das tmpfs dann unter /var/flash gemounted ist - der weitere Schreibzugriff auf die "originale" Datei unterbunden. War die Datei bisher in /var/flash vorhanden (nicht alle TFFS-Nodes haben einen korrespondierenden Dateieintrag), wird der alte Inhalt (ggf. auch die leere Datei) nun als reguläres File in das tmpfs kopiert, alle Änderungen bis zum nächsten Systemstart finden dann in dieser temporären Datei statt. Anschließend wird für den korrespondierenden TFFS-Node ein char-Device temporär angelegt und die Einstellungen aus dem Backup dorthin kopiert. Nachdem dann als Abschluß das neue tmpfs per Mount mit move-Option nach /var/flash "befördert" wurde, ist die Wiederherstellung der Einstellungen für das andere System beendet und man sollte im Normalfall eigentlich so bald als möglich neu booten. Wenn jemand die Änderungen im laufenden System wieder rückgängig machen wollte, müßte er nur die alten Inhalte wieder in die TFFS-Nodes schreiben (wer schlau ist, hat ohnehin kurz zuvor noch ein Backup der Einstellungen des laufenden Systems gemacht) und anstelle des tmpfs wieder /dev/mtdblock4 auf /var/flash mounten.

Das zu startende System wechselt man entweder über Telnet oder über das GUI (bei Verwendung einer zusätzlichen Modifikation).

Die Umschaltung per Telnet kann für jede Partition getrennte Einstellungen verwalten, die per WebIF ist im Moment nur für identische Systeme in beiden Partitionen (und damit keine Notwendigkeit für verschiedene Einstellungen) gedacht.

Was geschieht nach einem Recover? Ist die Box dann wieder "normal"?

Zum Vergrößern anklicken....

Um es noch einmal ganz klar zu sagen: Die Box (bzw. die Firmware in einer der beiden Partitionen) wird vom Skript gar nicht verändert. Die Möglichkeit der beiden Systeme wird von AVM selbst eingeführt, vermutlich um das Auto-Update sicherer zu machen.

Das Skript schreibt nur die gesicherten Einstellungen zusätzlich in die Partition mit dem jeweils aktiven System, die sind bei Recovery dann weg (aber auch nur in der vom Recovery behandelten Partition, das ist bei der 7490 immer die aktive, bei der 7362SL weiß ich das nicht genau).

Zum Sinn:
Gesetzt den Fall, Du installierst die nächste AVM-Firmware und diese gefällt Dir nicht (die Situation haben einige Nutzer bei der diesjährigen 06.20-Rallye für die 7490 mehrmals erlebt), dann kannst Du auf der Telnet-Konsole mit einem Aufruf wieder auf Dein altes System zurück, vollkommen ohne Recovery (bei einigen braucht das eine andere Verkabelung usw.). Wenn die neuere Firmware dabei Deine Einstellungen so aktualisiert hat, daß diese von der vorhergehenden Version nicht mehr verwendet werden können, mußt Du zwar u.U. noch ein Werksreset und ein Restore für die Settings anschließen, aber Du brauchst (solange Du im neuen System die Konsole erreichst) eben kein Recover.
Mit ein wenig Erfahrung lassen sich sogar zwei vollkommen verschiedene Versionen der Firmware auf der Box jeweils alternativ nutzen. Oder meinetwegen auch eine Version mit Freetz und eine ohne, wo man die Frage, ob ein bestimmtes Problem nur mit Freetz oder auch mit der originalen Firmware auftritt, dann ohne zweimaliges Flashen (nur durch zwei Neustarts jeweils nach Umschalten) klären kann.

Ich persönlich setze es in erster Linie ein, um bei Problemen mit meinen eigenen Untersuchungen und Anpassungen der Firmware auf die vorhergehende Version zurückzukommen, ohne neue Firmware über das GUI flashen zu müssen.
Es gibt ja einige hier im Forum, die ihre eigenen Anpassungen auch jenseits von Freetz per Skript vornehmen und da kann man neben dem Weg mit dem bind-Mount (das ja erst relativ spät greift und frühe Modifikationen im Bootprozess somit nicht erlaubt) auch die Modifikation des root-FS direkt verwenden. Dabei hauen einem Fehler dann aber auch mal die Beine weg ... und da finde ich so einen Weg zur schnellen Rückkehr zum vorherigen Stand schon sehr komfortabel.

Wer aber an seiner Box ohnehin nicht rumbastelt (meint die Software), kann damit nur beim Ausprobieren von neuen AVM-Versionen etwas anfangen ...

@eisbaerin:
Danke für den Test und die Bestätigung, daß es an der Firmware-Version liegt. Damit hake ich das vermutlich unter "funktioniert" ab und baue event. noch einen Test ein, daß bei Firmware < 06.20 eine Warnung vor irgendwelchen Aktionen ausgegeben wird. Das "Hängenbleiben" des gemounteten Filesystems ist imho keine sinnvolle Option ... dann muß man unmittelbar danach auch neu starten.

Komischerweise funktioniert es auf der 06.05 für die 7490 dann schon wieder einwandfrei ... aber imho sind da auch verschiedene Kernel-Versionen am Start.

@SF1975:
Da hatte ich nicht nachgesehen bei meiner Behauptung. Im Rahmen von modfs habe ich eine GUI-Version gebaut (da ist auch ein Screenshot des geänderten AVM-GUI dabei), die kann aber (noch) keine getrennten Einstellungen für die unterschiedlichen Systeme verwalten.

Geht doch ... bei mir funktioniert es jedenfalls. :mrgreen: Und zwar vollkommen unabhängig davon, welches "n" man wegläßt ...

Aber es ist ohnehin Zeit für neue Peripherie (das mit den fehlenden Zeichen bei zu geringer Anschlagstärke ist nämlich wirklich so - ich bin nur noch am Korrigieren, weil irgendwelche Eingaben "untergehen") ... die aktuelle Logitech-Tastatur (MX3200) läßt ohnehin schon fast keine Zeichen mehr auf den Tasten erkennen (das kann man ja noch kompensieren, auch wenn gerade das "n" besonders betroffen ist), aber die Hall-Kontakte sind inzwischen wohl auch hinüber. Vielleicht müßte man sich auch nur mal die Zeit nehmen und den ganzen Dreck unter den Tasten gründlich entfernen.

Aber zurück zum BootManager ... wenn man nicht gerade tatsächlich die Funktion zum Sichern der Einstellungen für zwei unterschiedliche Systeme jeweils in der zugehörigen yaffs2-Partition benutzen will (das mache ich seit dem Umstieg auf 06.50 auch selbst kaum noch), bleibt ja im Grunde nur die Umschaltung zwischen den zwei Systemen übrig und die ist mit switch_system (HTTP-Link: http://yourfritz.de/7490/switch_system) leichter und schneller zu realisieren.