Ne, das wird schon im TFFS "genullt" ... wegen der Arbeitsweise des Flash-Speichers (gelöscht (erased) hat eine Zelle den Wert 1 und diese kann dann wahlweise auf 0 "geschossen" werden, wenn es erforderlich ist für den zu speichernden Wert in aufeinanderfolgenden Zellen) wird da tatsächlich nur die "Differenz" gebildet beim Schreiben und zwar so, daß bisher noch auf "1" stehende Bits in einer ID am Ende gelöscht sind und das Längenfeld für die Daten dahinter unangetastet bleibt, damit man mit dessen Wert den nächsten Eintrag finden kann.
Das geschieht beim alten Wert sowohl für ein SETENV als auch ein UNSETENV - bei ersterem wird dann halt der neue Wert "hinten" angefügt, wo bisher nur binäre Einsen stehen in den gelöschten Zellen. Am Ende ergibt das also an den Stellen, wo "alte Werte" im Flash stehen, eine ID von 0, gefolgt von der Länge des (ehemaligen) Eintrags, mit der man dann den nächsten Eintrag findet.
Ab einem gewissen Füllstand wird dann das Ganze komprimiert (die "freien" Plätze innerhalb der Abfolge der Einträge, die durch gelöschte/überschriebene Einträge entstanden sind, werden dabei dann natürlich nicht mit kopiert, wodurch automatisch eine Verdichtung der Daten erfolgt) und als neues Image in die andere Partition geschrieben. Durch dieses mehrfache Beschreiben eines "erase blocks" mit zusätzlichen Nullen spart man halt Löschzyklen für den Speicher (trotzdem werden die neuen Daten zeitnah gespeichert) und berücksichtigt so dessen (begrenzte) Lebensdauer besser, als wenn man stets einen ganzen Erase-Block neu schreibt und damit diesen natürlich dann auch wieder komplett löschen muß.
Bei der nachgereichten Beschreibung oben würde ich dann aber auch davon ausgehen, daß halt das FRITZ!OS die "provider_additive.tar" im TFFS findet (daß dafür kein "provider"-Eintrag erforderlich ist, ist bekannt - siehe 6490) und somit selbst wieder den Guard in der "provider"-Variablen setzt. Allerdings kenne ich das bisher nur so, daß das System selbst dort "additive" einträgt und nicht den Wert "O2" (oder irgendeinen anderen Wert). Vielleicht ist das ja auch wieder vom Inhalt der konkreten "provideradditive.tar" abhängig oder auch hier wurde "additive" und nicht "o2" wieder eingetragen. Der "Schutzeffekt" sollte bei beiden Angaben derselbe sein ... wenn das nur anhand der Auswirkungen beobachtet wurde (das Recovery-Programm weigert sich weiterhin), wäre das eine plausible Erklärung (wobei eigentlich das Recovery-Programm den ausgelesenen Wert auch anzeigt in seiner Dialog-Box).
An der Stelle war (oder ist?) ja auch die Beschreibung bei
@skyteddy nicht 100% korrekt (bei neueren Versionen), weil dieser Umstand (Recovery muß direkt nach dem UNSETENV ausgeführt werden) dort nicht aufgeführt war.
Ansonsten sind die Bootloader auch bei AVM schon reichlich "stabil" und ändern sich nicht jedes Jahr bzw. bei jedem neuen Modell (mit "bekanntem" Prozessor). In gewisser Weise ist das ja auch nachvollziehbar ... so ein Bootloader-Update ist zumindest mal eine Stelle, an der die "Herzfrequenz" einer CPU nach oben gehen könnte, weil es wohl die riskanteste Update-Operation ist, die einer Box zuteil werden kann. Wobei die GRX-Boxen ja inzwischen auch zwei Kopien des Loaders im (NAND-)Flash haben ... das aber wohl eher wegen der per se geringeren Lebenserwartung des NAND-Flashs und weniger als Sicherheitsnetz bei einem Update-Problem.
Daher bin ich immer besonders hellhörig, wenn ein Bootloader sein Verhalten geändert haben soll und es erst auf den zweiten oder dritten Blick auch Sinn ergibt,
warum AVM das machen sollte. Da ist nun mal die naheliegendste Erklärung bei einer solchen Beobachtung erst einmal ein Fehler des Ausführenden (wie oft habe ich selbst schon eine Reaktion eines Bootloaders nicht verstanden, ein Problem/eine Änderung vermutet und am Ende war es doch nur mein Bedienfehler - das ist einer der Gründe, warum ich solche vermeintlich neuen Feststellungen
mehrfach prüfe, bevor ich sie "veröffentliche") oder auch ein simples Mißverständnis.
Bei diesem "immutable branding" auch bei VR9-Boxen macht es auf den ersten Blick auch nur begrenzt Sinn, andererseits wird AVM vermutlich keine Updates für ältere Bootloader machen lassen (per Recovery-Programm oder bei der Firmware-Installation, wobei auch hier die GRX-Boxen bereits entsprechende Vorbereitungen in der "/var/install" aufweisen, um auch den Bootloader über ein Programm aus dem laufenden System heraus aktualisieren zu lassen), nur um da auch ein unveränderliches Branding nachträglich einzuführen.
Daß der Bootloader ansonsten Änderungen an den "mac*"-Variablen einfach wieder überschreibt (dabei landet dann auch der korrekte Wert am Ende wieder im TFFS, wobei es nicht trivial ist festzustellen, ob der bereits vom Bootloader oder erst vom gestarteten FRITZ!OS wieder geschrieben wird - dazu muß man schon sein eigenes System laden und vor dem ersten Schreiben ins TFFS den alten Zustand irgendwohin dumpen), ist bekannt ... das gilt auch nicht nur für "maca", sondern (mindestens noch) für "macb" und (iirc) auch für "macdsl". Für deren permanente Änderung müßte man dann wieder selbst in den Finalisierungsbereich schreiben.
