Related
As you know, we were unable to extract ext4 from Sony ICS firmwares. I took a look at the problem and found out that Sony changed the way sin are generated.
I wrote a quick and (very) dirty command line tool to extract sin properly, it's now possible to extract a working system.ext4.
Usage:
sin2raw <sin file> <output file> [size[K|M|G]]
Usage examples:
sin2raw system.sin system.ext4
sin2raw userdata.sin userdata.ext4
sin2raw kernel.sin kernel.elf
Note:
For linux, there are two versions, sin2raw for 64 bits and sin2raw32 for 32 bits. I strongly recommend using the 64 bits one, 2 gig+ ext4 files are safer with this one.
Release history:
v 0.2:
new: partition size is extracted to generate file, specifying file size is not needed anymore.
new: loader.sin is detected and handled properly.
fix: block header sizes are int, not short.
fix: win32 compatibility.
fix: various size fixes for 32 bits cpu.
code cleanup.
v 0.1 :
Initial release
FAQ
*obsolete* What is size param / 1G ?
When extracting ext4, you have to specify the original partition size on phone. For instance, on xperia S, system is exactly 1 gig, so you have to add 1G. Userdata partition is almost 2 gig, you have to add 2097120K instead of 1G
(Ugly) source code is there, pre-built binaries for windows and linux are attached to this post.
More details to come soon on sin format in second post.
Background:
So, here is the deal: basically, new ext4 sins are using something that was in sin format but that we didn't dig into.
Sin is like this:
Code:
-----------------------
| Sin Header (15 bytes) |
-----------------------
| Block descriptors |
-----------------------
| File Header |
-----------------------
| File Data |
-----------------------
Block descriptors are like this:
Code:
---------------
| target_offset |
---------------
| block_count |
---------------
| block_length |
---------------
| payload_size |
---------------
| payload |
---------------
I presume payload is block signature. A block descriptor is working like this: takes "block_length" bytes from sin "data" and put them at "target_offset" on target device/file.
Up to ics, all block target_offsets were contiguous and that's why sin2img was working. With ics, they are not, explaining why sin2img doesn't work anymore.
History:
2012/08/16 18:00: new analysis, used in 0.2
2012/08/16 11:00: pdfs with more detailed information
it works, thx.
but with only this option 1G added.
Code:
sin2raw system.sin system.ext4 1G
:good:Great job! Thank you very much, i just got extract problem on new *.sin files.
Let me test this tool,I will give some feedback soon.
---------- Post added at 01:50 PM ---------- Previous post was at 01:44 PM ----------
DearTanker said:
:good:Great job! Thank you very much, i just got extract problem on new *.sin files.
Let me test this tool,I will give some feedback soon.
Click to expand...
Click to collapse
It works now,:laugh:,but what is "1G" means?
It seems output file system.ext4 size is 1G?
sorry for my pool english.
---------- Post added at 02:00 PM ---------- Previous post was at 01:50 PM ----------
can extract userdata.sin too,but when extract userdata.sin it will run out space of disk..
Thanks for the info..I will try it.
1G is output file size, 1 gigabyte, you can also use 1024M.
When extracting ext4, you have to specify the phone system partition size if you want to be able to mount it. System partition is 1 gig on Xperia S, I don't know about the other xperias.
If you extract other files like kernel.sin, you don't need to specify output file size.
can extract userdata.sin too,but when extract userdata.sin it will run out space of disk..
Click to expand...
Click to collapse
userdata.sin is almost 2GB, use this:
sin2raw userdata.sin userdata.ext4 2097120K
it will mount properly.
letama said:
userdata.sin is almost 2GB, use this:
sin2raw userdata.sin userdata.ext4 2097120K
it will mount properly.
Click to expand...
Click to collapse
thx, it works on userdata now
but why 2G does not work?
matchung said:
thx, it works on userdata now
but why 2G does not work?
Click to expand...
Click to collapse
Because partition is not exactly 2gig, more 1.999
Why is the system folder not available after converting sin to ext4?
Sharaz22, what do you mean by not available after converting ? This tool extracts a .ext4 image file, you have to mount it to see files. For instance:
mkdir system
sudo mount -o loop -t ext4 system.ext4 system
On windows, I don't know, I know there are some options but never looked at them.
I have mounted the system.ext4 image but there is no system folder in there all the other folder are available e.g. apps xbin etc.
Ah, got it. Well, system.ext4 is the system folder content. In android, system directory is coming from a partition that is mounted to an empty system directory. This is exactly this partition you have there.
Just want to confirm that this tool works fine. I can create pre-rooted image much easier. Don't need to create it from Nandroid anymore. Thanks
Sent from my LT26i using xda premium
Thanks for the feedback!
I'm working on a new release, 0.1 has issues with kernel extracts and hopefully I should be able to compute ext4 size automatically.
And a special thanks to Androxyde for his help!
Thanks,
It's work fine!
New version 0.2 is out, extract is much better now (previous one has few bugs) and size parameter is not needed anymore.
Check first post for details.
its working very fast and without bugs, thats nice, thanks!
I'm using Windows 7 Ultimate 32bit. About sin2raw, how do I open & use it You know, when I left-clicked on "sin2raw.exe", a command windows did appear in just one second, then it disappeared...
banking.amateur said:
I'm using Windows 7 Ultimate 32bit. About sin2raw, how do I open & use it You know, when I left-clicked on "sin2raw.exe", a command windows did appear in just one second, then it disappeared...
Click to expand...
Click to collapse
Sin2raw is a command line tool. You have to use it in a cmd.exe window. Or you could use last FlashTool as Androxyde added the same algorithm in his tool.
These are working Boot.img LZO repack/unpack scripts, modified from the original Perl scripts from http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images.
This allows you to modify boot.img (kernels packs) by most of the developers out there. Old tools used gunzip.
Requires perl, lzop, cpio, mkbootimg
Just changed the magic to match lzo in the unpack script, and modified the commands to use lzop instead of gunzip.
Obviously your kernel needs to support lzo for this to work
Any kernels that you know of which use lzo for the ramdisk compression?
Please PM me when you get this.
Huawei Update Extractor
After messing around a bit with the perl tools available for extracting Huawei update.app files,
i got the idea to create an own (windows) tool.
Requirements
(All versions <= v0.9.9.3 need .Net Framework 3.5)
Latest version uses .Net Framework 4.6.1
Install
Extract the content of the zip to a folder somewhere on your system.
Execute HuaweiUpdateExtractor.exe
I'm planning to create an installer sometime.
Usage
Press the browse (...) button and select an update.app file. Select a device or unknown and press on the open button.
You'll see the content of the update.app file in the listview.
Select one or more files and right click. Choose Extract selected from the context menu.
Choose the ouput folder and press ok.
Or just right click on the list and select Extract all, choose the output folder again and press ok.
Press close on the extract window.
You can sort the list on sequence, filename and size. Just press on the desired column header.
Command line:
HuaweiUpdateExtractor extract input output [profile]
HuaweiUpdateExtractor repack input output profile
Profile
The profiles.xml file is used to identify the files in the update.app file. Every file in the update.app has a sequence or type, which is also
shown in the list. Those sequences or types are used to identify the file/device partition.
Example:
Code:
<?xml version="1.0"?>
<Profiles>
<Profile name="Unknown" author="worstenbrood">
<Files/>
</Profile>
<Profile name="Huawei G510-0100" author="worstenbrood">
<Files>
<File sequence="00000000" partition="/dev/block/mmcblk0p17">system.img</File>
<File sequence="40000000" partition="/dev/block/mmcblk0p13">recovery.img</File>
<File sequence="80000000" partition="/dev/block/mmcblk0p03">baseband.img</File>
<File sequence="EC000000">version.txt</File>
<File sequence="E4000000">splash.raw565</File>
<File sequence="FC000000" partition="/dev/block/mmcblk0p12">boot.img</File>
<File sequence="70000000" partition="/dev/block/mmcblk0p16">cust.img</File>
<File sequence="30000000" partition="/dev/block/mmcblk0p18">userdata.img</File>
<File sequence="FE000000" filetype="signature">signature</File>
<File sequence="FF000000" filetype="checksum">crc</File>
</Files>
</Profile>
<Profile name="Huawei P6" author="worstenbrood">
<Files>
<File type="system" partition="/dev/block/mmcblk0p16">system.img</File>
<File type="cache" partition="/dev/block/mmcblk0p17">cache.img</File>
<File type="cust" partition="/dev/block/mmcblk0p18">cust.img</File>
<File type="userdata" partition="/dev/block/mmcblk0p19">userdata.img</File>
<File type="modemimage" partition="/dev/block/mmcblk0p13">modemimage.img</File>
<File type="boot" partition="/dev/block/mmcblk0p12">boot.img</File>
<File type="recovery" partition="/dev/block/mmcblk0p11">recovery.img</File>
<File type="md5rsa" filetype="signature">signature</File>
<File type="crc" filetype="checksum">crc</File>
</Files>
</Profile>
</Profiles>
<Profiles>
- Root tag of the xml file.
<Profile>
- Identifies a device
- attribute name: name of the device
- attribute author: author of the device
<Files>
- File root tag
<File>
- Identifies a file
- attribute sequence: sequence of the file in update.app
- attribute type: type of the file in the update.app
- attribute partition: destination partition on the device
- attribute filetype: can be one of the following values:
* signature: used to identify the signature file
* checksum: used to identify the checksum file
- value: file name
You can add or edit devices. If you want them to integrate in newer version, pm 'em to me.
I'm gonna make some auto update for the device file somewhere in the future
To add your devices profile you'll have to identify your device partitions and map them against the files inside the update.app.
Thread about identifying partitions: http://forum.xda-developers.com/showthread.php?t=1959445
Roadmap
- You tell me ...
Credits
ZeBadger ([email protected]) for figuring out the file headers
S34Qu4K3 for the P6 partition layout
ngamyarthar for adding ALOT of devices!
Changelog
v0.9.1.0
- Create update zip works now, this requires to have a PERFECT device entry in the devices file. The sequence is used to identify the file AND partition. Only files that have these two will be included in the zip. USE WITH CAUTION, MAKE SURE THE PARTITION IS CORRECT OR YOU'LL END UP FLASHING THE WRONG IMAGES TO THE WRONG PARTITION !! I'M NOT RESPONSABLE FOR BRICKING YOUR DEVICE! IF YOU DON'T KNOW WHAT YOU'RE DOING, THEN DON'T USE IT!
v0.9.1.1
- Added Type to the filelist (shows INPUT for g510 roms, but shows some useful info on P6 roms)
v0.9.2.0
- Files now can also be identified by the type attribute in devices.xml
- Added P6 device
v0.9.3.0
- Crc check during extract
- Crc check during creating flashable zip
- Added row to see file is flashable
v0.9.5.0
- Added repack
- Added icons and tooltip
- Added settings
- Experimental, no signing on repack, crc file gets generated
- Alot of stuff i forgot
v0.9.6.0
- Added command line options
v0.9.7.0
- Added G300 profile (thx ZeBadger)
- Added detailed info about the file (libmagic) in the tooltip on the extract list. This way it is easier to identify files inside the update.
(see screenshot). It will detect ext/fat/... partitions.
v0.9.7.1
- Alot of devices added in profiles (Credits to ngamyarthar, thanks alot dude!)
- Added android boot/recovery image recognition in magic.mgc
v0.9.7.2
- Made setup
-v0.9.7.4
- App will now remember last used profile.
- Fixed bug in repack code (remainder writing)
- Added signing options (During repack, once set, it will use the selected keyfile (PEM format) and algorithm to create the signature file. If there is no file selected or the file doesn't exist, it will use the existing signature file.)
Example of keyfile content:
Code:
-----BEGIN RSA PRIVATE KEY-----
MIICXgIBAAKBgQDU9GF9tdk59edEXWX4MEJNjMqGce/CqqGZSDBwnAzHITZYBm+y
ZEVkaOGGdPY7rmmWO6w3P/+nPVHO0kxA1/J+FY+sbUF7uz0kzVDxuW6t5KDc9Qr4
NRAE1ZzX0eB0aYpLImlqI7yigih6ds+Yp83mTbF+BiaFTLLtMVdWS7wQiwIDAQAB
AoGBAMok2E4+Sl9sfwU0K1E2bhmzJaQNj2wYEKGyFtkuKCr16eIQ6gJKkFxJ+ppp
eDsaynujVUx04bbczEUo9t0un603s5HAGq6USO5flERco0TlNw7xnTornPPrNxfU
sXOtIGzb0FlRuC129JqZJ9QsfvOyt3KIWwmJqc0R/k0xB8uRAkEA9+v1ohNXB8CL
plhQOtq0ueWrf9CCCeiqhf6ijg7UEegMLGKZ2gFMvMNwuojz/pbQmHdWTU9eC0k1
3yiAwHtcLQJBANvkvjXdzCYHO6nWOH1vf8DRLwCnwEteyxJ2qnrqKLS3fxCjWN4h
4vSNqgC9uoLEb/6T/72XTdG9gS8GsuoAupcCQBZ4eIb8IcM+HGozTvJGqGLBAk5P
Y7nqMKp8bddaWLZWxeOv/CnaPE5PmIQPra3BlZ58EoJnUyrKs+tKDIFlrPECQQC9
Ie0cxc4e81+0/+WMtkdq4EGOTbsO2NTP57NQj3E9pwqqk+UPApSEBgkwJAB1E2LE
1CVGvAoaGeYwPZHLxZ63AkEAugR+cC+5/BtTeMeXEcijnU0qkgkwLCMgTB1DIoMm
X0/wRGPPmZpGmMStHd+87ZxQSOiq5nAyZ4riFXLziUNOlA==
-----END RSA PRIVATE KEY-----
-v0.9.7.5
- Default sorting on filename
- Small changes in structure of profiles.xml
-v0.9.7.6
- Added progress for signing and checksum generation
- Extract/CreateZip order by offset
- Repack order by Signature, Checksum, Files
-v0.9.7.7
- Doubleclick on item in extract files listview copies tooltip text to clipboard
- Added detailed android boot/recovery image detection to magic.mgc
- Added SecVRL header (the 2048 byte header in front of fastboot/boot/recovery image) detection
-v0.9.7.8
- Added timestamp options in settings
- Added tooltips in settings
- Some ui changes (which hopefully fix the missing "..." button issue)
-v0.9.7.9
- Some small ui fixes
- When saved location of the app is on a monitor that isn't attached anymore, app location is restored to center of primary screen.
-v0.9.8.0
- Some small ui changes
- Sort profiles by name
- Remember last used directory
- Added profile for Huawei G526 (Credits Roman Dmitriev)
-v0.9.9.0
- Added compatibility for wine/mono
- Fixed bug in settings (Verify header checksum)
- Made the app localizable (Download the Resources_EN example, if you make a translation, make sure that your assembly start with "Resources_" and ends with the TwoLetterISOLanguageName (eg. EN for english) of your culture and put the assembly in the same directory as the application)
- Added profile for Huawei Ascend Mate 7 (Thanks to sketchykingy)
-v0.9.9.1
- Added missing translatable resources (updated Resources_EN)
- Added profile for Huawei MediaPad X1 7.0 (7D-503L) (Credits ElectroMyStyle)
-v0.9.9.2
- Fixed int overflow (extracting big files)
-v0.9.9.3
- Added drag/drop for files and folders.
-v0.9.9.5 - 12/12/2016
- Upgraded to .Net Framework 4.6.1
- Fixed libmagic calling convention
- Huawei Mediapad M2 8.0 (M2-802L) profile by @beast.in.black
- Huawei Ascend P8 (GRA-L09) profile by @nexolight
- Huawei Mate S profile by @philipp900
- Huawei P8 lite profile by @linus2014
- Huawei Honor 5x (Kiwi-L2X) profile by @deadman96385
26122015
Created an opensource c# library to work with update.app files:
https://github.com/worstenbrood/HuaweiUpdateLibrary
Enjoy
Download
- v0.9.9.3: Setup - Zip
- v0.9.9.5: Zip
Mirror
Donate if you like my work.
Is it possible to repack update.app?
If so, could you implemet such feature?
xan said:
Is it possible to repack update.app?
If so, could you implemet such feature?
Click to expand...
Click to collapse
Since i almost finished update zip creation (new version tomorrow), i have put it on the roadmap (already thought about it anyway )
The problem is sign the app, not repack it
Sent from my HUAWEI P6-U06 using xda app-developers app
S34Qu4K3 said:
The problem is sign the app, not repack it
Sent from my HUAWEI P6-U06 using xda app-developers app
Click to expand...
Click to collapse
I dont think its signed, but it has a per file per block checksum which should be correct...
worstenbrood said:
I dont think its signed, but it has a per file per block checksum which should be correct...
Click to expand...
Click to collapse
So, repack is useless, i tried it, you need to resign the app to make the new checksums match or it will give you an error when you flash it via default recovery.
Don't missunderstand me, is a great tool, and simplifies the unpack/repack for more unexperienced users, but without the sign, you can't flash it, that's what i say that is a bit useless (like the other scripts to unpack and repack)
S34Qu4K3 said:
So, repack is useless, i tried it, you need to resign the app to make the new checksums match or it will give you an error when you flash it via default recovery.
Don't missunderstand me, is a great tool, and simplifies the unpack/repack for more unexperienced users, but without the sign, you can't flash it, that's what i say that is a bit useless (like the other scripts to unpack and repack)
Click to expand...
Click to collapse
I'll investigate some more when i have the time. Also the signing part is why i actually made a function to create a flashable zip from it, this way you CAN flash it with a custom recovery (ok you need an unlocked bootloader, but why would'nt you do that anyway )
worstenbrood said:
I'll investigate some more when i have the time. Also the signing part is why i actually made a function to create a flashable zip from it, this way you CAN flash it with a custom recovery (ok you need an unlocked bootloader, but why would'nt you do that anyway )
Click to expand...
Click to collapse
That's great
Huawei Update Extractor
v0.9.2.0
- Files now can also be identified by the type attribute in devices.xml
- Added P6 device
Click to expand...
Click to collapse
Please add Ascend P2
Thanks
Carlos Varella said:
Please add Ascend P2
Thanks
Click to expand...
Click to collapse
S34Qu4K3 made a nice post on how to identify the partitions on your phone, after identifying them you have to map them to the files inside the update.app. Since i don't have access to an P2 i'm counting on you guys to complete the devices.xml file.
http://forum.xda-developers.com/showthread.php?t=2398404
Excellent work Worstenbrood! :good:
The tool is very good. I've tried with several Update.app and all OK.
It would be very interesting to get to repack the file Update.app because still do not have a custom recovery bootable. With the current cwm recovery can not extract files. Img a partition.
May you work on the file repack Update.app
The author Genokolar the custom recovery of Honor 2 miui port and a large majority of Huawei moblies have to pack and repack the file Update.app (over 4 months ago):
https://github.com/genokolar/unpacker_huawei/blob/master/unpack.php
That really says there that forked from tewilove / unpacker_huawei
Best Regards
Next version will have a repack function included, i'm adjusting the UI but most of the repacking code is already written.
worstenbrood said:
Next version will have a repack function included, i'm adjusting the UI but most of the repacking code is already written.
Click to expand...
Click to collapse
Excellent news!
Update to v0.9.5.0, added repack function, it only repacks the file + recalculates all checksums and the checksum file. No signing is done yet ! Since i have no access to a huawei device atm it would be nice to see some results (i'm wondering if the order of the files inside the update.app is important)
Thank you for the update. BTW, the Huawei Ascend Mate has the same partition information as the P6 so should be easy to add to the tool. I've been using it to unpack Mate updates with success.
flibblesan said:
Thank you for the update. BTW, the Huawei Ascend Mate has the same partition information as the P6 so should be easy to add to the tool. I've been using it to unpack Mate updates with success.
Click to expand...
Click to collapse
Then it is just a matter of cloning the P6 profile inside the profiles.xml and changing the Name attribute or changing the name so that it suits both...
Any updates may be sent to me
worstenbrood said:
Then it is just a matter of cloning the P6 profile inside the profiles.xml and changing the Name attribute or changing the name so that it suits both...
Any updates may be sent to me
Click to expand...
Click to collapse
Confirm, it work too with D1QXL
Amazing, I found anywhere and none of them work. Great Tool
My I ask one feature? pack/unpack *.img
In my device, Ascend D1 Quad XL, every image has additional 2048 header before ANDROID magic word.
To extract boot.img/recovery.img, dsixda's Android Kitchen remove the 2048 header, save as new boot.img then extract it. Repack it.
But then, the repack image have no 2048 header. So I can't flash it manually to device.
Would yo learn/track this 2048 header
Thank's
twins.7 said:
Confirm, it work too with D1QXL
Amazing, I found anywhere and none of them work. Great Tool
My I ask one feature? pack/unpack *.img
In my device, Ascend D1 Quad XL, every image has additional 2048 header before ANDROID magic word.
To extract boot.img/recovery.img, dsixda's Android Kitchen remove the 2048 header, save as new boot.img then extract it. Repack it.
But then, the repack image have no 2048 header. So I can't flash it manually to device.
Would yo learn/track this 2048 header
Thank's
Click to expand...
Click to collapse
Thanks.
I want to keep the app as generic as possible, you can easily write a bat file that does that
worstenbrood said:
Thanks.
I want to keep the app as generic as possible, you can easily write a bat file that does that
Click to expand...
Click to collapse
No, I mean this 2048 header are unique. That's why I need your help to determine contain of header.
without that header I can't flash img to device. Each change in img, the header must change too.
twins.7 said:
Confirm, it work too with D1QXL
Amazing, I found anywhere and none of them work. Great Tool
My I ask one feature? pack/unpack *.img
In my device, Ascend D1 Quad XL, every image has additional 2048 header before ANDROID magic word.
To extract boot.img/recovery.img, dsixda's Android Kitchen remove the 2048 header, save as new boot.img then extract it. Repack it.
But then, the repack image have no 2048 header. So I can't flash it manually to device.
Would yo learn/track this 2048 header
Thank's
Click to expand...
Click to collapse
twins.7 said:
No, I mean this 2048 header are unique. That's why I need your help to determine contain of header.
without that header I can't flash img to device. Each change in img, the header must change too.
Click to expand...
Click to collapse
Share an image with me (with the header included) and i'll take a look when i have some time.
I have a script and tools hosted on dropbox.
Stick with the beta script unless you're interested in testing.
What the script can do.
1. Essentially replace aroma in the most basic sense. [Can be made to run with]
It will take any ROM.zip convert the initrd.gz to the desired type (DataOnExt, NativeSD, DirectSD) and copy them to /boot and /boot_dir
Will strip the updater-script of the ROM.zip down to the symlink/set_perm lines along with extract data and system folders.
(Essentially turning an aroma ROM.zip to a basic CWM ROM.zip)
2. Mount appropriate folders
Just tell the script the type of install and the name of the ROM (i.e the ROM folder name on ext4).
Then you can flash any zip you want (as long as the zip doesn't change the mounts)
3. Modify the ramdisk
If you just want the ramdisk modified that can be arranged
4. System install.
In consideration.
It's difficult to get things running as they should without a device to reliably test things on, so need user feedback to correct stuff.
I have been unsuccessful thus far in getting a portadroid type up and running, I'm not sure why at this point.
If the interest is there I can try and add in the updating mechanic from portadroid to Native/Direct, i.e where you have a named folder(s) (open to suggestion on folder names) present in /sdcard/NativeSD and these folders are copied over to the ext4 folders on boot.
How to run:
Instruction can be seen on the dropbox page but:
Simpliest way is via adb.
Copy the bins folder to /sdcard/bins
Reboot to recovery
Push the script to /tmp for example: adb push *.sh /tmp/
Run the script:
adb shell
cd tmp
chmod 777 *.sh
./*.sh
Then read the prompts.
Alternatively you can run it directly as ./*.sh {opt} $type $ROM_NAME $data_NAME $systeminstall
Feel free to report any issues, suggestions/improvements.
I'll be posting a recovery with most of the needed stuff bundled in, so running it will be easier for devs.
Writing the script took some doing (especially as it's in dash - not bash), any feedback would be appreciated.
Credits due.
The portadroid guys (if/when it's up and running)
[cedesmit, Takaaki, boonbing]
The Native/DirectSD guys
[securecrt,Xylograph]
RobbieP for testing thus far.
I have noticed that I already have the code for an update feature in the script just need to add a loop, what would be the general consensus for the location of the script to flash /sdcard/NativeSD/*.zip or /sdcard/NativeSD/ROM_NAME/*.zip?? The second would mean that you can't rename the foldername (unless I manage to add in startup.txt features).
Update added to gamma script - using ROM folder (subject to change)
is this any good for determining kernel version? http://stackoverflow.com/questions/9535227/getting-uname-information-from-a-compressed-kernel-image
I added a modified version of @macs18max CM11 ROM using a version of my gamma script (will pull on request) to dropbox last night, if anyone is willing to test...
1. Does it boot
---If it doesn't add a blank file as /sdcard/bins/makemountfs (echo "" > /sdcard/bins/makemountfs will do it)---
---And try it again; unfortunately this will remove the update feature---
2. Are update zips installed properly
Diff from original:
only one initrd - script makes the others as needed
script performs the partition mounting for the ROM
script checks for zips in the ROM folder in NativeSD
Need to add:
my build.prop append code - once I where I posted it... to reduce duplicates.
Edit. Whoops didn't mean to edit my post from yesterday - @Robbie P just for reference "strings zImage | grep 'Linux version'" is similar to what you posted and can be run on the leo but doesn't seem to give reliable/usable results - I haven't ran the hexdump check on the latest kernel yet so not sure if the check is still valid.
i did try 1_92 on macs18max's rom last night, the kernel was not recognised as a 3.0 kernel. i added 6mb but it didn't boot. I had the extended battery in throughout
i did use the f2fs sd recovery though to flash it, that booted ok and has 3.0 kernel
i still think a simple "if kernel >3mb => 3.0 kernel" haven't checked the latest .35 kernel yet for size.
did you add the adb fix?
will try yours later:fingers-crossed:
thanks
Edit; in fact, size of kernel is the over-riding factor, surely. it is size-of-magldr's-boot-partition minus size-of-initrd.gz(any-type) gives the max size of a kernel before we have to add 6mb. i guess it is around 3mb.
it is conceivable that we may have to add 6mb to the .35 kernel's ramdisk if more code is added.
Robbie P said:
i did try 1_92 on macs18max's rom last night, the kernel was not recognised as a 3.0 kernel. i added 6mb but it didn't boot. I had the extended battery in throughout
i did use the f2fs sd recovery though to flash it, that booted ok and has 3.0 kernel
i still think a simple "if kernel >3mb => 3.0 kernel" haven't checked the latest .35 kernel yet for size.
did you add the adb fix?
I added the ADB 'fix' to on boot - with gamma 4_4 (the ROM zip is using 4_3) - the line I added is with the variable, not ABCD..., might work, moight not
will try yours later:fingers-crossed:
thanks
Edit; in fact, size of kernel is the over-riding factor, surely. it is size-of-magldr's-boot-partition minus size-of-initrd.gz(any-type) gives the max size of a kernel before we have to add 6mb. i guess it is around 3mb.
it is conceivable that we may have to add 6mb to the .35 kernel's ramdisk if more code is added.
You could be right about the 3mb size always needing 6MB but I can't be sure. My feeling is it is a 3.0.x issue rather than a size one (I could be wrong though). 3.0.x kernels could probably be cut down (esp. recovery kernels) to be less than 3MB (and vice versa with the 2.6.x) that's why I was keen to stay away from size as being the determining factor - I'll switch to using sizes in the next gamma.
Click to expand...
Click to collapse
ADB fix with 4_4 is:
sed -i "/on boot/ a write /sys/class/android_usb/android0/iSerial \${ro.serialno}" /tmp/work/init.htcleo.rc
I could try variable substitution \${ro.serialno:-ABCDEF123456} but not sure if that works with .rc's
Edit. 4_5 kernel check changed to:
Code:
[strike]zI=` busybox ls -la /tmp/zImage | awk '{print (${NF-4)}' `
if [ ${zI} -gt '3145728' ]; then...[/strike]
zI=` du -m /tmp/zImage | awk '{print $(NF-1)}' `
if [ ${zI} -gt '2' ]; then...
mac rom; i have an error from aroma-config line 147 col 40, pretty sure it is missing comma on line 145 after "1"
rezipping and re-flashing. is the rom-name different from original?
it went through aroma options (chose directsd, softkeys,wipe), then installed immediately, no files actually installed, attached recov logg
i did have original rom.zip on sdcard and nativesd rom installed, might have to delete either, or both?
Edit; deleted original rom.zip and used 4ext recovery (f2fs sd previously), but same, installs successfully immediately, log did not save unfortunately
Robbie P said:
mac rom; i have an error from aroma-config line 147 col 40, pretty sure it is missing comma on line 145 after "1"
rezipping and re-flashing. is the rom-name different from original?
it went through aroma options (chose directsd, softkeys,wipe), then installed immediately, no files actually installed, attached recov logg
i did have original rom.zip on sdcard and nativesd rom installed, might have to delete either, or both?
Edit; deleted original rom.zip and used 4ext recovery (f2fs sd previously), but same, installs successfully immediately, log did not save unfortunately
Click to expand...
Click to collapse
Have reupped with aroma fixed, rom-name was the same as original (folder in NativeSD would be different). Reupped version has _test added to it. recov.logg reports that system was installed??? Based on the other stuff in the log I don't think it's made from the zip.
type=NativeSD rom_name=cm11_ma and command run was m(ntstuff) rather then m(odify)r(amdisk)...
Yea - the log is from a different zip install:
Code:
Installing '/sdcard/cm11_ma_NativeSD.zip'...
Checking for MD5 file...
I:Cannot find file /sdcard/cm11_ma_NativeSD.zip.md5
Skipping MD5 check: no MD5 file found.
I:Zip does not contain SELinux file_contexts file in its root.
about to run program [/tmp/multi.sh] with 5 args
There really shouldn't be any conflicts with other zips here... Is there any text reported on screen after/before the system supposedly installs?
Edit. Anyone know where the HD2 HaRET source is located? Anyone trying to run 3.0.x with haret try adding 1MB of zeros to the initrd.gz (PM if you don't know how).
sorry about that log, was the one from previous night's install.
i just tried GAMMA4_5.sh DirectSD cm11_m
get screen.txt attached
i know @gilbert32 was looking at getting haret to boot with 3.0 kernel
Robbie P said:
sorry about that log, was the one from previous night's install.
i just tried GAMMA4_5.sh DirectSD cm11_m
get screen.txt attached
i know @gilbert32 was looking at getting haret to boot with 3.0 kernel
Click to expand...
Click to collapse
Could you try just using the zip on the dropbox page - the sh and bins are already added to it. No need to run any script. I might need to change the bundled script though. Picking through the errors in the log:
sh: 3.1: bad number
is from the kernel check - I added h (so that it reports 3.1M rather than 3, wasn't sure how it would handle the decimal) - reverted 4_5
cp: can't stat '/tmp/mountfs-DirectSD.sh': No such file or directory
copying fsck for f2fs
cp: can't create '/system/bin/mkfs.f2fs': No such file or directory
cp: can't create '/system/bin/fsck.f2fs': No such file or directory
chmod: /system/bin/mkfs.f2fs: No such file or directory
chmod: /system/bin/fsck.f2fs: No such file or directory
gamma doesn't use mountfs.sh's by default
f2fs added in error?? Can't copy to system/bin as there isn't one
/GAMMA4_5.sh: line 1236: /tmp/7za: not found
Should have been /bin/7za - fixed 4_5
sh: porta: unknown operand
Trying to figure this one out - it's line 1197 - fixed 4_5 - still not sure why it reported as an error (nested if??)
Current 4_5 bundled in ROM zip
My thinking regarding haRET - the source I saw (different device) seems to have the ramdisk offset by 5MB. Offset for 3.0.x is 16MB (magldr default offset is 10MB plus the 6MB of zeroes = 16MB). If the offset in haret is matched to that of magldr (10MB) then 1 more MB is needed to get to to 16 - if haret is compiled to add a 5MB offset. Source I was referencing is here.
Robbie P said:
sorry about that log, was the one from previous night's install.
i just tried GAMMA4_5.sh DirectSD cm11_m
get screen.txt attached
i know @gilbert32 was looking at getting haret to boot with 3.0 kernel
Click to expand...
Click to collapse
funny thing, i just was looking into it (after a long time since being on xda), and saw this mention
still, i can't find any clue on what to do, or what's the cause for the no-boot with haret...
tried latest mac.zip, have attached logs
i have a work assessment coming up in the next couple of days, so need to get my head down.:fingers-crossed:
Robbie P said:
tried latest mac.zip, have attached logs
i have a work assessment coming up in the next couple of days, so need to get my head down.:fingers-crossed:
Click to expand...
Click to collapse
Get your head down, mate. Just some missing ,'s in the updater-script (used to separate arguments). Should be fine now - at least on the non-script side of things.
Correction - it's fine now (sh was wiping /tmp and thus /tmp/aroma before it was needed by updater-script), managed to botch a working device again - currently installing as DirectSD on cLK.
HypoTurtle said:
Anyone trying to run 3.0.x with haret try adding 1MB of zeros to the initrd.gz (PM if you don't know how).
Click to expand...
Click to collapse
Just tried this and it still doesn't boot, same as before, hangs on jumping to kernel
edit; tried changing initrd offset in startup.txt from 0x00a00000 to 0x00b00000 and 0x00900000 but no joy either
Robbie P said:
Just tried this and it still doesn't boot, same as before, hangs on jumping to kernel
edit; tried changing initrd offset in startup.txt from 0x00a00000 to 0x00b00000 and 0x00900000 but no joy either
Click to expand...
Click to collapse
nah, this isn't the problem. it's somewhere else and i can't figure it out we have to stick with clk or mag for 3.0.x atm
gilbert32 said:
nah, this isn't the problem. it's somewhere else and i can't figure it out we have to stick with clk or mag for 3.0.x atm
Click to expand...
Click to collapse
How about mtype? we know that the .35 kernel was originally from desire. is it possible that it still has mtype set to 2215 somewhere? i tried setting it to this in startup.txt but same.
Edit; might have found haret source code https://code.google.com/p/android-kaiser/downloads/detail?name=haret.tar.gz&can=2&q=
@gilbert32 @Robbie P
Just for reference: haretlog from 2.x
Built virtual to physical page mapping
Allocated 3124 pages (tags=5C000000/16368000 kernel=5C001000/16369000 initrd=5C2BB000/2c161000 index=5CC2D000/2b7ef000)
Built kernel tags area
Built page index
Tags will be at offset 0x00000100 (0xf00)
Kernel will be at offset 0x00008000 (0x2b9800) [2.72MB]
Initrd will be at offset 0x00a00000 (0x971ad6)
Video buffer at 49739000 sx=480 sy=800 mx=120 my=133
Video Phys FB=03839000 Fonts=2b7ea0e4
[email protected]/2b7e9000 sj=5CC33278 stack=5CC31000/2b7eb000 data=5CC32000/2b7ea000 exec=2b7e93a0
Reading 2856960 bytes...
Read complete
Reading 9902806 bytes...
Read complete
Launching to physical address 2b7e9288 [695.91MB]
Trampoline setup ([email protected]/10028f68/1323ff68) [256.16MB][306.25MB]
MMU setup: mmu=A04C0000/11cc0000
Go Go Go...and from 3.x
Built virtual to physical page mapping
Allocated 3308 pages (tags=5C900000/163e0000 kernel=5C901000/1649a000 initrd=5CC73000/16294000 index=5D5E5000/2b87c000)
Built kernel tags area
Built page index
Tags will be at offset 0x00000100 (0xf00)
Kernel will be at offset 0x00008000 (0x3715b0) [3.44MB]
Initrd will be at offset 0x00a00000 (0x971ad6)
Video buffer at 49739000 sx=480 sy=800 mx=120 my=133
Video Phys FB=03839000 Fonts=2b8770e4
[email protected]/2b876000 sj=5D5EB278 stack=5D5E9000/2b878000 data=5D5EA000/2b877000 exec=2b8763a0
Reading 3610032 bytes...
Read complete
Reading 9902806 bytes...
Read complete
Launching to physical address 2b876288 [696.46MB]
Trampoline setup ([email protected]/1a028f68/12ca6f68) [416.16MB][300.65MB]
MMU setup: mmu=A04C0000/11cc0000
Go Go Go...There's probably nothing there of any help. Physical address is changed by about 1.5MB?? 160MB in trampoline == graphics??
Double post
how about booting a 2.6.32 kernel from haret and then using kexec to change to 3.0 kernel in running rom?
HypoTurtle said:
@gilbert32 @Robbie P
Just for reference: haretlog from 2.x
Built virtual to physical page mapping
Allocated 3124 pages (tags=5C000000/16368000 kernel=5C001000/16369000 initrd=5C2BB000/2c161000 index=5CC2D000/2b7ef000)
Built kernel tags area
Built page index
Tags will be at offset 0x00000100 (0xf00)
Kernel will be at offset 0x00008000 (0x2b9800) [2.72MB]
Initrd will be at offset 0x00a00000 (0x971ad6)
Video buffer at 49739000 sx=480 sy=800 mx=120 my=133
Video Phys FB=03839000 Fonts=2b7ea0e4
[email protected]/2b7e9000 sj=5CC33278 stack=5CC31000/2b7eb000 data=5CC32000/2b7ea000 exec=2b7e93a0
Reading 2856960 bytes...
Read complete
Reading 9902806 bytes...
Read complete
Launching to physical address 2b7e9288 [695.91MB]
Trampoline setup ([email protected]/10028f68/1323ff68) [256.16MB][306.25MB]
MMU setup: mmu=A04C0000/11cc0000
Go Go Go...and from 3.x
Built virtual to physical page mapping
Allocated 3308 pages (tags=5C900000/163e0000 kernel=5C901000/1649a000 initrd=5CC73000/16294000 index=5D5E5000/2b87c000)
Built kernel tags area
Built page index
Tags will be at offset 0x00000100 (0xf00)
Kernel will be at offset 0x00008000 (0x3715b0) [3.44MB]
Initrd will be at offset 0x00a00000 (0x971ad6)
Video buffer at 49739000 sx=480 sy=800 mx=120 my=133
Video Phys FB=03839000 Fonts=2b8770e4
[email protected]/2b876000 sj=5D5EB278 stack=5D5E9000/2b878000 data=5D5EA000/2b877000 exec=2b8763a0
Reading 3610032 bytes...
Read complete
Reading 9902806 bytes...
Read complete
Launching to physical address 2b876288 [696.46MB]
Trampoline setup ([email protected]/1a028f68/12ca6f68) [416.16MB][300.65MB]
MMU setup: mmu=A04C0000/11cc0000
Go Go Go...There's probably nothing there of any help. Physical address is changed by about 1.5MB?? 160MB in trampoline == graphics??
Click to expand...
Click to collapse
@HypoTurtle @gilbert32 @Robbie P
How do I get this logs from haret. I have just install win6.1. Could someone guide me?
Dear All,
I'm new to this forum, so apologies if this is not the right section for my question.
I'm entering the world of AOSP and I built the product target aosp_arm64-eng on a MacOS M1 (ARM64 processor).
Unfortunately when I launch the emulator I get a kernel panic with the below message and I would like to understand how I can debug it
Code:
RAMDISK: lz4 image found at block 0
RAMDISK: lz4 decompressor not configured!
Invalid ramdisk decompression routine. Select appropriate config option.
Kernel panic - not syncing: Could not decompress initial ramdisk image.
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.94+ #1
Hardware name: ranchu (DT)
Call trace:
[<ffffffc00008a590>] dump_backtrace+0x0/0x128
[<ffffffc00008a6cc>] show_stack+0x14/0x1c
[<ffffffc0005ca064>] dump_stack+0x80/0xa4
[<ffffffc0005c95a0>] panic+0xe8/0x228
[<ffffffc00074ba34>] rd_load_image+0x2fc/0x5e0
[<ffffffc00074be30>] initrd_load+0x50/0x2cc
[<ffffffc00074b47c>] prepare_namespace+0xd8/0x1ac
[<ffffffc00074ad04>] kernel_init_freeable+0x1bc/0x1dc
[<ffffffc0005c8150>] kernel_init+0x10/0xf4
Rebooting in 5 seconds..Reboot failed -- System halted
From the message it seems that the kernel is not configured correctly.
How can I check if the kernel I build contained the LZ4 support with which the Ramdisk image seems to be compressed?
Thanks.
I think it's not possible to run an emulator on a mac with an arm processor see here