Related
Hi all !
I'm new to custom kernel building, and after fairly long searches across the net, I still have some questions. About initramfs first, how do I build an initramfs image compatible with my kernel ? Which files should absolutely be included ? Any (Android-oriented) documentation on this ? I'm able to unpack a zImage and extract the corresponding initramfs, but should I modify some of the files before including them in my custom kernel (besides the modules) ?
Also, as far as I understand, the recovery image is included in the initramfs. If I want to change the recovery (to CWM, say), how should I do : nothing else than changing recovery related files ?
Then, I have found that there is the j4fs.ko module that is included in the Samsung stock kernels I've seen (KK9 and LB1). However, when I compile my kernel from the Samsung's sources, I do not get that module (and I don't find any corresponding sources). Any idea where I could find them, and if j4fs is necessary ?
Thank you !
how to update Kernel ?
Anyone ?
All discussion should go the SuperSU BETA thread
Attached find modified boot.img for the Nexus firmwares released so far. Together with SuperSU v2.50+ these allow root with SELinux in Enforcing mode.
These are the stock boot images from Google, with the ramdisk modified as follows:
- patched sepolicy
- disabled dmverity (if applicable)
- disabled forceencrypt (if applicable)
Rooting procedure:
- flash/upgrade to Marshmellow
- flash modified boot.img
- flash/boot TWRP and sideload latest v2.50+
Acquiring root without modifying the boot images is still under investigation. Please note that the current method will not be officially supported. Future roots may require a clean system: we are at a very early stage of root for 6.0, methods used are subject to change.
For the modders, you can do the sepolicy modifications yourself as follows:
- root a reference device (4.4+ with SELinux enabled) with v2.50+
- extract the sepolicy file from the target boot image's ramdisk
- with the reference device connected to ADB:
Code:
adb push sepolicy /data/local/tmp/sepolicy
adb shell su -c "supolicy --file /data/local/tmp/sepolicy /data/local/tmp/sepolicy_out"
adb shell su -c "chmod 0644 /data/local/tmp/sepolicy_out"
adb pull /data/local/tmp/sepolicy_out sepolicy_out
- replace the sepolicy file in the boot image's ramdisk with the sepolicy_out file
- profit
(this trick should also work on the Samsung 5.1.1 kernels that people are having issues with lately)
Fugu requires v2.51+
EXPERIMENT: Root without modifying /system
EXPERIMENTAL, ARE YOU SURE YOU WANT THIS ?
All discussion should go the SuperSU BETA thread
Idea
To have root on modern Android versions, we need our files to be executable and our daemon to be started on boot. We normally do this by making modifications to /system, tapping into binaries and scripts executed by init. If we're also modifying the boot image, then we should be able to do all this without modifying system at all. A benefit of this is that it makes OTAs easier - reflashing the boot image is less hassle than reflashing system.
As the binaries should still be updatable, and we don't know the space we have available in the boot image itself, we're mounting a (writable) ext4 image with /su as mount point from /data, and modifying PATH accordingly. Interestingly, for reasons yet unknown to me, if the image is mounted r/o by init, later remounting it r/w causes a bunch of issues. So we're keeping it r/w (for root) for now.
An overlayfs/unionfs solution would be even more ideal, transparently placing files in /system without modifying the actual partition, but I have not been able to find one that is (a) compatible with all Android architectures and (b) not kernel dependent and (c) not GPL - or even just one of those requirements, really. It's technically all possible, it just needs to be done.
Caveats
- Apps with hardcoded paths to su (seriously?) will bork
- Factory reset unroots
- Factory reset wipes pin
- ...
- Bugs... Bugs everywhere!
Instructions
You must absolutely re-flash your stock /system partition, or the separate root instances will interfere with eachother. The installer for this experiment will not clean up old root files.
- Flash stock /system (and /vendor and /oem, if present)
- Flash the attached boot image
- Flash the attached SuperSU ZIP in TWRP
Ramdisk modifications
- include (post above this one)
- init.rc (devs: please open file for reference)
--- on init
------ mkdir /su ...
--- on post-fs-data
------ copy image from cache to data (for rooting without access to /data in custom recovery)
------ mount image to /su
--- service daemonsu
- init.environ.rc
--- export PATH, prepended with /su/bin
- file_contexts
--- /su(/.*)? ubject_r:system_file:s0
NOTE
- Not all SuperSU options are supported yet in this mode
- I have not tested with encrypted devices
- /system should never be remounted r/w, I hope I didn't miss anything here
- Root with modifying /system is also still operational. I can't predict what the exploiters will need.
- I'm not sure where we're going with this. Future roots may require a clean system.
BETA-SuperSU-v2.56-20151030013730.zip
Changes
(The changelogs for the specific SuperSU versions can be found here: http://forum.xda-developers.com/showpost.php?p=23427824&postcount=3)
2016.01.21
- v2.67 ZIP
2016.01.03
- v2.66 ZIP
2015.12.26
- v2.65 ZIP
2015.12.20
- v2.64 ZIP
2015.12.11
- v2.62-3 ZIP:
--- (systemless) ZIP: Fix calling wrong script name for custom patcher script
--- (systemless) ZIP: Improve APK overwrite
--- (systemless) ZIP: Do not move backups from /cache to /data, just copy them
(there are no changes to SuperSU itself compared to v2.62, just minor script changes in the ZIP)
2015.12.10
- v2.62 ZIP
2015.12.07
- v2.61 ZIP
2015.12.05
- v2.60 ZIP with automated boot image patcher
2015.10.30 #2
- Added systemless root experiment for other Nexus than hammerhead
2015.10.30
- Added systemless root experiment for hammerhead
2015.10.28
- Added Angler kernel
- Added Razor mra58u kernel
2015.10.20
- Added Bullhead kernel
2015.10.08
- New image for Fugu, requires v2.51
2015.10.07
- New images, should fix the factory reset issues some users with encrypted data were seeing
EXPERIMENT: Root without modifying /system #2: Automation
EXPERIMENTAL, ARE YOU SURE YOU WANT THIS ?
All discussion should go the SuperSU BETA thread
Continuing on the previous post, here is SuperSU v2.62 BETA, with automated boot image patching. It's been tested by myself on various Samsung's running anything from 4.3 to 5.1, and all of the recent Nexus devices on 6.0. Even on CM13. Other users have tested it with success on various other devices.
If you are coming from any SuperSU install in /system, you must re-flash the stock system (and vendor and oem, if present) partition contents prior to installing this.
If you are coming from a SuperSU 2.56 system-less install, you must re-flash the stock boot image prior to installing this.
If you are coming from a SuperSU 2.60 system-less install, or were not rooted at all, then you can just flash the ZIP without any special prior instructions.
If TWRP offers you to keep /system read-only, indeed keep it read-only.
If TWRP tells you SuperSU is not installed, and asks you to install it, do not do it, you will break things!
If on Android 6.0 or Samsung 5.1, the ZIP installer will install SuperSU in systemless mode and patch the boot image. The boot image patcher currently only supports gzip compressed ramdisks and the standard Android boot image format. Some devices do not use the standard format, and many custom kernels use a compression other than gzip. A backup is made (/data/stock_boot_<sha>.img.gz) of the original boot image before patching it.
Further implementation details (including an updated list of changes to the ramdisk) are explained in the installer script itself, as usual.
Notes on 2.62+
A poor man's overlay is used on /system/xbin. We are creating a copy of /system/xbin in /su/xbin_bind, adding a symlink to /su/bin/su there, then mounting the entire thing on top of the original /system/xbin. This is likely to fix some compatibility issues with some apps, without actually modifying /system. Removing /su/xbin_bind and rebooting will disable this feature, or "echo BINDSYSTEMXBIN=false>>/data/.supersu" in recovery root shell before a SuperSU ZIP flash.
If you have one of those devices that refuse to remount system r/w in Android such as the Nexus 6P, but you do want to do this, "echo FSTABSYSTEMRW=true>>/data/.supersu" in recovery root shell before a SuperSU ZIP flash will patch the boot image in such a way that remounting will work. This feature itself breaks OTA compatibility, regardless of if you end up writing to /system or not.
Both of these features are likely temporary.
Notes on 2.64+
There have been a lot of changes to the ZIP installer. Hopefully they won't break a lot of installs. If 2.64 works well, it is likely to be promoted to the "main beta" in place of 2.52, and the How-To SU document will be updated with the relevant information.
A major change in setup is that the ZIP installer will try to detect 6.0 firmwares that can be rooted without doing a systemless install. In other words, a root that modifies only /system, but not the boot image. If this is possible, the installer will install into /system (unless you override via "echo SYSTEMLESS=true>>/data/.supersu").
This may catch (a) firmwares that allow sepolicy reloading from /data but have a locked bootloader and (b) custom firmwares setup to handle this. Regarding the latter, while it is not as clean as systemless, those running custom firmwares are more likely to want to modify /system anyway, it is less likely to mess with updates to those firmwares, and it prevents the necessity of reflashing the ZIP after each kernel switch. Of course, the kernel's SELinux policies must support this! See this thread for details for devs.
Notes on 2.65+
As 2.65 adds /su/xbin, I recommend flashing the ZIP rather than installing the APK from the ZIP, as some people tend to do.
Notes on 2.67+
I recommend flashing the ZIP rather than installing the APK from the ZIP, as some people tend to do.
Downloads
BETA-SuperSU-v2.60-20151205163135.zip
BETA-SuperSU-v2.61-20151207213702.zip
BETA-SuperSU-v2.62-20151210170034.zip
BETA-SuperSU-v2.62-2-20151211155442.zip
BETA-SuperSU-v2.62-3-20151211162651.zip
BETA-SuperSU-v2.64-20151220185127.zip
BETA-SuperSU-v2.65-20151226141550.zip
BETA-SuperSU-v2.66-20160103015024.zip
BETA-SuperSU-v2.67-20160121175247.zip
The latest WIP version has become the main BETA version.
For all intents and purposes, this thread is closed. It will be cleaned up and unstickied in good time.
Changelog:
V5.23 Fix for Android 6 (Freeze on boot logo)
Installation of kcal kernel module for supported kernels. Get the app from https://forum.xda-developers.com/android/software-hacking/dev-kcal-advanced-color-control-t3032080
V5.22 Bug in the vendor overlay creation. Existing directories (like /vendor/bin) have not been replicated correctly
V5.21 Fix issue when running on Linux (some CR/LF)
Patch libsepol in bootimg for backwards compatibility with Android 6
V5.20 Support for superuser as an alternative to SuperSU (https://github.com/phhusson/Superuser)
Fix for the missing internal storage link in TWRP
V5.11 Support for Android 7.0
Fix in the overlay layout which could prevent some libraries from loading and cause battery drain
V5.1 Support for Android 7.0
Updated bootimg to deal with Android 7.0 policies
New tool inside bootimg for adding new contexts to binary file contexts
New system overlay layout due to a more restrictive linker in Android 7
V5.0 New system overlay method using the /vendor directory. As this directory is also in the library search path even libraries can be easily replaced without modifying the system partition
System-less SuperSU integration improved (Version 2.76 or higher recommended)
System-less xposed integration (using the standard distribution)
Support for 32.A.0.253
V4.51 Fix for awk script for Linux kernel version detection when running on Linux
V4.5 Fixed adb and mtp file access in TWRP for 32.2.A.0.224
V4.42 Added support for Z2 (Sirius) and TWRP fstab fix for leo and aries (thanks to waleedsq81)
V4.41 Fixed issue with Y/N choice on non-english Windows. Added support for Z3 (leo)
V4.4 Support for Z3+/Z4, Tablet Z2, Tablet Z3 and Tablet Z4 added (Z4 still has an issue with TWRP, but DRM fix works)
SuperSU integration reworked in order to need less SELinux exceptions and to be more secure
All tasks can now be individually selected. Therefore there is no separate DRM only script required
V4.31 Renabled Z5P (satsuki) and Z5C (suzuran) for TWRP and drmfix
V4.3 Support for older Lollipop added
Script execution for Linux fixed
V4.24 Fix for for a bug in SuperSU integration in V4.23
V4.23 Fix for repacking 3rd party kernel (Some permissions were on custom directories were lost)
V4.22 Bugfix for readta (flash_dk reported unit not)
V4.21 Fix for the Linux binary of bootimg
V4.2 Updated TWRP to 3.0.2
V4.1
Fix for WideWine (if you have your device key) Thanks a lot to goofnorf101 for testing
unpackinitfs and makeinitfs in my bootimg tool now maintain date/time of files correctly
Automatic SuperSU installation
V4.0
Fix for older kernels (Lollipop)
Binary for Linux (The older version had the ARM version packaged)
Device is not stored in the kernel image anymore
TWRP updated to version 3.0.1
FAQ - Please read
Is is possible to have root with locked bootloader?
Short answer: no
Long answer: The locked bootloader only boots unmodified kernel packages signed by Sony. The stock kernel only mounts unmodified /system partitions (dm-veritiy) -> No modification without unlocking
So any change to the kernel (like this script) or system partition requires unlocked bootloader
What is dm-verity?
A hash checksum on all blocks of a filesystem in order to verify the integrity
What is Sony RIC?
A protection to avoid mounting the root filesystem or system read/write
What happens if I unlock my bootloader
The device key (TA unit 0x1046b) will be wiped, which deactives everything DRM related. In addition a full wipe of your phone will be perfomed.
So extract your TA partition before with this great tool http://forum.xda-developers.com/crossdevice-dev/sony/iovyroot-temp-root-tool-t3349597 from zxz0O0
If you already unlocked the bootloader before, then at least the credentials will be restored, which will reactivate stuff like x-reality and camera de-noise
Why do I need to flash my device key?
Without your device only some functions can be reactivated, like x-reality. Other functions like widevine do not work with out your device key.
How do I enter TWRP recovery?
Restart your phone and press the volume key up as soon as the LED switches to yellow
I want to use a custom kernel with the DRM fix
Just say "N" to all other options. Nevertheless be prepared for problems if the custom kernel does not match your Android version.
What should I do if there is an update to this script?
First check if you really need to run this update by checking the changelog. E.g. if it says binary for Linux fixed and you are using Windows then probably you don't care. If you did not change your Android version then all you have to do is to update the kernel package with fastboot flash boot. If you do not use the automatic SuperSU integration then you have to reinstall SuperSU in TWRP.
This tool repacks an existing kernel package (usually the stock kernel) in order to make it rootable and adds TWRP recovery as well. Version 4 has been succesfully tested with LP and MM.
In particular it adresses the following issues:
DM-Verity: Android is now using dm-verity to verfy the integrity of the system partition. Until you switch it off your phone won't boot after modifying /system
SONY RIC: RIC is blocking the write access to the system partition
DRM Keys: After unlocking the bootloader your device key is wiped, which deactivates some functionaliy. E.g. x-reality, denoise in camera aso.
Recompiling the kernel is not required as only the init ramdisk needs to be modified. You can run these scripts either in Windows or Linux.
Thanks to the excellent work of zxz0O0 you can now backup the TA partition before unlocking the bootloader with this tool http://forum.xda-developers.com/crossdevice-dev/sony/iovyroot-temp-root-tool-t3349597
If you managed to backup your TA partition before you unlocked the bootloader then this version will fully reactivate your keys as well. (many thanks to addicted1900 for helping me with the testing)
As there has been some confusion I would like to point out one more time that you cannot run any kernel package which is not signed by Sony without unlocking the bootloader. So this works only with unlocked bootloader.
As it seems that it is not clear to everyone I also want to mention that <...> is a placeholder. E.g. <extracted kernel> means that you should replace it with then name of your extracted kernel, which could be kernel.elf
There was a report that having SuperSU in the system partition installed may lead to a bootloop. Therfore you shoud first install the bootimage created by this script and then install SuperSU afterwards, as it will then use the system-less strategy.
In order to use these scripts you need the kernel boot image of your current version. There two different ways to obtain it:
Method1:
If you have a .ftf image then open it with zip application (7Zip, WinZip, Windows Compressed Folder) and extract kernel.sin. Afterwards use Flashtool -> Tools -> SIN Editor to extract the kernel. You should end up with the boot image with extension .elf.
Method2:
Run your favourite recovery and connect via
Code:
adb -d shell
Now run
Code:
find /dev -name boot
dd if=<output of the find command before> of=/sdcard/kernel.img
Once you have the kernel image you are ready to use the script.
The newest version support superuser as an alternative to SuperSU. This is available open source and can be verified. In order to integrated you need the current superuser.zip from http://superuser.phh.me/superuser.zip and to be install the app afterwards from Google Play (look for superuser phh) or build it yourself from github.
To integrate the kernel part just place superuser.zip in the rootkernel directory.
You can also still use SuperSU, although it is causing a huge battery draining on my Z5 with Android 7.0 If you place SuperSU in the same directory (SuperSU*.zip, case sensitive) then it will be also installed automatically . It did all the tests with 2.76, but newer versions should work as well. Please be aware that you can not update SuperSU within the application. For a newer SuperSU version you need to rerun the script.
If you want to integrate xposed as well just place the distribution for you device and Android version in the same directory. (e.g. xposed-v86-sdk23-arm64.zip). Only support with Android 6.0 (sdk 23) and higher.
xPosed for Android 7.0+ is still not available.
Code:
rootkernel <extracted kernel> boot.img
You are prompted for several choices:
Sony RIC is enabled. Disable?
I prefer not to disable it in order to keep my phone more secure. Unfortunately there are a lot of bad guys in this world and SELinux and RIC still can save us if someone discovers a new kernel exploit.
Sony RIC basically prevents mounting the /system partition for write. You can still modify it in recovery of of course, but if you require write access to /system without entering recovery then you need to disable it.
Install TWRP recovery? Here you should say yes unless you are trying to patch a non-stock kernel, which comes already with a recovery
Install busybox? For security reasons I prefer not to install. In recovery you have it anyway. This choice is only available if you chose install TWRP
Found SuperSU-v....zip. Install? Integrates SuperSU. For this option to show up you have to place the SuperSU package into the same directory with the name SuperSU*.zip (case sensitive)
Found superuser.zip. Install? Integrates superuser. For this option to show up you have to place superuser.zip into the same directory (case sensitive)
# Make su permissive (Permits any action as su)? This only appears if you install superuser. Permissive means you can anything as root, without it is restricted mainly to file operations (sufficient for e.g. Titanium Backup)
Found xposed-v....zip. Install? Integrates xposed system-less. For this option to show up you have to place the xposed for your device and Android version into the same directory. (e.g. xposed-v86-sdk23-arm64.zip)
Install DRM fix? Installs the DRM fix. First it tries to use the device key which you flashed with flash_dk. If it does not exist it uses an alternative method which cannot fix everything (e.g. Widevine will not work, but X-reality, Camera denoise etc. will work)
Now put your phone into fastboot mode (Volume Up + connect USB) and then run:
To test it without actually flashing it:
Code:
fastboot boot boot.img
For flashing it:
Code:
fastboot flash boot boot.img
If you managed to backup for TA partition before then you can reactivate your original device key as follows:
Code:
flash_dk <ta backup image> DK.ftf
Flashing this file with flashtool will write your device key to an alternative unit, from where the drmfix library will pick it up.
This is a one-time task. It will survive a complete reset of the phone or Android system upgrade. The device key has a length of just 16 bytes, so it is correct that the resulting DK.ftf has a size of only aprox. 500 bytes.
If you like my work you can buy me a coffee
Some background information:
There are two main tools involved (for both Android and Windows)
- busybox
Probably everyone knows it
- bootimg
A multicall binary with several tools for unpacking and packing the boot image as well as adapting the SELinux policy. Part of the code is written by me from scratch, some other parts are cherry picked from other projects. I will also provide the source for it. As Windows doesn't have softlinks I modified the tools for unpacking and packing the init ramdisk to write text files with __lnk__ at the end instead.
Would be great if someone shared E6653 stock .200 kernel boot.img or flashable zip so we can try this out
Funkmasterchilla said:
Would be great if someone shared E6653 stock .200 kernel boot.img or flashable zip so we can try this out
Click to expand...
Click to collapse
Do you want the kernel.sin of stock . 200?
lordriguez said:
Do you want the kernel.sin of stock . 200?
Click to expand...
Click to collapse
I am downloading the whole firmware again from xperifirm. Thank you mate !
Edit: Working great! I'll stick to stock kernel now since Androplus' consumes more battery while asleep !
Edit2: I successfully flashed recoveries in command window from my PC but can't access TWRP at boot though, no LED flashing.
Edit3: Ok that's cuz there's no recovery boot script obviously, my bad. That's above my pay grade, if somebody is kind enough to create a stock. 200 with recoveries it'd be much appreciated PM me if so
Edit!: I flashed monx new stock based kernel
Thank you Tobias !
tobias.waldvogel said:
Hi everyone,
as most of you know, even after unlocking the bootloader there are a few more requirements before you can modify the system partition, i.e. install SuperSU, xposed etc.
- Android is now using dm-verity to verfy the integrity of the system partition. Until you switch it off your phone won't boot after modifying /system
- SONY RIC is blocking the write access to the system partition
The good news is, that it is not required to recompile the kernel. It is sufficent to modify the init scripts inside the init ram disk. So you can just stick to the stock kernel.
I created a package which precisely does this job for you. Just run it from TRWP after installing a new Android version
With this you don't have to wait anymore until someone creates the right kernel package for your phone
PS: It leaves a copy of the new boot image in the internal sdcard if you want to save it somewhere. (boot.img) It can be flashed with fastboot if required.
Click to expand...
Click to collapse
Hmm... I don't understand what this zip file do with phone.... Can you explain more primitive for me?!
Is that for recover stock kernel with stock drm keys?! I understand correct?!
zavpasha said:
Hmm... I don't understand what this zip file do with phone.... Can you explain more primitive for me?!
Is that for recover stock kernel with stock drm keys?! I understand correct?!
Click to expand...
Click to collapse
Before you can start to install thing like SuperSU and xposed you have to change the kernel, otherwise your phone won't boot anymore. In the past you had to wait for someone to come up with a compatible kernel for your phone, now this package just converts your existing kernel.
Regarding the DRM please install the package from the DRM restore thread.
Funkmasterchilla said:
I am downloading the whole firmware again from xperifirm. Thank you mate !
Edit: Working great! I'll stick to stock kernel now since Androplus' consumes more battery while asleep !
Edit2: I successfully flashed recoveries in command window from my PC but can't access TWRP at boot though, no LED flashing.
Edit3: Ok that's cuz there's no recovery boot script obviously, my bad. That's above my pay grade, if somebody is kind enough to create a stock. 200 with recoveries it'd be much appreciated PM me if so
Edit!: I flashed monx new stock based kernel
Thank you Tobias !
Click to expand...
Click to collapse
Thanks for the feedback. Future versions of this package will add TRWP as well. I am currently working on it.
tobias.waldvogel said:
Thanks for the feedback. Future versions of this package will add TRWP as well. I am currently working on it.
Click to expand...
Click to collapse
As promised the new package with TWRP is out
tobias.waldvogel said:
As promised the new package with TWRP is out
Click to expand...
Click to collapse
Great work thanks ,
How would I go about disabling the vibration for recovery?
Sent from my E6653 using Tapatalk
Well, the script which checks if recovery should be started is bin/init inside the zip. If you don't like the vibrate then just remove the line and run the package again
Gesendet von meinem E6683 mit Tapatalk
huh, so it is possible to have 2 recoveries at the same time? (and why would anyone want 2 recoveries? )
Three Recoveries are als possible
CWM, Phils Touch & TWRP
Sent from my E6653 @ XDA Portal
Sorry for being noob.
I miss my Oneplus one where things were so easy.
After unlocking BL what do i do with this zip.
Is it going to Root my phone and Install TWRP?
Thanks for help.
I flash the v2 and i got bootloop. 4 time red LED and the phone reboot and all over again. What's the problem?
Hi Tobias,
can you please build a v2 for the z5 compact too?
thx
stiffmeister
FakeSmile said:
I flash the v2 and i got bootloop. 4 time red LED and the phone reboot and all over again. What's the problem?
Click to expand...
Click to collapse
On which model did you use it and with which firmware version?
If you used flashtool before then you can just flash the kernel one more time (i.e. deselect everything else).
stiffmeister75 said:
Hi Tobias,
can you please build a v2 for the z5 compact too?
thx
stiffmeister
Click to expand...
Click to collapse
This should work on Z5 compact with stock kernel as well, without any change.
In case of any issues you can flash the kernel again via flashtool
If it did not work you can pass me the generated boot.img from your interal sdcard for further analysis
hi tobias,
i didn't try the v2, because i thought, that the twrp recovery wouldn't be compatible.
but when you say it's ok, than i'll try it
br
stiffmeister
stiffmeister75 said:
hi tobias,
i didn't try the v2, because i thought, that the twrp recovery wouldn't be compatible.
but when you say it's ok, than i'll try it
br
stiffmeister
Click to expand...
Click to collapse
I flashed zombie kernel without making backup of stock kernel, can you share it with me so I can try this method (I doubt it will work on zombie)
ps : I have .200 fw
tobias.waldvogel said:
On which model did you use it and with which firmware version?
If you used flashtool before then you can just flash the kernel one more time (i.e. deselect everything else).
Click to expand...
Click to collapse
E6653 on .200 firmware
I have a few apps that won't function on my phone because they can detect the root, but Magisk is unable to hide the root because my kernel does not support mount namespace. Are there any custom ROMs/kernel that have this functionality backported or is the phone simply too old?
From Magisk:
Mount namespace issues
If you see this line in the Magisk log/magisk_debug.log (see "Asking for help/reporting bugs"): "proc_monitor: Your kernel doesn't support mount namespace", your device has a Linux kernel that is to old. The Linux kernel version have to be at least 3.8 (thank you TheCech12), or otherwise have the necessary features backported. Ask in your ROM/kernel thread or try a different ROM and/or kernel.
Click to expand...
Click to collapse
if you are using a marshmallow rom there's this kernel. i use it, magisk works, and safetynet tests clean
One of the things I missed most since moving to Oreo and Pie on the Note 4 has been trying out the new ROMs without having to mess with my daily driver setup. After a ton of research and some training on building ROMs from source, I was finally able to make Android Pie boot from any slot on Dualboot patcher. *
What you need?
* An Android Pie ROM
* Android Image Kitchen (AIK)
* modified device tree binary (dtb)
* a text editor
* RAR or some other zip file manager.
Instructions
1) Download and extract AIK from https://forum.xda-developers.com/showthread.php?t=2073775
2) extract the boot.IMG from your ROM to the same folder where you extracted AIK.
3) unpack the boot image using the unpackimg.sh script. This will create a split_img folder and a ramdisk folder.
4) go to the split_img folder and delete boot.img_dt (or boot.img_dtb depending on which version of AIK you are using).
5) copy the attached dtb.img file to the split_img folder and rename it to the original file name (boot.img_dt or boot.img_dtb)
6) go to the ramdisk folder and edit fstab.qcom. change this line:
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait,recoveryonly
To this:
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1,discard wait
7) still in the ramdisk folder, modify init.qcom.rc. change this line **:
mount_all fstab.qcom
To this:
mount_all /fstab.qcom
8) go back to the AIK folder and run repacking.sh. this will create a file called image_new.img.
9) rename image_new.img to boot.img
10) replace the boot.img in your ROM zip file with the new one you just created.
Now you can use DualBoot Patcher to patch the ROM file for any slot and flash the patched file.
Just a few extra notes here:
* I only built these images for Android Pie for Snapdragon Note 4 devices. Make sure you use the the correct file for your device.
** in step 7, I noticed that some ROMs have an earlymount flag. You must delete that flag, otherwise the phone reboots to download mode.
***If anyone has any ideas to make this a flashable process, let me know. I would push these change upstream, but I don't know know enough about Git to do that. And, I don't know if the other devs want these changes.
Ok, so that was the manual way, but these changes can also be added to the kernel and boot image files at the time you build your ROM. Here is where you make the changes:
In the kernel, go to the dts sources. The file to modify is this one:
kernel/samsung/apq8084/arch/arm/boot/dts/qcom/aps8084.dtsi
Find this section and delete it:
Code:
system {
compatible = "android,system";
dev = "/dev/block/platform/msm_sdcc.1/by-name/system";
type = "ext4";
mnt_flags = "ro,barrier=1,discard";
fsmgr_flags = "wait";
status = "ok";
};
In the boot image, there are 2 files to modify.
1) device/samsung/trlte-common/rootdir/etc/fstab.qcom
Change this line:
Code:
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait,recoveryonly
to this:
Code:
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1,discard wait
2) device/samsung/trlte-common/rootdir/etc/init.qcom.rc
Change this line:
Code:
mount_all fstab.qcom
to this:
Code:
mount_all /fstab.qcom
That's it. Build the ROM and it will be compatible with DualBoot Patcher. Since those are common files across the TRLTE, TBLTE and DUOS devices, all of those builds will be compatible with dualboot patcher.
So, one more thing. There are limitations to what you can install with DualBoot Patcher. Most things are easy to get around, though.
1) Flashable zip's that use Aroma installer might not change their behavior after being patched, and might install to your primary ROM slot anyway. Just something to be aware of.
2) Any flashable zip that has a custom script for updater-binary will fail to flash after being patched. For example, all the MicroG installers that I know of use custom scripts instead of the real updater-binary.
3) you cannot install a patched Magisk zip. But, you can install the Magisk Manager in your ROM, tap the install button (and the next install button that shows up), choose "Select and Patch a file", then choose the boot image from the Multiboot folder on your internal storage (/sdcard). It will patch the boot image and leave a file called "magisk_patched.img" in your Download folder on the internal storage (/sdcard). Use TWRP to flash this file to your boot partition, then reboot. Open DualBoot Patcher, tap the 3-dot button next to the ROM name, and tap "Set Kernel" to replace the saved boot image with the Magisk patched boot image. Note: if you accidentally
4) Magisk doesn't do much. You can use it to grant superuser permissions, but modules only work on the primary ROM.
5) custom kernels probably include their own dtb files. Flashpoint is an example of this. You may have to update the zip to remove the existing dtb file and add one of the files attached to OP. Make sure you rename it to match the original name in the zip file.
I set up my primary ROM per the above instructions, installed it, and I am trying to get my secondary rom installed. Do I need to set it up the same way (it is a 7.1.2 rom). When I patch it (7.1.2) through Dual Boot and try to flash it I get the following error.... " Failed to create temporary image /raw/data/.system.img.tmp" and it fails to flash. I've tried setting it both as secondary and in slot 1.... Any help would be appreciated... Hopefully I am just missing something simple.
rickpub said:
I set up my primary ROM per the above instructions, installed it, and I am trying to get my secondary rom installed. Do I need to set it up the same way (it is a 7.1.2 rom). When I patch it (7.1.2) through Dual Boot and try to flash it I get the following error.... " Failed to create temporary image /raw/data/.system.img.tmp" and it fails to flash. I've tried setting it both as secondary and in slot 1.... Any help would be appreciated... Hopefully I am just missing something simple.
Click to expand...
Click to collapse
What Rom are you trying to flash? Do you have enough space available on system or cache to flash that Rom? If not, try patching it for a data slot instead.
thanks
why when i do this the rom that have modified wont turn wifi on ?
n910f
i try it on linageos pie and havocos 2.8 and both have same issue after doing this solution
samdakid said:
thanks
why when i do this the rom that have modified wont turn wifi on ?
n910f
i try it on linageos pie and havocos 2.8 and both have same issue after doing this solution
Click to expand...
Click to collapse
That's really odd. Maybe I need to update the dtb images here. I will try to do that this weekend.
Would love to try this out