[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

[PeterPawn]

Wozu dient denn das ruKernelTool in diesem Kontext gleich noch mal?

Aber das wird jetzt eher OT, mach Dir doch einfach einen eigenen Thread zum Thema "6360 - eigenes SquashFS-Image" auf, da beansprucht das (eher abseits gelegene) Thema der DOCSIS-Box dann nicht die Aufmerksamkeit der Leute mit einer NAND-Box.

EDIT: Letzte Bemerkung meinerseits zum Thema "auslesen" ... gab es nicht auch bei der 6360 irgendwie die Möglichkeit, einen USB-Speicher mit der FRITZ!Box zu verbinden? :gruebel: Wozu braucht es dann unbedingt tftp zum Auslesen? Und /data ist i.d.R. ein jffs2-Dateisystem für den AB, das hat mit der Firmware nur entfernt zu tun (eigentlich nur insoweit, als daß der nicht genutzte Platz im NOR-Flash dafür verwendet wird).

- - - Aktualisiert - - -

Ich habe mal wieder einige Änderungen vorgenommen und daher die Version auf 0.3.5 angehoben.

Die Änderungen:

- es gibt jetzt eine Möglichkeit, nach dem Initialisieren der yaffs2-Partition und nach dem Kopieren der Dateien für die Firmware in diese Partition, weitere Dateien dort abzulegen ... das können z.B. Erweiterungspakete sein, die von E99-custom geladen werden sollen oder zusätzliche Dateien, auf die man in seinem Firmware-Image mit einem Symlink verweisen will, weil sie eben doch einmal neu geschrieben werden müssen und man nicht gleich das ganze Image wieder ändern will oder auch zusätzliche Programme oder beliebige andere Dateien, die man für eigene Modifikationen braucht - dieser Teil des Dateisystems ist ja im laufenden Betrieb unter dem Pfad /wrapper jederzeit zugänglich (das Thema habe ich im Zusammenhang mit E99-custom ein paar Beiträge vor diesem ausführlich erläutert)

- um diese Dateien zusätzlich in das neue System zu integrieren, müssen sie in einer ausgepackten Dateisystemstruktur vorliegen (also nicht als .tar.gz o.ä., wie bei "ownfiles") und der Name dieses Verzeichnisses ist mit der Variablen "ADD_TO_WRAPPER" beim Aufruf von modfs anzugeben ... die Dateien werden in genau der Struktur, die in diesem Quellverzeichnis existiert, dann in die yaffs2-Partition kopiert

- ein Aufruf mit dieser Möglichkeit (und dem Quell-Verzeichnis in /var/media/ftp/extend) würde also in etwa so aussehen:

ADD_TO_WRAPPER=/var/media/ftp/extend modfs ...

- ich bin mir gerade nicht sicher, ob ich schon etwas zum Stoppen der Swap-Spaces beim Stoppen der USB-Geräte geschrieben hatte, jedenfalls ist "mod_swapoff" dazu gedacht, das Hängenbleiben der Box (nach dem Auslagern durch heftigeren Speicherbedarf, was bei mir reproduzierbar erfolgt) beim Neustart zu verhindern

- "mod_custom_images" (das ist die Modifikation, die für die E99-custom sorgt) ist jetzt "offiziell" in diesem Release

- ich habe ein statisch gelinktes "openssl"-Binary in der Version 1.0.2h dem Paket hinzugefügt - ob ich es schaffe, das jeweils aktuell zu halten (auch wenn es Änderungen gibt, die für "modfs" nicht relevant sind), will ich nicht versprechen

- um dieses OpenSSL-Programm selbst zu erstellen, braucht man die Änderungen aus meinem Freetz-Fork im GitHub, weil Freetz ansonsten nur die zum Ende des Jahres abgekündigte Version 1.0.1 unterstützt

- mit diesem Binary kann man dann in Verbindung mit der ebenfalls enthaltenen Busybox auch mittels "wget" auf HTTPS-URIs zugreifen, u.a. auch auf das GitHub-Repo selbst - irgendwann baue ich mal eine Update-Möglichkeit in "modfs" ein

- gleichzeitig habe ich ein paar Aufrufe einer optionalen Signaturprüfung für AVM-Firmware-Images und ggf. auch für künftig im Rahmen von "modfs" bereitgestellte Binärpakete in "modfs" hinzugefügt, die machen aber außer einer Meldung in der Konsole nichts, solange die entsprechenden Skript-Dateien dahinter noch fehlen - später kann man dann durch Angabe von "NOVERIFY=1" beim Aufruf von "modfs" so eine Prüfung auch überspringen, die ansonsten auf alle Eingabedateien losgehen würde, die wie ein originales Firmware-Image aussehen (also auch auf umgepackte Freetz-Images u.ä.)

- es war/ist ja etwas heikel, einfach irgendwelche Dateien aus dem Internet zu laden (wer weiß denn, ob das tatsächlich vom AVM-Server kommt) und dann mit deren Inhalt die neue Firmware für den Router zu bauen - kriegt jemand an dieser Stelle den Fuß in die Tür, kann er "modfs"-Benutzern so wieder irgendwelche Änderungen unterjubeln und das ist es ja genau, was ich mit dem Beharren auf Shell-Code für "modfs" verhindern möchte (da kann jeder nachlesen, was passiert) ... daher würde ich die AVM-Firmware vor der Verwendung durch "modfs" erst noch einer Prüfung unterziehen wollen, so wie es AVM beim GUI auch macht

 

[blennitom]

Hi zusammen,

ich brauche eure Hilfe.

Ich habe folgende Ausgangssituation:
FritzBox 7490 mit 06.51 und O2-Branding

Folgendes habe ich gemacht und es hat soweit auch funktioniert:

• O2-Branding entfernt
• Recovery auf 06.50
• SIAB installiert

Jetzt wollte ich mit modfs (mindestens) die drei Optionen

• edit_rcuser
• mod_enable_telnet
• mod_rc_tail_shh

hinzufügen.
Also modfs auf die Box geladen und ausgeführt - ich wollte dabei das auf der Box laufende Image als Quelle verwenden. Nach Auswahl der Anpassungen bootet nach der Anzeige von Packen des neuen root-Dateisystems die Box neu, es ist aber nicht das modifizierte image installiert. Also hier im Forum gesucht, evtl. liegt es daran, dass zu viele Dienste auf der Box laufen. Leider bringt der Befehl prepare_fwupgrade start_tr069bei mir keine Abhilfe.

Also wollte ich mir das erzeugte Image anschauen, und habe mit ./modfs update quelle.image ziel.image ein angepasstest Image aus dem FRITZ.Box_7490.113.06.50.image erstellen lassen.
Erste Auffälligkeit: das image ist nur 18,4 statt 25,4 MB groß - naja, kann ja sein.
Anschließend wollte ich das image über ./modfs update ziel.image installieren, wo ich dann folgende Fehlermeldung erhalte:
Extrahieren des neuen Kernel-Images aufs dem Firmware-Image ... Fehler
Beim Extrahieren des Kernel-Abbilds aus der Firmware-Datei ist ein Fehler aufgetreten.
Also wieder gesucht und auf zwei Möglichkeiten gestoßen:
Beitrag #305 mit dem Repacken des Images
Beitrag #306 mit dem Anpassen des Skriptes (auch für extract-filesystem())

Jetzt weiß ich leider nicht mehr weiter - könnt ihr mir helfen?
Was mir noch aufgefallen ist: Ich kann das erstellte image auch auf dem PC nicht öffnen, wenn ich es von .image in .tar umbenenne - mit den originalen Dateien von AVM geht das.

Danke euch für die Hilfe!

 

[PeterPawn]

Genau für solche Fragen habe ich in modfs eine (inzwischen standardmäßig aktivierte) Protokollierung eingebaut ... hänge bitte einfach mal die Protokolldatei hier an (wirklich als Anhang) und Dir kann bestimmt geholfen werden. Ich würde allerdings als erste Maßnahme mal einen USB-Stick mit mehreren Partitionen anschließen, von denen eine als "Linux Swap" gekennzeichnet sein sollte. Das Stoppen der Dienste ist der eine Punkt ... es kann aber trotzdem zum Speichermangel kommen (das hängt u.a. davon ab, was die Box bei start_tr069 noch am Leben lassen will) und dabei hilft es ungemein, wenn da Speicherinhalte ausgelagert werden können.

Ich hoffe mal nicht, daß es an einer Änderung zur 0.3.5 hin liegt ... ich habe die eigentlich schon seit fast 2 Monaten im Einsatz (mit den meisten Änderungen jedenfalls) und bisher nichts bemerkt. Aber wie gesagt ... dafür gibt es das "debug log" und seit 0.3.3 (oder so ähnlich) ist das auch immer eingeschaltet.

Ansonsten hast Du das mit dem "update" auch etwas falsch verstanden (oder ich das von Dir Geschriebene) ... das "update" erwartet ein volles Firmware-Image und erzeugt aber bloß ein SquashFS-Image, das man mit "installroot" dann in ein ansonsten bereits mit der richtigen OS-Version versehenes Gerät verfrachten kann., das wäre nur der Teil eines normalen Firmware-Images, den man mit der "installroot"-Option installieren würde. Die 18,4 MB sollten also "nur" das SquashFS-Image sein, was unter dem Namen "filesystem_core.squashfs" in der wrapper-Partition liegt und da müßte die Größe auch stimmen.

 

[blennitom]

Das hab ich tatsächlich falsch verstanden - allerdings funktioniert es leider trotzdem nicht.
Hier hab ich mal das log-File vom Erstellen des Images sowie das log-File vom installroot (Anhänge funktionieren irgendwie nicht...) - jetzt mit USB-Stick als swap:

http://blenni.bplaced.net/IPPF/create_modified_image.log
http://blenni.bplaced.net/IPPF/installroot_modified_image.log


Wenn ich das richtig sehe, steigt er bei installroot bei extract_kernel aus.

Führe ich den Befehl zum Entpacken aus dem Skript manuell aus, bekomme ich folgende Meldung:
tar: invalid tar magic

Vielen Dank für die Hilfe!

 

[PeterPawn]

Ok, ich habe mich in #664 tatsächlich mißverständlich ausgedrückt.

In diesem Beitrag steht etwas dazu, wie man das einzelne erzeugte SquashFS-Image als Ergebnis des "update"-Aufrufs mit einer Zieldatei in die Zielpartition bekommt (mit install_inactive_rootfs). Dafür braucht man kein "modfs" oder irgendwelche anderen Faxen - das ist am Ende nur das Mounten der richtigen Partition und das Kopieren der Image-Datei unter dem richtigen Namen.

Die "installroot"-Option von "modfs" ist nur das Pendant zu diesem einfachen Kopieren, wenn eben ein komplettes Firmware-Image vorliegt, aus diesem aber nur Teile installiert werden sollen. Wie die drei "install*"-Optionen arbeiten, steht hier genau erläutert: http://www.ip-phone-forum.de/showthread.php?t=273304&p=2150764&viewfull=1#post2150764

Es gibt in Deinem Falle ja eigentlich keine Notwendigkeit, da erst ein gesondertes SquashFS-Image zu erstellen und das hinterher mit "install_inactive_rootfs" an seinen Platz zu kopieren (dann müßte man die Umschaltung anschließend auch von Hand vornehmen) ... mit ausreichendem Swap-Space sollte das ja nun funktionieren, das Erstellen des Images ist vom Resourcenbedarf her auch nichts anderes als der "komplette Lauf", es wird nur eben vorher abgebrochen - aber erst nach der Aktion, die den größten Bedarf an freiem Hauptspeicher hat.

Das ist zweifellos das Zusammenpacken des neuen SquashFS-Images, bei meiner 7490 sieht die Statistik für diesen Prozess z.B. so aus:

root@FB7490:~ $ cat /proc/$(pidof mksquashfs4)/status
Name:   mksquashfs4
State:  S (sleeping)
Tgid:   17634
Pid:    17634
PPid:   14041
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 32
Groups:
[COLOR="#FF0000"]VmPeak:   239492 kB
VmSize:   233892 kB[/COLOR]
VmLck:         0 kB
VmPin:         0 kB
VmHWM:     83112 kB
VmRSS:     83112 kB
[COLOR="#FF0000"]VmData:   233364 kB[/COLOR]
VmStk:       140 kB
VmExe:       380 kB
VmLib:         0 kB
VmPTE:       240 kB
VmSwap:        0 kB
Threads:        10
SigQ:   1/934
SigPnd: 00000000000000000000000000000000
ShdPnd: 00000000000000000000000000002000
SigBlk: 00000000000000000000000000000005
SigIgn: 00000000000000000000000000000000
SigCgt: 0000000000000000000000018008e002
CapInh: 0000000000000000
CapPrm: 0000001fffffffff
CapEff: 0000001fffffffff
CapBnd: 0000001fffffffff
Seccomp:        0
Cpus_allowed:   3
Cpus_allowed_list:      0-1
voluntary_ctxt_switches:        7277
nonvoluntary_ctxt_switches:     911

Diesen Speicherbedarf kann man ohne Swap-Space schwer bis gar nicht befriedigen und daher predige ich immer wieder, daß man seinem System für die Verwendung mit "modfs" eine Swap-Partition gönnen soll (dann muß man sich nicht um das Mounten kümmern, das macht dann das FRITZ!OS selbst) oder zumindest das Swappen in eine Datei aktivieren soll. Dann klappt das Einpacken auch auf einem System mit nur 128 MB RAM ... so eines ist natürlich mit dem oben gezeigten Bedarf erst recht überfordert. Wenn das auch anders ginge, könnte man auch die 7412 problemlos auf der Box ändern ... aber das klappt bekanntermaßen nicht (und auch extern über NFS o.ä. funktioniert nicht wirklich, weil das System es nicht unterstützt).

 

[blennitom]

Läuft! Vielen Dank - der Stick mit SWAP-Partition hat geholfen!

 

[PeterPawn]

Ich hatte nach langer Zeit mal wieder eine fabrikneue 7490 mit 06.51 in der Hand (wie man da erst einmal ShellInABox aktivieren kann, kommt demnächst als (wirklich leicht nachvollziehbare) Anleitung) und als ich dort die "ursprüngliche Funktion" mit dem Kopieren des aktiven Systems in die zweite Partition verwendet habe (die Box hatte keinen Internetzugang, daher ging das Laden vom AVM-FTP-Server nicht), fiel mir dann auf, daß die jetzt standardmäßige aktivierte Debug-Protokollierung im "modfs" den eigentlich nach dem Kopieren geplanten Neustart verhindert (weil dann das Log auch weg wäre). Der Text dazu ist zwar fest verdrahtet in Englisch, aber ich will hier noch einmal den Hinweis unterbringen, daß nach dem erfolgreichen Kopieren dann einfach durch die eigene Eingabe von "reboot" die Box neu gestartet werden kann/muß. Theoretisch ist allerdings auch das nicht notwendig (die Erkenntnisse da haben sich je verändert seit den Anfängen von "modfs") und man kann einfach mit dem erneuten Aufruf von "modfs" fortsetzen.

 

[BurningCrash]

Gibts schon mutige Leute die es mit der 06.60 ausprobiert haben?

 

[eisbaerin]

Jo, soweit du nur das auspacken, anschauen, modifizieren und einpacken meinst. Hat alles geklappt. Aktiv geflasht habe ich es noch nicht. Kommt in kürze.

 

[BurningCrash]

Kann aktuell meine Box nicht ausser Betrieb nehmen fürs modden. Nennen wir es höhere Mächte sind aktuell auf eine erreichbare Box angewiesen ;-)

 

[Mathias-R]

Hallo, bei mir sieht auch nach dem Reboot mit 6.60 alles gut aus.
Menu-Erweiterungen und Telnet sind wieder da.

Gruß,
Mathias

 

[PeterPawn]

Wie mutig müßte man denn sein?

Wenn tatsächlich etwas anders wäre (was ggü. den letzten Laborversionen schon unwahrscheinlich wäre), dann klappt entweder das Modifizieren und die Box startet mit dem neuen System oder eben nicht. Bei "nicht" kostet das 2 Minuten und das vorhergehende System läuft wieder.

Einer der Gründe war es ja, risikolos (oder zumindest mit recht geringem Risiko) die Vorteile des Aufbaus bei den NAND-Boxen zu nutzen - man kann eigentlich nichts kaputt machen. Anders bei den NOR-Modellen, deshalb gibt es dort (anders als ganz am Beginn mal gedacht) auch keine Unterstützung ... auch wenn das praktisch genauso funktioniert (zumindest bei der 7390) und bis zum Einpacken des Dateisystems.

---

-Um aber die eigentliche Frage zu beantworten ... "läuft bei mir" (seit dem Nachmittag).

OT:
Ich suche seitdem nahezu ununterbrochen irgendwie nach der entscheidenden Änderung bei der Sicherheit der Internet-Telefonie ... aber vielleicht habe ich auch zu viel erwartet.

Was ich bisher gefunden habe (bzw. glaube gefunden zu haben - muß ich erst mit älteren Versionen vergleichen), ist eine abweichende "Bewertung" des Kennworts für einen SIP-Client. Kleines 'a' bis kleines 'z' (also 26 Zeichen) gilt jetzt als "kurz" - auch verwürfelt wie in "sfecoqhkanxtdljgmurivpybzw" kommt es gerade mal auf "mittel" (vermutlich wegen des beschränkten Zeichensatzes). Die Einstufung als "kurz - mittel - lang" dürfte auch nicht so richtig günstig gewählt sein, "schlecht - mittel - gut" wäre wohl deutlicher. Irgendwelche Konsequenzen aus einem "schlechten Kennwort" finde ich gar nicht.

Wahrscheinlich stelle ich mich einfach zu glatt an, aber ich kann problemlos (und ohne jeden warnenden Hinweis im GUI, wenn man mal von dem lapidaren "kurz" absieht, aber das sollen ja auch 26 Zeichen noch sein) einen neuen SIP-Client mit dem Kennwort "1234" anlegen und diesen Account aus dem LAN auch problemlos nutzen (mit 3CXPhone) ... allerdings muß ich tatsächlich mindestens 4 Zeichen eingeben. Unter "Änderung - Anforderung für Kennwörter von IP-Telefonen weiter erhöht" hätte ich mir jetzt irgendetwas anderes vorgestellt - vielleicht kann mir ja jemand auf die Sprünge helfen, was sich da tatsächlich verbessert hat.

Ist aber eh' der falsche Thread, ich bin eben total verwirrt von so hohen Anforderungen - das steckt man in meinem Alter nicht mehr einfach so weg, wenn man sich ab jetzt Kennwörter mit mindestens 4 Zeichen ausdenken soll (vor allem dann, wenn die sich auch noch unterscheiden sollen von anderen bereits verwendeten).

 

[eisbaerin]

Die Einstufung als "kurz - mittel - lang" dürfte auch nicht so richtig günstig gewählt sein, "schlecht - mittel - gut" wäre wohl deutlicher.

Bei der 113.06.51 ist es: kurz - mittel - gut
Dabei gilt "sfecoqhkanxtdljgm" noch als "kurz" und "sfecoqhkanxtdljgmsfecoqhkanxtdljgm" als "mittel". Länger geht aber nicht.

Es ging aber noch "1" als Password, auch wenn ich den Haken bei "Anmeldung aus dem Internet erlauben" setze. Daß man jetzt wenigstens 4 Zeichen braucht, ist ja ein riesiger Sicherheitsgewinn. :lach:

 

[PeterPawn]

Ja, die Steigerung der Sicherheit um 300% hatte ich jetzt nicht berücksichtigt. ;-)

Wie ich auf "kurz - mittel - lang" kam, weiß ich auch nicht ... vielleicht ein freud'scher Vertipper? :mrgreen:

 

[eisbaerin]

Wenn ich den Haken bei "Anmeldung aus dem Internet erlauben" setze, sollte als Password IMO mindestens 8, besser 16 Zeichen gefordert werden. Mein PW ist 32 Zeichen, wobei ich da schon mal Schwierigkeiten hatte, da ein SIP-Client nur 30 Zeichen konnte.

 

[andil!]

Hallo,

ich möchte gerne meine Fritz.Box 7490 mit 6.51 und modfs auf 6.60 heben. Da ich aktuell nur "von außen" auf die FB zugreifen kann, möchte ich beim Update auch direkt die Einträge aus meiner aktuellen rc.user übernehmen.

An welcher Stelle im Updateprozess kann ich wie sicherstellen, dass entweder meine alte rc.user übernommen wird oder ich manuell die rc.user so editieren, dass sie auch nach dem ersten reboot nach dem update bereits ausgeführt wird?

(Falls jemand nach dem Sinn fragt: ich möchte direkt einen SSH Server via dropbear nach dem reboot nach dem update starten)

Viele Grüße
Andil

 

[PeterPawn]

Der Inhalt der rc.user wird vom modscript nur dann geändert, wenn diese leer ist ... das dient(e) nur dem Zweck, die bei einigen anzutreffenden Zweifel, ob die Kommandos tatsächlich ausgeführt werden, auszuräumen ... bei leerer "rc.user" wird ein Kommando für einen Eintrag ins Eventlog hinzugefügt.

Ansonsten bleibt der Inhalt, wie er ist ... enthält das neue System die Einbeziehung der "rc.user" beim Booten, sollten alle Kommandos genauso wieder abgearbeitet werden - immer unter der Voraussetzung, daß die dort aufgeführten Kommandos auch erreichbar sind.

Weil jedes System ja sein eigenes wrapper-Dateisystem hat, gibt es überhaupt nur die zusätzliche Möglichkeit, mit "ADD_TO_WRAPPER=verzeichnis" beim Aufruf von modfs zusätzliche Dateien in das wrapper-FS kopieren zu lassen, nachdem das dort liegende root-FS ausgetauscht wurde.

Startet man die eigenen Kommandos aus dem NAND-FS unter /var/media/ftp oder gar vom USB-Stick (oder braucht man keine weiteren Dateien, was bei einem SSH-Server ja eher unwahrscheinlich ist), braucht man sich um unterschiedliche Inhalte unterhalb von /wrapper natürlich nicht zu kümmern.

 

[andil!]

Danke für die schnelle Antwort.

Da die rc.user nicht leer ist und beim Aufruf Dateien vom NAND-FS zur Laufzeit kopiert, sollten die Inhalte ja ein normales Update überstehen. Ich wage es und antworte gleich, falls ich mich anschließend wieder per SSH auf die FB connecten kann.

Ansonsten halt "ein bisschen" später...

EDIT:
Hat perfekt geklappt! Danke!

 

[luplupescu]

Hallo!
Ich möchte ein USB-Stick als Hilfmittel für modfs auf einem 7362 SL benutzen. 16 GB Speicherplatz.
Wie lege ich die Partitionen an? (ich nehme MiniTool Partition Wizard Free 9.1)
Ich teile 1 GB für Swap und Rest formatiere ich mit ext3, ist 1 GB für Swap ausreichend? zu viel? richtig?
Soll ich den Swap an den ersten Partition anlegen oder an den zweiten?
Mounten tut man aus der Webinterface oder muss ich vom telnet tun?
Muss ich dass nach jedem reboot wieder mounten oder kann man in einen config Datei oder Script automatisch tun.
Ich bedanke mich im Voraus.

 

[PeterPawn]

Der entscheidende Vorteil (in meinen Augen) einer Swap-Partition ist es, daß ein aktuelles FRITZ!OS den die beim Booten oder beim Anstecken des Sticks automatisch einbindet als Swap-Space (anders als bei einer Datei als Ziel); das gilt auch für erkannte Partitionen mit einem Dateisystem. Die Reihenfolge spielt keine Rolle, auch primäre oder logische Partition macht keinen Unterschied.

1 GB Swap-Space reicht locker und am Ende kann man das Einrichten sogar mit der BusyBox machen, die beim "modfs" dabei ist - der habe ich das "fdisk"-Applet "spendiert".

Ich wollte schon immer mal aufschreiben, wie das funktionieren würde ... mal sehen, ob ich es nachher noch schaffe.

Den Rest kann man formatieren wie man will ... bei der 7362SL mit nur 22 MB im NAND-FS macht es auch richtig Sinn, wenn man dort ein Linux-Dateisystem (ext2 oder ext3) unterbringt.

Zum Vor- und Nachteil von ext2 bzw. ext3 habe ich irgendwo etwas geschrieben (bei der Erklärung zu E99-custom müßte das gewesen sein) ... zwischen diesen beiden muß jeder selbst wählen.

ext4 halte ich an der FRITZ!Box für Unsinn (ältere Modelle/Firmware-Versionen kennen es auch nicht) ud selbst (v)FAT(32) ist nicht wirklich tauglich beim Einsatz von "modfs", weil am Ende ohnehin eine Containerdatei für ein 128 MB-ext3-Image verwendet würde.

NTFS verbietet sich (wie andere fuse-basierte FS) von selbst (und wäre ebenfalls nicht "native").