Sent from my GT-I9301I using XDA-Developers mobile app
I tried it on my tablet and, yes, TWRP correctly resized the image. Thanks.
I'm aware that TWRP has its own binaries, but the image resizing that SuperSU 2.76 natively attempts is performed, as far as I can tell, by /sbin/launch_daemonsu.sh.
Looking inside that file, resize2fs is called without a path, so whichever $PATH is in effect at the time is the one that is used. That presumably results in the ineffective invocation of /system/bin/resize2fs on these Samsung devices.
I don't have TWRP on my S7 Edge, so I'll have to either install it or look up how to create a flashable ZIP for FlashFire if I want to resize the image on that device as well.
Actually, now that I think about it, TWRP won't even work on the S7 Edge, because /data is encrypted.
But this has nothing to do with FlashFire, I thought. /sbin/launch_daemonsu.sh is part of SuperSU and is run at boot time, I think. Or am I wrong about that?
I've just created a flashable ZIP for FlashFire and gave that a shot, but that gives resize2fs: command not found.
I suppose I could just enlarge su.img on my laptop and then copy it back into place from the SD card (via a FlashFire ZIP). I'm not sure whether that has any hidden dangers, though.
v2.76 released !
(Google Play release later today by CCMT)
Changelog: post #3
CCMT is starting to take over development, and will soon also take over support in these XDA threads as well. The ZIPs linked from the XDA threads for download from my server (chainfire.eu) have always been checked, built and uploaded by myself. It may well be that v2.76 is the last version where this is the case.
Regarding bootloop, note that SuperSU ZIP install can reboot twice.
Unfortunately, sometimes one of the reboots inside the cycle may cause a file on /data to become corrupted, which in turn can cause another reboot and/or a boot freeze, which you can get out of by manually rebooting. I've only seen this happen on Samsung devices, by the way.
Additionally, xposed may trigger a reboot and automatically disabled itself in case of some issue as well. This might be a cause for an extra loop as well as the reason you needed to reinstall it.
Good news coming on that front soon.
Hearing about successes is good, especially from users that have seen problems in the past.
I wish I wrote bugfree code, but alas I do not. Memory leak tracking is tricky and time-consuming with su's daemon, and the big leak fixed in this case originates in libc, so allocation trackers didn't even catch it.
Enable compatibility mode (BINDSYSTEMXBIN flag), modify /system and touch /system/xbin/su, or wait for an update. ES File Explorer update is coming soon, at least.
To be updated to 96M your su.img needs to be exactly the original size, and you need to update SuperSU through the ZIP installer.
2.65 works just fine and I was able to flash that without issue and get root. Just curious to why this is happening and if anyone wants any logs to help troubleshoot the issue, just let me know what you need. Maybe it's a known issue and I can't use 2.76 but I didn't see that anywhere either.
|root, super user functions|
|Thread Tools||Search this Thread|