- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,274
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
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):
und für das tar-File - wenn man das gesondert prüfen will:
[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.
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.
Code:
MD5: 05569228d0d014501ae4fbe0664e30ef
SHA-1: 18167e49f9b0e9b7d3f426a9498a30bac16a214b
SHA-256: c97cf58c6928ce6130312c4582bee5e870fe770a09cec34c2eef9bbbe7ea16e7
SHA-512: 5ef020d1196dbfee0f6abc5aadc8bcb4f6d32610f3f6a5a61244efcd0be6e01ebe08fc0276f51e15b2dd6311239d76bcfe3f7e64ee4e10246dfa40ce84418b1c
SHA3-256: 6cebb85c434736730da8ca9d959498945098a9b124d9242518fd574fb02eb161
SHA3-512: d3c85d833eb455186ac442771154fc075dd87b35301da589da47c384df941266a3b4a2358ab2f01fd98e10005fb27770543b334d7d200a141a8fa5807db1210e
Code:
MD5: 4efac7102605fb1cd56f7ce9e837de0b
SHA-1: 01f6c00fb327dd27265aad3ebf103f5781e3efa3
SHA-256: a9cb4175e2daff4cba01d8251d2a71aa39e736c266011dda64388fd5a76d1ec5
SHA-512: f72ab8e05f9e5db7e2e658cb836d58825a7f62598183e1be024e09cfebbf3aaa6c7227996df01a8f3de2d7f95a948a23f97c228cf4e499663238d1dce1187857
SHA3-256: 564cedc7759278641b1ac9d689180ade026be374a40e94b26a9065095dcee04b
SHA3-512: a18228ccfad53eda6ecf75d155be749a991a4f496578c31c48d7b31dcf0562ec8a81674d43e1a49d6c9642abc0e8661afbefdf0bddc8848d0a4aa40da3d745b7Der 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:
Code:
cd /var;wget -q -O - http://www.yourfritz.de/bootmanager_7490.tgz | gunzip -c | tar x;./bootmanager_7490 test && ./bootmanager_7490Verwendung:
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
Code:
tffs_minminor=30
tffs_maxminor=255
tffs_ignore_set="95 96 116 121 122 129 130 131 132 133 142 143 145 161 176 177 178"
tffs_ignore_back="95 96"
tffs_filenames="97:rc.user_add 98:debug.cfg 87:fwattrib 60:freetz"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:
Code:
95 crash.log
96 panic
116 stat.cfg
121 userstat.cfg
122 voipd_call_stat
129 fx_conf
130 fx_lcr
131 fx_moh
132 fx_cg
133 telefon_misc
142 phonebook
143 fonctrl
145 tamconf
161 configd
176 dect_misc
177 dect_eeprom
178 dmgr_handset_userDas "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.
Zuletzt bearbeitet:
