Related
There's nothing here to see // Regards
Unpacking and packing the blobs is the easy part- I did this just yesterday when I was fooling around with my TF. The hard part is getting them to flash. On an unrooted TF, the staging partition is read only and the stock recovery won't flash it if the crypto signature is wrong.
In fact, I think this was one of the early root exploits- use gingerbreak to gain root access, then send a blob to the staging partition. This will flash on reboot and install clockworkmod. Unfortunately, gingerbreak only works on the earlier firmware.
Maybe i have missed something...
The firmware of honeycomb is downloadable from the asus website.
You can extract it with blobunpack by Rayman, edit it, add/remove things, put the sudo and superuser packages etc...
If your device isn't already rooted, you can't flash it back
gee one said:
Unpacking and packing the blobs is the easy part- I did this just yesterday when I was fooling around with my TF. The hard part is getting them to flash. On an unrooted TF, the staging partition is read only and the stock recovery won't flash it if the crypto signature is wrong.
In fact, I think this was one of the early root exploits- use gingerbreak to gain root access, then send a blob to the staging partition. This will flash on reboot and install clockworkmod. Unfortunately, gingerbreak only works on the earlier firmware.
Click to expand...
Click to collapse
got it: blob.APP how to extract this
rebound821 said:
Maybe i have missed something...
The firmware of honeycomb is downloadable from the asus website.
You can extract it with blobunpack by Rayman, edit it, add/remove things, put the sudo and superuser packages etc...
If your device isn't already rooted, you can't flash it back
Click to expand...
Click to collapse
as i told you, this can work if we do it correctly, (as i need to extract blob.app "wich has almost all stuffs in it, as its 512 mb, but i cant open it l0l)
The blob.APP is a ext4 file system. You can view it with
Code:
mount -o loop blob.APP system/
This assumes you have an empty directory named system and you are on a linux machine. Just to be safe, you could also use loop,ro to mount it read-only.
That's all fun stuff in there, but the real magic happens in blob.LNX and blob.SOS. You can extract them with the boot tools (not blob) that rayman has also posted in his github. Modding these files will allow you to keep root. rebound posted a thread in the dev section about an insecure boot- good stuff. Keep in mind that this still doesn't get you past nvflash or the stock recovery.
gee one said:
The blob.APP is a ext4 file system. You can view it with
Code:
mount -o loop blob.APP system/
This assumes you have an empty directory named system and you are on a linux machine. Just to be safe, you could also use loop,ro to mount it read-only.
That's all fun stuff in there, but the real magic happens in blob.LNX and blob.SOS. You can extract them with the boot tools (not blob) that rayman has also posted in his github. Modding these files will allow you to keep root. rebound posted a thread in the dev section about an insecure boot- good stuff. Keep in mind that this still doesn't get you past nvflash or the stock recovery.
Click to expand...
Click to collapse
ah, thanks a heap! but after recompile, how to "update the firmware"
Well, if you are rooted, you can flash the blob via the staging partition. If you are not rooted, the staging partition is read only. Aye, there's the rub!
I'm not saying it's not possible, but you'd have to know some clever tricks. Have a look at the gingerbreak exploit and how it was used to flash a blob.
sent from my cyanogen(mod) vision
exciting...waiting for good news from you.
hope its will successfully Root on B80, and a complete method to do it.
thanks~
would be nice have a B70 and its locked
evangelism said:
exciting...waiting for good news from you.
hope its will successfully Root on B80, and a complete method to do it.
thanks~
Click to expand...
Click to collapse
it will root, (but recovery will be same, if i dont change it, as its inside some of the blob files,
so its possible, but hard ) and a damn lot of workaround,
Arctiik said:
would be nice have a B70 and its locked
Click to expand...
Click to collapse
this is the latest WW, so it would also be working on B70 aswell
the recovery is blob.SOS - use bootunpack blob.SOS
There's a little android! magic in there too. The kernel is the same, but you can mod the ramdisk. Download roaches version of CWM and unzip, blobunpack, and bootunpack. Then use his ramdisk and pack it all back together into the blob.
Then you will have rooted firmware. Now get to work on getting it to flash! We need an exploit like gingerbreak to make it work.
gee one said:
the recovery is blob.SOS - use bootunpack blob.SOS
There's a little android! magic in there too. The kernel is the same, but you can mod the ramdisk. Download roaches version of CWM and unzip, blobunpack, and bootunpack. Then use his ramdisk and pack it all back together into the blob.
Then you will have rooted firmware. Now get to work on getting it to flash! We need an exploit like gingerbreak to make it work.
Click to expand...
Click to collapse
took the recovery-ramdisk -> renamed so it replaces old file, now to pack this +__+
folder looks like this "see pic"
this was already discussed here in the forum. The only thing new would be a way to flash unsigned updates, and in this mater there are no news (yet...)
brk said:
this as already been discussed here. The only thing new would be a way to flash unsigned updates, and in this mater there are no news (yet...)
Click to expand...
Click to collapse
this is what we are trying to do here
added blob.SOS and LNX in this zip file (help with make it to blob.SOS
http://www.multiupload.com/BKCX9Y7CB8
totaly lost on how to pack blob files,
Try typing "blobpack" or "blobpack --help" one of them will show you the syntax.
sent from my cyanogen(mod) vision
gee one said:
Try typing "blobpack" or "blobpack --help" one of them will show you the syntax.
sent from my cyanogen(mod) vision
Click to expand...
Click to collapse
Usage: blobpack <headerfile> <outfile> <partitionname> <partitionfile> ...
i don't know what is header, and partition file of this +__?
Follow the capital letters- blob.HEADER is the header file. blob.SOS is the SOS partition ,etc.
Experiment a little, you won't break your ubuntu box if you pack up the wrong blob. You can unpack it to see if it worked. There are also instructions on raymans blob where you got the link for the tools.
The header has to be correct, so essentially you have to pack up the same number of parts if you re-use the header. Unpack a few blobs and see what is different with them. They don't always have the parts. Some have EBTs, some have SOSs, some have peaches and candy.
sent from my cyanogen(mod) vision
did you already check the universal root script for linux? There you can find the tools to mod blob.SOS (RAM disk for CWM) and blob.LNX (insecure flag change).
But this is the easy part. To be able to flash a modded update file you need to know the encryptation key from ASUS, or find a bug in android that you can exploit to flash the modded update.
brk said:
did you already check the universal root script for linux? There you can find the tools to mod blob.SOS (RAM disk for CWM) and blob.LNX (insecure flag change).
But this is the easy part. To be able to flash a modded update file you need to know the encryptation key from ASUS, or find a bug in android that you can exploit to flash the modded update.
Click to expand...
Click to collapse
only need to repack all, and thats the stuff i dont know lmao
Hi,
I've been trying to get my own kernel with few modifications running on my ASUS Transformer. I've followed few guides around with no luck. What I did:
Tried two source trees:
1) Official from ASUS
2) Roach2010s tree from github (https://github.com/Roach2010/android_kernel_TF101.git)
Used .config from my current kernel which is running fine (Prime kernel) without any changes.
Compiled kernel.
So far looks good, with few modifications to config I got new modules that works so crosscompiler is not misscompiling. Now the part where I'm doing something wrong and can't figure out what.
I started with Prime Kernel from http://forum.xda-developers.com/showthread.php?t=1251044
* Unziped the archive
* blobunpack blob
* created blob.LNX in several ways described bellow
* blobpack blob.HEADER blob LNX blob.LNX
* dd if=blob of=/dev/block/mmcblk0p4
* reboot
How I created blob.LNX
A) Use extracted blob.LNX and use abootimg to replace kernel
* abootimg -u blob.LNX -k zImage
B) Extracted all parts and recreated image using abootimg
* abootimg -x blob.LNX
* abootimg --create blob.LNX -f bootimg.cfg -k zImage -r initrd.img
C) Extracted all parts and recreated image using bootunpack and mkbootimg
* bootunpack blob.LNX
* mkbootimg --kernel zImage --ramdisk ramdisk.gz -o blob.LNX
In addition I tried few modifications:
* enlarging bootsize in bootimg.cfg to make sure everything fits
* passing cmdline my current kernel booted up with as default in .config, as cmdline in bootimg.cfg and both
All my efforts ended up on ASUS boot up screen, no matter what I try. So my question is, am I missing something? Did I skipped some important part? Have I done something wrong? Any ideas appreciated.
If nobody has any idea, can somebody please create kernel with enabled kexec for my ASUS Transformer? That was the ultimate goal of trying to get my own kernel, but if I can't get working just recompiled one...
-miska- said:
Hi,
I've been trying to get my own kernel with few modifications running on my ASUS Transformer. I've followed few guides around with no luck. What I did:
Tried two source trees:
1) Official from ASUS
2) Roach2010s tree from github (https://github.com/Roach2010/android_kernel_TF101.git)
Used .config from my current kernel which is running fine (Prime kernel) without any changes.
Compiled kernel.
So far looks good, with few modifications to config I got new modules that works so crosscompiler is not misscompiling. Now the part where I'm doing something wrong and can't figure out what.
I started with Prime Kernel from http://forum.xda-developers.com/showthread.php?t=1251044
* Unziped the archive
* blobunpack blob
* created blob.LNX in several ways described bellow
* blobpack blob.HEADER blob LNX blob.LNX
* dd if=blob of=/dev/block/mmcblk0p4
* reboot
How I created blob.LNX
A) Use extracted blob.LNX and use abootimg to replace kernel
* abootimg -u blob.LNX -k zImage
B) Extracted all parts and recreated image using abootimg
* abootimg -x blob.LNX
* abootimg --create blob.LNX -f bootimg.cfg -k zImage -r initrd.img
C) Extracted all parts and recreated image using bootunpack and mkbootimg
* bootunpack blob.LNX
* mkbootimg --kernel zImage --ramdisk ramdisk.gz -o blob.LNX
In addition I tried few modifications:
* enlarging bootsize in bootimg.cfg to make sure everything fits
* passing cmdline my current kernel booted up with as default in .config, as cmdline in bootimg.cfg and both
All my efforts ended up on ASUS boot up screen, no matter what I try. So my question is, am I missing something? Did I skipped some important part? Have I done something wrong? Any ideas appreciated.
If nobody has any idea, can somebody please create kernel with enabled kexec for my ASUS Transformer? That was the ultimate goal of trying to get my own kernel, but if I can't get working just recompiled one...
Click to expand...
Click to collapse
Here is what I've done. If you have successfully built a kernel with the resulting zImage, then you are part way there, I believe there is a kernel config option to enable kexec support but I haven't tried that. Next, you can take some other kernel's .zip file (CWM flashable) and unzip it. You may need to download a zip utility. You'll have 2 folders and a kernel blob. If you bootunpack this kernel blob, you'll end up with the kernel blob and a some *.LNX file. This *.LNX file is the same as a boot.img file. You can use dsixda's Android kitchen to split this into the initrd and the kernel (zImage) parts. Replace the zImage with your own and move any modules you may have also built if necessary into the initrd part, join them back together into a boot.img in the kitchen.
copy this boot.img back to where you unzipped the kernel.zip, delete the original *.LNX file, rename the boot.img to the same name as the previous *.LNX file and then bootpack it together and flash it through CWM. Zip the 2 folders and the kernel blob you just made back together with whatever name you want. You can edit the text in the updater script before you zip it all up, but whether you do or not it should boot.
Yes, there is kexec config option, but I haven't suceeded even without changing anything so enabling it doesn't make kernel boot :-D I tried Android Kitche to split boot image and I ended up with the same files (compared the content to check) as with abootimg -x. Tried recreating update.zip and sign it using Android Kitchen, just to be sure, that something in android is not in the way to the actualization from running system. Still no luck :-(
-miska- said:
Yes, there is kexec config option, but I haven't suceeded even without changing anything so enabling it doesn't make kernel boot d:-D I tried Android Kitche to split boot image and I ended up with the same files (compared the content to check) as with abootimg -x. Tried recreating update.zip and sign it using Android Kitchen, just to be sure, that something in android is not in the way to the actualization from running system. Still no luck :-(
Click to expand...
Click to collapse
I didn't even sign mine as I have signature verification turned off in CWM recovery. Didn't change the text either as I was mostly experimenting and learning. I know kexec works under linux, but I think it requires separate package(s) and configuration to do so. I got a bit confused with blobpack, blobunpack info, but figured out that with just the kernel you don't seem to need the mentioned header file, just the .LNX which is the same as boot.img which is the combined kernel zImage and initramfs. If the kernel blob is still there and you use the same name for the output file then it doesn't matter because it will get overwritten anyway. Worked for me at least using source of kernel I've booted before and my running .config.
sidneyk said:
I didn't even sign mine as I have signature verification turned off in CWM recovery. Didn't change the text either as I was mostly experimenting and learning. I know kexec works under linux, but I think it requires separate package(s) and configuration to do so. I got a bit confused with blobpack, blobunpack info, but figured out that with just the kernel you don't seem to need the mentioned header file, just the .LNX which is the same as boot.img which is the combined kernel zImage and initramfs. If the kernel blob is still there and you use the same name for the output file then it doesn't matter because it will get overwritten anyway. Worked for me at least using source of kernel I've booted before and my running .config.
Click to expand...
Click to collapse
hmmm, zip file I had as an example was using blobed boot image going through mmcblk0p4. Do you have some link to .zip file that does it differently?
kexec is a way how to boot something else from linux directly without need to fiddle with bootloader. To use it, two parts are needed - kernel that supports it (that's what I can't get) and tool to actually use it/call it. Tool is not a problem, got that one hopefully ready, but without the kernel...
-miska- said:
hmmm, zip file I had as an example was using blobed boot image going through mmcblk0p4. Do you have some link to .zip file that does it differently?
kexec is a way how to boot something else from linux directly without need to fiddle with bootloader. To use it, two parts are needed - kernel that supports it (that's what I can't get) and tool to actually use it/call it. Tool is not a problem, got that one hopefully ready, but without the kernel...
Click to expand...
Click to collapse
Have you tried Koush's "anykernel.zip" code (probably requires a few mods)? It appears to be trying to replace the blob based updater-scripts that are all over the place.
I've used it successfully, but it has mostly been on other devices, and it is very easy to use. I think some of the templates are too generic and maybe confusing, and without figuring out how edify scripting actually works, it is mysterious, but I'd look at this code, git it and try to use it:
I'll try to provide a working example since I just added a few modules to one of the kernels 2.6.36-4 that're out there for the tf101, but I need to be sure it's working first. I think there's perhaps one difference at least between what Koush shows for the xoom and the tf101 so am working on it.
https://github.com/koush/AnyKernel
Good luck -
-miska- said:
hmmm, zip file I had as an example was using blobed boot image going through mmcblk0p4. Do you have some link to .zip file that does it differently?
kexec is a way how to boot something else from linux directly without need to fiddle with bootloader. To use it, two parts are needed - kernel that supports it (that's what I can't get) and tool to actually use it/call it. Tool is not a problem, got that one hopefully ready, but without the kernel...
Click to expand...
Click to collapse
I was using clemsyn-blades_kernel_ver22a zip file. I don't know if it was doing it different or not, haven't checked that far into it.
sidneyk said:
I was using clemsyn-blades_kernel_ver22a zip file. I don't know if it was doing it different or not, haven't checked that far into it.
Click to expand...
Click to collapse
hmmm, checked that one, uses blobed image and 'dd if=/tmp/blob of=/dev/block/mmcblk0p4' as well. Maybe I'll try different crosscompiler anyway, that's the one thing I haven't altered yet :-/
hachamacha said:
Have you tried Koush's "anykernel.zip" code (probably requires a few mods)? It appears to be trying to replace the blob based updater-scripts that are all over the place.
I've used it successfully, but it has mostly been on other devices, and it is very easy to use. I think some of the templates are too generic and maybe confusing, and without figuring out how edify scripting actually works, it is mysterious, but I'd look at this code, git it and try to use it:
I'll try to provide a working example since I just added a few modules to one of the kernels 2.6.36-4 that're out there for the tf101, but I need to be sure it's working first. I think there's perhaps one difference at least between what Koush shows for the xoom and the tf101 so am working on it.
Click to expand...
Click to collapse
Haven't tried that one, looks interesting... This one doesn't use blobed update and wites image directly somewhere. Just would require to check that that somewhere is the right place :-D Thanks, will take a look at that and what other edify commands are availble in updater, sounds like interesting alternative approach...
-miska- said:
Haven't tried that one, looks interesting... This one doesn't use blobed update and wites image directly somewhere. Just would require to check that that somewhere is the right place :-D Thanks, will take a look at that and what other edify commands are availble in updater, sounds like interesting alternative approach...
Click to expand...
Click to collapse
I'm modifying the script I've seen passed around (not quite Koush's git repo version) passed around to see if I can get it to work on the tf101. The 'write it somewhere' edify command is the question mark, but I think it is going on it's (the device's) internal partition table and vectored to 'boot', which is either a terrific generic idea, or terrible depending upon what edify does. I can't really find a heck of a lot explaining anything about the individual edify commands. I'm just getting rid of the 'showstoppers' where partition names like mmc0p* are used that are clearly wrong for the tf101. I made the mistake of trying one that I only later realized thought that partition 1 was data, when it is actually partition 7. Good thing I can make nvflash backups on my 'old' transformer.
I'll post back later today with any results I get. I'm not concerned about whether my kernel worked since it is completely experimental , just that it got written there, so I might use a working version with a different kernel name (in Makefile) just so I can get 'proof of concept' .
On a slightly different note but having to do with what you're doing, I tried the blob route this week, and for some reason, blobunpack/pack right from Rayman's git repo do not unpack the blobs correctly for say 'clemsyms' or 'Prime's' blobs, which has me wondering about some change that maybe took place. In any case, it forces me down this other path anyway.
If they are working OK for you, could you tell me a couple things?
1) Your linux distro and architecture (x86/x86_64)
2) did you build them from Rayman's repo? Did you get binaries from somewhere, if so where?
3) parameters? I don't think mine take any but the blob name.
4) Output suffixes. I only get .LNX from any of the above blobs which is useless.
EDIT: I was recalling that 'edify' in CWM came into being somewhere (maybe) past the only version that works with the tf101 (we're on ~v3.x and edify ~v4/5+). If that's the case, then we're all stuck with blobs because that one write command is edifi(ed) most likely. I'll stare at the git CWM source today too to figure out if it used the edify stuff in this version. I think Solarnz had it in his git hub.
hachamacha said:
I'm modifying the script I've seen passed around (not quite Koush's git repo version) passed around to see if I can get it to work on the tf101. The 'write it somewhere' edify command is the question mark, but I think it is going on it's (the device's) internal partition table and vectored to 'boot', which is either a terrific generic idea, or terrible depending upon what edify does. I can't really find a heck of a lot explaining anything about the individual edify commands. I'm just getting rid of the 'showstoppers' where partition names like mmc0p* are used that are clearly wrong for the tf101. I made the mistake of trying one that I only later realized thought that partition 1 was data, when it is actually partition 7. Good thing I can make nvflash backups on my 'old' transformer.
I'll post back later today with any results I get. I'm not concerned about whether my kernel worked since it is completely experimental , just that it got written there, so I might use a working version with a different kernel name (in Makefile) just so I can get 'proof of concept' .
On a slightly different note but having to do with what you're doing, I tried the blob route this week, and for some reason, blobunpack/pack right from Rayman's git repo do not unpack the blobs correctly for say 'clemsyms' or 'Prime's' blobs, which has me wondering about some change that maybe took place. In any case, it forces me down this other path anyway.
If they are working OK for you, could you tell me a couple things?
1) Your linux distro and architecture (x86/x86_64)
2) did you build them from Rayman's repo? Did you get binaries from somewhere, if so where?
3) parameters? I don't think mine take any but the blob name.
4) Output suffixes. I only get .LNX from any of the above blobs which is useless.
EDIT: I was recalling that 'edify' in CWM came into being somewhere (maybe) past the only version that works with the tf101 (we're on ~v3.x and edify ~v4/5+). If that's the case, then we're all stuck with blobs because that one write command is edifi(ed) most likely. I'll stare at the git CWM source today too to figure out if it used the edify stuff in this version. I think Solarnz had it in his git hub.
Click to expand...
Click to collapse
Blobs are used on the tf101 because they are the ONLY way of flashing boot/recovery, there is no block device mapping of them on our device
lilstevie said:
Blobs are used on the tf101 because they are the ONLY way of flashing boot/recovery, there is no block device mapping of them on our device
Click to expand...
Click to collapse
OK: Thanks lilstevie,
That takes care of that. Time for me to make peace with blobs.
After steve's reply, I just went to using blobs. I've got my own kernel running fine on the tf101 using that method.
For the best reference I've seen on using blobs and boottools , try this post:
http://forum.xda-developers.com/showthread.php?t=1193737
---
Just got back from work, will ply with it some more, but I'll start with answering the questions...
hachamacha said:
1) Your linux distro and architecture (x86/x86_64)
Click to expand...
Click to collapse
Gentoo x86-64
hachamacha said:
2) did you build them from Rayman's repo? Did you get binaries from somewhere, if so where?
Click to expand...
Click to collapse
Compiled from git repo. I always tried to find the most upstream repo for each tool and then compiled it by myself.
hachamacha said:
3) parameters? I don't think mine take any but the blob name.
4) Output suffixes. I only get .LNX from any of the above blobs which is useless.
Click to expand...
Click to collapse
These two comes together:
'blobunpack blob' - takes a blob as input and ouptuts blob.HEADER and blob.LNX
'bootunpack blob.LNX' - takes blob.LNX as input and outputs blob.LNX-kernel.gz, blob.LNX-ramdisk.cpio.gz and blob.LNX-config
'abootimg -x blob.LNX' - takes blob.LNX as input and outputs zImage, initrd.img and bootimg.cfg
Resulting files from bootunpack and abootimg are almost same, only difference is the configuration file
To repack:
'abootimg --create newblob/blob.LNX -f bootimg.cfg -k zImage -r initrd.img'
or
'mkbootimg --kernel zImage --ramdisk blob.LNX-ramdisk.cpio.gz -o newblob/blob.LNX'
and then
'blobpack blob.HEADER newblob/blob LNX newblob/blob.LNX'
Unless I change kernel, everything works just fine :-D
-miska- said:
Just got back from work, will ply with it some more, but I'll start with answering the questions...
Gentoo x86-64
Compiled from git repo. I always tried to find the most upstream repo for each tool and then compiled it by myself.
These two comes together:
'blobunpack blob' - takes a blob as input and ouptuts blob.HEADER and blob.LNX
'bootunpack blob.LNX' - takes blob.LNX as input and outputs blob.LNX-kernel.gz, blob.LNX-ramdisk.cpio.gz and blob.LNX-config
'abootimg -x blob.LNX' - takes blob.LNX as input and outputs zImage, initrd.img and bootimg.cfg
Resulting files from bootunpack and abootimg are almost same, only difference is the configuration file
To repack:
'abootimg --create newblob/blob.LNX -f bootimg.cfg -k zImage -r initrd.img'
or
'mkbootimg --kernel zImage --ramdisk blob.LNX-ramdisk.cpio.gz -o newblob/blob.LNX'
and then
'blobpack blob.HEADER newblob/blob LNX newblob/blob.LNX'
Unless I change kernel, everything works just fine :-D
Click to expand...
Click to collapse
Pretty similar, although the kernel zImage itself is always a mystery unless you've not changed anything, but even then, getting it built with the right toolchain, etc isn't guaranteed. So lets assume that just works for now since it'll become obvious as it goes along.
I guess I have not heard of 'abootimg' as a tool for this, so I've been using the more manual way of dissecting the initrd as follows:
Code:
gunzip -dc ../blob.LNX-ramdisk.cpio.gz | cpio -i
If you need to change something , for example, in default.prop like ro.secure=0, then you'd do it there.
Then repack into a new ramdisk:
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
Finally I just had a somewhat heavily modified zImage from my build, so did this to make the blob (I'd copied zImage to blob.LNK-zImage.gz below):
Code:
./mkbootimg --kernel blob.LNX-zImage.gz --ramdisk newramdisk.cpio.gz -o boot.img
./blobpack blob.HEADER newblob LNX boot.img
zip -r imagename.zip blob MET* system // whatever the syntax was.
NOTE: I did this on a native 64 bit ubuntu LTS 10.04 box.
Unless I typo'd up there, that 'should' work. If it does boot, then first thing, take a look at settings, and kernel info so you can verify that you're running the kernel you desired (hopefully you renamed it in Makefile the first 4-5 lines).
Solved
Ok, got it working!!! Problem was bad crosscompiler :-( Modules I crosscompiled worked fine, so I ruled crosscompiler out :-/ Looks like I was too quick in judgement :-( Now I have kernel recompiled with original settings and evne the modified one and it still works and boot. Now I'm going to play with new features I got! Thanks a lot for all help!!!
Just for the record, crosscompiler I was originally using was codesourcery 2011.03 and to make it work I switched to official crosscompiler from NDK. Rest of the commands was Ok, I was just suspecting wrong step as I was quite familiar with kernel building and quite unfamiliar with the blob stuff :-(
Congrats!
For some reason I avoid the codesourcery stuff and stick with either the prebuilt toolchains or else just build my own from gnu source.
Anyway, glad you figured it out.
I have been following a few different instructions for the tools and was concentrated on just learning to rebuild a kernel on my own setup - Ubuntu 11.10. I only installed Ubuntu since it was the distro mostly referenced in the tutorials. I've also tried a couple different tool chains, some work, some don't.
I then find an existing *.zip CWM flashable kernel to work with, usually trying to use one I've successfully ran before, and unzip it. This gives 2 folders and a blob file. Whenever I run bootunpack on the blob I only get a resultant blob.LNX file and, so far never any blob.HEADER file. I understood that the blob.LNX was the same as boot.img from reading through and use dsixda's kitchen to split up the .LNX file I've renamed to boot.img. I then replace the zImage with the one I've just built and repack to boot.img in the kitchen. Then I move that boot.img back to unzipped kernel directory and rename to blob.LNX and run bootpack with blob as output and just ignore the .HEADER part. I then rezip the 2 folders (after replacing any modules in there) and blob into a new zip file and reflash in CWM. If it was based on a kernel I've booted before then it usually works without any problems. I can replace text in the updater-script, if I want and am just reusing the initramfs from the original zip. I have signature verification turned off in CWM, so that doesn't choke it. I need to read more about building initramfs before I do it. So far, this works for me, but I haven't really done any modification to the source, other than rebuilding it with my running config.
sidneyk said:
I have been following a few different instructions for the tools and was concentrated on just learning to rebuild a kernel on my own setup - Ubuntu 11.10. I only installed Ubuntu since it was the distro mostly referenced in the tutorials. I've also tried a couple different tool chains, some work, some don't.
I then find an existing *.zip CWM flashable kernel to work with, usually trying to use one I've successfully ran before, and unzip it. This gives 2 folders and a blob file. Whenever I run bootunpack on the blob I only get a resultant blob.LNX file and, so far never any blob.HEADER file. I understood that the blob.LNX was the same as boot.img from reading through and use dsixda's kitchen to split up the .LNX file I've renamed to boot.img. I then replace the zImage with the one I've just built and repack to boot.img in the kitchen. Then I move that boot.img back to unzipped kernel directory and rename to blob.LNX and run bootpack with blob as output and just ignore the .HEADER part. I then rezip the 2 folders (after replacing any modules in there) and blob into a new zip file and reflash in CWM. If it was based on a kernel I've booted before then it usually works without any problems. I can replace text in the updater-script, if I want and am just reusing the initramfs from the original zip. I have signature verification turned off in CWM, so that doesn't choke it. I need to read more about building initramfs before I do it. So far, this works for me, but I haven't really done any modification to the source, other than rebuilding it with my running config.
Click to expand...
Click to collapse
The architecture really seems to make a big difference in some configurations.
I have one native linux box with 64 bit 10.04 LTS on it, and it always behaves as well as possible, so I did this blob/boot/tools work on it, and it went as it should (creating HEADER and LNX) files, etc.
Then in addition I use several linux distros in VMs, one of them being more like yours, an 11.10 distro with just the androidSDK and all the build tools, prebuilt chains, etc. That will do exactly as you said. I actually built those blobtools/boottools from Koush's git, and they don't work correctly in that one environment. What is different to make that happen? I'm just guessing that something important like the native x86_64 gcc world is different enough to foul things up. It really doesn't matter. Once I got the tools working on the native box, I just transferred them to the other boxes including 11.10 and they work fine.
If you're using 64 bit and would like them I can probably stick them into a .tar.bz2 or whatever and stick up a link to them, or maybe if you can find working binaries to download, you might get those working. Once the blobunpack is returning only the .LNX file, you've pretty well had it as far as progress.
Good luck
hachamacha said:
The architecture really seems to make a big difference in some configurations.
I have one native linux box with 64 bit 10.04 LTS on it, and it always behaves as well as possible, so I did this blob/boot/tools work on it, and it went as it should (creating HEADER and LNX) files, etc.
Then in addition I use several linux distros in VMs, one of them being more like yours, an 11.10 distro with just the androidSDK and all the build tools, prebuilt chains, etc. That will do exactly as you said. I actually built those blobtools/boottools from Koush's git, and they don't work correctly in that one environment. What is different to make that happen? I'm just guessing that something important like the native x86_64 gcc world is different enough to foul things up. It really doesn't matter. Once I got the tools working on the native box, I just transferred them to the other boxes including 11.10 and they work fine.
If you're using 64 bit and would like them I can probably stick them into a .tar.bz2 or whatever and stick up a link to them, or maybe if you can find working binaries to download, you might get those working. Once the blobunpack is returning only the .LNX file, you've pretty well had it as far as progress.
Good luck
Click to expand...
Click to collapse
If by 'native' you mean a hard disk install as opposed to a VM install, then that's where I'm at. I have Ubuntu 11.10 x86_64 installed to a separate partition. I have the recommended stuff installed including the ia32 libs, but I never see a blob.HEADER file with either kernel.zips or ROM zips. I can unpack and repack kernels without the HEADER though and they boot just fine.
But, yes, if you don't mind posting a link with your files I'll give them a try sometime. Thanks.
Hi all,
My Samsung Stratosphere (yeah I know it is old) recently had a hw issue with the Movinand. I cannot access any devices off mmc0. I figured out i can bypass the movinand and remount the mmcblk0 partitions to my external SD card. I also figured out I need to reconfigure my init.rc file (and some others) to do this. I have used the "repack-zimage.sh" tool to extract my initramfs from my zimage kernel. The problem I am having is that the script unpacks things fine..but when I try to repack the initramfs back into zimage, the script stops and gives me the following error:
The command used was "$/ sudo bash repack-zimage.sh -p"
Error: repack-zimage.sh: piggy.gz too large (gzip -9: +689, gzip -8: +1330)
You might want to try a different combination of the -g, -r and -s options.
I ran the repack-zimage using the bash command..and am using Ubuntu 14.04 (if that helps)
The funny thing is I made no changes to any of the initramfs files..I was just testing the script to see if it would unpack and repack correctly.
The reference thread is: [script] repack-zImage.sh: Unpack and repack a zImage without kernel source, V. 5
I know the thread is old, but since I am a new member, I cannot reply within the thread..I was recommended to post here...Sorry if it is in the wrong place.
Any ideas on why the repacked file is larger and how can I modify the script or anything else to correct this issue. When this gets working, I can move onto the next part of the "fix"..and hopefully get my phone working..
Thanks!
EDIT: I was able to get the file repacked..but had to choose "-r" as an option..which means things are not repacked in the same order as the original zImage...So the question is...does it matter? Will the system know the components are "out of order" and deal with it?..or will this cause a problem in the booting sequence?
Hello there, I flashed the KatKernel for Android 5.0, moved the Linux folders into the /data/media/linux folder. The dual boot works great, it boots into XUbuntu, I managed to get the Wifi and the sound work allthough the sound volume is a little low. I also noticed that I have lag when playing hd videos but this isnt't the point. The problem is the Android. It boots into Android but it became unusable as I constantly get errors like Launcher3 stopped working or googleplayservices stopped working. I have CM 12 and XUbuntu. How can I get the Android to work again and still be able to boot into Ubuntu?
niemand_23 said:
... How can I get the Android to work again and still be able to boot into Ubuntu?
Click to expand...
Click to collapse
Did You tried kexecboot kernel? You need to replace android kernel inside archive. To do so You should extract blob file from CM12 firmware and then unpack them with androidroot blobtools and boottools. If You use windows minimal set in attach. First of all drop blob on blobunpack.exe to get <blob_name>.LNX file. Then drop <blob_name>.LNX on bootunpack.exe to get <blob_name>.LNX-ramdisk.cpio.gz and <blob_name>.LNX-kernel.gz. Now rename <blob_name>.LNX-ramdisk.cpio.gz to initrd.img and <blob_name>.LNX-kernel.gz to zImage and replace similar files inside archive in system/boot directory.
Graiden05 said:
Did You tried kexecboot kernel? You need to replace android kernel inside archive. To do so You should extract blob file from CM12 firmware and then unpack them with androidroot blobtools and boottools. If You use windows minimal set in attach. First of all drop blob on blobunpack.exe to get <blob_name>.LNX file. Then drop <blob_name>.LNX on bootunpack.exe to get <blob_name>.LNX-ramdisk.cpio.gz and <blob_name>.LNX-kernel.gz. Now rename <blob_name>.LNX-ramdisk.cpio.gz to initrd.img and <blob_name>.LNX-kernel.gz to zImage and replace similar files inside archive in system/boot directory.
Click to expand...
Click to collapse
Quick question: Would it be easier if I do a full wipe, install KatKiss-5.0_TF300T_017 and then install DB_katkern18_50? I am asking this becaus e I want to perform a clean installation of a new Android Rom and KatKiss doesn't seem that bad. What do you think?
niemand_23 said:
Quick question: Would it be easier if I do a full wipe, install KatKiss-5.0_TF300T_017 and then install DB_katkern18_50? I am asking this becaus e I want to perform a clean installation of a new Android Rom and KatKiss doesn't seem that bad. What do you think?
Click to expand...
Click to collapse
Possibly yes. Dualboot kernel is much closer to original boot method but it have one disadvantage - it's really hard to keep it up to date. So I don't know if curent KatKiss uses same kernel source as dualboot kernel, but it shouldn't cause any big issues.
Graiden05 said:
Possibly yes. Dualboot kernel is much closer to original boot method but it have one disadvantage - it's really hard to keep it up to date. So I don't know if curent KatKiss uses same kernel source as dualboot kernel, but it shouldn't cause any big issues.
Click to expand...
Click to collapse
I flashed the KatKiss Rom and then the KatKernel for DualBoot, the Android works now but it wont't boot into XUbuntu any more. I get the following errors:
*Setting up X socket directories...
start-stop-daemon: unable to start /usr/sbin/kerneloops (Permission denied)
*speech-dispatcher disabled: edit /etc/default/speech-dispatcher
saned disabled: edit /etc/default/saned
What seems to be the problem?
niemand_23 said:
I flashed the KatKiss Rom and then the KatKernel for DualBoot, the Android works now but it wont't boot into XUbuntu any more. I get the following errors:
*Setting up X socket directories...
start-stop-daemon: unable to start /usr/sbin/kerneloops (Permission denied)
*speech-dispatcher disabled: edit /etc/default/speech-dispatcher
saned disabled: edit /etc/default/saned
What seems to be the problem?
Click to expand...
Click to collapse
May be permissions was overwritten during ROM installation.
Graiden05 said:
May be permissions was overwritten during ROM installation.
Click to expand...
Click to collapse
So what now? How can I restore the permissions? It is very weird because back when I had CM 12 and the dual boot kernel it would boot into XUbuntu without any issue but the Android wasn' t working anymore. Now after i flashed the KatKiss Rom and then the dual boot kernel again, it won' t boot into XUbuntu anymore. Has anyone magaged to have a fully working dual boot (Android 5.0 and XUbuntu) ?
niemand_23 said:
So what now? How can I restore the permissions? It is very weird because back when I had CM 12 and the dual boot kernel it would boot into XUbuntu without any issue but the Android wasn' t working anymore. Now after i flashed the KatKiss Rom and then the dual boot kernel again, it won' t boot into XUbuntu anymore. Has anyone magaged to have a fully working dual boot (Android 5.0 and XUbuntu) ?
Click to expand...
Click to collapse
Just a dumb question... Where exactly did you find the dual boot Katkernel? I've looked pretty much everywhere and still no luck for me.
Mich3lin said:
Just a dumb question... Where exactly did you find the dual boot Katkernel? I've looked pretty much everywhere and still no luck for me.
Click to expand...
Click to collapse
This is where I got the dual boot kernel from: http://forum.xda-developers.com/showpost.php?p=57927124&postcount=556 (it's the 5.0 experimental one). I just don't understand why it won't boot into XUbuntu anymore now that I have the KatKiss Rom. Back when I got CM 12, it had no issues, the Android wouldn't work though.
It allways stops at this:
*Setting up X socket directories...
start-stop-daemon: unable to start /usr/sbin/kerneloops (Permission denied)
*speech-dispatcher disabled: edit /etc/default/speech-dispatcher
saned disabled: edit /etc/default/saned
niemand_23 said:
This is where I got the dual boot kernel from: http://forum.xda-developers.com/showpost.php?p=57927124&postcount=556 (it's the 5.0 experimental one). I just don't understand why it won't boot into XUbuntu anymore now that I have the KatKiss Rom. Back when I got CM 12, it had no issues, the Android wouldn't work though.
It allways stops at this:
*Setting up X socket directories...
start-stop-daemon: unable to start /usr/sbin/kerneloops (Permission denied)
*speech-dispatcher disabled: edit /etc/default/speech-dispatcher
saned disabled: edit /etc/default/saned
Click to expand...
Click to collapse
So, I finally had time to try this kernel and it works! Boots just fine into Katkiss ROM and Ubuntu, though I have not used my own rootfs, instead I used img file for our sibling TF700 https://goo.im/devs/rabits/tf700/rootfs.img.7z.zip/. Wifi works, though I couldn't connect...
If I'll have time I'll try to build my own rootfs and report back.
Mich3lin said:
So, I finally had time to try this kernel and it works! Boots just fine into Katkiss ROM and Ubuntu, though I have not used my own rootfs, instead I used img file for our sibling TF700 https://goo.im/devs/rabits/tf700/rootfs.img.7z.zip/. Wifi works, though I couldn't connect...
If I'll have time I'll try to build my own rootfs and report back.
Click to expand...
Click to collapse
Surprisingly , Ubuntu boots fine from the img file, but directly doesn't work. This is odd. Has anyone got a full working rootfs.img ?
@Mich3lin in order to make the wifi work open up a terminal session and type following (password for sudo is ubuntu):
sudo groupadd -r -g 3003 inet
sudo groupadd -r -g 3004 netraw
sudo groupadd -r -g 3005 netadmin
sudo adduser ubuntu inet
sudo adduser ubuntu netraw
sudo adduser ubuntu netadmin
Afterwards, log out and log in again. Now the wifi should work.
The audio works only on the headphones and the volume is kinda low. I really don't know how to make the speakers work.
The key mappings have some bugs. The volume buttons don't work properly. Instead of turning up or down the volume, it takes a screenshot.
I tried to install LibreOffice but I cannot install anything as I keep getting the error unsolved broken packages.
Has anybody figured out how to get rid of the Bootloader Unlocked warning when booting this phone? It certainly slows down the booting process.
I haven't figured it out yet. To be honest I've been trying to figure out what apps are safe to uninstall and a custom ROM or how to update to Android 12. But I'll definitely let you know if I figure a way out.
dfreedom834 said:
I haven't figured it out yet. To be honest I've been trying to figure out what apps are safe to uninstall and a custom ROM or how to update to Android 12. But I'll definitely let you know if I figure a way out.
Click to expand...
Click to collapse
I have been trying to build TWRP for this device. I am very close, but the mkbootimg command script is issuing a bad argument and I have been unable to trace it down so far.
Code:
[100% 4/4] Target boot image: /mnt/audio/android/twrp/out/target/product/minsk/boot.img
FAILED: /android/twrp/out/target/product/minsk/boot.img
/bin/bash -c "(/android/twrp/out/host/linux-x86/bin/mkbootimg --kernel /mnt/audio/android/twrp/out/target/product/minsk/kernel --ramdisk /android/twrp/out/target/product/minsk/ramdisk.img --base 0x00000000 --pagesize 4096 --cmdline \"console=ttyMSM0,115200n8 androidboot.hardware
=qcom androidboot.console=ttyMSM0 androidboot.memcg=1 lpm_levels.sleep_disabled=1 video=vfb:640x400,bpp=32,memsize=3072000 msm_rtb.filter=0x237 servic
e_locator.enable=1 swiotlb=1 androidboot.usbcontroller=a600000.dwc3 earlycon=msm_geni_serial,0x880000 loop.max_part=7 printk.devkmsg=on androidboot.ha
b.csv=10 androidboot.hab.product=minsk androidboot.hab.cid=50 firmware_class.path=/vendor/firmware_mnt/image buildvariant=user buildvariant=eng\" --os
_version 16.1.0 --os_patch_level 2099-12-31 --ramdisk_offset 0x01000000 --tags_offset 0x00000100 --dtb device/motorola/minsk/prebuilt/dtb.img --header
_version 2 --output /mnt/audio/android/twrp/out/target/product/minsk/boot.img ) && (true )"
mkbootimg: error: unrecognized arguments: --dtb device/motorola/minsk/prebuilt/dtb.img
ninja: build stopped: subcommand failed.
15:01:24 ninja failed with: exit status 1
So the --dtb should be --recovery_dtbo I believe. Not sure where this command is being generated in order to fix it.
I was running into problems like that I factor rest it and turned it off. Where did you compile the boot.img from? And ya it would work better if it was trying to go to the right path. I had to find a boot.img from one of the over seas ones I kept getting it were it would root but the screen did respond.
lexridge said:
So the --dtb should be --recovery_dtbo I believe. Not sure where this command is being generated in order to fix it.
Click to expand...
Click to collapse
I could be wrong but the recovery I'm using (orange fox) does use a kernel_dtb. So it seems your recovery image kernel doesn't have the right path to the dtb binary it needs. Try searching the build directory for any _dtb/.dtb and rename accordingly. I'd you need to alter the dtb from a related SoC there are tools for unpacking and modifying those.
The recovery and boot ones would be similar I imagine since those files are a map of the device's hardware.
dfreedom834 said:
I was running into problems like that I factor rest it and turned it off. Where did you compile the boot.img from? And ya it would work better if it was trying to go to the right path. I had to find a boot.img from one of the over seas ones I kept getting it were it would root but the screen did respond.
Click to expand...
Click to collapse
I took the boot.img from the full device A11 factory image.
MINSK_RETUS_11_RPCS31.Q2-109-16-2_subsidy-DEFAULT_regulatory-DEFAULT_CFC.xml.zip
I used the same one to create my magisk boot.img as well. I used dumpyara to build the device tree using the above file for my source which seemed to work properly. No errors in other words.
elrod16 said:
I could be wrong but the recovery I'm using (orange fox) does use a kernel_dtb. So it seems your recovery image kernel doesn't have the right path to the dtb binary it needs. Try searching the build directory for any _dtb/.dtb and rename accordingly. I'd you need to alter the dtb from a related SoC there are tools for unpacking and modifying those.
The recovery and boot ones would be similar I imagine since those files are a map of the device's hardware.
Click to expand...
Click to collapse
I have a dtbo directory containing these files:
Code:
00_kernel
01_dtbdump_amxbr.dtb
02_dtbdump_amxbr.dtb
03_dtbdump_amxbr.dtb
04_dtbdump_amxbr.dtb
05_dtbdump_amxbr.dtb
I also have a dtb.img in the root of the device tree. I will copy it to dtbo.img and see what happens. Thanks for the hint.
lexridge said:
I have a dtbo directory containing these files:
Code:
00_kernel
01_dtbdump_amxbr.dtb
02_dtbdump_amxbr.dtb
03_dtbdump_amxbr.dtb
04_dtbdump_amxbr.dtb
05_dtbdump_amxbr.dtb
I also have a dtb.img in the root of the device tree. I will copy it to dtbo.img and see what happens. Thanks for the hint.
Click to expand...
Click to collapse
I think dtb.img probably has all of the dtb files compiled together
elrod16 said:
I think dtb.img probably has all of the dtb files compiled together
Click to expand...
Click to collapse
That is my thought as well.
lexridge said:
That is my thought as well.
Click to expand...
Click to collapse
I just recently had to deal with all this crap because I didn't know GPD changed which revision of the mediatek SoC they used in the GPD XD while keeping the serial numbers the same. Flashed my old one's backup on it and half the cores were stuck offlined when it booted up. Ended up having to get ahold of the stock kernel for that board revision and patch in the correct dtb for that SoC.
I don't have links but some of the sites that delve into generic Linux kernel porting have tools for decompiling kernel_dtb files to an editable form that you can then recompile if you do have device/driver issues. Also the magisk module for enabling TWRP sdcard storage backups has some Android arm64 native binaries in it that can help with tearing apart kernel/recovery images. (They both are technically kernel images, just one boots a minimal OS).
Edit: I think any dtbo files would be individual compiled object files that get linked into the final dtb image.
Edit 2: I just saw your other comment above. Congrats, that sounds like a viable (and probably long term stable) way you found.
On another topic, I have been trying to mount /system as r/w (thru adb). It appears /system is not actually a mount point but under a different mount point. Any idea what that might be? Doing a cat on /proc/mounts yeilds a crapload of mounts, with many belonging to magisk, but no /system.
I know its been 4 month since last activity, but has there been any progress on this?
There does not seem to have been much progress on this, but I read somewhere recently that the G Stylus (2021) was either the most popular or best-selling Moto phone in 2021. Who knows if that is exactly true, but if it is indeed so popular, here's to hoping that some capable developers will take an interest in it eventually!
Several folks have mentioned that loading a GSI (Generic System Image) should be possible, but I have not had any extended downtime myself to be able to try this. But if you do, you can find some guidance for the 2020 version of the G Stylus at:
https://forum.xda-developers.com/t/...ic-system-image-on-the-moto-g-stylus.4131199/