Related
Finally managed to build a zImage, but now trying to build a *.nbh file with it. I've git both bootenv, tinboot, and also the latest kernel commit for 2.6.32.
Compressed initrd.lzma down to 1.1MB (original initrd.lzma was about 950KB, but with it, still got the error), and my zImage is 1.9MB, but I continue to get this error whenever I run this:
Code:
./compilekaiser
Code:
tinboot.S: Assembler messages:
tinboot.S:142: Error: attempt to move .org backwards
./arm-none-eabi-objcopy: 'tinboot.o': No such file
cat: tinboot: No such file or directory
=== yang v1.1: Yet Another NBH Generator
=== (c) 2008 Pau Oliva Fora - pof @ XDA-Developers
[] Output NBH file: KAISIMG-PANEL3-320-TILT4-FROYO.NBH
[] Input files: output.nb
[] Input types: 0x400
[] SignMaxChunkSize: 64
[] Device: KAIS****
[] CID: 11111111
[] Version: 1.0.MARTIN
[] Language: WWE
[] 0x400 --> output.nb
Done!
I've done some searches, and found that I have to decrease the size of my initrd, but not sure what else to strip from it, and also my zImage is base built, and the size really doesn't change whenever I change any options in menuconfig.
Ok, the original question of this thread has been solved, but a new question...
I used the vogue.config file provided from the git, but everytime I flash the kernel, it just shows a black screen?
Is there anything I'm doing wrong, or better yet, any developer able to provide their .config file that they know works, so I can take a look what I'm configuring incorrectly and correct it?
Krazy-Killa said:
Ok, the original question of this thread has been solved, but a new question...
I used the vogue.config file provided from the git, but everytime I flash the kernel, it just shows a black screen?
Is there anything I'm doing wrong, or better yet, any developer able to provide their .config file that they know works, so I can take a look what I'm configuring incorrectly and correct it?
Click to expand...
Click to collapse
I use the default vogue config, then I use tinboot but I use the initrd.lzma from bootenv since sometimes people update that and forget to update tinboot. Then, after I have an image, I use atools to edit. I always resize the NAND partitions so that /system is almost completely full, and set /system and /data to auto so I can experiment with sdcard /data without reloading the kernel. I could probably find a way to set those in the build so I don't need to run atools, but I just use what I know works.
I haven't used my own kernel build since February 10. I have been using l1q1d's experimental kernel. I have seen kernel updates since then but haven't even checked to see what they are.
n2rjt said:
I use the default vogue config, then I use tinboot but I use the initrd.lzma from bootenv since sometimes people update that and forget to update tinboot. Then, after I have an image, I use atools to edit. I always resize the NAND partitions so that /system is almost completely full, and set /system and /data to auto so I can experiment with sdcard /data without reloading the kernel. I could probably find a way to set those in the build so I don't need to run atools, but I just use what I know works.
I haven't used my own kernel build since February 10. I have been using l1q1d's experimental kernel. I have seen kernel updates since then but haven't even checked to see what they are.
Click to expand...
Click to collapse
Thanks! Using the default initrd.lzma did the trick. Now if only the bootenv git was updated with this compressed initrd. xD
Currently using a custom kernel I built. Made some changes to yaffs2, mtd, and NAND configuration. Had a crash on initial boot, did a soft reset and phone came back with no corruption, and my "bad block 160" went away. I'm currently testing it for 24hrs, then if all goes well, I'm going to go a week and report back.
Though currently I have no bluetooth, as the module isn't loading.. Will look into that, and try and see if it's build related, and if the module can be loaded manually.
if you use the bluetooth as module it doesn't works, probably because it doesn't enable on boot the correct hardware part. You need to select it as built-in.
l1q1d said:
if you use the bluetooth as module it doesn't works, probably because it doesn't enable on boot the correct hardware part. You need to select it as built-in.
Click to expand...
Click to collapse
Currently bluetooth is not my concern, though I did get it running, by loading the modules manually using 'modprobe', but I have no idea how well the bluetooth subsystem works in its current state, but it does turn on, and do a search of nearby devices.
My main concern is my NAND configuration. So far no issues as of yet, but will know more when 1.5days elapses. Had an issue last night with the phone app crashing with acore failing, but coming back after rebooting the phone with no data loss.
Gmail app also crashed, but after 2 crashes it reloaded (possibly some data loss), and started re-syncing my email.
Besides those two, no real issues yet.
Krazy-Killa said:
Besides those two, no real issues yet.
Click to expand...
Click to collapse
What have you changed, just options in the defconfig?
scooter1556 said:
What have you changed, just options in the defconfig?
Click to expand...
Click to collapse
Enabled yaffs ECC support, but forced it to use the same ECC as the NAND driver. Enabled NAND ECC support inside the driver itself, as well as other changes.
Also left block refreshing, background processing, and left force chunk erase check enabled.
Had to disable EXT2, and EXT4 file system support to decrease kernel size, but for my case, don't need them as I'm using full NAND install anyways.
Currently approaching 18hrs, with no issues, installed more apps with no issues with corruption, still getting random FCs with core apps, but they re-enable afterwards (Most likely isolated, so not a real concern at the moment). Once i approach 18hrs, I'll do a safe reboot, and see what happens there.
My bad block 160 came back, but that's the only bad block that has returned, no new ones as of yet.
I'm hoping to concentrate my efforts on working on cpu scaling, whether it be using CPUFreq, or a kernel hack... I'm actually interested in knowing how Myn got his Rogue Tools to adjust the CPU Scale dynamically. As I'm thinking (though horrible at coding), of writing a kernel module to dynamically adjust the CPU core based on activity of the core.
If you ask Myn nicely he might send you a link to his sources. I believe he modified the kernel parameter in /sys or /proc (I always get those two confused). I know that the battery parameters with which i am most familiar can be modified dynamically that way.
Sent from my Android on HTC Kaiser using XDA App
n2rjt said:
If you ask Myn nicely he might send you a link to his sources. I believe he modified the kernel parameter in /sys or /proc (I always get those two confused). I know that the battery parameters with which i am most familiar can be modified dynamically that way.
Sent from my Android on HTC Kaiser using XDA App
Click to expand...
Click to collapse
I'll most likely contact Myn first chance I get. Been busy with family matters as of late.
Built a new kernel yesterday morning, and showing promise. Phone goes into a very deep sleep now (literally have to wait 5-10 seconds for the phone to respond like when a PC wakes from suspend), and actually shows improvement in battery life while in sleep mode but massive increase in battery usage when phone is waking, so may have to change how the phone sleeps.
Phone stability has increased as well. Despite the slow time it takes to wake, the phone has yet to crash, or slow down performance wise.
NAND is also showing improvement. Did a soft reset last night, phone restarted without problem, and no loss of data or any yaffs tragedy errors. Still installing apps at the moment. Data partition is at 45MB out of 101MB.
Free RAM is at 35MB while on home screen.
Currently using Radio 1.70.19.09, and HardSPL 3.56.
If all goes well, tonight I may post my kernel flavor as well.
*EDIT* Anyway that the bootenv git repo be updated with what's being used in initrd.lzma file?
Something went wrong?
I'm eager to test the kernel you have prepared.
Sent from my CyanogenMod Kaiser/Kaiser using XDA App
tiagoclc said:
Something went wrong?
I'm eager to test the kernel you have prepared.
Sent from my CyanogenMod Kaiser/Kaiser using XDA App
Click to expand...
Click to collapse
Currently running into a problem with the acore being corrupted, which doesn't make since as it's in /system.
I'm testing out having CompCache running but not JIT, as each time acore gets messed up the JIT was enabled.
If all goes well tomorrow, I may post the updated kernel and and androidupdate.tgz file with modules.
n2rjt said:
I use the default vogue config, then I use tinboot but I use the initrd.lzma from bootenv since sometimes people update that and forget to update tinboot. Then, after I have an image, I use atools to edit. I always resize the NAND partitions so that /system is almost completely full, and set /system and /data to auto so I can experiment with sdcard /data without reloading the kernel. I could probably find a way to set those in the build so I don't need to run atools, but I just use what I know works.
Click to expand...
Click to collapse
And now, I haven't been able to build a kernel that fits for quite a while.
The initrd.lzma is larger than I remember:
bootenv: 1011446 bytes
tinboot: 1011027 bytes
bootenv/initrd, smallest I can pack it is 1012491 bytes.
And zImage is 2006008 bytes.
I tried to make a smaller initrd.lzma by replacing all the duplicate files with symbolic links. That resulted in 1012491 bytes. I tried using hard links, but ended up with 1582661 bytes. I even tried unpacking the tinboot/initrd.lzma and repacking it, but no success.
n2rjt said:
If you ask Myn nicely he might send you a link to his sources. I believe he modified the kernel parameter in /sys or /proc (I always get those two confused). I know that the battery parameters with which i am most familiar can be modified dynamically that way.
Click to expand...
Click to collapse
An extract from RogueTools source code:
String outputFreq = "echo \"" + strFreq
+ "\" > /sys/module/clock_7x00/parameters/a11\n";
Can parted be moved from initrd to the android rom?
That saves a ton of space, and allows all to fit.
NO, parted is needed for atools - sd partitioner, i change both the 2.6.25 and the 2.5.32 to lzma initrd for it.
n2rjt said:
And now, I haven't been able to build a kernel that fits for quite a while.
The initrd.lzma is larger than I remember:
bootenv: 1011446 bytes
tinboot: 1011027 bytes
bootenv/initrd, smallest I can pack it is 1012491 bytes.
And zImage is 2006008 bytes.
I tried to make a smaller initrd.lzma by replacing all the duplicate files with symbolic links. That resulted in 1012491 bytes. I tried using hard links, but ended up with 1582661 bytes. I even tried unpacking the tinboot/initrd.lzma and repacking it, but no success.
An extract from RogueTools source code:
String outputFreq = "echo \"" + strFreq
+ "\" > /sys/module/clock_7x00/parameters/a11\n";
Click to expand...
Click to collapse
I haven't had a problem with repacking initrd.lzma. I've kept mine below 975KBs, which is perfect for me.
Also as far as using what Rogue Tools uses, I've determined it wouldn't be a good system to code, as it requires to phone to sleep first before the new clock settings take effect.
I'll continue to look into the cpu coding, to find why scaling is not being recognized by the kernel. For now, I'm going to try and downclock the cpu core to 250MHz to see how much of a difference I get in battery life, but I suspect I won't get much since the voltage isn't being changed.
Krazy-Killa said:
Ok, the original question of this thread has been solved, but a new question...
I used the vogue.config file provided from the git, but everytime I flash the kernel, it just shows a black screen?
Is there anything I'm doing wrong, or better yet, any developer able to provide their .config file that they know works, so I can take a look what I'm configuring incorrectly and correct it?
Click to expand...
Click to collapse
Hi! Could you share what you did to slove the problem "tinboot.S:142: Error: attempt to move .org backwards".Thank you in advance.
Kernel plus initrd are too large if you get that message. First be sure your initrd is built with hardlinks to busybox. If that is still too large try fewer kernel features. For me, the standard kernel and bootenv fit. What sizes are the zImage and initrd.lzma files for you?
Sent from my Android on HTC Kaiser using XDA App
Man I need to read up on all the new Linux stuff... I'm so far behind I'm getting lost.
Personally I want to pack initrd and everything else into a package along with a singular build (current 2.2 8/25/2011) and just make one install package for everything. That way I can pack the install, updates and kernel into one kaisimg.
Keep up the good work guys!!!
The starting idea is wrong!
The multiple file: the nbh for kernel and initrd and the tgz file are setted up for large compatibility (multiple device use them). So creating a nbh only for kaiser is a bad idea.
Also you need to create a nbh for every single parameter in atools (like screen, keyboard, panel) it's crazy!
Ace 2 Gt-i8160L LATIN. How to install CM?
When I install CM, don't wok sim-card and not IMEI.
Restore IMEI don't helped.
This is modem or hw problems, i think.
Sorry my english is bad.
...
Replace tee folder in rom zip /system/lib with the one from stock rom
Sent from my GT-I8160 using Tapatalk
1) backup tee folder
2) On build.prop change all GT-I8160L to GT-I8160 (without L)
3) all wipes factory/cache/dalvik
3) Install CM_Xversion
4) Whith roo explorer replace tee folder
Enjoy.
2) also can delete assert :/
4) you can just replace in zip before flashing (just sayin)
Sent from my GT-I8160 using Tapatalk
When to alter ROM
teddytsen said:
2) also can delete assert :/
4) you can just replace in zip before flashing (just sayin)
Sent from my GT-I8160 using Tapatalk
Click to expand...
Click to collapse
Am located in New Zealand, and hence using model i8160L, running stock JB ROM
Am trying to modify / install Maclaw CM KK ROM -- but am having problems
-- it "reads" the ROM and "immediately" (afaik) but aborts installation
-- NO ERROR MESSAGES come up for any indication as to why it's aborting
Am trying to do the following -- appreciate any feedback to correct procedure if I'm making eny errors
(i) omitting any and all references to L in 8160L string -- should I restrict it to any particular lines? -- using Build.Prop Editor
-- the Settings/About Device shows it as an 8160, rather than an 8160L after the Build.Prop changes, but the boot screen still shows it as the 8160L -- but at least I don't get the error message about trying to install ROM on wrong device
(ii) before attempting installation, downloading the latest ROM, unzipping the ROM using 7zip, deleting "tee" folder
-- and pasting tee folder from the stock JB ROM installed on my phone
(iii) re-zipping the ROM using 7zip -- I notice I get a different MD5 to that llsted on the download page
(iv) attempting to flash the modified ROM in Recovery mode, but it aborts
Don't know enough to know if install procedure tries to validate the "to be installed" ROM's MD5 and aborts since it's different from that on the download page
Don't know what purpose of tee folder is -- is it to connect to local carrier?
How about if I try to install "unmodified" ROM (in its unmodified form) and once it's installed, if it does (?), replace the tee folder at that later stage, to check for ability to connect to carrier?
Do I need to unlock the SIM card first --- as that's also something I haven't done
(naturally, I've backed up and able to restore to what I had before attempting the install)
KiwiCool60a said:
Am located in New Zealand, and hence using model i8160L, running stock JB ROM
Am trying to modify / install Maclaw CM KK ROM -- but am having problems
-- it "reads" the ROM and "immediately" (afaik) but aborts installation
-- NO ERROR MESSAGES come up for any indication as to why it's aborting
Am trying to do the following -- appreciate any feedback to correct procedure if I'm making eny errors
(i) omitting any and all references to L in 8160L string -- should I restrict it to any particular lines? -- using Build.Prop Editor
-- the Settings/About Device shows it as an 8160, rather than an 8160L after the Build.Prop changes, but the boot screen still shows it as the 8160L -- but at least I don't get the error message about trying to install ROM on wrong device
(ii) before attempting installation, downloading the latest ROM, unzipping the ROM using 7zip, deleting "tee" folder
-- and pasting tee folder from the stock JB ROM installed on my phone
(iii) re-zipping the ROM using 7zip -- I notice I get a different MD5 to that llsted on the download page
(iv) attempting to flash the modified ROM in Recovery mode, but it aborts
Don't know enough to know if install procedure tries to validate the "to be installed" ROM's MD5 and aborts since it's different from that on the download page
Don't know what purpose of tee folder is -- is it to connect to local carrier?
How about if I try to install "unmodified" ROM (in its unmodified form) and once it's installed, if it does (?), replace the tee folder at that later stage, to check for ability to connect to carrier?
Do I need to unlock the SIM card first --- as that's also something I haven't done
(naturally, I've backed up and able to restore to what I had before attempting the install)
Click to expand...
Click to collapse
md5 sum change probably because you uncompressed and re-compressed file.
no you dont have to unlock carrier.
use total commander and delete first 3 lines in updater-script.(all before mount.. bahblablah) and then compress it, then try.
btw it doesnt show any status errors?
When to alter ROM cont'd
teddytsen said:
md5 sum change probably because you uncompressed and re-compressed file.
no you dont have to unlock carrier.
use total commander and delete first 3 lines in updater-script.(all before mount.. bahblablah) and then compress it, then try.
btw it doesnt show any status errors?
Click to expand...
Click to collapse
MANY MANY thanks for your very prompt reply, and further information
"status errors" -- as a result of ?? -- no status errors evident after rebooting with modfified Build.Prop
had lots of "fun" on my previous efforts with custom ROMs -- played with several on a Huawei G300 I had --
-- but, gee, this is an ongoing learning process -- now to learn about updater script !!!
(only learnt about Total Commander from your post - despite its high rating -- but note others have used other things for "text editing")
(but have discovered some TUTs on xda)
Reading more carefully through the posts I see it may be possible to flash the ROM, and then later, substitute the tee folder supplied in the Maclaw ROM with the stock JB one -- right?
I'll definitely learn more about updater-script, but I'll try to flash the ROM again without modifying the ROM === OK?
KiwiCool60a said:
MANY MANY thanks for your very prompt reply, and further information
"status errors" -- as a result of ?? -- no status errors evident after rebooting with modfified Build.Prop
had lots of "fun" on my previous efforts with custom ROMs -- played with several on a Huawei G300 I had --
-- but, gee, this is an ongoing learning process -- now to learn about updater script !!!
(only learnt about Total Commander from your post - despite its high rating -- but note others have used other things for "text editing")
(but have discovered some TUTs on xda)
Reading more carefully through the posts I see it may be possible to flash the ROM, and then later, substitute the tee folder supplied in the Maclaw ROM with the stock JB one -- right?
I'll definitely learn more about updater-script, but I'll try to flash the ROM again without modifying the ROM === OK?
Click to expand...
Click to collapse
-Dont care about ro.build.model. once assert is deleted you dont have to change it. And its not mandatory.
-I recommended total commander just because its the only root browser i have that shows the assert in 3 lines exactly. Unless es etc. You can also use other editors ^.^
-like when installation is aborted, it says status 7(or 0 etc)
Sent from my GT-I8160 using Tapatalk
Many thanks -- now for the "rest" and time for tee
teddytsen said:
-Dont care about ro.build.model. once assert is deleted you dont have to change it. And its not mandatory.
-I recommended total commander just because its the only root browser i have that shows the assert in 3 lines exactly. Unless es etc. You can also use other editors ^.^
-like when installation is aborted, it says status 7(or 0 etc)
Sent from my GT-I8160 using Tapatalk
Click to expand...
Click to collapse
Many thanks!! KK installed -- that was the "fascinating" thing -- no status errors on previous failed attempt at installation -- nothing
but now it's installed -- with GApps added, and now to "worry" about the rest of it all
unsurprisingly -- if tee does what I think it does -- but I can't find a TUT on that anywhere
-- so currently, I can't connect to my local carrier, so it's currently not a :"phone" as such
even more frustratingly, computer found phone when it was first plugged in, but now seems to have lost it!! time to reboot system
-- and, it's been a while since I used CM but I can't find extsdcard!!
Cm file manager?
Settings-general settings-access mode- root
Sent from my GT-I8160 using Tapatalk
Permissions
teddytsen said:
Cm file manager?
Settings-general settings-access mode- root
Sent from my GT-I8160 using Tapatalk
Click to expand...
Click to collapse
sorry, not used to that one -- for that matter, I tend to stay away from things affecting the system I don't know
so I'm lost in permissions in different apps -- can't find "paste" in CM file, and can't find RW permissions in ES!!
But you're being exceptionally patient! thanks, heaps
Lot easier than I thought -- and MANY thanks again
KiwiCool60a said:
sorry, not used to that one -- for that matter, I tend to stay away from things affecting the system I don't know
so I'm lost in permissions in different apps -- can't find "paste" in CM file, and can't find RW permissions in ES!!
But you're being exceptionally patient! thanks, heaps
Click to expand...
Click to collapse
Actually, it's a lot easier than I thought -- working phone, with KK installed -- without need to unlock carrier!!
Many thanks for the guidance, patience ....
and, of course, to the ROM developers
Repeated problems with Maclaw KK ROM
KiwiCool60a said:
Actually, it's a lot easier than I thought -- working phone, with KK installed -- without need to unlock carrier!!
Many thanks for the guidance, patience ....
and, of course, to the ROM developers
Click to expand...
Click to collapse
Many thanks for past help with intall procedure -- but have had repeated problems of late -- last installed ROM on March 9th -- could install several versions prior to that date, and use them successfully, but since then have been unable since I repeatedly get "Error searching for networks", and hence cannot connect to carrier, and hence unable to use phone as phone, though other functions seem to work OK, -- any ideas??
Hello everybody,
I created a tool for the nexus 9 that gets rid of the ForceEncrypt flag in a generic way (meaning it should work no matter what rom you are on). It does that by patching the currently installed boot.img.
Background
The Android CDD (Compatibility Definition Document) suggests that all devices SHOULD enable full disk-encryption (FDE) by default. Even though I support every step towards more security I have to criticize this approach. FDE comes at a price. Encryption takes time because some component has to de- and encrypt the stuff on the disk at some point and in the case of the nexus 9 (aka flounder) it's the CPU's task. Even though the nexus 9's CPU has 2 pretty fast cores you can still easily feel the difference between FDE in the on- or off-state. The I/O is faster and boot-times take only half as long. (I did not do any measurements)
There is an ongoing discussion about this topic in cyanogenmod's gerrit. Although it's a fun read it is pretty clear that this exchange of views is not going anywhere near a useful outcome.
Because performance is important to me and my tablet does not need the extra security I created the FED-Patcher (ForceEncrypt Disable Patcher)
How does it work?
FED-Patcher is a simple flashable ZIP that is supposed to be run in a recovery that has busybox integrated (like TWRP or CWM). This is what it does:
Checks if your device is compatible
Dumps the currently installed boot.img.
Unpacks the dump of your currently installed boot.img. The unpacking process is done via a self-compiled, statically linked version of unmkbootimg.
It patches the filesystem tables which include the force-encrypt flags. This process will change "forceencrypt" to "encryptable".
Then it patches the filesystem tables to not use dm-verity. This is done by removing the "verify" mount-parameter.
Creates a new boot.img. The unpacking process is done via a self-compiled, statically linked version of mkbootimg.
Flashes the modified boot.img
Supported devices
HTC Nexus 9 WiFi (flounder)
HTC Nexus 9 LTE (flounder_lte)
Motorola Nexus 6 (shamu)
Version History
v1 - Initial version with HTC Nexus 9 WiFi (flounder) support
v2 - Added Motorola Nexus 6 (shamu) support
v3 - Added support for HTC Nexus 9 LTE (flounder_lte)
v4 - Added support for signed boot-images
v5 - Changed error handling to compensate for missing fstab files. Some roms seem not to ship with the complete set of boot-files from AOSP.
v6 - FED-Patcher will enforce the same structure for the patched boot.img that the original boot.img had. Additionally, the kernel commandline will also be taken over. This should fix pretty much every case where devices would not boot after patching.
v7 - FED-Patcher will now disable dm-verity in fstab to get rid of the red error sign on marshmallow roms.
What do I need to make this work?
A supported device (Your nexus 9)
An unlocked bootloader
An already installed ROM with forceencrypt flag. (like cyanogenmod CM12.1)
A recovery that includes busybox (TWRP, CWM)
How do I use it?
Make a thorough, conservative backup of your data if there is any on your device
Go into your recovery (TWRP, CWM)
Flash fed_patcher-signed.zip
If your device is already encrypted (You booted your ROM at least once) you need to do a full wipe to get rid of the encryption. This full wipe will clear all your data on your data-partition (where your apps as well as their settings are stored) as well as on your internal storage so please, do a backup before. If you don't do a backup and want to restore your data... well... Call obama.
How do I know if it worked?
Go into your "Settings"-App. In "Security", if it offers you to encrypt your device it is unencrypted. If it says something like "Device is encrypted" it indeed is encrypted.
IMPORTANT: If you update your ROM you have to run FED-Patcher again because ROM-updates also update the boot-partition which effectively removes my patch. So, if you are on CM12.1 for example and you used my patch and do an update to a newer nightly you have to run FED-Patcher again. If you don't do so Android will encrypt your device at the first boot.
Is it dangerous?
Well, I implemented tons of checks that prevent pretty much anything bad from happening. But, of course, we're dealing with the boot-partition here. Even though I tested FED-Patcher quite a lot there is still room for crap hitting the fan.
Screenshot
Scroll down to the attached thumbnails.
Credits
* pbatard for making (un)mkbootimg (dunno if he is on xda)
* @rovo89 for his xposed framework - I used some of his ideas by reading the source of his xposed installer flashable ZIP for FED-Patcher.
Thanks for creating this! In theory, would this work for the Nexus 6 as well? It would seem like it's a similar process.
itlnstln said:
Thanks for creating this! In theory, would this work for the Nexus 6 as well? It would seem like it's a similar process.
Click to expand...
Click to collapse
Hey there,
yes, it would probably work because the process itself is pretty generic. The only real difference between devices is the device-path for the boot-partition as well as the path(s) for the fstab-file(s) inside the boot.img. Nothing that cannot be done - but I don't have a device for testing. If you feel adventurous I can do a nexus6 (shamu) version for you for testing. I will double check so it should not eff up your device .
EDIT: Not to forget, the nexus 9 is a 64bit device. mkbootimg as well as unmkbootimg are compiled for 64bit. I have to rebuild those two programs for 32bit to make them work for 32bit devices.
If you have time for a N6 build, that would be great. If not, it's not a big deal since there seems to be more support for that device.
itlnstln said:
If you have time for a N6 build, that would be great. If not, it's not a big deal since there seems to be more support for that device.
Click to expand...
Click to collapse
Well, it's pretty much done. Do you want to test a version that does not actually flash anything but do everything else - just to see if it works correctly?
Absolutely!
itlnstln said:
Absolutely!
Click to expand...
Click to collapse
Alright, here you go!
If no error occurs there will be the already modified boot.img file in your temp-directory of your nexus 6. You can send me this file to be completely sure that everything went according to plan. Here is the adb-command:
Code:
adb pull /tmp/fed_patcher/boot-new.img
If all goes well I will upload the new version with nexus 6 (shamu) support tomorrow.
Good night!
gladiac said:
Alright, here you go!
If no error occurs there will be the already modified boot.img file in your temp-directory of your nexus 6. You can send me this file to be completely sure that everything went according to plan. Here is the adb-command:
Code:
adb pull /tmp/fed_patcher/boot-new.img
If all goes well I will upload the new version with nexus 6 (shamu) support tomorrow.
Good night!
Click to expand...
Click to collapse
Thanks! It seemed to work OK. Here's the boot image.
itlnstln said:
Thanks! It seemed to work OK. Here's the boot image.
Click to expand...
Click to collapse
Thanks for your help! I just updated the flashable ZIP in the first post. Enjoy
gladiac said:
Thanks for your help! I just updated the flashable ZIP in the first post. Enjoy
Click to expand...
Click to collapse
You're the best! Thanks!
I noticed in op it says "4 pretty fast cores". This puppy only has 2 cores. Just throwing it out there for readers that don't know. I'm sure it was just a minor oversight.
Sent from my Nexus 9
madbat99 said:
I noticed in op it says "4 pretty fast cores". This puppy only has 2 cores. Just throwing it out there for readers that don't know. I'm sure it was just a minor oversight.
Sent from my Nexus 9
Click to expand...
Click to collapse
Hi,
you are right, thanks. I just fixed the text in the op.
Hey everybody,
I will enable support for the Nexus 9 LTE (flounder_lte) this afternoon in FED-Pather v3. If you want other devices to be supported please tell me. Is there a list of android devices that have forced encryption?
So this works great, leaving device unencrypted. But anyone having issues with apps crashing? Most especially Google Play Services?
femmyade2001 said:
So this works great, leaving device unencrypted. But anyone having issues with apps crashing? Most especially Google Play Services?
Click to expand...
Click to collapse
This problem is new to me. My patch only modifies the boot-image so that it does not enforce encryption. It is merely a flag in fstab that gets changed and should not have anything to do with crashing apps. Anyway, do you have a logcat?
Hey everybody,
v3 is here with HTC Nexus 9 LTE (flounder_lte) support!
Enjoy
I'm getting an error with my N9 (WiFi). When I try flashing in TWRP, it throws this error:
! Unpacking failed
=> unmkbootimg return value: 0
E: Error executing updater binary in zip...
All I did was go into fastboot, flash the updated image for LMY48M, then go into TWRP to flash the fix. I even went back into fastboot to try re-flashing the boot.img.
itlnstln said:
I'm getting an error with my N9 (WiFi). When I try flashing in TWRP, it throws this error:
! Unpacking failed
=> unmkbootimg return value: 0
E: Error executing updater binary in zip...
All I did was go into fastboot, flash the updated image for LMY48M, then go into TWRP to flash the fix. I even went back into fastboot to try re-flashing the boot.img.
Click to expand...
Click to collapse
Hi, sorry to hear that. I will have a look into the boot.img that gets shipped with LMY48M. Not sure what is going on here.
itlnstln said:
I'm getting an error with my N9 (WiFi). When I try flashing in TWRP, it throws this error:
! Unpacking failed
=> unmkbootimg return value: 0
E: Error executing updater binary in zip...
All I did was go into fastboot, flash the updated image for LMY48M, then go into TWRP to flash the fix. I even went back into fastboot to try re-flashing the boot.img.
Click to expand...
Click to collapse
Alright - unmkbootimg fails because the boot.img that google ships has 256 Bytes of extra data (it is probably signed or something) at the beginning. If you strip that off it works correctly:
Code:
dd if=boot.img of=boot-stripped.img bs=256 skip=1
Well, this was unexpected. But nothing that cannot be dealt with. I will make my flashable ZIP search for the offset of the boot.img-signature inside the dumped boot.img and strip of the preceding data. The rest of the process should work as usual.
itlnstln said:
I'm getting an error with my N9 (WiFi). When I try flashing in TWRP, it throws this error:
! Unpacking failed
=> unmkbootimg return value: 0
E: Error executing updater binary in zip...
All I did was go into fastboot, flash the updated image for LMY48M, then go into TWRP to flash the fix. I even went back into fastboot to try re-flashing the boot.img.
Click to expand...
Click to collapse
Hi @itlnstln,
I just made a new version which should do the trick. I tested the new functionality to the best of my knowledge. If the script fails for some reason it wont flash anything - so the probability for actual damage is very low. Do you feel adventurous xD?
Please tell me if it worked for you or not.
/etc/hosts blacklist entries seem to be ignored with Android 7.0 (e.g. adding 127.0.0.1 amazon.com still allows me to reach amazon.com). Is anyone else experiencing something similar or familiar with any gotchas around Android 7.0 and modifying /system/etc/hosts?
I'm running official Nexus 5X Android 7.0 build number NRD90R. I have an engineering build of android that I boot from as follows to modify my /system/etc/hosts file:
adb reboot-bootloader
fastboot boot my-recovery.img
<mount from phone menu>
adb remount
adb push my-hosts system/etc/hosts
adb shell
chmod 644 system/etc/hosts
exit
<reboot from phone menu>
I've been using this process after every OTA update since Android 6.0, and it's been working. I also noticed that I'm not getting the red warning on boot any more (the one you get after you modify anything on the system partition), just the yellow warning (the one you get from having phone unlocked). Maybe I did something wrong ¯\_(ツ)_/¯ but I could sure use a sanity check.
Could be related to java cache, after a modification to hosts file you should reboot to let the cache reload. Try it.
The OS is not booted when editing hosts since it's being edited from a recovery image with the system mounted into it. The last step is to reboot. I did reboot the phone again for good measure and it's still not working. If it is a cache related thing, it lives through reboot. I suspect it's not though as I was seeing ads in news websites that I do not frequent.
Any other thoughts?
Are you using chrome? Did you disable data saver option in chrome?
Sent from my SHIELD Tablet K1 using Tapatalk
Seems to be related to: http://forum.xda-developers.com/nex...oid-nougat-t3445647/post68737720#post68737720 . Basically the files that one would modify by mounting /system are no longer used, afaict.
When I boot a live image, mount the system partition, and make a modification (i.e. /system/etc/hosts), that change is persisted through a reboot back to the live image and remount. However, it's not loaded by the OS when it boots. Instead both /etc/hosts and /system/etc/hosts are unmodified. Odd, and why is there even anything mounted at /system? I'm not sure if there are multiple system partitions or what's going on. I would love to find some information about Android 7.0 that explains.
crashenx said:
Seems to be related to: http://forum.xda-developers.com/nex...oid-nougat-t3445647/post68737720#post68737720 . Basically the files that one would modify by mounting /system are no longer used, afaict.
When I boot a live image, mount the system partition, and make a modification (i.e. /system/etc/hosts), that change is persisted through a reboot back to the live image and remount. However, it's not loaded by the OS when it boots. Instead both /etc/hosts and /system/etc/hosts are unmodified. Odd, and why is there even anything mounted at /system? I'm not sure if there are multiple system partitions or what's going on. I would love to find some information about Android 7.0 that explains.
Click to expand...
Click to collapse
I responded to your post in the other thread. This is repost.
Android 7.0 introduced redundant bits for reed solomon forward error correction into the system and vendor partitions and code in the kernel to perform the error correction.
Your changes are being written to emmc but when you boot with 7.0 kernel with dm-verity enabled your changes are being treated as data corruption and on-the-fly error corrected back to original.
You can see your changes if you boot into twrp because it has dm-verity disabled. However if you boot into android with dm-verity enabled it will look like original image again even though your changes are technically still there.
It took me a day to figure out what was really going on because i initially had no idea they added this feature to Android N.
The simple way to disable dm-verity is to install SuperSU, but you can also accomplish the same patching your own kernel, installing pre-patched kernel, installing custom kernel, etc.
sfhub said:
I responded to your post in the other thread. This is repost.
Android 7.0 introduced redundant bits for reed solomon forward error correction into the system and vendor partitions and code in the kernel to perform the error correction.
Your changes are being written to emmc but when you boot with 7.0 kernel with dm-verity enabled your changes are being treated as data corruption and on-the-fly error corrected back to original.
You can see your changes if you boot into twrp because it has dm-verity disabled. However if you boot into android with dm-verity enabled it will look like original image again even though your changes are technically still there.
It took me a day to figure out what was really going on because i initially had no idea they added this feature to Android N.
The simple way to disable dm-verity is to install SuperSU, but you can also accomplish the same patching your own kernel, installing pre-patched kernel, installing custom kernel, etc.
Click to expand...
Click to collapse
That's good info and makes total sense. Thanks! Pretty neat actually, just a bummer for me.
Yeah so SuperSU path is not really one I want to pursue. I could learn how to update the dm-verity shas used for verification. That'd probably be the most secure, but it's gonna be a PITA I bet. I imagine I'd need to compile my own image similar to how I made my live image and update a few things. Might have to deal with encryption which is probably an even bigger headache. Also, I bet it would break OTA and have to reflash to update, though that's true now.
I'm really curious what AdAway is doing. Maybe I should pursue reverse engineering that.
I really appreciate you pointing us in the right direction.
crashenx said:
I'm really curious what AdAway is doing. Maybe I should pursue reverse engineering that.
Click to expand...
Click to collapse
I don't use adaway but I believe there are 2 ways to install it with Android N. First is to install SuperSU (or otherwise disable dm-verity) and have it update as it always has. 2nd way is systemless where it piggybacks on some init scripts SuperSU has created to mount "over" the existing hosts file. Basically like symlinking but using a mount point on top of the existing file.
sfhub said:
I don't use adaway but I believe there are 2 ways to install it with Android N. First is to install SuperSU (or otherwise disable dm-verity) and have it update as it always has. 2nd way is systemless where it piggybacks on some init scripts SuperSU has created to mount "over" the existing hosts file. Basically like symlinking but using a mount point on top of the existing file.
Click to expand...
Click to collapse
I'll probably try to go the route of updating init scripts to mount over the existing host file but without using SuperSU or AdAway.
This guide is intended to help people to achieve having a Pixel 6 Pro using GrapheneOS with Root (using Magisk) and a Locked Boot Loader
Though it should be possible to do this with any device that GrapheneOS officially supports.
Do not ever disable the OEM unlocking checkbox when using a locked bootloader with root. This is critically important. With root access, it is possible to corrupt the running system, for example by zeroing out the boot partition. In this scenario, if the checkbox is turned off, both the OS and recovery mode will be made unbootable and fastboot flashing unlock will not be allowed. This effectively renders the device hard bricked.
I am not responsible for any harm you may do to your device, follow at your own risk etc etc, Rooting your device can potentially introduce security flaws, I am not claiming this to be secure.
Simple method without building from source Although I highly recommend building Graphene yourself,
All you really need to do is patch the official OTA released by graphene using AVBRoot
Simply flash the official factory graphene build, then your patched OTA, then flash the avb_pkmd.bin you created following the instructions for AVBRoot and you can lock the bootloader, with patched rooted graphene.
You will need to patch each new OTA to update and sideload the update as explained HERE Flash it to Both Slots
Better Method, But requires more time and a decent computer
Only Recommended for people with experience things building from source
The first step is to build GrapheneOS from its sources or to use AVBRoot on official builds. I will include some of the information specific for Pixel 6 Pro to help with the build process
Part one, follow this guide to build GrapheneOS from source
You will want to build a Stable Release using the TAG_NAME
Code:
TP1A.221105.002.2022111000
this an EXAMPLE Tag for the Pixel 6 Pro
Find the Latest tag on the Releases page https://grapheneos.org/releases#raven-stable
Build the Kernal for Raviole (6th generation Pixels) and follow all the instructions there
When it comes to the step of "Extracting vendor files for Pixel devices"
The DEVICE is
Code:
raven
and an Example of the BUILD_ID is
Code:
tp1a.221105.002
Check the TAG_NAME for the Latest BUILD_ID
Continue to follow the guide until completion, creating your own Keys during the process
I do recommend testing to Lock the Boot Loader, Just to see if you are able to
In my experience if the pixel does not detect a valid signed boot etc, it will not allow you to lock the bootloader
So if it brings up the screen on your phone where you can confirm the locking of the bootloader
at this stage you can just select No / Do not lock
To build with a specific BUILD_NUMBER use the command
Code:
export BUILD_NUMBER=2022112500
Replacing the number with what matches the version you are attempting to build
Remove the encryption from keys/raven/avb.pem that was created for Graphene so that you can use it with AVBRoot
Use the script
Code:
script/decrypt_keys.sh
https://grapheneos.org/build#encrypting-keys
And set a copy of the key aside for the next steps.
Use the following process to create the correct keys for AVBRoot & GrapheneOS
Use the avb.pem you decrypted in the last step
Convert the avb.pem to avb.key with the following command
Code:
openssl rsa -outform der -in avb.pem -out avb.key
Then clone the avb.key and rename it to ota.key
as it says "The boot-related components are signed with an AVB key and OTA-related components are signed with an OTA key. They can be the same RSA keypair, though the following steps show how to generate two separate keys."
Convert the public key portion of the AVB signing key to the AVB public key metadata format. This is the format that the bootloader requires when setting the custom root of trust.
Code:
PATH/TO/avbroot/external/avb/avbtool.py extract_public_key --key avb.key --output avb_pkmd.bin
Generate a self-signed certificate for the OTA signing key. This is used by recovery for verifying OTA updates.
Code:
openssl req -new -x509 -sha256 -key ota.key -out ota.crt -days 10000 -subj '/CN=OTA/'
I also edit the "CN" to match what I used earlier when I generated the keys for Graphene
I am not entirely certain what other of the keys I should use instead, I think this is the best approach for now
as it creates all the keys it requires and this process works for me
Copy the OTA (raven-ota_update-*.zip) from the folder where you have your own Factory Graphene Build and use this with AVBRoot
Then you will have all the keys and files you need to continue the guide and use the AVBRoot script
Now it's time to follow the instructions Here https://github.com/chenxiaolong/avbroot
To create a full factory installer, Intall it and lock the bootloader.
When you are done with AVBRoot and you have the boot.img, vbmeta.img and vendor_boot.img
All patched and signed by AVBRoot, Take a factory image from your Graphene Build and Extract it anywhere
Open the image-raven-*.zip with an Archive manager
Delete the existing boot.img, vbmeta.img and vendor_boot.img files and replace them the patched ones
also replace the avb_pkmd.bin with the one you have created in the previous steps for AVBRoot (might work without this step)
Finally, you are able to run the flash-all.sh and then lock the bootloader
Code:
./flash-all.sh
Code:
fastboot flashing lock
Updating is very simple, Once you use AVBRoot to create the Patched OTA.zip
you can reboot to recovery and flash the patched ota.zip with adb sideload
Code:
adb sideload raven-ota_update-*.zip.patched
https://grapheneos.org/usage#updates-sideloading
Creating the patched full factory installer is not required if you simply flash the avb custom key and the patched OTA zip before locking the bootloader, after flashing the unpatched full system install build
This for me allowed me after much struggle to achieve a Rooted, Locked Boot Loader using GrapheneOS and Magisk
Now though with this guide worked out, I think it should be quite easy for anyone with basic terminal knowledge to accomplish.
Something to note is that GrapheneOS does Not Pass the CTS Profile integrity check
and I do Not Pass the Play Integrity API Check currently, Neither the Basic or Strong check
But I can pass the Basic attestation Safety Net test when using the patched SafetyNet Fix
Further testing is needed and welcomed to try and pass SafetyNet and Play Integrity
To Be Clear, Although it already should be, This is NOT Modifying the official Graphene OS Sources, it is simply using them as a SOURCE for a GUIDE, You build it using unmodified grapheneOS source code so it is an unnofficial build according to their website
Sources: GrapheneOS, AVBRoot, Magisk
PayPal Donation Link
I highly recommend using your own build that is signed with your own keys that you can keep secure!
I make no promises to provide any updates to this rom at this time
Here more as a proof of concept that it works and updates are possible
Latest builds moved to: Unofficial GrapheneOS, Magisk Patched for Pixel 6 / 6 Pro
This really is quite cool man. Maybe I'll try this on my new P7P. This way we have everything. Well Done!
How would you update the rom? Repeat the whole process?
Spl4tt said:
This really is quite cool man. Maybe I'll try this on my new P7P. This way we have everything. Well Done!
How would you update the rom? Repeat the whole process?
Click to expand...
Click to collapse
I haven't worked out updating yet but all it requires is patching an updated OTA with AVBRoot in theory
I have been quite busy irl and haven't had much time to play around with it, if you do figure it out then please let me know
Spl4tt said:
This really is quite cool man. Maybe I'll try this on my new P7P. This way we have everything. Well Done!
How would you update the rom? Repeat the whole process?
Click to expand...
Click to collapse
now that I have had time to do it, Updating was very easy
I have also updated and improved the process for getting and creating the correct keys used for signing
After updating it booted normally, still rooted, no apparent problems or issues
New Release 2022111000
Changes since the 2022110800 release:
remove TrustCor Certificate Authority due to malicious domain squatting and ties to entites involved in surveillance which should have very little impact on web compatibility due to this CA barely being used by anyone other than a specific dynamic DNS provider
ignore wireless alert channels being marked as always-on to prevent channel configuration overriding presidential alert toggle
GmsCompatConfig: change app label from "GmsCompat config" to "GmsCompatConfig"
GmsCompatConfig: disable TelecomTaskService to resolve sandboxed Google Play services crash caused by feature flag
kernel (Pixel 4, Pixel 4 XL, Pixel 4a, Pixel 4a (5G), Pixel 5, Pixel 5a): update base kernel to Android 13 QPR1 Beta 3 to ship the December security update early
Vanadium: update Chromium base to 107.0.5304.105
Download Moved to https://forum.xda-developers.com/t/...magisk-patched-13-raven.4518953/post-87728629
Hey, thanks for the excellent guide, this is all about to be applicable to me
I have run into a small issue though, when generating the avb.key, openssl gives me an unsupported error
openssl rsa -outform der -in avb.pem -out avb.key
routines:ssl_store_handle_load_result:unsupported:crypto/store/store_result.c:151:
Unable to load certificate
I am wondering if since I didn't put a password on the keys if that caused an issue. I tried encrypted/decrypted, same issue. It's a fresh arch linux install, so packages are up to date.
Thanks!
Wouldn't rooting GrapheneOS decrease the security of the operating system, a key aspect that Graphene is designed to improve? Seems like that defeats the purpose of using it in the first place.
holofractal said:
Hey, thanks for the excellent guide, this is all about to be applicable to me
I have run into a small issue though, when generating the avb.key, openssl gives me an unsupported error
openssl rsa -outform der -in avb.pem -out avb.key
routines:ssl_store_handle_load_result:unsupported:crypto/store/store_result.c:151:
Unable to load certificate
I am wondering if since I didn't put a password on the keys if that caused an issue. I tried encrypted/decrypted, same issue. It's a fresh arch linux install, so packages are up to date.
Thanks!
Click to expand...
Click to collapse
Thank you, I am glad that it has been helpful for you, I have not encountered that error myself but I did use a password initially for the steps to create the keys for Graphene, I don't think this should matter though
If you don't mind and are able to, can you create another copy of the avb.pem, see if the problem still occurs and share it with me if it does, so I can test if I get the same error when I use your .pem
EonOfBlack said:
Wouldn't rooting GrapheneOS decrease the security of the operating system, a key aspect that Graphene is designed to improve? Seems like that defeats the purpose of using it in the first place.
Click to expand...
Click to collapse
I do clearly say in the first post
> Rooting your device can potentially introduce security flaws, I am not claiming this to be secure.
I don't believe just using magisk is really such an issue, you are able to deny root from any applications you don't want to use it
it is possible there are unknown security vulnerabilities in magisk, but that's the same with anything.
Even though it may introduce some potential security vulnerabilities that Graphene combats against
I believe it should be everyones choice to use root and lock their boot loader if they choose to do so
holofractal said:
routines:ssl_store_handle_load_result:unsupported:crypto/store/store_result.c:151:
Unable to load certificate
Click to expand...
Click to collapse
This problem appears to be related to this https://github.com/openssl/openssl/issues/14100#issuecomment-847125920
A great and helpful guide!
Thank you, dear FireRattus
FireRattus said:
This problem appears to be related to this https://github.com/openssl/openssl/issues/14100#issuecomment-847125920
Click to expand...
Click to collapse
openssl x509 -outform der -in avb.pem -out avb.crt
It was this command
Code:
openssl x509 -outform der -in avb.pem -out avb.crt
Could not read cert etc. of certificate from avb.pem
4087C8C0777F0000:error:1608010C:STORE routines:ossl_store_handle_load_result:unsupported:crypto/store/store_result.c:151:
Following grapheneos's guide, that is generated with:
openssl genrsa 4096 | openssl pkcs8 -topk8 -scrypt -out avb.pem
I think the root of this issue is that the pkcs8 avb.pem is an RSA private key, and the command you specified is expecting a certificate.
At any point in time do you use the crt made by Copy the avb.pem and convert it to .crt with this command step?
So if I read over everything right, I believe the solution here would be to use
openssl req -new -x509 -sha256 -key avb.key -out avb.crt -days 10000 -subj '/CN=AVB/'
But since avb and ota can be the same key, then presumably avb.crt and ota.crt could be the same as well? I get my pixel 7 tonight. I'll try and report back.
I may have accidentally made a mistake like that in the guide, I am not able to test it at the moment but would love to know what works for you
FireRattus said:
I may have accidentally made a mistake like that in the guide, I am not able to test it at the moment but would love to know what works for you
Click to expand...
Click to collapse
So you don't even need that last section.
There are some small differences for the pixel 7 though, but it was easy enough.
I have to say, building grapheneos was the easiest time I've ever had building a ROM. Not once did I have to go on Google fishing for answers. Flashing the ROM and relocking the bootloader took less than 10m, even with root.
This is why I switched to a pixel. I am too old and don't have the time to sit here and fiddle with my phone for hours on end anymore. I need things to just work.
This is as close as you are going to get to first party level support with aftermarket software, but I still care about privacy.
I'll do a write up later so other's don't have the same issues as me, but thanks for getting me started!
holofractal said:
So you don't even need that last section.
There are some small differences for the pixel 7 though, but it was easy enough.
I have to say, building grapheneos was the easiest time I've ever had building a ROM. Not once did I have to go on Google fishing for answers. Flashing the ROM and relocking the bootloader took less than 10m, even with root.
This is why I switched to a pixel. I am too old and don't have the time to sit here and fiddle with my phone for hours on end anymore. I need things to just work.
This is as close as you are going to get to first party level support with aftermarket software, but I still care about privacy.
I'll do a write up later so other's don't have the same issues as me, but thanks for getting me started!
Click to expand...
Click to collapse
I am really glad that the process could be made so smooth and simple for you
I did spend a long time trying to get a rooted grapheneOS with a locked boot loader before I managed to finally work it out, thanks mostly to the developer of AVBRoot, their script is the essential part which has made this so easy
with my internet troubles as well it ended up taking me a few weeks from when I initially started trying to when I was able to lock the booloader with root successfully
Now that I have it all worked out though, I can update and patch it in very little time
Although I did write this guide for the Pixel 6 I would be happy to include any additional information which could be helpful for people using other pixels, I am just not able to test and verify the information myself on other devices
and you don't need the last section? the part where I create a full patched installer ? I did think about this, just using the patched OTA to update the rom should also work to get you root with a locked bootloader if you first flash the full installer you built yourself
I think this is possibly a better way of doing it, but I like also having the patched full installer
I would like to hear peoples opinions and what works best for them.
holofractal said:
I think the root of this issue is that the pkcs8 avb.pem is an RSA private key, and the command you specified is expecting a certificate.
At any point in time do you use the crt made by Copy the avb.pem and convert it to .crt with this command step?
So if I read over everything right, I believe the solution here would be to use
openssl req -new -x509 -sha256 -key avb.key -out avb.crt -days 10000 -subj '/CN=AVB/'
But since avb and ota can be the same key, then presumably avb.crt and ota.crt could be the same as well? I get my pixel 7 tonight. I'll try and report back.
Click to expand...
Click to collapse
I have tested it now and the last command I had to create the files was an unnecessary step I left in by mistake, I have updated and corrected the guide so that now people should be able to use those commands without error to create the required files for AVBRoot
there should be no need to have an avb.crt and if there is, then the ota.crt should suffice
I believe it was this change to AVBRoot which led to me making this mistake
Merge pull request #3 from tnagorran/master · chenxiaolong/[email protected]
Update README.md
github.com
FireRattus said:
I am really glad that the process could be made so smooth and simple for you
I did spend a long time trying to get a rooted grapheneOS with a locked boot loader before I managed to finally work it out, thanks mostly to the developer of AVBRoot, their script is the essential part which has made this so easy
with my internet troubles as well it ended up taking me a few weeks from when I initially started trying to when I was able to lock the booloader with root successfully
Now that I have it all worked out though, I can update and patch it in very little time
Although I did write this guide for the Pixel 6 I would be happy to include any additional information which could be helpful for people using other pixels, I am just not able to test and verify the information myself on other devices
and you don't need the last section? the part where I create a full patched installer ? I did think about this, just using the patched OTA to update the rom should also work to get you root with a locked bootloader if you first flash the full installer you built yourself
I think this is possibly a better way of doing it, but I like also having the patched full installer
I would like to hear peoples opinions and what works best for them.
Click to expand...
Click to collapse
Oh I meant the part about avb.crt.
As for differences, if you follow the pixel 7 section on grapheneos build guide, that will suffice. Also, instead of boot.img, you flash init_boot.img.
I did also make myself an OTA and flashed it through adb, and that worked great. I want to try making my own OTA server to do away with flashing via PC. I have other family on graphene now too, so it wouldn't be all that effort just for myself.
holofractal said:
Oh I meant the part about avb.crt.
As for differences, if you follow the pixel 7 section on grapheneos build guide, that will suffice. Also, instead of boot.img, you flash init_boot.img.
I did also make myself an OTA and flashed it through adb, and that worked great. I want to try making my own OTA server to do away with flashing via PC. I have other family on graphene now too, so it wouldn't be all that effort just for myself.
Click to expand...
Click to collapse
I did end up figuring out that is what you probably meant. since the differences for the pixel 7 are essentially in the graphene build guide, I don't think any changes are really necessary for the guide, I do recommend just following the official guide for that part, I just include some information to help make that process a bit easier for peoples first time building the rom
for me, it wasn't very clear what the TAG_NAME and BUILD_ID were supposed to be as they didn't provide examples, but a little bit of trial and error helped me work it out
Although, since you flash init_boot, does that init_boot get patched by avbroot?
I would also like to setup an OTA server, although I don't really have the funds to do that at the moment
Guide has been updated with a much simpler method thanks to https://forum.xda-developers.com/m/boom15.11870611/
I haven't tested it myself but it was pointed out, that for those who want to
All you need to do is use AVBRoot to patch the official OTA's provided by Graphene following the instructions in the readme here https://github.com/chenxiaolong/avbroot
I did think this should be possible, but I still recommend building it from source yourself if you are able to