Thanks for the update. I'll have a look at those commands. losetup -f is specifically not used because I have already encountered devices/recoveries where the built-in losetup does not support this flag. So just loop0 and loop1 are tried, on failure, too bad (guess that could use improvement, hehe). The same goes for the -b test for if, and the -f flag for readlink. While I have not specifically tested the block device test, I know the symlink test fails on some devices. So I need to do some testing.
This is why some things in the ZIP are done is such weird ways instead of just using standard command, they're all work-arounds for encounted recovery versions that didn't support command X or flag Y ...
If it's just regarding MultiROM Recovery versions, then I believe I can fix the loop device release, even without touching your script; MultiROM Recovery does indeed release loop devices, but after it tries to unmount the partitions first; I could rewrite that, to release /data/su.img before starting the other unmounts.
But regarding the dd command, that's going to be an issue... we could work around it with some kind of specific check just for this, but that is not ideal; I'm sure you have your reasons why to first null out the partition (not needed on my devices), before flashing the real kernel, but if the readlink & block device checks are unreliable, perhaps just limit the amount of data dd nulls out
giving dd "free reign" to null out as much as it possible can, could also be potentially unwanted for other recoveries/devices
If it's just regarding MultiROM Recovery versions, then I believe I can fix the loop device release, even without touching your script; MultiROM Recovery does indeed release loop devices, but after it tries to unmount the partitions first; I could rewrite that, to release /data/su.img before starting the other unmounts.
But regarding the dd command, that's going to be an issue... we could work around it with some kind of specific check just for this, but that is not ideal; I'm sure you have your reasons why to first null out the partition (not needed on my devices), before flashing the real kernel, but if the readlink & block device checks are unreliable, perhaps just limit the amount of data dd nulls out
giving dd "free reign" to null out as much as it possible can, could also be potentially unwanted for other recoveries/devices
Oh, I wasn't saying the changes won't happen, just that it may not be a copy/paste of what you stated.
For example, the way it will be used in the script with the expected input and output, "readlink -f FILE" can be replaced with "readlink FILE || echo FILE" twice.
Similarly, instead if "if -b" a "grep /dev/block" after using readlink should work.
Is it 100% foolproof? No. But I'll bet it'll work on every recovery/device currently out there.
As for releasing /data/su.img, I will definitely put this into the script as well. No need to patch MultiROM.
Reading again through this thread, I believe the following issues have been fixed:
- The symlink of the boot image partition to somewhere outside /dev/block is now detected, and the wipe skipped
- The loop device link to the /data/su.img or /cache/su.img file is now released after unmount
- The remount_ro section in launch_daemonsu.sh has been removed, as I now have a different workaround for the remount r/w issue
- If 'setprop sukernel.mount 1' fails to mount, a fallback attempt is made with losetup
That should cover all the issues you raised (correct me if I'm wrong), and hopefully this makes the entire thing work with MultiROM. Please do let me know
Reading again through this thread, I believe the following issues have been fixed:
- The symlink of the boot image partition to somewhere outside /dev/block is now detected, and the wipe skipped
- The loop device link to the /data/su.img or /cache/su.img file is now released after unmount
- The remount_ro section in launch_daemonsu.sh has been removed, as I now have a different workaround for the remount r/w issue
- If 'setprop sukernel.mount 1' fails to mount, a fallback attempt is made with losetup
That should cover all the issues you raised (correct me if I'm wrong), and hopefully this makes the entire thing work with MultiROM. Please do let me know
@Chainfire are you using sush to change the default path? After boot even though init.environ.rc is patched? The reason I ask is because when I switch to root user in shell and thus the shell changes from mksh to sush, my path changes and for some reason sbin isn't in either path (not as su or default shell user)
I noticed sush evaluates the default path but I don't know if this is intentional or if it's related to something I've messed up on my part
The only differences from the patched ramdisk that supersu 2.66/67 creates and my current ramdisk is that I changed the perms for /su to 750 instead of 755 and I added some paths to init.environ.rc
Code:
# set up the global environment
on init
export PATH /su/bin:/sbin:/vendor/bin:/system/sbin:/system/bin:/su/xbin:/system/xbin:/sbin:/data/local/tmp:/data/toolchain/bin:/tmp/bin
setenv LD_LIBRARY_PATH /data/vendor/lib64:/vendor/lib64:/data/lib64:/system/lib64:/data/vendor/lib:/vendor/lib:/data/lib:/system/lib:/data/toolchain/lib
export ANDROID_BOOTLOGO 1
export ANDROID_ROOT /system
export ANDROID_ASSETS /system/app
export ANDROID_DATA /data
export ANDROID_STORAGE /storage
export EXTERNAL_STORAGE /sdcard
export ASEC_MOUNTPOINT /mnt/asec
export BOOTCLASSPATH /system/framework/core-libart.jar:/system/framework/conscrypt.jar:/system/framework/okhttp.jar:/system/framework/core-junit.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/telephony-common.jar:/system/framework/voip-common.jar:/system/framework/ims-common.jar:/system/framework/apache-xml.jar:/system/framework/org.apache.http.legacy.boot.jar
export SYSTEMSERVERCLASSPATH /system/framework/services.jar:/system/framework/ethernet-service.jar:/system/framework/wifi-service.jar
@Chainfire are you using sush to change the default path? After boot even though init.environ.rc is patched? The reason I ask is because when I switch to root user in shell and thus the shell changes from mksh to sush, my path changes and for some reason sbin isn't in either path (not as su or default shell user)
I don't know either. /sbin is in my $PATH on my test device both with and without root.
The only differences from the patched ramdisk that supersu 2.66/67 creates and my current ramdisk is that I changed the perms for /su to 750 instead of 755 and I added some paths to init.environ.rc
@Chainfire regarding that hiccup (courtesy of @Captain_Throwback ) , I mentioned earlier, it seems it's back / still there.
At first we thought it's due to the size of the kernel, but turns out that's not the issue.
Trying to find the cause is proving difficult, so I'll just summarize my findings as best I can:
When installing SuperSU 2.67 from within a custom rom (twrp flashable zip), it fails to properly create the new boot.img (it's truncated for some reason):
extract of the recovery.log error
(towards the end of the SuperSU script, when it runs /su/bin/sukernel --bootimg-replace-ramdisk $STOCKBOOTIMAGE /sutmp/ramdisk.packed /sutmp/boot.img)
It says succeeded, but the log shows "Could not write data",
and the resulting boot.img is actually too small (it should be 12126208 bytes, not 12099584) and therefore corrupt (which will throw an error, since multirom can inject it's own changes into the kernel)
I've tried debugging, but results are quite confusing
1- added a sleep command just after
check_zero_def "- Creating boot image" "LD_LIBRARY_PATH=$SYSTEMLIB /su/bin/sukernel --bootimg-replace-ramdisk $STOCKBOOTIMAGE /sutmp/ramdisk.packed /sutmp/boot.img"
checked the recovery log, and it showed "Could not write data" (and incorrect size of boot.img in /sutmp)
opened an adb shell and manually ran
/su/bin/sukernel --bootimg-replace-ramdisk /dev/block/mmcblk0p42 /sutmp/ramdisk.packed /sutmp/boot.img (p42 is the same as the script is using)
--> succeeded with correct boot.img size, let the script continue and all went well
2- put the script to sleep, and manually ran all the commands from adb shell
I tried the exact same ROM without SuperSU installation chained in the installer; then immediately flashed SuperSU 2.67 afterwards, and it went through perfectly.
Also using the copy to a tmp file "wrk_boot.img", also worked fine directly in the embedded zip.
What I find most peculiar is the output of the --backup , which was done on a clean reboot into recovery, so plenty of free space
- backing up from file, yields proper size and sha1
- backing up from "fake" mmcblk, yields incorrect size and wrong sha1
---- but running sha1sum on the fake mmcblk gives the correct sha1
---- and cp from fake mmcblk, as well as dd from fake mmcblk, also work properly
As for the memory issue, I'm honestly uncertain, the device in question is the HTC One M8 (tested on GSM and Sprint variants), which reports 1.8GB space in recovery, 1.6GB free.
The ROM itself is ~500MB compressed and ~1GB uncompressed, that should still leave enough "working space" for pretty much anything
Hey @Chainfire , I've been using the context switching command to make the root commands work in my app LeanDroid. You probably don't remember but when Lollipop was new you showed me how to use your SuperSU library to switch context to system. As I understood this was in order to get around selinux restricting my root commands which involve system processes. My app calls the "phone" service through root and it seems that they only work by switching the context to system. I have been requiring my users to have SuperSU as their root, as for example CyanogenMod's built in root still isn't working. Is SuperSU still the only root option that allows context switching or can I code the call to work with other root modules as well?
Hey @Chainfire , I've been using the context switching command to make the root commands work in my app LeanDroid. You probably don't remember but when Lollipop was new you showed me how to use your SuperSU library to switch context to system. As I understood this was in order to get around selinux restricting my root commands which involve system processes. My app calls the "phone" service through root and it seems that they only work by switching the context to system. I have been requiring my users to have SuperSU as their root, as for example CyanogenMod's built in root still isn't working. Is SuperSU still the only root option that allows context switching or can I code the call to work with other root modules as well?
I have seen two roms today in N5 developer section and seems rom having stock kernel and system less root so embedded in other zip should work. Though I have not look script but just for acknowledge if @nkk71 want to explore.
I have seen two roms today in N5 developer section and seems rom having stock kernel and system less root so embedded in other zip should work. Though I have not look script but just for acknowledge if @nkk71 want to explore.
I just went through some more debugging, and the issue seems to be with sukernel when accessing files or symlinks in the /dev/ subfolder... long story short it truncates down to the nearest 65536 block size:
Code:
tst_BLOCKSIZE Original Truncated
12148736 12124160
65536 [COLOR="Red"]185.375[/COLOR] [COLOR="Blue"]185[/COLOR]
Test: 186x65536..: [COLOR="Blue"]12189696[/COLOR]
test 2: +/- 1byte: 12189697 12189695
Result...........: [COLOR="Red"]12189696 12124160[/COLOR]
I don't want to post extensive shell code of all the test's i've performed, but anything that sukernel accesses through /dev/ is truncated down to the nearest 65536 block size.
On the other hand a symbolic link from outside /dev/ to inside /dev/ seems to work:
Also worth noting, is other commands, such as dd , cp , ls , sha1sum directly into /dev/dummyfile(s) work properly, only sukernel is showing this issue.
I havent tested for MultiROM purposes (as of yet), but it shouldn't be difficult to just pad the boot.img (which in MultiROM would be a regular file) to be on the correct boundary.
Though, I felt you should need to know this about sukernel
and whether this is an expected result, or a possible bug
PS: all these tests were done in normal twrp recovery adb shell mode, nothing was being modified by multirom extensions.
Hey Chainfire, a few questions here:
-The sepolicy commit is still required to boot in enforcing, correct?
-As of 2.67, it's still required to re-bump after flashing on LG devices, correct? If so, wouldn't a simple solution be to just add an additional zip to the main OP which re-bumps it?
I had a few more as well, just can't remember them off the top of my head :-/
Hey Chainfire, a few questions here:
-The sepolicy commit is still required to boot in enforcing, correct?
-As of 2.67, it's still required to re-bump after flashing on LG devices, correct? If so, wouldn't a simple solution be to just add an additional zip to the main OP which re-bumps it?
I had a few more as well, just can't remember them off the top of my head :-/
That commit is only required if you want a system-based su installation. It's not needed for system-less root. It's still in testing, though.
Bumping is still required for the G3. Not sure about any other LGs. However, SuperSU does allow for a post-boot-image-patch script to be executed, I'm surprised nobody has made a ZIP yet that simply installs this script and makes all future flashes auto-bump the image.
THIS THREAD IS FOR DEVELOPERS ONLY. IF YOU ARE NOT A DEVELOPER (or very tech-savvy and well-versed), MOST LIKELY YOU SHOULD NOT POST HERE.
By request, I am creating this thread for developer discussion. This is the place for developers to ask questions about how to handle/implement/embed SuperSU, discuss the operation of SuperSU, suggest improvements to compatibility, etc.
This thread hopefully reduces important developer related matters from being buried in the more user-oriented threads.
Please always include the version number of SuperSU you are referring to, even if it's the latest version right now. If applicable, also include information about phone and firmware you are testing with.
The stop-gap solution is to disable this caching completely, which is what the 000000deepsleep script does, which you can find mentioned or quoted in many posts around the forum. From SuperSU 2.66 onwards, that script is automatically installed on Samsung devices when systemless root is used.
Please forgive me for posting (in a cf-auto-root thread) and digging afterwards. I had thought I'd just dump the info and forget about it, but I couldn't stop digging...
...which led me to the quoted material.
Digging in the supersu 2.66 update-scriptbinary, I see that you're detecting "samsung" in the build fingerprint, and if true, doing a systemless install AND applying a deepsleep fix. This works for Galaxy S6 devices, but not for some other similar platform devices. In particular, the Note5 has THREE devices that need caching disabled in order for deep sleep to function. (0:0:0:3 as well as :2 and :1.)
My first question is: does the SGS6 even have a file named "/sys/class/scsi_disk/0:0:0:3/cache_type"? If not, just write to all three files and don't worry about it. The third write would fail on the SGS6 and all would be good. It'd be no worse of a work-around than already exists (and I think it's a bad work-around.)
If that file DOES exist in the SGS6, then something would have caching turned off that really shouldn't. Of course, existing or not, automatically tossing in this deepsleep patch for every single device that has "samsung" in the build fingerprint would seem likely break proper caching in some yet unknown samsung device. Perhaps the SGS7 will change things up so that :1 should be left cache flushable, and :2 would be the only one that should block cache flushing.
As well, it's also possible that Samsung will pull in the kernel fix to resolve this issue before they release Android M. (Okay, perhaps it'd be more likely for Samsung to open source touchwiz... but we can always have fantasies.)
My problem with the work-around is expressed above: it can break something in the future (and cause a support headache when some ONE exynos7420 device is fixed, but the rest aren't.) As well, it sets precedent of having platform specific hacks in the generic update.zip (but only allowing for a single platform and not in an easily expandable way.)
Obviously, it would be a maintenance nightmare to have different "00000deepsleep" files for every different device model. (if 'zerolte.*', SGS6. If 'nobellte.*', Note5, etc.)...
In keeping with what I tell other people, I feel I now have an obligation to suggest A Better Way. (a person shouldn't complain about something unless they can make a reasonable suggestion on how it'd be better.)
So, here's my slightly convoluted (but expandable) suggestion:
You currently use /data/.supersu to read certain variables that modify the supersu.zip installer script. Perhaps those "platform specific lines" could be added to that file, and the installer script would put them in place. So, I could do the following in a recovery root shell before installing supersu.zip:
(I'd have included both (or all three) needed lines for samsung deep sleep, but I forget how to include CR in a shell cmdline.. )
Then, the supersu installer script would just read PLATFORMSTARTUP and write it's contents to /su/su.d/00000platformstartup (and set perms.)
Given this type of thing, the existing 000000deepsleep hack would be removed. Then, individual devs could easily create simplistic "pre-installers" for supersu for specific platforms that need changes. Those "pre" installers would just write the needed PLATFORMSTARTUP lines to /data/.supersu...
... and then supersu.zip no longer needs platform specific hacks.
Some random XDA developer could then generate a simple "SGS6-supersu.zip" would only contain an edify script to mount /data and add/edit the .supersu file's PLATFORMSTARTUP variable to contain the two lines needed for deep sleep (and another dev could write a Note5 for the 3 lines needed on that platform... and so on..)
The only problem with that is that it requires users to have two brain cells to rub together. We've seen time and time again on these forums that you can't assume this is always the case.
I think that Chainfire is doing pretty much the right thing here. At worst, disabling write-back caching will make I/O a bit slower, but that's better than not having deep sleep.
The problems with the existing solution are:
1. It blindly alters the system kernel behavior for every single device samsung manufactures.
2. It only actually does any good for a single one of the dozens of devices from that sam manufacturer.
3. It completely ignores every OTHER device that might need a bit of help (and potentially does more harm than good for those devices.)
4. It encourages device developers (users on XDA) to download SuperSU.zip and re-package it to have device specific hacks in the .zip archive (creating a mess.)
Actually, I don't think I need to explain all the problems with the existing hack. I'd imagine (hope) that it was done as something quick to test out an idea, and was never intended to be left in place in it's current form.
Which 5 devices? Who maintains that list? Who updates it for each firmware change that might require an update? Will there be a new "SuperSU.zip" package each time a firmware change on a device requires that one of those 5 be changed? Who deals with the support nightmare of saying "use SuperSU v a.bc for device X firmwawre Y" and "superSU v d.ef for device X firmware Z", etc?
My proposed solution takes all the device-specific stuff completely out of the SuperSU package. It changes it from a device-specific solution to be a more generic and expandable solution that requires LESS support from SuperSU and places the device specific burden outside.
Instead of encouraging device developers to repackage supersu to device specific packages, it encourages device developers to package something else alongside supersu that would work with the existing (and unaltered) supersu.zip (and would be future compatible.)
Hello @Chainfire, I'm the original author of systemless Xposed.
Recently I released a systemless Xposed based on your latest 2.76 version, which loads on post-fs-data if possible. [UNOFFICIAL][v86.0][July 12] Systemless / System Universal Compatibility Xposed
Several users reported that Xposed won't work on secure boot enabled devices (require password to boot up). By viewing the boot logcat, it seems SuperSU is not able to load on post-fs-data is this specific situation (I assumed it because there are other processes running at the same time when su.d scripts are executing, however no logs from SuperSU has shown. Although you did log which mode SuperSU is running in "log_print", launch_daemonsu.sh only logs in very few situations like image merging, apk moving etc., which in most cases there will be no logs showing which mode SuperSU is running with in logcat)
By viewing your scripts and the result boot image, I see you used similar techniques I used in my previous systemless Xposed versions to load in post-fs-data. However in my previous systemless xposed versions, I can handle secure boot devices. A wild guess is that you placed init.supersu.rc in the last of the import lists in init.rc, but other factors might cause daemonsu to fall back to service too, I'm not sure.
