Develop Bugs

stupid dev questions

so...i'm behide the curve on on this hero stuff (being a rom cook for the s200 i'm not complete clueless...but thats winmo)
Anyway i'm playing around and would love an answer on these from one of the resident dev's on here
1. i took boot.img from the RUU rom.zip of wwe 2.73.405.61, took the system.img, did the magic to create an update.zip, which seems to flash fine from a recovery rom BUT on reboot it's stuck on the Hero boot screen/logo, any clue as to where to look/debug (yes I did the wipe etc. etc. it must be something about the update.zip / boot.img i'm missing)
2. i assume there is still no way to re-sign the a changed RUU rom.zip ?
Thanks for your time !

1: extract the system with unyaffs
2: zip the contents of the extracted system
3: sign the resulting zip (androsign or whatever)
boot into recovery
4: copy over to sdcard
5: copy over boot.img also to sdcard
6: cat /dev/zero > /dev/mtd/mtd2
or
dd if=/dev/zero of=/dev/mtd/mtd2
whichever you prefer
7: flash_image boot /sdcard/boot.img
8: flash your update.zip or whatever you called it
9: wipe system (format DATA: & CACHE
OR
flash_image system system.img (might not work)

adwinp said:
1: extract the system with unyaffs
2: zip the contents of the extracted system
3: sign the resulting zip (androsign or whatever)
boot into recovery
4: copy over to sdcard
5: copy over boot.img also to sdcard
6: cat /dev/zero > /dev/mtd/mtd2
or
dd if=/dev/zero of=/dev/mtd/mtd2
whichever you prefer
7: flash_image boot /sdcard/boot.img
8: flash your update.zip or whatever you called it
9: wipe system (format DATA: & CACHE
OR
flash_image system system.img (might not work)
Click to expand...
Click to collapse
Thanks, i got that far, but rolling the whole thing (so boot.img + extracted system.img) into update.zip and flashing that from a recovery image is where it goes all tits up and doesn't boot, even tried without any changes and just taking the boot.img and system.img from a offical htc rom and creating an update.zip
so i must be doing something wrong but can't put my finger where it goes wrong.
anycase, i'll keep trying
thx

1: Did you sign your update.zip?
2: An update.zip usually contains an update script; did you write one too?
This is why I suggested you flash manually.

adwinp said:
1: Did you sign your update.zip?
2: An update.zip usually contains an update script; did you write one too?
This is why I suggested you flash manually.
Click to expand...
Click to collapse
both answers yes
still digging, but it could be that "something" in the update script isn't working, however i've copied one from a working rom, with the same results...
going through the script now....i'm sure it's something stupid and i'll smack my head later, but for now no go......thanks for your tips and time !
Edit:
is there something special you need to do with the boot.img if you just copy (unzip thats it) from a rom.zip and put it in the update.zip ??

Jesterz said:
Edit:
is there something special you need to do with the boot.img if you just copy (unzip thats it) from a rom.zip and put it in the update.zip ??
Click to expand...
Click to collapse
Either you push it to sdcard and
#flash_image boot /sdcard/boot.img
or
in the update.zip:
META-INF\com\google\android\update-script
where META-INF is a folder in the root, and update-script is a text file without file extension; its contents should be:
show_progress 0.1 0
write_raw_image PACKAGE:boot.img BOOT:
show_progress 0.1 10
So, the contents should be:
\META-INF\
com\
google\
android\update-script
\boot.img
zip all that into update.zip, and sign the zip.

trying to change my gps.pref file

How can I do this?
Can I somehow extract the whole /system and change the file, make it an img file and fastboot it back to the desire?

deswong said:
How can I do this?
Can I somehow extract the whole /system and change the file, make it an img file and fastboot it back to the desire?
Click to expand...
Click to collapse
if you have root, you can extract the file and push it back through Recovery
adb shell mount /system
adb push gps.pref /system/[place of gps.pref]

ext4 extraction from system.sin issues

Hi,
As you probably know, ext4 image can be extracted from system.sin but cannot be mounted. When trying to mount it, it fails with :
[ 1476.821582] EXT4-fs (loop0): bad geometry: block count 262144 exceeds size of device (144631 blocks)
I open this thread just to share what I did around the issue and maybe have some helpful quotes about it
Here is what I did (under linux)
# First create an zero filled file. Size is system partition size (262144 blocks of 4096 each)
dd if=/dev/zero of=/home/xperia/virtualfs bs=4096 count=262144
# Attach file to loopback
sudo losetup /dev/loop0 /home/xperia/virtualfs
# Format it with same features as system partition on phone
sudo mkfs.ext4 -O has_journal,^ext_attr,^dir_index,^flex_bg,^huge_file,resize_inode,filetype,extent,sparse_super,large_file,^uninit_bg,^dir_nlink,^extra_isize -v /dev/loop0
# Write extracted system.sin.ext4 extracted image to loopback
sudo dd if=system.sin.ext4 of=/dev/loop0
# Mount filesystem
sudo mount /dev/loop0 /mnt
It can be mounted and I can have folder structure but I can't work with files. Editing default.prop gives me a non readable file.
But we can go a step ahead as we can now mount the image.
Still some issues have to be worked out.

The poit is, why we cant mount system.img on ICS but we can on GB?
maybe someone can contact with sony t oask
im extracting the .sin to .img like always but its impossible to mount.. what are you using to extract the .sin to a .ext4?
BTW, thanks for the info, i've been trying to modify system.img since ICS appeared.
EDIT: of, ext4 can be extracte with flashtool ~.~
maybe we need to read something from system.partinfo

Yakandu said:
The poit is, why we cant mount system.img on ICS but we can on GB?
maybe someone can contact with sony t oask
im extracting the .sin to .img like always but its impossible to mount.. what are you using to extract the .sin to a .ext4?
BTW, thanks for the info, i've been trying to modify system.img since ICS appeared.
EDIT: of, ext4 can be extracte with flashtool ~.~
maybe we need to read something from system.partinfo
Click to expand...
Click to collapse
Yes Flashtool can extract image from system.sin.
partinfo is partition information used by loader in flashmode to identify where to flash image on phone. (Something like start nand address of system partition)

so, any ideas why ext4 cant be mounted? maybe its encrypted or something..

Sorry for double post, i found a solution
Flash the system through a .ftf with flashtools
Flash a custom kernel with recovery (or the nozomi recovery)
Backup nandroid
We get a system.ext4.tar ··· move it to your developement folder
Create a folder (mkdir system)
Enter nautilus with root acces
Extract system files to the created folder
Modify whatever you want
Make a flashable system.img with: "./mkuserimg.sh -s /system ./system.img ext4 ./temp 1024M"
AND ITS WORKING!

Yakandu said:
Sorry for double post, i found a solution
Flash the system through a .ftf with flashtools
Flash a custom kernel with recovery (or the nozomi recovery)
Backup nandroid
We get a system.ext4.tar ··· move it to your developement folder
Create a folder (mkdir system)
Enter nautilus with root acces
Extract system files to the created folder
Modify whatever you want
Make a flashable system.img with: "./mkuserimg.sh -s /system ./system.img ext4 ./temp 1024M"
AND ITS WORKING!
Click to expand...
Click to collapse
This solution is already known
But my goal is to be able to mod a system partition without having to flash it before. And more, understand why extracted system image cannot be mounted and how to work this out

oh, ok xD
i didnt know that solution, its new for me

Yakandu said:
Sorry for double post, i found a solution
Flash the system through a .ftf with flashtools
Flash a custom kernel with recovery (or the nozomi recovery)
Backup nandroid
We get a system.ext4.tar ··· move it to your developement folder
Create a folder (mkdir system)
Enter nautilus with root acces
Extract system files to the created folder
Modify whatever you want
Make a flashable system.img with: "./mkuserimg.sh -s /system ./system.img ext4 ./temp 1024M"
AND ITS WORKING!
Click to expand...
Click to collapse
Have you already tried flashing this img on your device? I have already tried this solution twice but didn't succeed (@Spectre51 that's why I haven't replied your PM yet). system.img was succesfully created but I got boot loop when I flashed it on my device.

Hi Androxyde,
I figured it out, basically we have to dig further in sin format as new ext4 sins skips part of the file. See my thread for more details.
PS: Thanks for flashtool, it's a great tool!
LeTama

letama said:
Hi Androxyde,
I figured it out, basically we have to dig further in sin format as new ext4 sins skips part of the file. See my thread for more details.
PS: Thanks for flashtool, it's a great tool!
LeTama
Click to expand...
Click to collapse
:good:

Marshmallow prerooted, unsecured boot.img

Because Motorola uses squashfs read-only filesystem on /system partition, we need to use systemless rooting procedure. Default SuperSU zip doesn't work with our device, because of incompatible partition table so I prepared it for us. It has also set ro.secure=0 and enabled adb at boot. You can flash it using fastboot for example or TWRP. Extract zip first.
Code:
fastboot flash boot <path to boot.img>

Hello. I have flashed it to my moto360 and nothing changed. no su available after boot

Small Utilities for Realme C12

Here I will share some of the zips/scripts I made for some specific things
You are only responsible for what you do to your things. You have been warned.​
Flash GSI in TWRP​As we all know from Android 10, Google introduced dynamic partitions. That is system, vendor, product and other partitions are now contain in single partition called *super*. The logical partitions in this super partition are resizable according to requirements.
We can flash GSI to system partition with `dd if=gsi.img of=/dev/block/mapper/system bs=10M`.
But it will fail if the size of partition is less than size of GSI. To increase the size, there is no normal way to resize in TWRP I know as of now.
To resize it to have more space, I used the trick that is used by custom ROMs. I made system.new.dat.br, system.transfer.list, system.patch.dat as empty and used dynamic_partitions_op_list to resize system.
We can do the same with `fastbootd` with `fastboot resize-logical-partition system <size-in-bytes>`, but it requires PC.
Usage:-
- Download below GSI_FLASHER.zip
- Place GSI.img/xz and the downloaded zip in same folder
- Flash the zip
- Wipe Dalvik, Data, Internal and Cache
- Reboot
Resize System​When we want to flash GApps in vanilla GSI that is flashed with fastbootd, it will resize system to the size of GSI keeping no space left to add something. So I used the same above trick to resize system for making space in it.
We can do the same with `fastbootd` with `fastboot resize-logical-partition system <size-in-bytes>`, but it requires PC.
Usage:-
- Download below SystemResizer_RealmeC12.zip
- Flash the zip before flashing GApps
- Enjoy
Custom Recovery Keep​When in Realme UI, if any recovery than stock recovery is detected then it will replace it with the stock recovery using /vendor/recovery-from-boot.p file. On every boot, /vendor/bin/oppo-install-recovery.sh is executed in UI 1.0 and /vendor/bin/install-recovery.sh is executed in UI 2.0. It will patch recovery. So replacing it will stop this process.
Usage:-
- Download below RealmeRecoveryKeep.zip for UI1 or RealmeRecoveryKeepUI2.zip for UI2
- Flash it in Magisk app as Magisk module
- Flash custom recovery
- Enjoy persistent recovery
Reference:- https://forum.xda-developers.com/t/...m-howto-downgrade-howto.4014773/post-81108309
Flash Stock ROM .ozip in TWRP​Note:- Realme C12 TWRP has 'Skip Treble Compatibility error' option in Settings. So no need of this.
When we flash a .ozip in TWRP by renaming it to .zip(since it is not encrypted), we will get Treble Compatibility error. It is because of compatibility.zip in the .ozip. If we remove it, then flashing will be fine.
But if we flash manually by executing update-binary with .ozip as argument, TWRP will not do any checks. So we can flash without removing compatibility.zip in .ozip.
Usage:-
- Download below Flash_OZIP_in_TWRP.zip
- Place .ozip and the downloaded zip in same folder
- Flash the zip(not .ozip)
- Enjoy
Sparse Data To Super Partition converter​Realme is not providing flashtool or fastboot flashable firmwares. So only .ozip is the solution for us. It has all the .img files that can be flashed with fastboot except super.img.
To get this, we have to dump the super partition from device or convert .dat.br files to raw images and join them as super partition with `lpmake` tool.
I made a Shell Script to automate this.
Usage:-
- Download below sdat2super.zip in your Linux distribution
- Execute sdat2super.sh with path to ozip as argument
bash sdat2super.sh RealmeC12.ozip
- After sometime you will get super.img in same folder as script
Spoiler
Downgrade to UI 1.0 from UI 2.0 with locked bootloader​Download Roll back package from https://c.realme.com/in/post-details/1391964925517193216 and flash in stock recovery and Format Data.
Another method:-
It is possible with SP Flash Tool, but it is somewhat scary for novice. To do this we have a small trick.
Realme recovery has ADB Root access. That is we can execute commands as SuperUser(root). So we can execute update-binary manually for flashing .ozip in stock recovery too.
Usage:-
- Extract META-INF/com/google/android/update-binary from .ozip to somewhere in External SDCard
- Place .ozip to same External SDCard
- Boot to Recovery mode
- See if .ozip is there are not in stock recovery file manager when installing .ozip
- Connect device to PC and run below commands in PC
Code:
adb devices
adb root
adb shell
cp /path/to/update-binary /sbin
chmod 755 /sbin/update-binary
/sbin/update-binary 3 1 /path/to/ozip
exit
- Format Data in recovery
- Enjoy

Thank you very much for your work sir, you're awesome!

Thanks, I will try it soon.

This zip will fix NVRAM Warning Err = 0x10 in WiFi section. Please backup nvdata partition before using this, since it will modify /mnt/vendor/nvdata/APCFG/APRDEB/WIFI to write MAC address taken from /sys/class/net/wlan0/address
Thanks