Recovery-OFOX: Partition DATA 10x größer als Handy-Speicher?

[nickoski]

xiaomi mi9 128GB, OFOX-recovery, android 14 / crDroid 10.2 ROM

OFOX zeigt mir plötzlich die Größe der DATA-Partition an mit 1067941 MB, das wäre über 1 TB und fast 10x größer als der Speicher. Weiß jemand, um was es da geht und wie ich es behebe?

Beim Backup bleibt es bei der Datei 40251 hängen wie auf dem Bild.

In gestartetm Android sehe ich keine Auffälligkeiten, es zeigt von 83GB frei von 111GB an.

 

[Klaus986]

@nickoski Offensichtlich hat diese Version von OFox einige Bugs. Nimm eine andere Custom Recovery.

 

[nickoski]

Danke. Andere funzen aber leider nicht mit diesem neuesten release von crDroid.
Und davor hat es monatelang problemlos gefunzt, das Problem ist erst seit einigen Tagen aufgetaucht.

 

[Klaus986]

@nickoski Wurde denn irgendein Update gemacht?

 

[nickoski]

Ich habe eigentlich 2 gleiche mi9, gleiche installation.
Nur auf einem habe ich dieses Problem, ich kann mir vorstellen, dass es durch Installieren von 2 Modulen nur auf diesem einen im kernelSU kam:

Zygisk-Next-v4-0.9.2.1-204-release.zip
PlayIntegrityFixNext14.1_daboynb.zip

Da aber in Android alles funzt, ist es mir einfach in der recovery nicht aufgefallen.
Inzwischen beide module deinstalliert, bringt aber nix.

 

[Klaus986]

@nickoski Keine Ahnung, woran es liegt. Jedenfalls haben Module o.ä., die im lfd. System installiert oder aktiv sind, keine Auswirkungen auf die Recovery. Die Recovery ist eine eigene, unabhängige Umgebung.

 

[nickoski]

Klar, deshalb wundert es mich, was da so komisch schiefgelaufen ist.

Es sieht so aus, dass da diese Datei 40251 beim backup auf dem Bild irgendwie "aufgeblasen" ist. Denn dort bleibt das backup hängen und kommt nicht voran.
Ich frage mich, wie ich danach suchen kann?

 

[Klaus986]

Ich frage mich, wie ich danach suchen kann?

recovery.log?


Basic questions

 

[nickoski]

Tja, aber wonach sollte ich da suchen?

 

[Klaus986]

@nickoski Ganz einfach: Mach ein Backup und sobald es abbricht, erstellst du das Log. Den Fehler findest du dann bei den letzten Einträgen ganz unten.

Alternativ kannst du es auch gerne hier hochladen (bitte als Anhang und nicht als Text in einem Post!!) und ich schaue es mir an.

 

[nickoski]

Ich sehe jetzt, dass die Logs sogar automatisch erstellt werden im Ordner FOX.

Das backup bricht aber nicht von selbst ab, es bleibt bei dem fünft-letzten file hängen, die Anzahl der gesicherten MBs rechts daneben vergrößert sich aber weiter, die 4% rechts bleibt aber auch stehen. Nach 1 St. immer noch 4%.

Ich muss dann oben links X drücken und es abbrechen, sonst wird es wohl den Speicher ganz voll machen.
Meinst du das log, nachdem ich abgebrochen habe?

Die letzten backuu-Zeilen, nach den Zeilen mit den einzelnen Apps, habe ich hier unten reinkopiert
Kann es sein, dass es doch mit diesen beiden kernelSU-Modulen was zu tun hat?

I:addFile '/data/adb' including root: 1
libtar:   ==> set selinux context: ubject_r:adb_data_file:s0
libtar: found fscrypt policy '/data/adb' - '2DK' - '0528f42c7e9848799893b86b75150ab2'
I:addFile '/data/adb/ksud' including root: 1
libtar:   ==> set selinux context: ubject_r:adb_data_file:s0
I:addFile '/data/adb/ksu' including root: 1
libtar:   ==> set selinux context: ubject_r:adb_data_file:s0
libtar: found fscrypt policy '/data/adb/ksu' - '2DK' - '0528f42c7e9848799893b86b75150ab2'
I:addFile '/data/adb/ksu/bin' including root: 1
libtar:   ==> set selinux context: ubject_r:adb_data_file:s0
libtar: found fscrypt policy '/data/adb/ksu/bin' - '2DK' - '0528f42c7e9848799893b86b75150ab2'
I:addFile '/data/adb/ksu/bin/busybox' including root: 1
libtar:   ==> set selinux context: ubject_r:adb_data_file:s0
I:addFile '/data/adb/ksu/bin/resetprop' including root: 1
libtar:   ==> set selinux context: ubject_r:adb_data_file:s0
I:addFile '/data/adb/ksu/bin/ksud' including root: 1
libtar:   ==> set selinux context: ubject_r:adb_data_file:s0
I:addFile '/data/adb/ksu/.allowlist' including root: 1
libtar:   ==> set selinux context: ubject_r:adb_data_file:s0
I:addFile '/data/adb/ksu/log' including root: 1
libtar:   ==> set selinux context: ubject_r:adb_data_file:s0
libtar: found fscrypt policy '/data/adb/ksu/log' - '2DK' - '0528f42c7e9848799893b86b75150ab2'
I:addFile '/data/adb/ksu/log/boot.log' including root: 1
libtar:   ==> set selinux context: ubject_r:adb_data_file:s0
I:addFile '/data/adb/ksu/log/boot.old.log' including root: 1
libtar:   ==> set selinux context: ubject_r:adb_data_file:s0
I:Closing tar
Irocess ended with no errors.
Splitting thread ID 0 into archive 15
I:Using compression...
I:addFile '/data/adb/ksu/modules.img' including root: 1
libtar:   ==> set selinux context: ubject_r:adb_data_file:s0
I:Killing pid: 902
I:InfoManager saving '/data/media/0/Fox/BACKUPS/d75b4480/2024-03-11--18-21-34_UQ1A240205004/data.info'
createTarFork() process ended with ERROR: 255
I:Backup_Run stopped and returning false, backup cancelled.
I:Removing directory /data/media/0/Fox/BACKUPS/d75b4480/2024-03-11--18-21-34_UQ1A240205004
Backup Failed. Cleaning Backup Folder.
I:Unable to unlink '/data/media/0/Fox/BACKUPS/d75b4480/2024-03-11--18-21-34_UQ1A240205004/data.info: No such file or directory'
Backup Cancelled
I:Set page: 'backup_action_complete'

 

[Klaus986]

@nickoski Nimm den Ordner /data/adb/ksu einfach mal raus, indem du ihn auf den internen Speicher schiebst und starte das Backup erneut.

 

[nickoski]

Dank deinen Tipps habe ich mir den Ordner KSU genauer angeschaut und musste staunen:
Das file data/adb/ksu/modules.img zeigt die Größe 1024,00GB im file manager an, also 1TB. Wie ist das möglich?

Auf meinem anderen mi9 ist es nur 275MB groß?

Woher kommt dieses file, wird es mit der app kernelSU oder einem der obigen module installiert?

 

[Klaus986]

@nickoski Keine Ahnung, was das ist oder woher es kommt. Nutze dieses Modul nicht.

 

[nickoski]

Inzwischen habe ich die modules.img gelöscht, OFOX zeigt jetzt wieder die richtige DATA-Größe mit 20GB an und ich konnte problemlos ein backup machen.

Besten Dank nochmals für deine entscheidenden Tipps für die Lösung!