Hi,
The installed boot-image has 0x100 bytes of data before the tag "ANDROID!", whereas usual boot-images start with that tag. Does anybody know about it?
The problem is, that unpackbootimg tool doesn't work on that image. I could help my self by installing first the BinDroid kernel. Based on that boot-image, I could bring my kernel to the device.
Additionally, I'm confused about the kernel base address. The .config file defines "0x00200000" and the unpackbootimg tool returns "0x14400000". Usually they are the same numbers. It works with "0x14400000".
Thanks,
Adrian
NOTE: Unfortunately I've had to remove links from this post because I'm a new user. I'll add them back in once I have enough posts.
I've been trying to edit a file in boot.img from the CyanogenMod 12.1 (huashan) nightlies but I'm experiencing some issues finding the right tools/methods for the job.
Most scripts I've found expect an Android Magic number at the beginning of the file but this simply isn't there. It seems there is no header at all that matches the specification from bootimg.h (missing link) though I did discover the cmdline argument at the end of the file with a hex editor.
After searching and experimenting for hours I found a script here (missing link) which enabled me to extract the kernel and ramdisk images despite the missing header but now I don't know how to repack the files into a boot.img of the same structure.
I've tried the following but it results in a boot.img that is about 40% larger than the orginal (despite me only adding one line of code) and has an entirely different structure (with an Android Magic number, etc.).
Code:
mkbootimg --base 0x00200000 --pagesize 2048 --kernel boot.img-kernel.gz --ramdisk newramdisk.cpio.gz -o newboot.img
I found this resource (TWRP, missing link) which mentions that Xperia devices have special boot images (or something like that, I didn't understand all of it) - this might explain why the boot.img structure is so different - but I can't find any further documentation on this or instructions on how to deal with the format.
The Xperia devices have a recovery-in-boot arrangement. This means that the recovery is booted using the regular kernel / boot image in the device. Team Win has worked with the FreeXperia device maintainers to come up with a way to extract the ramdisk from the FOTAKernel partition and use the ramdisk from that partition instead of the recovery that is included in the boot image of your device. This means that if you install current CM nightlies and flash TWRP to the FOTAKernel partition, you will be able to use TWRP instead of the CWM or CM recovery that normally comes in a CM boot image. Other boot images including stock kernels can be repacked to include this extraction utility to allow you to use TWRP from the FOTAKernel partition. This setup allows you to choose what recovery you want to have installed and allows you to update your recovery more easily. Unfortunately this setup requires that the boot image that you have installed include the ramdisk extraction utility.
Click to expand...
Click to collapse
So now I'm at a loss at how to continue. I would much appreciate any pointers, ideas or help in general.
@infernalpostcard , hopefully this tool made by @Adrian DC will help you out.
https://github.com/AdrianDC/android_huashan_bootimg_editor
Raienryu said:
@infernalpostcard , hopefully this tool made by @Adrian DC will help you out.
https://github.com/AdrianDC/android_huashan_bootimg_editor
Click to expand...
Click to collapse
Thanks. This looks really promising. I'm trying it out now...
EDIT: It worked! This is exactly what I needed. Unfortunately what I was actually trying to achieve (apply a fix to break a boot-loop my phone gets in, due to an encrypted filesystem) didn't work so I'll have to come up with new ideas.
Hallo, I hope someone in this forum can help me with a problem with my SM-T819 TWRP.
I tried to install a CustomRom without making a back-up copy and apparently I removed all details on the tablet.
The installation of TWRP was succesful, however all my recent trials to install a CustomRom failed with the following comments:
Updating partition details….
…done
Full SELinux support is present
MTP enabled
Installing zip file `/sdcard1/lineage-16.0-20181203_161503-Unofficial-gts210velte.zip`
Checking for digest file...
Updater process ended with ERROR: 7
Error installing zip file `/sdcard1/lineage-16.0-20181203_161503-Unofficial-gts210velte.zip`
Updating partition details…
…done
installing zip file `/ sdcard1/lineage-16.0-20181203_161503-Unofficial-gts210velte.zip`
Checking for digest file...
Warning: No file_contexts
Comparing TZ version TZ.BF.3.0.3-00054 to TZ.BF.3.0.3-00077
Comparing TZ version TZ.BF.3.0.3-00064 to TZ.BF.3.0.3-00077
Comparing TZ version TZ.BF.3.0.3-00067 to TZ.BF.3.0.3-00077
Comparing TZ version TZ.BF.3.0.3-00071 to TZ.BF.3.0.3-00077
assert failed: samsung.verify_trustzone ("TZ.BF.3.0.3-00054", "TZ.BF.3.0.3-00044",
"TZ.BF.3.0.3-00067", "TZ.BF.3.0.3-00071") == "1"
Updater process ended with ERROR: 7
Error installing zip file `/sdcard1/lineage-16.0-20181203_161503-Unofficial-gts210velte.zip`
Updating partition details…
… done
I have done this trial with various TWRP and Lineage varieties but in vain and always with the identical error.
The only thing I could do was via TWRP the installation of “SMT819_Deodex_Debloated Custom Rom” (based on Stock-Samsung-Firmware.
I have also tried via Odin (several versions) to apply the original firmware. The installation proceeds without error, the tablet starts,
the progress is shown on the blue screen and every time it is cancelled after 25 % and 32%. Then the tab shuts down and starts again and remains in a continous loop with the splash screen.
Well, what is the reason to install a ... REALLY REALLY OLD version like this?
Try this https://lineageos.wickenberg.nu/gts210velte/ or that https://drive.google.com/drive/folders/1VsHc9-k4LA3-n19dp6Gkvqwf0GZLTRcA depending on what you want to have, LOS 16 or 17.1
I am trying to flash an Android 12 GSI onto my Samsung Galaxy Tab Active3. Goal is to install the GSI without root / voiding the warranty. My company produces an app which is primarily used on Android on Galaxy Tab Active devices. It's expected Galaxy Tab Active3 will get Android 12 update in the next few months and we wanted to do some regression testing in advance of that. Hence the need to get Android 12 GSI onto the Tab Active3.
Device is an arm64 so I downloaded the arm64+gms version of Android 12 GSI (from Google's website). I have successfully unlocked the bootloader, and enabled DSU support. The device supports Project Treble and the VNDK isolated namespace, so in theory should support GSIs.
Everything I tried so far has failed. Any ideas to get it working?
Manual DSU
I have tried to install the GSI by manually starting the DSU via activity manager ("am start-activity -n com.android.dynsystem/com.android.dynsystem.VerificationActivity..." etc). Every time it just says "Installation failed" after reaching about 50% progress. I have tried setting different sizes for the USERDATA: 8GB (Google's recommended size), 2GB and 1GB. I get the same error every time. The device has around 40GB free space and the GSI image size is around 2GB (1GB gzipped), so it shouldn't be anything to do with the space requirements.
Logcat reports an error:
11-11 13:10:09.620 1103 3695 I DynamicSystemService: Failed to install system
11-11 13:10:09.621 16445 23403 E InstallationAsyncTask: java.io.IOException: Failed to start installation with requested size: 1257738436
This doesn't help unfortunately; it is thrown from the following file and this is just thrown if there is any error in the underlying dynamic installation:
packages/DynamicSystemInstallationService/src/com/android/dynsystem/InstallationAsyncTask.java - platform/frameworks/base - Git at Google
PS: Unfortunately the device does not support DSU Loader even though it's running Android 11 (searching for "dsu" in the settings returns no relevant results). Apparently none of the Samsung devices are supporting DSU Loader.
Fastboot / FastbootD
The device can be rebooted into fastboot mode ("adb reboot bootloader") but every command just hangs forever (except for "fastboot devices", which does detect the device). I tried "fastboot reboot fastboot", but it just reboots into the standard mode of the device and does not enter a fastboot userspace mode (fastbootd mode) as some have suggested it should.
Heimdall
At least one person has said they can patch GSIs using Heimdall: https://forum.xda-developers.com/t/can-i-flash-gsi-roms-with-odin.4029921/
That person was able to flash their GSI to the SYSTEM partition, but my device doesn't have a SYSTEM partition. The partitions are like SUPER, PRISM, etc.
I'm not able to get Heimdall working properly on Windows 10. I have tried with WinUSB, libusb0 and libusbK, but the same is true for all of them. After rebooting the device into ODIN mode, the device can be detected with "heimdall detect", but I can't do anything more including "heimdall print-pit", as I get a "Failed to access device. libusb error: -12" error.
I managed to set up Heimdall on an Ubuntu instance of WSL and map the USB using USBIPD. Inside WSL, "heimdall print-pit" does work but I can't get further to flashing anything (I tried to flash the GSI to SUPER, not sure if this was a good idea but anyway it failed) as I get a "Protocol initialisation failed!" error.
Odin
I am not sure if Odin itself even supports GSIs and I can't find anyone saying it supports them. I have tried flashing the GSI as an AP in Odin 3.12, 3.13, 3.14 and the patched 3.14 which removes signature checks. But every time it just fails.
Custom recovery
Just to also note, it seems none of the custom recoveries (TWRP, SHRP, Orangefox etc) support the Tab Active3, or I could have tried to flash those using Heimdall/Odin and then use them to flash the GSI. But I feel it's likely I would have had the same issues, at least with Heimdall.
you need custom recovery with dynamic partition support
aIecxs said:
you need custom recovery with dynamic partition support
Click to expand...
Click to collapse
as I mentioned, I couldn't find any custom recovery which supports my device...
Also, if I did have say TWRP or LOS recovery for my device, it seems I could run fastboot through the custom recovery (fastbootd). Then I assume I could just flash GSI using instructions like these: https://forum.xda-developers.com/t/...devices-with-dynamic-super-partition.4256667/
But it's a moot point because no such custom recovery exists for my device. There are custom recoveries for Tab Active 1 and 2, but not 3. So I'm trying to see what I can do with Heimdall
Also, quote from the above-linked thread in response to someone who asked about flashing using TWRP:
kusti420 said:
you can only do it in twrp if you rebuild the whole super partition with the gsi of your choice and flash that
Click to expand...
Click to collapse
if someone could tell me how to "rebuild the whole super partition with the gsi of your choice", that may help. because if I could convert gsi to super partition and if I could get Heimdall working (e.g. using native Linux version off a live USB or whatever), then I could use Heimdall to flash SUPER (in theory)
On that note, I found a couple of possible leads:
(1) https://forum.xda-developers.com/t/...r-img-and-flashing-our-modifications.4196625/ - shows how to unpack and re-pack super image using lpunpack and lpmake. I am wondering if I could use this to replace the system.img in my existing super partition with the one from GSI. But how to get the vendor.img and product.img? I don't think Heimdall has any command to backup existing partitions from a device
(2) https://source.android.com/devices/tech/ota/dynamic_partitions/implement#factory-images - it suggests that you can use "make dist" to build super.img, but I'm not sure if this requires me to completely rebuild AOSP from source or I can do it from existing system.img (i.e. GSI)
super_image_dumper
regarding build TWRP from source there are helpful users here
I ran Heimdall on native Linux rather than on WSL or the Windows version. This worked better and fixed the issues I was having before with Heimdall.
I then tried to flash VBMETA (the one bundled with the GSI) using Heimdall which worked, however my device was then soft-bricked, could only boot into Download Mode, and gave the following error:
ODIN MODE (AVB fail)
vbmeta: Public key used to sign data rejected. (5)
vbmeta: VERIFICATION_DISABLED bit is set.
CUSTOM VBMETA
VBMETA : No sign info
VBMETA ,
I also tried a VBMETA from avbtool, which gave a very similar error on boot:
ODIN MODE (AVB fail)
vbmeta: Error verifying vbmeta image: OK_NOT_SIGNED (3)
vbmeta: VERIFICATION_DISABLED bit is set.
CUSTOM VBMETA
VBMETA : No sign info
VBMETA ,
I managed to restore my stock vbmeta by extracting it from the stock ROM and installing using Heimdall, so my device can boot again, but it's back to vbmeta with verification enabled. How can I resolve this?
I tried to run lpmake, but I don't know my super partition size ("--device super:...") I thought it might be the partition block count from the PIT. but that is 1740800 for SUPER, whereas my system.img has size 2752909312, so surely it doesn't fit inside?
Got it fixed eventually (i.e. I am now able to run the GSI on Samsung Galaxy Tab Active3). I had made a really stupid error when running the DSU command. For KEY_SYSTEM_SIZE I was passing the gzipped system size, not original system image size. This is why the installation always failed after 50%, because it was only installing 50% of the system image. Also another really important thing to note is that after running DSU, you have to restart the system from the DSU notification and not from the normal power menu of the device.
In addition, I did flash "vbmeta_samsung.img" but I'm not sure if this was strictly necessary or not (I happened to notice that vbmeta_samsung.img has the same file size as the vbmeta disable images - 4KB vs 10KB for stock vbmeta). I'm going to be trying to help one of my colleagues to follow the same process, probably in the next few days, so will hopefully be able to report back on whether this flash is strictly necessary.
Also, I found that both Heimdall on native Linux and Heimdall on WSL actually suffer from the same problem. You can only post one command to the device, then subsequent commands fail with "protocol initialisation failed". On WSL I was doing things like "heimdall print-pit --no-reboot" and that's why I was facing issues when flashing. Basically, if you get protocol initialisation failed, just reboot the device and it should work.
ajbcc said:
I tried to run lpmake, but I don't know my super partition size ("--device super:...") I thought it might be the partition block count from the PIT. but that is 1740800 for SUPER, whereas my system.img has size 2752909312, so surely it doesn't fit inside?
Click to expand...
Click to collapse
stumbled across this post
https://forum.xda-developers.com/showpost.php?p=82241115&postcount=70
edit: bytes = block count × block size
aIecxs said:
stumbled across this post
https://forum.xda-developers.com/showpost.php?p=82241115&postcount=70
edit: bytes = block count × block size
Click to expand...
Click to collapse
Thanks for pointing this out, but this doesn't help me unfortunately. The number I'm trying to calculate here is the number 4294967296 in that post, which is the one number the guide doesn't explain how to calculate. Also, the PIT doesn't give my block size, only the "block size/offset". This seems to be just a plain offset, as it increases for every partition, even the small ones. So I have no idea what my block size is.
Just ran through the install steps with one of my colleagues (also with Samsung Galaxy Tab Active3) and there was no need to disable AVB as part of the process. We managed to get through with just the vanilla steps from Google. So all that stuff about "vbmeta_samsung.img" was just a red herring.
This is not actually a question but rather an answer to this "question" you may need help with, when trying to flash the April 2023 factory image for your Pixel 5. Also, this info can be something to keep in mind for future reference.
The answer is to use Platform Tools version 33.0.3
https://dl.google.com/android/repository/platform-tools_r33.0.3-windows.zip
(You can also edit the number in the link to obtain other versions).
For some reason, version 34 or newer is broken for the April factory image flashing.