i have an issue with an starlte device running on 2.9-s-20250321478216-official-starlte. for some time a warning has been shown, that the device is running low on disk space. however the warning has been ignored and one day, the device shut down and rebooted to recovery. since then i am not able to boot/start normally. now it looks like this:
boot
e-logo shows
pattern to decrypt the data partition
normal desktop shows and an information about “discover trust” appears on the top
at the bottom there is a message about “unable to create log file”
reboot (into recovery)
so far i tried:
mounting the /data partition because i think this is the root cause. unfortunately neither e-recovery nor twrp are able to decrypt it because of samsung special device encryption
safe mode - same thing happens. not enough time to fire up file managere and delete something off the /data partition
uninstall app from adb - not possible bc /data partition is not mounted
upgrade to 3.0.4 and 3.1.1 via adb sideload - success but same result. reboot into recovery after 2-3s
reformatting /cache and/or /system partition - success but same result in the end
is there any way to resolve this? i mean besides of factory reset. is there a way to slow down or stop the startup process after decrypting the /data partition? is there a way to decrypt the /data partition outside the device - i extracted the partition with adb pull .
the most promising proposition was that one from @rover from
but unfortunately one piece cannot work. as kiradotee on stackoverflow mentions, one has to copy his adb publickey to /data/misc/adb/adb_keys. this is impossible bc i cannot mount the /data partition. as he describes it, you should try to adb shell to your device but even adb devices does not work. and then for 1-2 seconds you are able to issue adb devices with this output:
List of devices attached
22559eb06d0d7ece unauthorized
adb: device unauthorized.
This adb server’s $ADB_VENDOR_KEYS is not set
Try ‘adb kill-server’ if that seems wrong.
Otherwise check for a confirmation dialog on your device.
but the confirmation dialog did not come.
if i was able to somehow slow down the process after unlocking the device…
yes, i managed via usb-cable reconnect and adb kill-server; adb start-server - for a millionth of a second i saw the adb debugging authorization popup. i tried five times but this is nearly impossible
as aibd linked, there are many threads covering and (at times, for specific devices) solving this with a bit of cli-fu. But for starlte / star2lte afaik there weren’t successful feedbacks on being able to mount at all and this irritation reason for the long threads.
The content of the post is interrupted by what I think is partly “quoted” where we see “post: 16” in the text. Post #16. While he seems to follow the idea of Post 16 he is guided in intermediate posts to find a Samsung location for userdata.
@tcecyk@aibd yes thank you, i read the monster threads thoroughly. the one answer with enabling adb through manipulating /system while in recovery mode was inspirative and i tried that yesterday. if only i had one more second after the full boot to confirm that i (always) trust the device = two clicks. i managed to click one (trust) and indeed on the console where i ran adb devices i saw that the device was recognized/trusted.
maybe there could be one more chance to achieve success. in the full or normal boot i also see a message that microG service could not be started. is there maybe a possibility to disable this service? say like in linux systemctl disable microg.service or just deleting a file in the /system partition that starts this service?
yeah, recovery is ok. i can boot to recovery and mount /system, enable adb - but that does not bring me further. in recovery i am not able to mount /data and thus delete something off that partition.
maybe there is a way to modify the start up procedure, disable start of microG, add some sleep/delay so that i am able to perform these two clicks to trust the usb device (pc)
I guess I was misunderstanding … Android uses space and headroom differently from Linux. system can run at 100% full … so, as I understand, it will be userdata which is the blocker. I think I might have been surprised once when a user reported uninstalling an app to clear some headroom. Maybe worth a variation on [HOWTO] Uninstall default Apps. The post details removal of a system app. Here one is attempting to remove the app for user 0 so potentially removal of Browser might take out a significant chunk of the user’s data. Untested and not a thing I have seen recommended before … might help if one thought only a small volume of “extra” space is required. (??)
Alternatively target a user installed app which is potentially a big space user.
guys, guys, guyyyyyys. there was a huge success. - there is no emoji expressing my happiness and relief. with a huge help from my daughter (14) who is really quick with her fingers we managed to klick the (always) authorize usb-debugging. and apparently there was enough space on the /data partition to persist the setting.
next time i booted normally adb devices showed the device id. during the next normal boot i managed to get files from the media folder adb shell ls -lah /sdcard/DCIM/Camera/
i picked a video with 80MB and during next normal boot i managed to delete this file and this time the device did not reboot and stayed booted. so my next move was to delete some bigger file (4,5GB).
next move will be to do a thorough cleanup and move files from 2023 and 2024 to nextcloud.
thnx a lot for suggestions i wouldn’ succeed without that.
the one answer with enabling adb through manipulating /system while in recovery mode was inspirative and i tried that yesterday. if only i had one more second
once the sonic fingers turned on always-authorize usb-debugging in boot #1, you needed a second boot #2 for the ls -lah and then a third boot #3 for the rm and then the device stayed booted. Wow, congrats to the button sniper.
Up to your comment I thought Samsung (starlte / star2lte) users had no way to recover from this, great.
- there is no emoji expressing my happiness and relief. with a huge help from my daughter (14) who is really quick with her fingers we managed to klick the (always) authorize usb-debugging. and apparently there was enough space on the /data partition to persist the setting.