di11i kernel beta .01 (unsecure boot.img- root shell, adb remount) ext4 tweaks/init.d

di11igaf · Mar 2, 2012

This basically (for right now) the stock kernel image with some tweaks to init.
-unsecure boot.img-(perma- rooted adb shell)
-adb remount(mount /system r/w)
-init.d support added in for init scripts(survive after reboot)
-ext4 filesystem mount tweaks-/system/data/cache(faster I/O)
(Actually have a full ext2 version for,****s and giggles, but it boots into the encryption error screen, so cant release that. May have a fix though)
-mem and cache tweaks coming soon

still working on the actual kernel, will release that next, still have lots of work to do

boot.img MD5- fca41dba8f4699b67fd461a1632b65cf

MAKE BACKUP FIRST

You will not have issues if you wipe data, chances are youll be fine if you dont, but if anything starts acting up just wipe data, then install boot.img
This is the actual boot.img and for now has to be flashed with adb with these EXACT commands--

Code:

adb push boot.img /sdcard/
adb shell
su
dd if=/sdcard/boot.img of=/dev/block/mmcblk0 seek=3968 bs=4096 count=2048
reboot


#Thanks Diamondback and friends for offsets

This is not the ideal way to flash this, but i can not get the blob file to staging partition to actually write the image. Im pretty sure its an issue with the signature of the blob file, so if someone wants to pack this into a blob id be glad test it and then update the OP.
My primes been using this boot.img for a few days, along with one other. Flash at your own risk.
NOT COMPATIBLE WITH CM-9

MasterZen88 · Mar 2, 2012

di11igaf said:
This basically (for right now) the stock kernel image with some tweaks to init.
-unsecure boot.img-(perma- rooted adb shell)
-adb remount(mount /system r/w)
-init.d support added in for init scripts(survive after reboot)
-ext4 filesystem mount tweaks-/system/data/cache(faster I/O)
(Actually have a full ext2 version for,****s and giggles, but it boots into the encryption error screen, so cant release that. May have a fix though)
-mem and cache tweaks coming soon

still working on the actual kernel, will release that next, still have lots of work to do

boot.img MD5- fca41dba8f4699b67fd461a1632b65cf

MAKE BACKUP FIRST

You will not have issues if you wipe data, chances are youll be fine if you dont, but if anything starts acting up just wipe data, then install boot.img
This is the actual boot.img and for now has to be flashed with adb with these EXACT commands--

Code:

adb push boot.img /sdcard/ adb shell su dd if=/sdcard/boot.img of=/dev/block/mmcblk0 seek=3968 bs=4096 count=2048 reboot #Thanks Diamondback and friends for offsets

This is not the ideal way to flash this, but i can not get the blob file to staging partition to actually write the image. Im pretty sure its an issue with the signature of the blob file, so if someone wants to pack this into a blob id be glad test it and then update the OP.
My primes been using this boot.img for a few days, along with one other. Flash at your own risk.

Great! I'm not the only one who as this problem. For what ever reason I too cannot get the blob to write.

I've tried running the blobpack -s to sign the blob but after trying to write it to the staging partition its a no go.....

EDIT: how are you working on the kernel if it has not been released yet?? JW, not trying to say your not but it would be cool if someone found a way to edit a compiled kernel.

Doktaphex · Mar 2, 2012

MasterZen88 said:
Great! I'm not the only one who as this problem. For what ever reason I too cannot get the blob to write.

I've tried running the blobpack -s to sign the blob but after trying to write it to the staging partition its a no go.....

EDIT: how are you working on the kernel if it has not been released yet?? JW, not trying to say your not but it would be cool if someone found a way to edit a compiled kernel.

ICS kernel source is on the global download site.

MasterZen88 · Mar 2, 2012

Doktaphex said:
ICS kernel source is on the global download site.

Correct but thats an older source code V9.4.2.7 right?

Doktaphex · Mar 2, 2012

MasterZen88 said:
Correct but thats an older source code V9.4.2.7 right?

True, I don't know how much they have changed since then. Surely they need to be releasing new source pretty quickly to be in compliance with the license. I don't know enough about that side of things though.

Dexter_nlb · Mar 2, 2012

prime has a BLOBSIGN signature in the first 28 bytes of the blob files for prime.
you just need to copy those 28bytes from an existing blob file that works.

this is of course only working on a unlocked prime. then the BLOBSIGN signature is not checked, so anything can be pasted in front of it.

Rayman will update the packblob to include the signature later on.

jermaine151 · Mar 2, 2012

MasterZen88 said:
Great! I'm not the only one who as this problem. For what ever reason I too cannot get the blob to write.

I've tried running the blobpack -s to sign the blob but after trying to write it to the staging partition its a no go.....

EDIT: how are you working on the kernel if it has not been released yet?? JW, not trying to say your not but it would be cool if someone found a way to edit a compiled kernel.

I'm confused. I thought after our PMs you had it flashing just fine?

Sent from my Galaxy Nexus using Tapatalk

MasterZen88 · Mar 2, 2012

jermaine151 said:
I'm confused. I thought after our PMs you had it flashing just fine?

Sent from my Galaxy Nexus using Tapatalk

Yes it flashed but later I realize non of my settings/changes took effect.

When I stated it work, I had took the stock kernel/initramfs from asus blob, extracted, made no changes at all, recompile like we talked about in our PM's then flashed it. It work but then after I made changes, recompiled. Non of my changes took effect.

Again Jermaine you have been a BIG help. and can only hope one day I can return the favor!!!

Diamondback · Mar 2, 2012

jermaine151 said:
I'm confused. I thought after our PMs you had it flashing just fine?

Sent from my Galaxy Nexus using Tapatalk

MasterZen88 said:
Yes it flashed but later I realize non of my settings/changes took effect.

When I stated it work, I had took the stock kernel/initramfs from asus blob, extracted, made no changes at all, recompile like we talked about in our PM's then flashed it. It work but then after I made changes, recompiled. Non of my changes took effect.

Again Jermaine you have been a BIG help. and can only hope one day I can return the favor!!!

Flashing blobs does NOT always work.

No idea why yet. Directly dd'ing the boot.img to the right place works BETTER than flashing a blob in some cases...

Asus really screwed up with this Unlocker thing....

jermaine151 · Mar 2, 2012

MasterZen88 said:
Yes it flashed but later I realize non of my settings/changes took effect.

When I stated it work, I had took the stock kernel/initramfs from asus blob, extracted, made no changes at all, recompile like we talked about in our PM's then flashed it. It work but then after I made changes, recompiled. Non of my changes took effect.

Again Jermaine you have been a BIG help. and can only hope one day I can return the favor!!!

No problem. I'm surprised it didn't work for you after you made changes.

Diamondback said:
Flashing blobs does NOT always work. No idea why yet. Directly dd'ing the boot.img to the right place works BETTER than flashing a blob in some cases...

Asus really screwed up with this Unlocker thing....

Flashing them to staging seems to work perfectly for me. That's how I made my insecure boot.blob and flashed it. It doesn't matter whether you're on unofficial CWM or Official since if you start your updater-script with unmounting staging, it doesn't hurt anything if staging wasn't mounted. Then you can either dd the blob to mmcblk0p4 or you can directly flash it via:

Code:

package_extract_file("boot.blob", "/dev/block/mmcblk0p4");

I have not found an occasion where this didn't work. You need to make sure that you don't add any --cmdline parameters when you mkbootimg or you will get a bootloop. Staging is definitely the safest way to flash to any partitions on the Prime.

MasterZen88 said:
Correct but thats an older source code V9.4.2.7 right?

The kernel versions seem to be the same with the latest .15 build as the previous one. I wonder if they just recompiled the same source and that's why the host name changed to Mercury.

EDIT: I'm going to pack this kernel into a flashable blob and attach it here.

MasterZen88 · Mar 2, 2012

jermaine151 said:
No problem. I'm surprised it didn't work for you after you made changes.

Flashing them to staging seems to work perfectly for me. That's how I made my insecure boot.blob and flashed it. It doesn't matter whether you're on unofficial CWM or Official since if you start your updater-script with unmounting staging, it doesn't hurt anything if staging wasn't mounted. Then you can either dd the blob to mmcblk0p4 or you can directly flash it via:

Code:

package_extract_file("boot.blob", "/dev/block/mmcblk0p4");

I have not found an occasion where this didn't work. You need to make sure that you don't add any --cmdline parameters when you mkbootimg or you will get a bootloop. Staging is definitely the safest way to flash to any partitions on the Prime.

Hmm.. not sure whats going on but I did use this command

Code:

mkbootimg --kernel boot.img-kernel.gz --ramdisk newramdisk.cpio.gz -o newboot.img

To recompile the boot.img then used the new blobtoolsv2 to repack the blob

Code:

blobpack -s kernelblob blob.LNX newboot.img

I know staging is unmounted because I'm using your updater-script

Dexter_nlb · Mar 2, 2012

jermaine151 said:
Flashing them to staging seems to work perfectly for me. That's how I made my insecure boot.blob and flashed it. It doesn't matter whether you're on unofficial CWM or Official since if you start your updater-script with unmounting staging, it doesn't hurt anything if staging wasn't mounted. Then you can either dd the blob to mmcblk0p4 or you can directly flash it via:

Code:

package_extract_file("boot.blob", "/dev/block/mmcblk0p4");

I have not found an occasion where this didn't work. You need to make sure that you don't add any --cmdline parameters when you mkbootimg or you will get a bootloop. Staging is definitely the safest way to flash to any partitions on the Prime.

if you copy the blob, while p4 is mounted to staging in cwm, you will have a problem when you reboot, as the filesystem umount, and that cause a small change to the mounted filesystem, to indicate it is umounted normally. and the p4 partition becomes invalid.

so it can easily become a problem if p4 is mounted.

at least thats how i experienced the problem when seen initially.

jermaine151 · Mar 2, 2012

Dexter_nlb said:
if you copy the blob, while p4 is mounted to staging in cwm, you will have a problem when you reboot, as the filesystem umount, and that cause a small change to the mounted filesystem, to indicate it is umounted normally. and the p4 partition becomes invalid.

so it can easily become a problem if p4 is mounted.

at least thats how i experienced the problem when seen initially.

That's why I said to always add an unmount("/staging"); to the top of your script. The attached flashable zip works perfectly on the official CWM; staging is not mounted by default, but I told the script to unmount it anyway in case someone with the unofficial CWM tries to flash it. If it's already unmounted, the script just continues.

Anyone may use this as a template for consistently flashing a kernel to staging.

jermaine151 · Mar 2, 2012

MasterZen88 said:
Hmm.. not sure whats going on but I did use this command

Code:

mkbootimg --kernel boot.img-kernel.gz --ramdisk newramdisk.cpio.gz -o newboot.img

To recompile the boot.img then used the new blobtoolsv2 to repack the blob

Code:

blobpack -s kernelblob blob.LNX newboot.img

I know staging is unmounted because I'm using your updater-script

Hmm... That all looks good. What happens after you attempt to flash this and what changes did you make to the ramdisk?

EDIT: Hey, I just re-read your PM. It sounds like you're editing the wrong file in the ramdisk. To make an insecure boot image, you should be editing init.rc, NOT init.cardhu.rc.

Here's a great guide to follow. It's the same procedure for the Prime as the original Transformer:

http://xdaforums.com/showthread.php?t=1193737

MasterZen88 · Mar 2, 2012

jermaine151 said:
Hmm... That all looks good. What happens after you attempt to flash this and what changes did you make to the ramdisk?

EDIT: Hey, I just re-read your PM. It sounds like you're editing the wrong file in the ramdisk. To make an insecure boot image, you should be editing init.rc, NOT init.cardhu.rc.

Here's a great guide to follow. It's the same procedure for the Prime as the original Transformer:

http://xdaforums.com/showthread.php?t=1193737

Okay that makes sense. One f my changes was to default.prop for insecure boot.img

Code:

ro.secure=0

This did not show after I flashed. But I will try again in a couple hour's once my workload calms down... SysAdmin life is not easy...lol

jermaine151 · Mar 2, 2012

MasterZen88 said:
Okay that makes sense. One f my changes was to default.prop for insecure boot.img

Code:

ro.secure=0

This did not show after I flashed. But I will try again in a couple hour's once my workload calms down... SysAdmin life is not easy...lol

LOL! I meant to say default.prop and not init.rc. I totally understand. I used to be a SysSdmin too. Now I moved more towards the networking side of things. Much more calm.

MasterZen88 · Mar 2, 2012

jermaine151 said:
LOL! I meant to say default.prop and not init.rc. I totally understand. I used to be a SysSdmin too. Now I moved more towards the networking side of things. Much more calm.

Would love to be on that side of the tracks. I'm banging my head against the wall right now trying to figure out how to implement Microsoft System Center Service Manager 2010 and on top of that one of our Citrix Broker boxes went down last night... Not a funny day at all. But I'll keep this thread about Android

...for now....

Diamondback · Mar 2, 2012

No, unfortunately flashing a blob does not always do the same as dd'ing boot.img directly. We recently had a case were someone lost root access. the only way to recover was to directly dd a boot.img.

Flashing the SAME boot.img via blob did not work (nor did any other blob we tested)

So blob flashing obviously has some quirks....

jermaine151 · Mar 2, 2012

Diamondback said:
No, unfortunately flashing a blob does not always do the same as dd'ing boot.img directly. We recently had a case were someone lost root access. the only way to recover was to directly dd a boot.img.

Flashing the SAME boot.img via blob did not work (nor did any other blob we tested)

So blob flashing obviously has some quirks....

I just haven't see that issue flashing any of my blobs and CM9 is using the same method and it's working. Who knows.

Diamondback · Mar 2, 2012

jermaine151 said:
I just haven't see that issue flashing any of my blobs and CM9 is using the same method and it's working. Who knows.

We only had it one time too, but one time is enough to scare me further

This whole blob stuff just is crap

di11i kernel beta .01 (unsecure boot.img- root shell, adb remount) ext4 tweaks/init.d

Inactive Recognized Developer

Attachments

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Retired Dev Committee Lead / Retired Senior Mod

Senior Member

Senior Member

Senior Member

Senior Member

Attachments

Senior Member

Senior Member

Senior Member

Senior Member

Retired Dev Committee Lead / Retired Senior Mod

Senior Member

Retired Dev Committee Lead / Retired Senior Mod

Similar threads

Top Liked Posts