Moto E 2015 LTE
I have to open a new thread, after everything went ok considering the camera for many hours, it again stopped working after restore.
What happened? I made a backup with TWRM and rebooted my phone, a message from SuperSu appeared that the binaries have to be updated, but this message disappeared as fast as it appeared. So I could not do anything. A hint was shown at the display to DOWNgrade! the google playstore. I installed a very early version of playstore 3.1 and rebooted. But the camera continued to stop working...is busy etc... I do not want the get rid of root access, all the rest of the apps are working without problems. Do we have to wait for another version of SU? A total unroot gives back the full functionality of the cam. But certainly I do not want to do this. It seems to be a problem with android 5.0.2 hxxps://play.google.com/store/apps/details?id=com.motorola.camera&hl=de or even motorola. But why does it work without SU?
Camera is working again after deleting cache, stopping the programm, wiping the dalvik (I did it but I am not really sure if it is necessary, have a try) and rebooting. So it is definitely not an hardware issue. So we have to wait for an update working with Android 5.0.2 as they have had several problems with their camera app before regarding other smartphones . Thanks Motorola
Greets
RioGrandeBlood said:
Moto E 2015 LTE
I have to open a new thread, after everything went ok considering the camera for many hours, it again stopped working after restore.
What happened? I made a backup with TWRM and rebooted my phone, a message from SuperSu appeared that the binaries have to be updated, but this message disappeared as fast as it appeared. So I could not do anything. A hint was shown at the display to DOWNgrade! the google playstore. I installed a very early version of playstore 3.1 and rebooted. But the camera continued to stop working...is busy etc... I do not want the get rid of root access, all the rest of the apps are working without problems. Do we have to wait for another version of SU? A total unroot gives back the full functionality of the cam. But certainly I do not want to do this. It seems to be a problem with android 5.0.2 hxxps://play.google.com/store/apps/details?id=com.motorola.camera&hl=de or even motorola. But why does it work without SU?
Camera is working again after deleting cache, stopping the programm, wiping the dalvik (I did it but I am not really sure if it is necessary, have a try) and rebooting. So it is definitely not an hardware issue. So we have to wait for an update working with Android 5.0.2 as they have had several problems with their camera app before regarding other smartphones . Thanks Motorola
Greets
Click to expand...
Click to collapse
this is already a known issue when you flash twrp and root. its kinda hit and miss for users.
fix-this! said:
this is already a known issue when you flash twrp and root. its kinda hit and miss for users.
Click to expand...
Click to collapse
I did not know this. Extracted the recovery img from stock rom and the camera is working.
Would you please give me a hint if any cwm working for moto g g2 and x should be working on our phone?
RioGrandeBlood said:
I did not know this. Extracted the recovery img from stock rom and the camera is working.
Would you please give me a hint if any cwm working for moto g g2 and x should be working on our phone?
Click to expand...
Click to collapse
No idea if there is a cm recovery yet. So maybe its twrp that messes up the cam.
There is no clockwork recovery, hopefully a dev can port it.
Is the camera breaking a stock camera thing, or all cameras? Like if the stock doesn't work would downloading the Google camera from the Play Store work?
bobbyphoenix said:
Is the camera breaking a stock camera thing, or all cameras? Like if the stock doesn't work would downloading the Google camera from the Play Store work?
Click to expand...
Click to collapse
Did you try? I have not, because now stock camera works, after update after rebooting. I wonder how long will it work and what happens next...
RioGrandeBlood said:
Did you try? I have not, because now stock camera works, after update after rebooting. I wonder how long will it work and what happens next...
Click to expand...
Click to collapse
Not yet. I haven't rooted yet because of this bug. That's why I asked if anyone has tried a Play Store camera while the stock one doesn't work.
Sent from my MotoE2(4G-LTE)
bobbyphoenix said:
Not yet. I haven't rooted yet because of this bug. That's why I asked if anyone has tried a Play Store camera while the stock one doesn't work.
Sent from my MotoE2(4G-LTE)
Click to expand...
Click to collapse
Thats broke to, any camera will be. To fix it download root explorer, go to system/app/supersu and rename the apk to .bak. Reboot, your not totally unrooted and the camera will work.
A perm fix will be when moto releases our kernel source and we can compile a kernel with selinux set to off or permissive.
Whatever I do, delete SuperSU or not, delete TWRP or not, after any reboot the camera starts working, then after the next reboot it stopps working, after the next reboot it is working again. Even with working and not renamed SuperSU
What the hell is this?
Renaming does not work better or less.
Could you post the output of running this after you try to use your camera and it doesn't work:
Code:
adb shell su -c dmesg | grep denied
This may help identify the cause of problems if SELinux is to blame. Tonight, I will build and post a kernel with SELinux disabled to see if that fixes anything.
Alright, I built a kernel with SELinux disabled. Apart from that, the source code is straight from the Motorola GitHub.
This is for Styx LTE (surnia) only! Flash at your own risk. I am not responsible for bricking your device, causing damage, bodily harm yada yada.
http://filebin.ca/1v4FfHSxMtX3/surnia_boot_noselinux.img
To install it, go into fastboot and run
Code:
fastboot flash boot surnia_boot_noselinux.img
This kernel is probably missing a bunch of stuff, and it breaks Bluetooth and WiFi. The camera should work though. Try it out and see if it changes the behaviour of the camera. Once you're done with it, you can return to the stock kernel by flashing the stock boot.img.
adb shell su -c dmesg | grep denied
Thanks, I will try, but time is the problem right now.
I was a bit too fast, camera seems to work after renaming SU.apk into bat.
squid2 said:
Could you post the output of running this after you try to use your camera and it doesn't work:
Code:
adb shell su -c dmesg | grep denied
This may help identify the cause of problems if SELinux is to blame. Tonight, I will build and post a kernel with SELinux disabled to see if that fixes anything.
Click to expand...
Click to collapse
Not sure you can modify the kernel since we have no source yet.
fix-this! said:
Not sure you can modify the kernel since we have no source yet.
Click to expand...
Click to collapse
We do have the source. It's on Motorola's GitHub. It was posted right when the phone was released. Yesterday, I built a kernel with SELinux disabled and posted it two posts above yours.
EDIT: Kernel source link
After renaming SU into bak I later renamed it into the original apk. version to see what will happen. And in fact nothing happens. . Camera is working for days now after several rebootings. TWRP is working great and has no issue on the camera. Thank you fix-this!
squid2 said:
Alright, I built a kernel with SELinux disabled. Apart from that, the source code is straight from the Motorola GitHub.
This is for Styx LTE (surnia) only! Flash at your own risk. I am not responsible for bricking your device, causing damage, bodily harm yada yada.
http://filebin.ca/1v4FfHSxMtX3/surnia_boot_noselinux.img
To install it, go into fastboot and run
Code:
fastboot flash boot surnia_boot_noselinux.img
This kernel is probably missing a bunch of stuff, and it breaks Bluetooth and WiFi. The camera should work though. Try it out and see if it changes the behaviour of the camera. Once you're done with it, you can return to the stock kernel by flashing the stock boot.img.
Click to expand...
Click to collapse
tried to flash on my lte model us based gsm. just kept booting back into fastboot until i flashed my stock boot.img. you may wanna talk to chainfire to see if it would be better to make it set to permissive instead of fully disabling selinux.
---------- Post added at 09:11 PM ---------- Previous post was at 09:11 PM ----------
squid2 said:
We do have the source. It's on Motorola's GitHub. It was posted right when the phone was released. Yesterday, I built a kernel with SELinux disabled and posted it two posts above yours.
EDIT: Kernel source link
Click to expand...
Click to collapse
i didn't know that.
---------- Post added at 09:13 PM ---------- Previous post was at 09:11 PM ----------
RioGrandeBlood said:
After renaming SU into bak I later renamed it into the original apk. version to see what will happen. And in fact nothing happens. . Camera is working for days now after several rebootings. TWRP is working great and has no issue on the camera. Thank you fix-this!
Click to expand...
Click to collapse
its hit or miss for me. sometimes the cam works sometimes it doesn't.
fix-this! said:
tried to flash on my lte model us based gsm. just kept booting back into fastboot until i flashed my stock boot.img. you may wanna talk to chainfire to see if it would be better to make it set to permissive instead of fully disabling selinux.
Click to expand...
Click to collapse
Thanks for trying it. I'm not surprised that it didn't work. The quick hack of a boot image I posted is missing the device tree, and it will also fail to load all kernel modules due to a version mismatch. I had tested it on the unit I had at hand, and was shocked that it was able to boot and function without a device tree image, but the hardware I used is a bit different than what you have. I've ordered a production device, and it will hopefully arrive this week. Then I will be able to test properly.
I've been working on setting up proper build infrastructure to build working kernels for surnia (complete with compatible driver modules, device tree images etc). I'm hoping to publish an initial release of my kernel for surnia over the next week or two. My initial release would probably be largely the same as the stock kernel, and then I'll start adding improvements from there.
I think you can make SELinux permissive from boot without recompiling the kernel by simply adding androidboot.selinux=permissive to the kernel command line arguments in boot.img. If anyone wants, I can make such an image using the stock kernel. I don't have a suitable device to test with at the moment though.
squid2 said:
Thanks for trying it. I'm not surprised that it didn't work. The quick hack of a boot image I posted is missing the device tree, and it will also fail to load all kernel modules due to a version mismatch. I had tested it on the unit I had at hand, and was shocked that it was able to boot and function without a device tree image, but the hardware I used is a bit different than what you have. I've ordered a production device, and it will hopefully arrive this week. Then I will be able to test properly.
I've been working on setting up proper build infrastructure to build working kernels for surnia (complete with compatible driver modules, device tree images etc). I'm hoping to publish an initial release of my kernel for surnia over the next week or two. My initial release would probably be largely the same as the stock kernel, and then I'll start adding improvements from there.
I think you can make SELinux permissive from boot without recompiling the kernel by simply adding androidboot.selinux=permissive to the kernel command line arguments in boot.img. If anyone wants, I can make such an image using the stock kernel. I don't have a suitable device to test with at the moment though.
Click to expand...
Click to collapse
Yes fix-this, my camera stopped from working again after using a root cleaner (fixed permissions here-is this the problem?) and rebooted the device. But as squid2 wrote/suggested, the problems (permissive) do not seem to be too severe and could be solved in the near future. It seems to be just a matter of time. At this point I strongly recommend the installation of TWRP. I got a functioning camera back and it helps while working on our handy, TWRP does not seem to be the problem so better install it and keep it working. It helped me a lot. Greets
squid2:adb shell su -c dmesg | grep denied
I did it, but got the message grep written wrong/not found
Related
NOTE: This thread is for the discussion of kernel development. If you don't recompile kernels, please don't post/reply.
After a couple years playing with nexus devices, I'm coming back over to Samsung (until I get bored) and I'm seeing that no one has managed to root a Note 5 device without a recompiled kernel. Why? Because using the stock kernel seems to result in just boot loops.
From what I've been able to observe, the custom kernels all have one thing in common in regards to allowing root to work: They are all changing sepolicy to run permissive instead of making modifications to allow 'su' to work in enforcing mode.
Why?
I have to be honest in saying that I haven't studied how @Chainfire had managed to get su working on the nexus devices while retaining sepolicy in enforcing mode, but it seems that this would be a far better solution than just neutering sepolicy all together.
Has anyone yet attempting to get a sepolicy enforcing kernel working with root? If so, are you willing to share what you tried and how things worked out?
My end-goal is probably to throw together a "as stock as possible" kernel that's root-able. If at all possible, I'm hoping that just some modifications to the ramdisk would be enough to get things working. However, I'd like to take advantage of any previous work done (if any) to get this working.
Thanks
Gary
Edit:
FOR CLARIFICATION. THIS THREAD IS NOT FOR GENERAL USER DISCUSSION. THIS IS FOR DEVELOPERS TO DISCUSS SELINUX, THE NOTE 5 KERNEL, AND METHODS BY WHICH ROOT CAN BE ACHIEVED WITHOUT CHANGING SELINUX TO PERMISSIVE.
Reminder,
Read the OP and stay on topic.
Thanks.
The_Merovingian
Forum Moderator
I have to ask my friend. Since I'm back to Samsung at the same time as you it seems. I see very little advantage of running root atm but I see none of running Selinux non permissive. Also these devices being exynos you will not find much support for it.
I may be wrong but Selinux non permissive has been a problem on samsung custom roms from day one guys just disabled it and be done with I've never seen anyone complain ;p
DAGr8 said:
I have to ask my friend. Since I'm back to Samsung at the same time as you it seems. I see very little advantage of running root atm but I see none of running Selinux non permissive. Also these devices being exynos you will not find much support for it.
I may be wrong but Selinux non permissive has been a problem on samsung custom roms from day one guys just disabled it and be done with I've never seen anyone complain ;p
Click to expand...
Click to collapse
I'm in the process of trying to modify the sepolicy in the stock boot image ramdisk to see if that allows root to work with the stock kernel (modified ramdisk.)
Wish me luck.
Dammit - all of my tools are out of date. Have to recompile mkbootimg, unpackbootimg, etc.
Okay, so I'm finding out all kinds of Fun Things that Samsung has done with this device...
First, at least some versions of this phone (mine is a 920i) have something in the stock firmware kernel(?) that restores factory recovery on first boot. This is my first sammy device in several years, but I seem to remember reading that other samsung devices have done this as well. (This is the reason that people are having to not allow ODIN to auto-reboot the phone.)
What's really pissing me off, however, is that if I allow TWRP to modify the system partition (based on the prompt on the initial boot) and don't actually make any system changes, the normal stock kernel won't boot... it gets stuck in a boot loop. (pre-bootanimation)
This is similar to the reports people are having of boot loops if they install root without changing the kernel. I'm starting to think it has nothing to do with actually being rooted, but that ANY system partition change is causing the bootloop. (Surprise!)
So, I decided to try something a bit different: I restored stock firmware (tar.md5 via odin) and after the reboot, I went back into ODIN mode. This time, I flashed TWRP and rebooted immediately back into ODIN and a flashed kernel with a modified sepolicy in the ramdisk. I then booted normally. My kernel loaded. I used adb to reboot to recovery. TWRP loaded. From TWRP, reboot normally.. it worked. Good start. adb reboot recovery, and this time I uncheck the option to "only mount system R/O." (It's in the "mount" section of TWRP.) Reboot system... and... BOOTLOOP.
(This has nothing to do with root. I'm not installing root... )
Time to start digging in the kernel ramdisk to try and figure this one out...
Tried the same as above, but with Philz compiled by @arter97. This time, I was stuck in a bootloop after the first time recovery ran. I'm guessing that this particular recovery will ALWAYS touch the system partition without first asking? Not sure... Philz did ask if I wanted to install root when I chose the option to reboot, but I declined.
Note to self:
http://forum.xda-developers.com/showpost.php?p=61542104&postcount=433
Just remove support_scfs,verify from the fstab and altering system will work.
Click to expand...
Click to collapse
I have NFC what "support_scfs" is, but I'll have to spend some time with google to figure it out. Perhaps a bit of SourceDiving. Won't have a chance to test this until tomorrow evening.
I love replying to myself. The truth is, I'm probably one of the few people who could stand talking to me. Of course, even I feel like killing me every now and then. It gets complicated.
Oh.. anyway.. I got it. A stock kernel with a modified ramdisk running selinux in enforcing mode and root-able. I want to spend a day running tests, but will post results of the results in about 20 hours. (assuming I get to sleep tonight...)
As well as gaining the enforcing selinux security (somewhat degraded by being rootable), this also ensures all hardware is working even if samsung "cheats" in posting source code.
(see attached screenshot... it's really the stock kernel and still enforcing SE for Android. )
Edit:
Then again, there's no harm in posting the boot image now. This is from a n920i device using the N920IDVU1AOH6 firmware. I'm attaching a file that can be unzipped and flashed with ODIN (AP slot.) Someone fluent should be able to pull the boot image out of the tarball and flash it directly with TWRP or even via 'dd' (assuming you're already rooted.)
(If you try to flash the .zip file directly, you deserve whatever horrible things happen to your phone.)
THIS IS NOT A RELEASE. THIS IS FOR DEVELOPERS WHO KNOW WHAT THEY ARE DOING TO FIND FLAWS WITH IN REGARDS TO ROOT AND SELINUX. I can't claim this would work for any device without the above mentioned firmware. If you don't know exactly how to recover from Bad Things, don't even download the attachment.
No support. No help. If you have to ask how to flash this or anything of the sort, this isn't for you.
Changes from stock ramdisk:
1. Modify sepolicy as @Chainfire documented (ironically using an unrooted note 5) to allow supersu to work it's magic.
2. Modify fstab to remove support_scfs,verify from the mount options for the system partition. (this solves the boot loops)
That's IT.
One warning, though: This is using supersu beta 2.51. That's not released. Actually, I think it's flagged as a work in progress.
garyd9 said:
Changes from stock ramdisk:
1. Modify sepolicy as @Chainfire documented (ironically using an unrooted note 5) to allow supersu to work it's magic.
2. Modify fstab to remove support_scfs,verify from the mount options for the system partition. (this solves the boot loops)
That's IT.
One warning, though: This is using supersu beta 2.51. That's not released. Actually, I think it's flagged as a work in progress.
Click to expand...
Click to collapse
Please, publish original boot.img from N920IDVU1AOH6
svadev said:
Please, publish original boot.img from N920IDVU1AOH6
Click to expand...
Click to collapse
Did you not bother to read any of the posts in this thread? There are known locations for stock images. This thread isn't one of them.
Read the very first line in the first post.
I made it for my SM-N9208, and it is really works with supersu 2.50 .
Thanks!
garyd9 said:
Changes from stock ramdisk:
1. Modify sepolicy as @Chainfire documented (ironically using an unrooted note 5) to allow supersu to work it's magic.
2. Modify fstab to remove support_scfs,verify from the mount options for the system partition. (this solves the boot loops)
That's IT.
One warning, though: This is using supersu beta 2.51. That's not released. Actually, I think it's flagged as a work in progress.
Click to expand...
Click to collapse
Hi
Could you please post a more detailed guide ? I want to do it myself for my n920c.
Thanks
geek78 said:
Could you please post a more detailed guide ? I want to do it myself for my n920c.
Click to expand...
Click to collapse
yeah. well, at least assuming you know how to unpack and repack boot images... (Because this stuff is very experimental at this point, and still very much a work in progress, you should have a certain level of proficiency before mucking with it. I can't and won't hold anyone's hand for this stuff at this point.)
you need to unpack the boot image. Get the boot.img and unpack. Open the ramdisk. In the ramdisk is a file called 'sepolicy.'
Start with this post to figure out how to change it:
http://forum.xda-developers.com/showpost.php?p=63190351&postcount=2071
Find the reply to that post from Chainfire to see how it can be done without a "reference" device.
You'll also have to change the proper fstab as I documented already in this thread.
Then pack up the ramdisk and repack the boot image.
Thanks. Perfect !
DAGr8 said:
I have to ask my friend. Since I'm back to Samsung at the same time as you it seems. I see very little advantage of running root atm but I see none of running Selinux non permissive. Also these devices being exynos you will not find much support for it.
I may be wrong but Selinux non permissive has been a problem on samsung custom roms from day one guys just disabled it and be done with I've never seen anyone complain ;p
Click to expand...
Click to collapse
I'm trying to place your name. Do I know you from SGS2 days or Note2 days?
Anyway, I'm not happy with settling. Never have been...
Edit:
Note or Note 2. Must have been Note2. You were doing smali edits for enabling tablet mode. That was pre-xposed days.
Edit 2:
To answer the question: enforcing selinux adds a layer of security on the device and blocks many security infractions. Basically, if you haven't been given permission to do something, you can't do it. Even as root. In theory, selinux could block the stagefright security issues. When a device is in "permissive" mode, selinux is there, but isn't actually blocking anything. It just logs violations and then ignores them.
In other words, permissive mode completely negates having the se extensions at all. Permissive was a mode that devs could run in to see what might break and what might not.
"root" access is, of course, a hole in the scheme. Chainfire, with supersu, has done quite a bit to ensure that the hole is controlled, but it's still a hole. However, a rooted device with an enforcing selinux kernel is still significantly more secure than a non-rooted permissive selinux kernel.
Another edit:
Here's some links:
https://su.chainfire.eu/#selinux
http://linux.die.net/man/8/selinux
<sarcasm> Wow, I almost forgot how much JOY and FUN it is working with Samsung sh!t kernels. </sarcasm>
So, in testing this (yes, I really DO test things.. imagine that) I found that my device wasn't going into deep sleep. Wow. How interesting. Oh, and not a single wakelock. WTF?!
Instead of google'ing first, I reverted to being a kernel dev (that is now trying to debug a kernel that he hasn't even compiled.) The first thing a kernel dev looks at: "dmesg" So, I copy dmesg to a file and transfer it my PC. (BTW, Notepad++ is God's gift to windows editors.) I search for various strings like "error" and "fail" and "suspend." What I end up seeing is a crapload of messages like this:
Code:
[0: system_server: 3858] PM: Device 0:0:0:x failed to suspend: error -5
(replace x with 1, 2, or 3)
Huh? So, before I dive into the code (because I really don't believe that samsung actually shares the kernel code that they use for themselves), I decided to google around a bit. I finally had enough search terms to hopefully narrow down the search results.
Guess what I found? People having the exact same problem on another samsung device: the S6 (and edge.) Here's the best of the threads:
http://forum.xda-developers.com/galaxy-s6-edge/help/deep-sleep-t3079705
It gets into some interesting detail around page 4 and 5. You'll have to skip past all the clueless people preaching about turning off wifi, downloading snake oil, and worshipping recycled NiCad batteries.
To make a long story short, the stock kernel (or perhaps the bootloader? That shouldn't be possible...) marks a few block devices as read-only if you're using a modified device. (If it's rooted, it's modified. If KNOX is tripped, it's modified, etc.) The kernel from Sammy is trying to flush caches to those devices (which is ironic when you consider they are marked read-only) before going into the suspend. The flush fails, so the entire suspend process fails. It seems that on the SGS6, there were only two devices like this. On the Note5, it seems to be 3 (everything except sda)
In that thread, @HomerSp not only tracked down the problem there, but also (thankfully) figured out that writes to a file in the /sys tree could work around the issue. Thankfully, because the entire point of THIS thread is to use the stock compiled kernel (with a modified ramdisk) to make life Happy. With 3 writes to the /sys tree, magically the device goes to sleep.
(Yes, I'll be taking care of it... and documenting it better...)
What a pain... for some reason, I couldn't write to the cache_type files from within the init.rc structure. No clue why not. Ended up having to add a "service" to the init structure
Anyway...
If you're following along at home, add the following lines to the bottom of init.rc:
Code:
service fix_cache_types /system/bin/sh /sbin/fix_cache_types.sh
class core
user root
oneshot
Then add a new file in the ramdisk's sbin directory called (I bet you guessed this already): fix_cache_types.sh
That file should have perms of 0750 and contain the following:
Code:
#!/system/bin/sh
echo 'temporary none' > /sys/class/scsi_disk/0:0:0:1/cache_type
echo 'temporary none' > /sys/class/scsi_disk/0:0:0:2/cache_type
echo 'temporary none' > /sys/class/scsi_disk/0:0:0:3/cache_type
If you're using the same kernel as I am (n920i), I've attached an updated image. Same rules, conditions, instructions as the last one I posted earlier in this thread. Except this one lets the device take naps. It helps the battery life.
Tomorrow (or Sunday) I'll see if this all works with xposed or not. (I seem to remember something about xposed not working with selinux enforcing kernels, but I could be wrong.) After that, if nothing prevents it (or me), I'll repackage this stuff again, and also throw together an n920c kernel (based on N920CXXU1AOH6) for general use.
BTW, at least on my n920i, I've confirmed that I don't reboot when getting a call (or making one), that NFC works, that bluetooth works, that I can wirelessly charge and quick charge. I'm trying to ensure all the "common" complaints with non-stock boot images are non-issues before giving this out... The whole purpose of using the stock kernel is to retain enforcing selinux and retain completely functional hardware.
garyd9 said:
yeah. well, at least assuming you know how to unpack and repack boot images... (Because this stuff is very experimental at this point, and still very much a work in progress, you should have a certain level of proficiency before mucking with it. I can't and won't hold anyone's hand for this stuff at this point.)
you need to unpack the boot image. Get the boot.img and unpack. Open the ramdisk. In the ramdisk is a file called 'sepolicy.'
Start with this post to figure out how to change it:
http://forum.xda-developers.com/showpost.php?p=63190351&postcount=2071
Find the reply to that post from Chainfire to see how it can be done without a "reference" device.
You'll also have to change the proper fstab as I documented already in this thread.
Then pack up the ramdisk and repack the boot image.
Click to expand...
Click to collapse
Hi
I have unpacked my boot.img. So I can see my sepolicy file in ramdisk/, I have patched it with my rooted Nubia Z9 but I don't understand next steps. Do you have time to explain a little more ?
For the fstab mods I have done it in fstab.samsungexynos7420 and fstab.samsungexynos7420.fwup. Is it ok ?
Thanks.
garyd9 said:
No support. No help. If you have to ask how to flash this or anything of the sort, this isn't for you.
Click to expand...
Click to collapse
garyd9 said:
I can't and won't hold anyone's hand for this stuff at this point.)
Click to expand...
Click to collapse
garyd9 said:
Same rules, conditions, instructions as the last one I posted earlier in this thread.
Click to expand...
Click to collapse
geek78 said:
Do you have time to explain a little more ?
Click to expand...
Click to collapse
Need I say more?
Read First: This method is relatively drastic, and will hurt device performance some. You should only use this as a last resort, if the more basic methods of fixing a soft brick didn't work (e.g, factory reset, flash stock firmware, etc.)
*Update 8/22: Android O is working with 4 Cores now! Big thank you to @xls654 for finding out how to get Android O to work.
*Petition:
I made a petition for Google to officially release and sign modified boot.imgs, so that people with locked bootloaders can fix their devices too. Check it out here. (I apologize for dumbing it down so much, I wanted to make sure everyone could understand it)
*Changelog:
8/25 - EX kernel for Android O added.
8/22 - Android O DPR6 boot.img and source added.
8/16 - Started making this fix open-source, source code section added in OP. Also uploaded modified Franco and Flash kernel & source.
8/10 - Added PA 7.2.2 and DarkROM boot images.
8/08, 2nd change - Uploaded modified boot.img for firmware 48C.
8/08 - Updated EX kernel to version 4.1.2. This updated zip adds the CPU utilization patch to the init.elemntalx.rc, instead of removing the old init.angler.rc and copying the new init over. That should mean more compatibility with Roms/kernels that modify the init.angler.rc. I also modified the camera-daemon to use cpus 0-3 instead of 0-2, so hopefully this should make the a camera bit faster too.
8/07 - Added boot.img that only uses 1 core. Someone suggested I make a boot.img that only uses 1 core, just to see if it works for devices that didn't work with the 4 Core fix.
7/30 - Added universal EX zip, this zip should modify your kernel to use only 4 cores, and it should modify it to utilize all 4 cores. You can flash this over most ROMs and it should work. Also added a donation url, and this changelog.
7/29, 2nd change - Added Pure Nexus and PA dev version boot images, modified to use 4 cores, and utilize all 4.
7/29 - Updated this fix to greatly improve performance. Before this fix, the device was only using 1 core for foreground tasks, now it will use all 4 cores. Also revamped OP.
7/21 - Fix created, stock boot.img, TWRP image, and EX kernel modified to use 4 cores.
*What this fix does, and how to apply it:
The problem:
The problem with most of the devices in a BLOD, is that a hardware failure related to the BIG cluster has occurred. This fix remedies the problem by disabling the BIG cores. Unfortunately, this does mean that you will take a performance hit. However, I am continually working on ways to improve the device's performance.
The update: If anyone remembers device performance with the first fix, it was hurt a lot, however, after finding out that the device was only using 1 core for all foreground tasks, I modified the ramdisk to utilize all 4 cores more effectively, and it helps a lot.
Requirements: For this fix to work, you need:
A brain
A computer
A bootlooping 6P with an unlocked bootloader/OEM unlocking enabled
The modified files of your choice
Fastboot on your computer (preferably installed system wide). If you do not know what this is, or do not have it, look at this post. Answer yes to all of the prompts to install it.
How to apply the fix:
Boot your phone into bootloader (hold power and volume down).
Connect your phone to the computer.
Go to the folder where you have the modified files, then hold shift and right click in a blank space, click on "open command prompt here" in the menu that pops up.
In the command prompt: type "fastboot flash boot [name of the file here]" and then press enter. If you're flashing TWRP, replace boot with recovery. (Linux users, make sure you're running as root)
Edit: With the new EX zip, you shouldn't need to flash the boot.img anymore, you can just flash twrp, and then flash EX in twrp.
Boot up your phone, and hopefully it should work!
*If your phone is bootloader locked/OEM locked:
You can try to get your phone to boot long enough to enable OEM unlocking. Some users have reported success by freezing their phone for a bit, then booting it. Others have let their battery drain all the way, and then tried to boot their phone, but the most successful method seems to be heating up your phone (a lot).
If you do attempt any of these methods, make sure you have time and patience, as it will take a long time.
To enable OEM unlocking and unlock bootloader:
Go to settings.
Go to developer options, if you do not see that, go to "about phone", scroll to build number, and then tap it 7 times. You should now see developer options in settings.
Once you're in developer options, click on "OEM unlocking" and accept the prompt.
Now reboot your phone to bootloader, connect your phone to the computer, and type "fastboot flashing unlock" Your bootloader should now be unlocked.
*Downloads:
Boot.img from stock 6.17, 8.0 firmware: Download | Mirror. This Image is the from the first official release of Android O, and is modified to use 4 cores. It also disables forced encryption as a bonus. Thank you to @xls654 for figuring out how to get Android O to work.
Boot.img from stock 48C, 7.1.2 firmware: Download | Mirror. This Image is modified to use only 4 cores, and is modified to utilize the 4 cores more effectively. I have had multiple people say that first boot takes a while after flashing this, so just wait about 20 minutes before you declare something is wrong with it.
Boot.img from stock 48B, 7.1.2 firmware: Download |Mirror. This Image is modified to use only 4 cores, and is modified to utilize the 4 cores more effectively. I have had multiple people say that first boot takes a while after flashing this, so just wait about 20 minutes before you declare something is wrong with it.
TWRP version 3.1.1: Download | Mirror. This TWRP image is modified to use only 4 cores.
EX kernel version 5.03: Download | Mirror. EX kernel 5.03 works with android 8.0.0. This zip applies the 4 cores patch, but you will need to flash it over an already modified boot.img to work.
Elemental X kernel version 4.12, universal zip: Download | Mirror. This zip is EX kernel, modified to use only 4 cores. Update: I modified it to apply the CPU utilization patch too, so now this is a universal zip, flash it over almost any ROM, and you should now have the BIG cores disabled fix, and the little core utilization fix.
Flash kernel version 2.5: Download | Mirror. This zip is modified to use only 4 cores, and utilize all 4. Works with android 7.1.2. You can flash this over almost any ROM, including stock, and it should boot again.
Franco kernel r55: Download | Mirror. This zip is modified to use only 4 cores, and utilize all 4. Works with android 7.1.2. You can flash this over almost any ROM, including stock, and it should boot again.
You will most likely not need these images. It will be much easier, and much more universal to flash one of the custom kernel zips above ^^^
PA boot.img from PA version 7.2.2, build 8/10: Download | Mirror. Uses only 4 cores, and has core utilization patch.
PA boot.img from PA version 7.2.1: Download | Mirror. Boot.img from PA dev preview 7.2.1, uses only 4 cores, and is modified to utilize 4 cores more effectively. Flash it after you flash the PA zip, either with fastboot, or TWRP image flash.
Pure Nexus boot.img from Pure Nexus 7/25 build Download | Mirror. This image is modified to use only 4 cores, and it has a tweak to utilize the 4 cores more effectively. Flash it after you flash Pure Nexus, either with fastboot, or TWRP image flash.
DarkROM boot.img from 7/21 build: Download | Mirror. This image is modified to use only 4 cores, and has the utilization patch.
Boot.img modified to use only 1 Core. Some people were reporting that the 4 core images weren't working for them, someone suggested that I make a 1 core version to see if that helps at all. Edit: seems not to help unfortunately. Here it is: Download | Mirror
Unfortunately, I have not been able to get Android O working yet, but I am working on it right now.
If you have a favorite custom ROM or kernel you want to ported over to use 4 cores, let me know, and I'll put it up.
*Source code:
Flash kernel: source | Flash ramdisk/AK2: source.
Franco kernel: source | Franco ramdisk/AK2: source.
Android O boot.img: source.
p-0000000000000000000000000000007 (sorry that was my kitten)
*Tested custom ROMS/kernels
I have used Pure Nexus by flashing the modified EX zip over it, it has notably better performance than the stock ROM, and very good battery life. It's a clean, stable ROM, with plenty of good features that are actually useful.
I have also used Paranoid android dev preview, very good performance, definitely my favorite as of now. Battery life leaves something to be desired, but I have not tried a custom kernel yet. Also, 7.2.1 seemed smoother to me than 7.2.2.
If you have a custom ROM/kernel that worked for you, let me know and I'll put it up here.
*To improve performance slightly:
Flash a custom kernel. I will upload more kernels as I test more, so stay tuned.
Overclock the little cores. It can slightly help offset the lost performance, on my 6P, I have mine overclocked to 1632MHz, and it works perfectly for me. Edit: I actually recommend not overclocking. Many people have reported their Little cores failing, so I would go for longevity on this device, and keep it at stock clocks, or even underclock it. The speed difference you get from overclocking is negligible anyways.
Disable animations in developer options. Seriously, as soon as I found out about this tweak, I've used it on ever single device I've owned, it helps a ton.
Turn resolution down to 1080p. On a small screen, the difference in between 1080p and 1440p is not very noticable. To do this, first get root access, then download a terminal emulator. In the terminal, type "su" and grant it root access, then type "wm size 1080x1920", and finally, change the density "wm density 400". Personally, I like my density at 400, but you can expieriment with it. Lower density=Smaller items and text, Higher density=Bigger items and text. Also @Adithya FRK mentioned that you also want to put density in build.prop so apps display correctly. Change ro.sf.lcd_density=560 to your density, if you changed it.
*Credits:
@rchtk, His post here gave me the idea for how to modify the images.
@flar2, He built the Elemental X kernel for this device, I merely made a small modification to his kernel to use 4 cores. In no way am I trying to steal and/or discredit his work.
The TWRP development team, they built the TWRP recovery for this device, I merely made a small modification to their recovery to use 4 cores. In no way am I trying to steal and/or discredit their work.
@tr1gg3r.man, He made the the PA kernel, I just added a couple modifications. In no way am I trying to steal and/or discredit his work.
@BeansTown106, He made the Pure Nexus kernel, I just added a couple modifications. In no way am I trying to steal and/or discredit his work.
@Dark_Eyes_, He made the DarkROM kernel, I just added a couple modifications to it. In no way am I trying to steal and/or discredit his work.
@[U][COLOR="Purple"]The Flash[/COLOR][/U], He made The Flash kernel, I just made a couple modifications to it. In no way am I trying to steal and/or discredit his work. His posts have also helped me a lot with learning how to build a kernel from source, understanding how to use git more, etc. I recommend you check them out if you are interested in getting started with android development.
@[B]franciscofranco[/B], He made Franco kernel, I just made a couple modifications to it. In no way am I trying to steal and/or discredit his work.
@xls654, He found out how to get Android O working with 4 cores.
FAQs
What's the password for TWRP/Why is TWRP asking for a password? - In android 7.0, Google added forced encryption to the data partition. To get around this, click cancel when TWRP asks you for a password, and then factory reset the device. Then you can flash EX kernel/Magisk to disable forced encryption.
Why am I getting an error when I try to flash the images? - Your bootloader is probably not unlocked, try running the command "fastboot flashing unlock", If you get an error there too, then you will have to enable OEM unlocking before you can continue.
It's not working for me, how do I fix it? - My only advice for that is: "Flash the stock firmware for whatever version image you're trying to flash, then reflash the images again" If you're stuck on the boot animation, wait at least 20 minutes before you declare it's not working. If none of that works, chances are your device may have a different problem.
Does EX kernel have the new speed fix? - Yep, you can flash this over just about any ROM, and it should patch it to use only 4 cores, and use them well.
I would like to help as many people as I can, however, I am much more likely to be able to easily help you/reply to your post if you clearly state your problem and the steps you attempted to fix it. I will be much less likely to reply to posts such as "omggg i flashed the image and my phone won't boot helppp" Please read through post first, I did not spend time typing up this OP for no one to read it. If I can see that you read through the OP and have attempted all the steps, then I will be much more willing to help you.
I set up donations on my profile, for those of you who want to donate. I have spent countless hours modifying, flashing, testing, and helping, don't get me wrong, I love doing this and helping y'all out, but donations really keep me motivated to keep going, and donations also will help me fund new equipment and devices that will help further my android development. Every single donation is appreciated Donate to me here!
If this guide helped you, please click thanks, it means a lot to me
flashed modded TWRP then flashed modded EX Kernel and I'm back up and running... thanks so much!!
How the fuuuuuuuu man you save me, how do you make this.
Really work for my Nexus 6p thank you man, is there any way to send a cup of coffe.
worked for my brick - can enter TWRP again
Hello man is there any way to can use this with Android O ????
You are god!
Enviado desde mi ONEPLUS A3000 mediante Tapatalk
Today it suddenly happened to my device too. I flashed your img and the device booted again, thank you! However, seeing you disabled some cores, would it be caused by a bad core in the device? So, a hardware failure? Or is the boot.img simply corrupted in some sort of way? I'm trying to pinpoint the issue here.
edit: flashed the stock boot.img and the device was back into loop. So it's probably is a hardware defect.
@nabears101 you are AMAZING! Outstanding job.
My phone has life again (even though I already bought a OP5 to replace it)
NeoS said:
Today it suddenly happened to my device too. I flashed your img and the device booted again, thank you! However, seeing you disabled some cores, would it be caused by a bad core in the device? So, a hardware failure? Or is the boot.img simply corrupted in some sort of way? I'm trying to pinpoint the issue here.
edit: flashed the stock boot.img and the device was back into loop. So it's probably is a hardware defect.
Click to expand...
Click to collapse
That would be my guess, I'm trying to figure out if there's a way to debug the bootloader so I can pinpoint the problem with the BIG cores.
javitomen said:
Hello man is there any way to can use this with Android O ????
Click to expand...
Click to collapse
I'll go ahead and upload a version for android O later today
javitomen said:
How the fuuuuuuuu man you save me, how do you make this.
Really work for my Nexus 6p thank you man, is there any way to send a cup of coffe.
Click to expand...
Click to collapse
To anyone who wants to make a boot.img with 4 cores: It's actually fairly simple, you need to get abootimg tools on linux. Then unpack the boot.img with abootimg -x (name of your boot.img) Once the image is extracted, there should be a file named bootimg.cfg, edit that file and put in maxcpus=4 in the line that starts with cmdline =. Then repack the image with abootimg --create myboot.img -f bootimg.cfg -k zImage -r initrd.img And viola! You have a (half) working kernel.
XCnathan32 said:
I'll go ahead and upload a version for android O later today
Click to expand...
Click to collapse
Thanks man you dont know how thankfull i am, i hope your release of the android O to test it, thanks again for your work :good:
javitomen said:
Thanks man you dont know how thankfull i am, i hope your release of the android O to test it, thanks again for your work :good:
Click to expand...
Click to collapse
Just uploaded boot.img and EX Kernel for Android O, check OP. And no problem, I'm always happy to help a fellow android fan.
XCnathan32 said:
I'll go ahead and upload a version for android O later today
Click to expand...
Click to collapse
XCnathan32 said:
Just uploaded boot.img and EX Kernel for Android O, check OP. And no problem, I'm always happy to help a fellow android fan.
Click to expand...
Click to collapse
Hi man i just flash it, but after Android logo just return bobootloader
javitomen said:
Hi man i just flash it, but after Android logo just return bobootloader
Click to expand...
Click to collapse
Oops I'm getting that problem too, working on it now...
XCnathan32 said:
Oops I'm getting that problem too, working on it now...
Click to expand...
Click to collapse
lol thanks man, i hope you can fix it
I don't have this bootloop issue but it is extremely reassuring to know there is a fix even though it means limiting performance and such an easy fix too. Making the modifications seems very easy which makes me wonder why it's taken so long for someone to do a modification like this.
NeoS said:
Today it suddenly happened to my device too. I flashed your img and the device booted again, thank you! However, seeing you disabled some cores, would it be caused by a bad core in the device? So, a hardware failure? Or is the boot.img simply corrupted in some sort of way? I'm trying to pinpoint the issue here.
edit: flashed the stock boot.img and the device was back into loop. So it's probably is a hardware defect.
Click to expand...
Click to collapse
If you're interested, I made a post here https://forum.xda-developers.com/nexus-6p/help/dev-help-debugging-ramoops-bootlooping-t3640826 that semi-identifies the problem, I'm trying to get help on how to fix it.
I'm still downloading your imgs but the response of people to this thread/guide is already making me feel like I've arrived at the end of the Amazing Race (filled with awful challenges of unlocking, rooting, flashing, discharging, waiting, and just. literally. staring.)
Thank you, BLOD SLAYER!
XCnathan32 said:
Oops I'm getting that problem too, working on it now...
Click to expand...
Click to collapse
Hi man, did you found the fix for Android O?
Device: LG V30+
No matter which ROM I try, device encryption (from settings) fails every time. The process does nothing, it just shows the Android logo and reboots. It works on stock firmware (I think, just an option to require password upon boot) but I need encryption on a ROM without Google apps.
I've been trying to get this thing set up all day, if anyone can help I will be beyond thankful.
Averie said:
Device: LG V30+
No matter which ROM I try, device encryption (from settings) fails every time. The process does nothing, it just shows the Android logo and reboots. It works on stock firmware (I think, just an option to require password upon boot) but I need encryption on a ROM without Google apps.
I've been trying to get this thing set up all day, if anyone can help I will be beyond thankful.
Click to expand...
Click to collapse
Which ROMs? On AOSP based ones encrpytion is (for now) completly disabled, because it ****ed with TWRP (even though only encryptable, twrp couldnt mount /data anymore)
an option would be to modify the fstab
(/systen/vendor/etc/fstab.joan or so), commit that removed it is here: https://github.com/SGCMarkus/androi...mmit/e285c593f249e48d1b3a8048a1d173cc2a6f21a0
just add that back (after mounting system as read/write), and then reboot after saving
SGCMarkus said:
Which ROMs? On AOSP based ones encrpytion is (for now) completly disabled, because it ****ed with TWRP (even though only encryptable, twrp couldnt mount /data anymore)
an option would be to modify the fstab
(/systen/vendor/etc/fstab.joan or so)
just add that back (after mounting system as read/write), and then reboot after saving
Click to expand...
Click to collapse
Ohh OK, that makes sense now. The ROMs were a few you have listed, Lineage, AospExtended, RR, etc.
Thank you for clarifying!
Question, how would I go about modifying the fstab? I'll try it myself but I've never done this before.
Averie said:
Ohh OK, that makes sense now. The ROMs were a few you have listed, Lineage, AospExtended, RR, etc.
Thank you for clarifying!
Question, how would I go about modifying the fstab? I'll try it myself but I've never done this before.
Click to expand...
Click to collapse
for modifying it
spaces matter (the amount doesnt though), same for new lines
and to make it writeable
either go to twrp and mount system as rw (you could adb pull it, then edit it on pc (just not with windows editor) and push it back to the old location, overrides it)
or remount system (adb remount)
and then edit it with some text editor on your phone (from a root file explorer most likely)
how it should look like, check the commit from the link in my previous post
SGCMarkus said:
for modifying it
spaces matter (the amount doesnt though), same for new lines
and to make it writeable
either go to twrp and mount system as rw (you could adb pull it, then edit it on pc (just not with windows editor) and push it back to the old location, overrides it)
or remount system (adb remount)
and then edit it with some text editor on your phone (from a root file explorer most likely)
how it should look like, check the commit from the link in my previous post
Click to expand...
Click to collapse
It works
Thank you so much, I appreciate your work.
SGCMarkus said:
Which ROMs? On AOSP based ones encrpytion is (for now) completly disabled, because it ****ed with TWRP (even though only encryptable, twrp couldnt mount /data anymore)
an option would be to modify the fstab
(/systen/vendor/etc/fstab.joan or so), commit that removed it is here: https://github.com/SGCMarkus/androi...mmit/e285c593f249e48d1b3a8048a1d173cc2a6f21a0
just add that back (after mounting system as read/write), and then reboot after saving
Click to expand...
Click to collapse
This does not seem to be working on LG v30 H932 LineageOS 16 lineage-16.0-20190610-UNOFFICIAL-h932.zip
It hangs at 00:00 time left and never finishes encrypting. If I reboot the phone tells me that data is corrupted.
ShapeShifter499 said:
This does not seem to be working on LG v30 H932 LineageOS 16 lineage-16.0-20190610-UNOFFICIAL-h932.zip
It hangs at 00:00 time left and never finishes encrypting. If I reboot the phone tells me that data is corrupted.
Click to expand...
Click to collapse
See the age of the thread? It was for Oreo (encryption still worked there). Not for Pie, that has broken encryption on AOSP (idk if the pie blobs for los17 or so help with that)
SGCMarkus said:
See the age of the thread? It was for Oreo (encryption still worked there). Not for Pie, that has broken encryption on AOSP (idk if the pie blobs for los17 or so help with that)
Click to expand...
Click to collapse
I'm sorry, but not all the information for this device is terribly organized. It was hard for me to figure out that it was broken and not just "user error" by myself. It took you to tell me this, thank you!
Do you happen to have a idea exactly what is crashing or going wrong when encryption is triggered? I'm not that familiar with the lower level hardware and software so I'm not sure how the newer blobs would help.
ShapeShifter499 said:
This does not seem to be working on LG v30 H932 LineageOS 16 lineage-16.0-20190610-UNOFFICIAL-h932.zip
It hangs at 00:00 time left and never finishes encrypting. If I reboot the phone tells me that data is corrupted.
Click to expand...
Click to collapse
ShapeShifter499 said:
I'm sorry, but not all the information for this device is terribly organized. It was hard for me to figure out that it was broken and not just "user error" by myself. It took you to tell me this, thank you!
Do you happen to have a idea exactly what is crashing or going wrong when encryption is triggered? I'm not that familiar with the lower level hardware and software so I'm not sure how the newer blobs would help.
Click to expand...
Click to collapse
Were you on stock Oreo or stock Pie before installing LOS-16?
ChazzMatt said:
Were you on stock Oreo or stock Pie before installing LOS-16?
Click to expand...
Click to collapse
I was in talks with SGCMarkus on Telegram and others. It's been determined to be a SELinux policy issue. It encrypts fine with SELinux set to permissive but not enforcing. I'm trying to sort out the issue but hopefully some others are also working on it now that I have found the issue and reported it in the Telegram channel.
ChazzMatt said:
Were you on stock Oreo or stock Pie before installing LOS-16?
Click to expand...
Click to collapse
ShapeShifter499 said:
I was in talks with SGCMarkus on Telegram and others. It's been determined to be a SELinux policy issue. It encrypts fine with SELinux set to permissive but not enforcing. I'm trying to sort out the issue but hopefully some others are also working on it now that I have found the issue and reported it in the Telegram channel.
Click to expand...
Click to collapse
You're still not answering the question. And reporting in actual ROM thread is still best.
So I assume you installed stock Pie and didn't read the MANY warnings about needing permissive kernel if you go back to LOS-16 ROMs. Also that LOS-17 ROMs are still unfinished work in progress with bugs.
This is Root Sticky Guide. Read post #2:
https://forum.xda-developers.com/lg-v30/how-to/root-v30-t3927154
ShapeShifter499 said:
I'm sorry, but not all the information for this device is terribly organized. It was hard for me to figure out that it was broken and not just "user error" by myself. It took you to tell me this, thank you!
Click to expand...
Click to collapse
It's organized quite well. There's a Root Sticky Guide that tells everything you need to know about custom ROMs.
Seems you ignored that.
It's also linked in HUGE hyperlink in the WTF instructions (near top of that post), pointing to that Guide if you missed it for some reason. You ignored that, also.
It's also linked in post #1 every KDZ Pie thread I maintain.
If the ROM threads themselves don't contain such information -- or at least links to such information -- that's the fault of the ROM maintainers. But
* Sticky Guide
* HUGE Link in bootloader unlock/root instructions
* Link in post #1 of Pie KDZ threads
is quite good organization of material.
ChazzMatt said:
You're still not answering the question. And reporting in actual ROM thread is still best.
So I assume you installed stock Pie and didn't read the MANY warnings about needing permissive kernel if you go back to LOS-16 ROMs. Also that LOS-17 ROMs are still unfinished work in progress with bugs.
This is Root Sticky Guide. Read post #2:
https://forum.xda-developers.com/lg-v30/how-to/root-v30-t3927154
It's organized quite well. There's a Root Sticky Guide that tells everything you need to know about custom ROMs.
Seems you ignored that.
It's also linked in HUGE hyperlink in the WTF instructions (near top of that post), pointing to that Guide if you missed it for some reason. You ignored that, also.
It's also linked in post #1 every KDZ Pie thread I maintain.
If the ROM threads themselves don't contain such information -- or at least links to such information -- that's the fault of the ROM maintainers. But
* Sticky Guide
* HUGE Link in bootloader unlock/root instructions
* Link in post #1 of Pie KDZ threads
is quite good organization of material.
Click to expand...
Click to collapse
I've already been compiling my own LineageOS. It's been determined that due to the issues I've been experiencing that the previous owner must have installed PIE at some point. The seller then seems to have gone back to stock Android 7 Nougat which didn't help the permissive issue. I personally never have installed stock Android 9 PIE. I brought this phone used from a seller on Amazon, there was no way for me to know before receiving the device whether or not the device had been upgraded to PIE before.
However according to SGCMarkus, encryption was never reported working for anyone regardless of if they had the permissive issue or not. I know why, there are no SELinux permissions set up for it. From what I can tell his sources doesn't have them. So even if you didn't have a permissive issue from upgrading to PIE, encryption wouldn't have worked.
ShapeShifter499 said:
I know why, there are no SELinux permissions set up for it. From what I can tell his sources doesn't have them. So even if you didn't have a permissive issue from upgrading to PIE, encryption wouldn't have worked.
Click to expand...
Click to collapse
Well that's interesting.
ChazzMatt said:
Well that's interesting.
Click to expand...
Click to collapse
https://github.com/ShapeShifter499/...mon/blob/lineage-16.0/sepolicy/vendor/vold.te
This needs to be added to a new build in order to allow things to work for encryption. Otherwise the phone attempts the encryption but hangs after rebooting because it's unable to double check that the encryption was successful due to SELinux blocking Vold.
I might have found a quick and dirty Method to Port TWRP to the newest 7.2 shield experience. It's not guaranteed, but it's a chance im going to try. But as I didn't upgraded my own shield yet, I need some files from someone who has rooted his shield already.
1. Is an recovery.img
2. The build.prop
If I can get hands on these files I might be able to bring up a testing version asap
Enough. Seriously.....
Keep it clean, and on-topic... The rules are there for a reason. Don't remember them? HERE you go.
Adromir said:
I might have found a quick and dirty Method to Port TWRP to the newest 7.2 shield experience. It's not guaranteed, but it's a chance im going to try. But as I didn't upgraded my own shield yet, I need some files from someone who has rooted his shield already.
1. Is an recovery.img
2. The build.prop
If I can get hands on these files I might be able to bring up a testing version asap
Click to expand...
Click to collapse
If you want the files
Then can you please update your Sheild tv to the latest firmware for us 7.2.2
An back up the recovery.img
An back up your build.prob
Because I can't help you! I refuse!
Thx again have a great day
i hope you can port the twrp to nvidia sheild tv thx
Foster_e (Shield TV 2015 16GB) - 7.2.2 (30.7.130.7)
recovery.img + build.prop
https://drive.google.com/open?id=18E_u8as1E9dstmRtRwPb97hALdmsrdsc
The recovery is dumped directly from
Code:
/dev/block/platform/sdhci-tegra.3/by-name/SOS -> /dev/block/mmcblk0p16
No offense but quick and dirty does not do it on the new kernel.
You can port as much as you like and it might work for the older models but certainly not for the 2017 model.
And if you have no clue how to get the required files by simply exctracting the firmware files that you can download then I wonder how you will be able to actually modify the recovery image.
People with quite some experience tried and failed, so unless you compile TWRP from source he proper way it won't work (at least not on the 2017).
And even if compiled correctly there is no garantee it will be usable with the secure boot restrictions still in place.
You need a fully rooted device to fully use TWRP and you can not root the 7.2 in the simple way anymore.
Fully rooted the normal TWRP will work just fine.
Downunder35m said:
No offense but quick and dirty does not do it on the new kernel.
You can port as much as you like and it might work for the older models but certainly not for the 2017 model.
And if you have no clue how to get the required files by simply exctracting the firmware files that you can download then I wonder how you will be able to actually modify the recovery image.
People with quite some experience tried and failed, so unless you compile TWRP from source he proper way it won't work (at least not on the 2017).
And even if compiled correctly there is no garantee it will be usable with the secure boot restrictions still in place.
You need a fully rooted device to fully use TWRP and you can not root the 7.2 in the simple way anymore.
Fully rooted the normal TWRP will work just fine.
Click to expand...
Click to collapse
So if I understand you correctly the only way that a recent version of TWRP would work on 7.21 and above are if you have a "rooted" developer image? I have stayed with 7.1 (rooted with a flashed TWRP recovery) My expectation is that Ill stay with it until a stable version is released.
Odd thing is every OTA notification I get refuses to install. It just boots to TWRP without updating. I even opted in for the 7.2.2 beta updates and the shield refuses to update. Kinda thankful as others seem to have so many issues, just not worth it until 7.3 is released perhaps?
Any decent update is worth applying.
But if you ask if it is worth it for those really needing full root access then the answer is no.
The cummunity behind the shield might not be as big as behing Samsung devices but I am sure something will be figured out sooner or later.
@Downunder35m : As I mentioned in a deleted Post, I know how to get these Files from the recovery images. But they are Still 7.2.1 and as 7.2.2 already I didn't see a point in starting with already Outdated Files.
What kind of Things have you been trying already? My Approach was, that maybe TWRP hangs itself, because it can't find the Vendor and system Partition. After unpacking the recovery.img i found out, that the partitions still get mounted, but not over over the fstab anymore but single commands in some init scripts. So my Idea was to patch the kernel of the recovery image with a proper fstab and then use that to build a twrp around it, with the modified boot image. But sadly the resulting TWRP exceeded the Partitionsize. But i didn't set up the Source Tree to compile correctly, because I assumed that with such a breaking approach nvidia did at least moved onward to Android 8.1 ..
A real life job sadly limits my time far more than what I would like.
So maybe my failures are of use to you...
Lets start with the basics:
(All for the 2017 model!)
Firstly, the bootloader has changed and now enforces basically everything Google has on offer.
This means you can not just boot into a custom recovery because the bootloader does not accept it as genuine.
Lets say you get around this problem by, dor example, compiling TWRP from source and with the not yet realesed NVidia 7.2 sources.
There might be other ways but right now I think we can't get around compiling it from scratch.
Once you are able to somehow properly boot into TWRP there is more problems:
A lot if not all special rights and permissions are now handled almost exclusively by the DTB, or to be precise the DTS, which is compiled during boot.
By default TWRP does not make any use of the DTB but instead relies only on the FSTAB configuration.
And since TWRP is not an authorised service, task or app the bootloader won't provide the required rights.
The system partition stays invisible, the vendor part locked and since TWRP is required to copy or store at least some things somewhere this is detected as a possible intrusion.
As that the bootloader now marks the entire system as compromised - the dreaded corrupted system message appears and the system fails to boot.
You could tweak the init files, get the complete FSTAB info from the plat - and nonplat_file_contexts and even fiddle with the rest.
Then you get this happy feeling of a booting TWRP, pull a backup and think all is fine.
That it until you try to reboot and nothing works anymore.
The backup is useless as firstly you can not write it back and secondly it will be encrypted or otherwise corrupt.
To be able to use TWRP ADBD must be able to run in root mode, this is not possible by default on a user or release build, which NVidia now provides as a "developer" firmware.
A bootloader set to enforce all SeLinux and DM-Verity funtions will not allow any vital modifications to any vital part of the system.
In theory you must first at least free the bootloader (we can not do that) or destroy the safety, like by using a modified DTB.
Then you must make sure that you modifiy the prop files so full ADB and ADBD rights are available where they are needed.
After that TRWP will run just fine but it creates a cricle that first needs to be broken somehow
No root rights means no TWRP, no TWRP means no mods to the system.
Magisk currently fails to help us as it does not make use of DTB features at this stage.
And if you ask me then messing with the DTB can backfire badly.
Unlike normal firmwares we won't get a DTB partition included in the boot image or kernel image.
So once the dTB is stuffed too much it will be hard to impossible to install a genuine or custom firmware.
Once Pie comes out this will be worse.
Here the DTB too will be protected and generated/checked during boot.
Unless NVidia wakes up and removes these restrictions from the developer firmwares we will be locked out until someone finds a way to restore full root rights.
Right now I am hopin they will still release the full sources one day.
With a massive effors one could then just compile a normal userdebug firmware and all is fine once more.
Any luck yet? I upgraded one of my Shield TV to 7.2.2 from 7.2.1 dev root and want to install Magisk....
Thanks!
Here you go TWRP recovery for Shield TV 2017 running 7.2.3
UPDATE: Boots but not working correctly so removed links
leezaal said:
Here you go TWRP recovery for Shield TV 2017 running 7.2.3
https://www.androidfilehost.com/?fid=6006931924117905072
---------- Post added at 07:06 PM ---------- Previous post was at 07:05 PM ----------
Here you go TWRP recovery for Shield TV 2017 running 7.2.3
https://www.androidfilehost.com/?fid=6006931924117905072
Click to expand...
Click to collapse
Every time i open recovery it works, but after trying to reboot it bootloops at nvidia. I flash-all and it works again until i enter recovery (then botloops again on reboot). Am i missing something? (shield 2017 7.2.3 dev edition)
Here's twrp 3.3.1-0 for Shield TV. It seems to work properly on my shield pro running 7.2.3, I was able to flash magisk with it, but I don't have the 2017 model to test on. Please let me know how it works and report any errors in as detailed a manner as possible. As ever, this is experimental and you flash at your own risk :good:
https://drive.google.com/file/d/1BCfXg9pUpFm_3sPXp_nEwBlkNU9nelkg/view?usp=sharing
rootfan said:
Here's twrp 3.3.1-0 for Shield TV. It seems to work properly on my shield pro running 7.2.3, I was able to flash magisk with it, but I don't have the 2017 model to test on. Please let me know how it works and report any errors in as detailed a manner as possible. As ever, this is experimental and you flash at your own risk :good:
https://drive.google.com/file/d/1REnehReTaA5BamUBDe8XmBMyZG6zQkFB/view?usp=sharing
Click to expand...
Click to collapse
there is always the bug for 4k screen display?
rootfan said:
Here's twrp 3.3.1-0 for Shield TV. It seems to work properly on my shield pro running 7.2.3, I was able to flash magisk with it, but I don't have the 2017 model to test on. Please let me know how it works and report any errors in as detailed a manner as possible. As ever, this is experimental and you flash at your own risk :good:
https://drive.google.com/file/d/1REnehReTaA5BamUBDe8XmBMyZG6zQkFB/view?usp=sharing
Click to expand...
Click to collapse
Many thanks i renamed this to recovery.img and renamed magisk boot img to boot.img reflashed both as part of the whole 7.2.3 dev OS shield tv 2017 image.
booted into TWRP via adb from my pc it loads up fine on my LG 43" 4k tv no problem rebooted and got back into 7.2.3 also without any issues
UPDATE: TWRP will not let me wipe system / data or anything else or mount any partitions in order to wipe before trying to install anything making this sadly kinda useless right now
twrp seems complicated to be functional lately, the same on my mi max 3, but orange Fox might be better on Shield
leezaal said:
UPDATE: TWRP will not let me wipe system / data or anything else or mount any partitions in order to wipe before trying to install anything making this sadly kinda useless right now
Click to expand...
Click to collapse
Well that makes sense because I was overwriting the emmc fstab with the sata one. I've updated my original post with a link to a new twrp that should have this problem fixed. If you're still having issues please click on the menu button to the right of the home button in twrp and tell me what the log says. Do this when first booting into twrp before doing anything else. It should say something like the following with no mounting complaints if everything is working right.
Shield Debug: Hardware variant is darcy
Shield Debug: Using emmc fstab
Shield Debug: Found required fstab
rootfan said:
Well that makes sense because I was overwriting the emmc fstab with the sata one. I've updated my original post with a link to a new twrp that should have this problem fixed. If you're still having issues please click on the menu button to the right of the home button in twrp and tell me what the log says. Do this when first booting into twrp before doing anything else. It should say something like the following with no mounting complaints if everything is working right.
Shield Debug: Hardware variant is darcy
Shield Debug: Using emmc fstab
Shield Debug: Found required fstab
Click to expand...
Click to collapse
Thanks for the great feedback will DL the updated TWRP and give it a go will report back shortly
UPDATE: 100% working ! Amazing work all partitions mount etc no problem FULLY working TWRP on my 4k TV too
Compiled Stock Kernel + Sources
*insert usual disclaimer here*
I AM NOT RESPONSIBLE FOR ANY DAMAGE TO YOUR DEVICE. USE AT YOUR OWN RISK. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Testing? What will work?
Bugs:
- You tell me
INSTRUCTIONS
0. MAKE BACKUP
1. Download zip file
2. Download Magisk
3. Download Magisk fix
4. Flash Magisk
5. Flash Magisk fix
6. Flash Kernel zip
Resources:
SOURCE CODE
DOWNLOAD {Mod edit}
Credits:
karthick111
@datty
Hi mKenfenheuer, thanks for the credit.
I'm at the same point, I can get the kernel to build but no boot. I get dropped back to fastboot immediately after trying to boot.
I've tried flashing a blank vbmeta, but it didn't seem to help. I'm not sure if it is the AVB2.0 blocking the boot or something else.
I've noticed you've changed OPPO_TARGET_DEVICE to MSM_19061. How did you decide on that value? I've since been using MSM_19781 as that is the value of getprop ro.product.prjversion from my device (Malaysian version)
datty said:
Hi mKenfenheuer, thanks for the credit.
I'm at the same point, I can get the kernel to build but no boot. I get dropped back to fastboot immediately after trying to boot.
I've tried flashing a blank vbmeta, but it didn't seem to help. I'm not sure if it is the AVB2.0 blocking the boot or something else.
I've noticed you've changed OPPO_TARGET_DEVICE to MSM_19061. How did you decide on that value? I've since been using MSM_19781 as that is the value of getprop ro.product.prjversion from my device (Malaysian version)
Click to expand...
Click to collapse
Same behaviour for me. I've started with the target device mentioned in your repo, then changed to 19781, afterwards i've been trying out the ones from drivers/input/oppo_fp_driver/Makefile. I've just been stuck at 19061 since it was the last one i've tried, there is no specific reason for that.
I've not been working with devices with AVB 2.0 - i can see that my device is displaying "Secureboot enabled" in fastboot. As far as i can say this would be a pretty good reason for the device to refuse booting the new kernel as our kernel is probably not signed.
I'll look into signing the kernel with the dev key in the repo root. Maybe this helps. If not we would problaby need another solution to get around the secure boot.
I've made some progress, I can get the kernel to try to boot but I'm stuck at the realme logo without adb to debug what is wrong.
If you're using the kernel config extracted from the device, add the following config option.
CONFIG_BUILD_ARM64_DT_OVERLAY=y
I'm not sure if this is also necessary but I generated a new dtbo.img to flash from the compiled kernel.
You'll need mkdtboimg.py and you can run the following from the out/arch/arm64/boot directory after compilation.
python mkdtboimg.py create dtbo.img dts/*/*.dtbo
You can try to compare arter97 realme X kernel to raw source if it's any helpful.
datty said:
I've made some progress, I can get the kernel to try to boot but I'm stuck at the realme logo without adb to debug what is wrong.
If you're using the kernel config extracted from the device, add the following config option.
CONFIG_BUILD_ARM64_DT_OVERLAY=y
I'm not sure if this is also necessary but I generated a new dtbo.img to flash from the compiled kernel.
You'll need mkdtboimg.py and you can run the following from the out/arch/arm64/boot directory after compilation.
python mkdtboimg.py create dtbo.img dts/*/*.dtbo
Click to expand...
Click to collapse
Unfortunately i cannot. even with the config option i am still not able to get it booting.
I have created a repo to reflect how i am building the kernel and making the boot img + dtbo img.
https://github.com/mKenfenheuer/realme-X2Pro-kernel-build
Am i missing something? Also i assume that my generated dtbo.img is bad, as soon as i flash it, i cannot even boot to recovery.
This is a long shot but as @SHiFT! pointed out, maybe comparing the source of @arter97 can help us getthing this mess to boot.
mKenfenheuer said:
Unfortunately i cannot. even with the config option i am still not able to get it booting.
I have created a repo to reflect how i am building the kernel and making the boot img + dtbo img.
https://github.com/mKenfenheuer/realme-X2Pro-kernel-build
Am i missing something? Also i assume that my generated dtbo.img is bad, as soon as i flash it, i cannot even boot to recovery.
Click to expand...
Click to collapse
Try using the Image-dtb file rather than the plain Image to add to boot.img. You might need to change your make line to the following to get it to generate:
make -j$(nproc --all) O=out CC=clang CLANG_TRIPLE=aarch64-linux-gnu- Image-dtb dtbs
For the dtbo.img, it looks like you're adding *.dtb rather than *.dtbo.
I'll try and upload my build scripts later tonight, I'm at work at the minute and can't get to them.
I've made a little more progress, I've managed to get adb to come up at early boot so I can get a logcat and shell. The kernel looks to be failing on the audio and wireless at the minute from what I can see.
Thanks for the pointer to arter97's kernel. I can see where I've missed adding the external wifi module in, I'll give that a go and hopefully it gets a little further.
datty said:
Try using the Image-dtb file rather than the plain Image to add to boot.img. You might need to change your make line to the following to get it to generate:
make -j$(nproc --all) O=out CC=clang CLANG_TRIPLE=aarch64-linux-gnu- Image-dtb dtbs
For the dtbo.img, it looks like you're adding *.dtb rather than *.dtbo.
I'll try and upload my build scripts later tonight, I'm at work at the minute and can't get to them.
I've made a little more progress, I've managed to get adb to come up at early boot so I can get a logcat and shell. The kernel looks to be failing on the audio and wireless at the minute from what I can see.
Thanks for the pointer to arter97's kernel. I can see where I've missed adding the external wifi module in, I'll give that a go and hopefully it gets a little further.
Click to expand...
Click to collapse
My kernel is booting now, but wifi and aod are causing issues.
As for now, the zip requires magisk to be flashed first.
I've had some chat with other devs working on our devices kernel in the official telegram group, they're in touch with realme, realme will release their wifi driver from qualcomm soon on their github.
Credits for getting me up to here go to karthick111 from the telegram group.
Realme kernel source code got updated. Any great news?
BlazeMaster64 said:
Realme kernel source code got updated. Any great news?
Click to expand...
Click to collapse
No. I've imported the changes by realme, things got worse. Now the kernel is not booting anymore.
I'll look into this once i've got more time
mKenfenheuer said:
No. I've imported the changes by realme, things got worse. Now the kernel is not booting anymore.
I'll look into this once i've got more time
Click to expand...
Click to collapse
Do you think this phone is worth buying over xiaomi redmi k20 pro?
BlazeMaster64 said:
Do you think this phone is worth buying over xiaomi redmi k20 pro?
Click to expand...
Click to collapse
Of course it's a better phone in almost all terms
Great news! Turns out that the changes by realme actually fix the AoD and the reason why the kernel was not booting was my fault, i still had unfinished changes regarding SafetyNet which got compiled and caused the kernel to panic (i'd do that too if i were him).
So the current status is that now all main functionalities work as i was able to fix wifi too (with a little help of arter97).
All changes can be found in my github repo so feel free to fork!
mKenfenheuer said:
Great news! Turns out that the changes by realme actually fix the AoD and the reason why the kernel was not booting was my fault, i still had unfinished changes regarding SafetyNet which got compiled and caused the kernel to panic (i'd do that too if i were him).
So the current status is that now all main functionalities work as i was able to fix wifi too (with a little help of arter97).
All changes can be found in my github repo so feel free to fork!
Click to expand...
Click to collapse
Good job ,that's a good news Go on
If I may ask after you finish working in the kernel would it be easy to build custom roms with the help of your kernel ,Thanks to you
Hi. Thank you for your kernel. I'm a bit noob about kernel, so it's difficult to me understand kernel's features. What's this kernel different then the stock one?
asusgarb said:
Hi. Thank you for your kernel. I'm a bit noob about kernel, so it's difficult to me understand kernel's features. What's this kernel different then the stock one?
Click to expand...
Click to collapse
It's a work in progress to have a working kernel base for our phone which will then be useful for other people to build their own customized kernel with it.
Is the FP issue an kernel related issue? Or overlay?
natedogg20050 said:
Is the FP issue an kernel related issue? Or overlay?
Click to expand...
Click to collapse
What do you mean by FP issue? In case you are refering to the issues with GSI's, check out the issues on phhussons github:
https://github.com/phhusson/treble_experimentations/issues/1103
The cause of this is Realme/Oppo not sticking to standards and of course the fact that the in display fp reader is quite new and does not have any generic stock implementation yet.
So TL;DR its not a kernel issue. Phhusson is working on this with Google.
realme x2pro cm rom
---------- Post added at 12:22 PM ---------- Previous post was at 12:17 PM ----------
John Amin said:
Good job ,that's a good news Go on
If I may ask after you finish working in the kernel would it be easy to build custom roms with the help of your kernel ,Thanks to you
Click to expand...
Click to collapse
sir videos