I managed to run the fastboot boot ... command, but get an error message:
anonymous@anonymous:~$ fastboot boot ~/Downloads/twrp-3.7.0_9-0-FP3.img
Sending 'boot.img' (31512 KB) OKAY [ 0.854s]
Booting FAILED (remote: 'unlock device to use this command')
fastboot: error: Command failed
I think I must unlock the bootloader. But if I remember correctly, this will erase all my data. Am I right? Or what shall I do?
Yes, exactly, that’s the problem. And when your device is locked you unfortunately can’t use the Fastboot command to install or not an image (and by unlocking it, it’d indeed remove all data).
Dammit! Is there any way to access my encrypted data via adb? I just need to erase some files and then it would probably start normally… It would probably even be enough to erase some cache or apps or so…
One more question: Does it make sense to keep the bootloader unlocked next time I install /e/OS?
I’m very sorry, I’m not aware of any way… 
Maybe others are…
Edit: cache might be deletable in recovery No, at least not in /e/ recovery.
Well, it’s more secure to leave the bootloader locked, but you have much more options if you keep it unlocked… (So everyone must decide for themselves…)
Thank you very much for your time! 
Is it possible to remove some system files, like old OS versions or so? Not sure what parts are encrypted and what not. This is how the filesystem looks like:
FP3:/ # ls -l
total 1236
dr-xr-xr-x 4 root root 0 1970-01-02 04:54 acct
drwxr-xr-x 2 root root 40 1970-01-02 04:54 apex
lrwxrwxrwx 1 root root 11 1970-01-01 00:00 bin -> /system/bin
lrwxrwxrwx 1 root root 50 1970-01-01 00:00 bugreports -> /data/user_de/0/com.android.shell/files/bugreports
drwxr-xr-x 2 root root 0 1970-01-02 04:54 cache
drwxr-xr-x 5 root root 0 1970-01-01 00:00 config
lrwxrwxrwx 1 root root 17 1970-01-01 00:00 d -> /sys/kernel/debug
drwxr-xr-x 2 root root 0 1970-01-01 00:00 data
drwxr-xr-x 2 root root 0 1970-01-01 00:00 data_mirror
drwxr-xr-x 2 root root 0 1970-01-01 00:00 debug_ramdisk
lrwxrwxrwx 1 root root 12 1970-01-01 00:00 default.prop -> prop.default
drwxr-xr-x 11 root root 3580 1970-01-02 04:54 dev
lrwxrwxrwx 1 root root 11 1970-01-01 00:00 etc -> /system/etc
drwxr-xr-x 3 root root 0 1970-01-01 00:00 first_stage_ramdisk
lrwxrwxrwx 1 root root 16 1970-01-01 00:00 init -> /system/bin/init
-rwxr-x--- 1 root root 3171 1970-01-01 00:00 init.recovery.qcom.rc
drwxr-xr-x 2 root root 60 1970-01-02 04:54 linkerconfig
drwxr-xr-x 2 root root 0 1970-01-01 00:00 metadata
drwxrwxr-x 10 root system 200 1970-01-02 04:54 mnt
drwxr-xr-x 2 root root 0 1970-01-01 00:00 odm
-rw-r--r-- 1 root root 0 1970-01-01 00:00 odm_file_contexts
-rw-r--r-- 1 root root 0 1970-01-01 00:00 odm_property_contexts
drwxr-xr-x 2 root root 0 1970-01-01 00:00 oem
-rw-r--r-- 1 root root 36665 1970-01-01 00:00 plat_file_contexts
-rw-r--r-- 1 root root 48232 1970-01-01 00:00 plat_property_contexts
drwxr-xr-x 2 root root 0 1970-01-01 00:00 postinstall
dr-xr-xr-x 355 root root 0 1970-01-01 00:00 proc
lrwxrwxrwx 1 root root 15 1970-01-01 00:00 product -> /system/product
-rw-r--r-- 1 root root 107 1970-01-01 00:00 product_file_contexts
-rw-r--r-- 1 root root 3369 1970-01-01 00:00 product_property_contexts
-rw-r--r-- 1 root root 19971 1970-01-01 00:00 prop.default
drwxr-xr-x 3 root root 0 1970-01-01 00:00 res
drwx------ 2 root root 0 2022-10-28 15:17 root
lrwxrwxrwx 1 root root 11 1970-01-02 04:54 sbin -> /system/bin
drwxr-xr-x 2 root root 0 1970-01-01 00:00 sdcard
-rw-r--r-- 1 root root 1017092 1970-01-01 00:00 sepolicy
drwxr-xr-x 2 root root 0 1970-01-02 04:54 sideload
d---r-x--- 2 root sdcard_r 40 1970-01-02 04:54 storage
dr-xr-xr-x 12 root root 0 1970-01-02 04:54 sys
drwxr-xr-x 5 root root 0 1970-01-01 00:00 system
lrwxrwxrwx 1 root root 18 1970-01-01 00:00 system_ext -> /system/system_ext
-rw-r--r-- 1 root root 4382 1970-01-01 00:00 system_ext_file_contexts
-rw-r--r-- 1 root root 7036 1970-01-01 00:00 system_ext_property_contexts
drwxrwxr-x 2 root shell 100 1970-01-02 04:56 tmp
drwxr-xr-x 2 root root 0 1970-01-01 00:00 vendor
-rw-r--r-- 1 root root 80781 1970-01-01 00:00 vendor_file_contexts
-rw-r--r-- 1 root root 16818 1970-01-01 00:00 vendor_property_contexts
Strange how little memory everything takes. The 64GB should be full…
If you feel desperate and you’re sure it’s a diskspace issue and you do have backups - you can delete directories via fbe when unencrypted too, you just don’t know what you’re deleting.
mount userdata via
mkdir -p /mnt/userdata
mount /dev/block/bootdevice/by-name/userdata /mnt/userdata/
du -cs /mnt/userdata/* | sort -n | tail -n10
and go rummaging?
an aside: mounting + chrooting /system and /lib partition (for shared lib dependencies) one can use vold for volume management - and maybe it has cli options to do the decryption for the ext4crypt scheme interactively. You can also push binaries (openrecoveryscript) via adb to the device… but really do that exploring only if you can stomach losing the userdata
I don’t understand exactly where to execute this. If I run your commands in a terminal from Ubuntu the following happens:
anonymous@anonymous:~$ sudo mount /dev/block/bootdevice/by-name/userdata /mnt/userdata/
mount: /mnt/userdata: special device /dev/block/bootdevice/by-name/userdata does not exist.
anonymous@anonymous:~$ ls /dev/block/
253:0 259:3 259:7 7:10 7:14 7:18 7:21 7:25 7:29 7:32 7:36 7:4 7:8
259:0 259:4 259:8 7:11 7:15 7:19 7:22 7:26 7:3 7:33 7:37 7:5 7:9
259:1 259:5 7:0 7:12 7:16 7:2 7:23 7:27 7:30 7:34 7:38 7:6 8:0
259:2 259:6 7:1 7:13 7:17 7:20 7:24 7:28 7:31 7:35 7:39 7:7
anonymous@anonymous:~$ adb shell
FP3:/ # mount /dev/block/bootdevice/by-name/userdata /mnt/userdata/
mount: '/dev/block/bootdevice/by-name/userdata'->'/mnt/userdata/': No such file or directory
I don’t know how to access the Ubuntu system when I am in adb shell and vice versa.
the commands are meant for the phone context, in the adb shell - not your host machine. You can only mount if the mountpoint exists (what’s the prior mkdir is for).
Here you find only the size of thefiles in root directory. Most data will be within the directories.
You can check in cache and tmp directories if you find data there. This could be delete without grater risk.
yep, as ff2u notes, you have to kind of know where it is safe do delete. It’s dangerous advice I’m giving if you dont know linux/android filesystem layouts
Okay thanks! I executed the commands:
anonymous@anonymous:~$ adb shell
FP3:/ # ls /dev/block/bootdevice/by-name/userdata
/dev/block/bootdevice/by-name/userdata
FP3:/ # mkdir -p /mnt/userdata
FP3:/ # mount /dev/block/bootdevice/by-name/userdata /mnt/userdata/
FP3:/ # du -cs /mnt/userdata/* | sort -n | tail -n10
5132 /mnt/userdata/system_ce
17080 /mnt/userdata/misc
17336 /mnt/userdata/vendor
23048 /mnt/userdata/system
34888 /mnt/userdata/user_de
118424 /mnt/userdata/tombstones
3021288 /mnt/userdata/app
14200420 /mnt/userdata/data
32829028 /mnt/userdata/media
50273856 total
Also the other directories:
FP3:/ # ls -l mnt/userdata/ total 468
drwx------ 2 root root 4096 1970-01-02 14:24 adb
drwx------ 2 root root 4096 1970-01-02 14:24 adbroot
drwxrwxr-x 2 system system 4096 2022-11-11 15:41 anr
drwxr-xr-x 6 root system 4096 1970-04-28 05:40 apex
drwxrwx--x 56 system system 12288 2022-11-11 16:13 app
drwx------ 2 root root 4096 1970-01-02 14:24 app-asec
drwxrwx--x 2 system system 4096 1970-01-02 14:24 app-ephemeral
drwxrwx--x 2 system system 4096 1970-01-02 14:24 app-lib
drwxrwx--x 2 system system 4096 1970-01-02 14:24 app-private
drwxr-x--- 2 system system 4096 1970-01-02 14:24 app-staging
drwx------ 5 system system 4096 2022-11-13 13:22 backup
drwxr-xr-x 2 shell shell 4096 1970-01-02 14:24 bootchart
drwxrwx--- 5 system cache 4096 1970-01-02 14:24 cache
drwxrwx--x 4 root root 4096 1970-03-22 04:41 dalvik-cache
drwxrwx--x 297 system system 20480 2022-11-11 16:06 data
drwxrwx--x 2 system system 4096 1970-04-28 05:41 dpm
drwxrwx--- 3 drm drm 4096 2020-12-15 00:47 drm
drwxrwx--x 2 system system 4096 1970-01-02 14:24 fota
drwx------ 5 root root 4096 1970-04-28 05:41 gsi
drwxrwx--- 2 system wifi 4096 1970-01-02 14:24 hostapd
drwxrwx--x 2 system system 4096 1970-04-28 05:40 incremental
drwxrwx--- 2 system cache 4096 2022-11-05 16:04 lineageos_updates
drwxr-x--x 4 root root 4096 1970-01-02 14:24 local
drwxrwx--- 2 root root 16384 1970-01-02 14:24 lost+found
drwxrwx--- 3 media_rw media_rw 4096 2022-11-13 13:22 media
drwxrwx--- 2 mediadrm mediadrm 4096 1970-01-02 14:24 mediadrm
drwxrwx--t 55 system misc 4096 2022-11-07 12:22 misc
drwxrwx--t 3 system misc 4096 2020-12-15 00:47 misc_ce
drwxrwx--t 3 system misc 4096 1970-01-02 14:24 misc_de
drwxrwx--- 3 nfc nfc 4096 2020-12-15 00:47 nfc
drwxrwx--x 2 root root 4096 1970-03-22 04:41 ota
drwxrwx--- 2 system cache 4096 1970-01-02 14:24 ota_package
drwx------ 2 system system 4096 2022-11-13 13:22 per_boot
drwxrwxr-x 2 system system 4096 1970-01-02 14:24 preloads
drwx------ 2 root root 4096 2022-11-13 13:22 property
drwxrwx--x 2 system system 20480 2022-11-07 12:22 resource-cache
drwx------ 2 system system 4096 1970-01-02 14:24 rollback
drwx------ 2 system system 4096 1970-01-02 14:24 rollback-observer
drwxrwxr-x 2 system system 4096 1970-01-02 14:24 server_configurable_flags
drwxr-xr-x 2 system system 4096 1970-01-02 14:24 shared
drwx------ 2 system system 4096 1970-01-02 14:24 ss
drwxr-x--- 3 root shell 4096 1970-01-02 14:24 ssh
drwxrwxr-x 26 system system 4096 2022-11-13 13:22 system
drwxrwx--- 3 system system 4096 2020-12-15 00:47 system_ce
drwxrwx--- 3 system system 4096 2022-11-13 13:22 system_de
drwxrwx--x 2 system system 4096 2022-10-23 13:09 tombstones
drwx------ 3 root root 4096 1970-01-02 14:24 unencrypted
drwx--x--x 3 system system 4096 1970-04-28 05:40 user
drwx--x--x 3 system system 4096 1970-01-02 14:24 user_de
drwxrwx--x 40 root root 4096 1970-04-28 05:41 vendor
drwxrwx--x 3 root root 4096 2020-12-15 00:47 vendor_ce
drwxrwx--x 3 root root 4096 1970-01-02 14:24 vendor_de
and the question is now: Is there anything that I can remove more or less safely? I hoped to be able to remove data from certain apps. But I cannot find where the data belongs to.
you go inside media/ and drill yourself down the dirextories until you find some juicy big files, videos presumably (you wont be able to tell from outside though). It’s russian roulette and I wont take responsibility
Can I somehow copy all of it to my Ubuntu? There I could probably decrypt it.
part of the encryption schemes on Android involve a device-key, stored with the TEE (trusted exec environ)… so your pin unlocks the device-key, and the device-key (or both together) encrypt data. So if you grab that data, you’ll also need to extract the TEE key. I’m sure the forensic toolkit for this exists … but it’s easier to throw a bit of data away?
go into /mnt/userdata/media (and data) and exec a “du -cs . | sort -n” to see where there is potential? in my experience, videos received via messengers comprise a large portion of smartphone storage.
I don’t know if the find command is available (can’t check presently). If it is, then maybe this helps:
find . -type f -size +10M
It worked!!! Thank you both so much! It is possible to see the type of a file. So I could simply delete some videos and /e/OS would boot normally again!
1|FP3:/mnt/userdata/media/0/wIQzCnKK9bp7ZKlZTZC9yB # ls -l
total 340124
drwxrwxr-x 2 media_rw media_rw 4096 2022-11-09 11:38 7ZeokuV,R3Ql3iEToWKOSC
-rw-rw-r-- 1 media_rw media_video 15933812 2020-12-20 17:01 B,wdUX7x,T60iwFvPWDIoQrxTkwgxQYhSilb,A
-rw-rw-r-- 1 media_rw media_video 23049127 2021-04-17 07:57 HHFLEXY4CcLwD,pjhK5HS1P,Gc9hFVakwpAXKA
I think /e/OS should ensure that it can always boot (if that’s possible), no matter how much memory is used. I think user applications should not be able to polute the system so much that /e/OS cannot be booted anymore. Maybe an issue can be opened for this?
so I haven’t read about code that controls this - but my guess is that your device did have enough storage for the OTA zip and the unpack → but had insufficient space at first boot when creating the dalvik cache, as this one is with the userdata partition on the FP3.
The update mechanism would need to calculate some extra space for the dalvik-cache before update. Depending on amount of apps installed the size requirements can be different.
The teamwin recovery (twrp) has menu options to clear that directory. Could be implemented with the lineage/e-recovery menu too for users that have locked devices.
Why dalvik cache? after an update all dex classes of apps and system are regenerated. That’s bytecode optimization for the java apps running in the android jvm (aka dalvik).
Edit: and nice that Android shows the file-group for encrypted files, makes it easier to pick them out. It cannot infer the filetype at that point, but file ownership gives it away interestingly
Hi everyone, I’m in the same situation as 2t8 but when i try this line:
mount /dev/block/bootdevice/by-name/userdata /mnt/userdata/
it says “need -t”, and when I do:
mount -t /dev/block/bootdevice/by-name/userdata /mnt/userdata/
it says
mount: ‘/mnt/userdata/’ not in fstab
yet, ‘/mnt/userdata/’ exists.
Any suggestion? Thanks!
if you need for whatever reasons supply -t it needs a filesystem type: it’s either ext4 or f2fs:
mkdir -pv /mnt/userdata/
mount -t ext4 /dev/block/bootdevice/by-name/userdata /mnt/userdata/
Thank you for the quick reply after all this time!
When I try the ‘mount’ line with ext4 or f2fs it now says:
mount: ‘/dev/block/bootdevice/by-name/userdata’ → ‘/mnt/userdata/’: Invalid argument
I forgot to mention that it’s a Pixel 5, if that makes a difference