Related
LAYOUT MAPPING COMPLETE! THANKS EVERYONE!
based on XXJF5 stock 2.1#1
256 KB -- bml1, contain boot.bin (262144 bytes), Primary Boot Loader (low-level hardware initialization)
256 KB -- bml2, contains PIT file first 512 bytes
10240 KB -- bml3 /dev/block/stl3 /efs
1280 KB -- bml4 contain Sbl.bin (1310720 bytes) Secondary Boot Loader (loads the Linux kernel and passes the necessary arguments)
1280KB -- bml5 contains Secondary Boot Loader (for recovery, ect)
5120KB -- bml6 param.lfs /mnt/.lfs j4fs
7680KB -- bml7 contain zImage and initramfs
7680KB -- bml8 empty
293376KB -- bml9 factoryfs.rfs ( /system RFS Partition) /dev/block/stl9
137216KB -- bml10 dbdata.rfs ( /dbdata RFS Partition) /dev/block/stl10
35840KB -- bml11 cache.rfs ( /cache RFS Partition) /dev/block/stl11
12800KB -- bml12 modem.bin
Hello husq510
Thanks for this infos, i'll follow this thread closely because i'm looking for the place where ServiceMode settings are stored.
anyone tried writing to the bml directly?
husq510 said:
bash-3.2# ls -al /dev/block/bml*
1280 KB -- bml4 kernel (zImage)
293376KB -- bml9 factoryfs.rfs ( /system RFS Partition)
Click to expand...
Click to collapse
interesting. so ive dd the bml4 and bml9 of optus australia stock 19000DTJF3. now anyone want to point me in the direction of creating an odin package out of it.
i whoner .... how can bml4 be the zImage? bml4=1.2MB, zImage=5.8MB ?? also if it should just contain the kernel without initram, it's still about 2.6MB? any idea?
jodue said:
i whoner .... how can bml4 be the zImage? bml4=1.2MB, zImage=5.8MB ?? also if it should just contain the kernel without initram, it's still about 2.6MB? any idea?
Click to expand...
Click to collapse
you are right, cant be. then kernel must be in some other bml place, seems bml7.
gandalf:~/Desktop/android/bml ackie$ grep "booting the kernel" *
Binary file bml7.dump matches
gandalf:~/Desktop/android/bml ackie$ hexdump -n 128 bml7.dump | grep "e1a0 0000 e1a0"
0000000 0000 e1a0 0000 e1a0 0000 e1a0 0000 e1a0
0000020 0002 ea00 [2818 016f] [0000 0000] [a510 005b] <- zimage magic number 0x016F2818, start at 0x0, end at 0x005b10a5
0000030 7001 e1a0 8002 e1a0 2000 e10f 0003 e312
0000040 0001 1a00 0017 e3a0 3456 ef12 2000 e10f
0000050 20c0 e382 f002 e121 0000 0000 0000 0000
0000060 00d0 e28f 307e e890 0001 e050 000a 0a00
0000070 5000 e085 6000 e086 c000 e08c 2000 e082
0000080
Offset into zImage Value Description
0x24 0x016F2818 Magic number used to identify this is an ARM Linux zImage
0x28 start address The address the zImage starts at
0x2C end address The address the zImage ends at
so if you start at 0x0 of bml7 and read untill offset inside 0x2c for XXJF5 is 0x005b10a5 you have your zImage.
husq510 said:
so if you start at 0x0 of bml7 and read untill offset inside 0x2c for XXJF5 is 0x005b10a5 you have your zImage.
Click to expand...
Click to collapse
so is it safe to assume after 0x005b10a5 is the ram disk?
Hello Folks.
I found some interesting bits in bml12.
"Service Mode" datas strings are in it, like show these example :
Code:
strings ./bml12 | grep Diamond
[SND] TurnON UtaAudioModifyHf(prev_Diamond_mode:0x%x)
`[SND]DiamondVoice_GetMode : path = 0x%x, Diamond_mode = 0x%x
`[SND]DiamondVoice_GetMode : Diamond_mode = 0x%x
[SND]DiamondVoiceTXcfgMSG
`[SND] DiamondVoice_RxInit : DiamondVoice_Mode_v = 0x%x
Diamond Solution
[9] Diamond Solution
[SND]DiamondVoice_Config : DiamondVoice_Mode_v = 0x%x, Diamond_mode= 0x%x
strings ./bml12 | grep DEBUG
MN_GPS_DEBUG_INFO_CNF
GPS_DEBUG_INFO_CNF
[1] DEBUG SCREEN
[2] DEBUG INFO
DEBUG INFO
DEBUG MSG 115200
DEBUG MSG SETTING FAIL
DEBUG MSG 921600
DEBUG MSG ON
DEBUG MSG OFF
AUDIO_LIB_DSP_DEBUG_GRP1
AUDIO_LIB_DSP_DEBUG_GRP2
AUDIO_LIB_DSP_DEBUG_GRP3
AUDIO_LIB_DSP_DEBUG_GRP4
AUDIO_LIB_DSP_DEBUG_GRP5
AUD_LIB_DSP_DEBUG
IPC_MISC_PHONE_DEBUG
IPC_MISC_DEBUG_LEVEL
IPC_SVC_DEBUG_DUMP
IPC_SVC_DEBUG_STRING
And I found my IMEI number in bml3
edit :
+ some MAC hardware address too (but not the Wifi one)
+ the HW Version : MP 0.800
I guess that bml3 is device-specific.
But I don't know if it's the source of specific values or just contains copy of hardware-related data.
In the first case, modifying bml3 would allow to change IMEI or other sensitive values ^^
nonato said:
so is it safe to assume after 0x005b10a5 is the ram disk?
Click to expand...
Click to collapse
nope, to extract the ram disk, u hv to find the magic number of gz and extract the gzip image out... i was able to get the directory listing of the ramdisk but not the content..
the other problem is after u get the ramdisk and do any modifications, u hv to reverse the process.. not an easy job but if anyone found a solution, please share.
anyone try writing to the bml directly? dd doesnt seem to work
anyway, its possible to extract the image and use odin to flash after tar but if can write to bml directly, clockworkmod can effectively backup/restore the kernel.. (just a thought)
raspdeep said:
nope, to extract the ram disk, u hv to find the magic number of gz and extract the gzip image out... i was able to get the directory listing of the ramdisk but not the content..
the other problem is after u get the ramdisk and do any modifications, u hv to reverse the process.. not an easy job but if anyone found a solution, please share.
anyone try writing to the bml directly? dd doesnt seem to work
anyway, its possible to extract the image and use odin to flash after tar but if can write to bml directly, clockworkmod can effectively backup/restore the kernel.. (just a thought)
Click to expand...
Click to collapse
No, you cant write directly to bml.
Data write to a sector involves following sequence of low-level flash operations:
1. Block copy for back-up
2. Block erase
3. Copy back for non-modified pages
4. Writing the sector data to the modified page
These sequences of operations are not atomic, so a write request to this block device driver is prone to data corruption. For this reason, read-only file systems such as CRAMFS are adequate to run on top of this block device driver.
use this small script to extract your current zImage:
offset=`dd if=/dev/block/bml7 bs=1 skip=44 count=4 2>/dev/null| hexdump -e '1/4 "%d"' -e '"\n"'`
echo $offset
dd if=/dev/block/bml7 bs=1 count=$offset of=/sdcard/zImage_backup
husq510 said:
use this small script to extract your current zImage:
Click to expand...
Click to collapse
nice, thanks for sharing that!
i just extracted initramfs from bml7, file attached, unzip and cpio -i
some file differs from leshak:
modules/dpram.ko
modules/multipdp.ko
modules/dhd.ko
modules/stgloc
initramfs/init.rc
.info/rootfs.info
default.prop
init.smdkc110.sh
sbin/recovery
sbin/init
how do u extract this?
gunzip -c initrd-cpio.zip | cpio -i does not work.. gave errors
how did you dump and make the zip file you have attached?
thanks,
husq510 said:
i just extracted initramfs from bml7, file attached, unzip and cpio -i
some file differs from leshak:
modules/dpram.ko
modules/multipdp.ko
modules/dhd.ko
modules/stgloc
initramfs/init.rc
.info/rootfs.info
default.prop
init.smdkc110.sh
sbin/recovery
sbin/init
Click to expand...
Click to collapse
raspdeep said:
how do u extract this?
gunzip -c initrd-cpio.zip | cpio -i does not work.. gave errors
Click to expand...
Click to collapse
[email protected] you have to use unzip instead gzip, cuz forum dislike .gz format, so I had to use standard zip.
mkdir initramfs
mv initrd-cpio.zip initramfs
cd initramfs
unzip initrd-cpio.zio
cat initrd.cpio | cpio -i --no-absolute-filenames
Hey, did somebody already tried to dump one or some bml partitions and restore them later ?
I guess this could be the ultimate backup tool.
I took a look into this and found that
bml2 : PIT file is here
bml5 : Sbl.bin is here
I opened it with a Hexeditor and compared with things from the firmware.
My device is running on JP3, froyo, at the moment.
thanks i will update first post. layout mapping is complete now!
Extracting the N2 root filesystem and adding rc.local
These instructions assume using a linux console.
The root filesystem lives in a u-boot/PPCboot ramdisk. These instructions tell you how to extract it.
Boot your nt with the "rooted forever" sdcard while connected with usb.
Make a copy of the boot partition. After this you may reboot your nt normally.
$ tar -cf boot.tar boot/
$ tar xvf boot.tar
$ cd boot
Extract the uRamdisk file. first 64 bytes is the u-boot header, we need to skip it.
$ dd if=URamdisk bs=64 skip=1 of=ramdisk.gz
ramdisk.gz now contains the root file system.
Copy ramdisk.gz to a work directory, then extract it:
gunzip -v ramdisk.gz
cpio -iv < ramdisk
The root file system will populate your work dir. Delete the ramdisk file. You can now make changes to the root file system.
The change I'm going to make is a simple one: adding the ability to run an rc.local file at boot.
edit the init.rc file in your work directory, adding at the bottom:
Code:
service rclocal /etc/rc.local
enabled
user root
oneshot
rebuilding the uRamdisk file is simple, once you know how (thanks to JesusFreke for pointing me in the right direction). cd into your working directory, issue these commands:
Code:
find . -regex "./.*"| cpio -ov -H newc | gzip > ../ramdisk.gz
mkimage -A ARM -T RAMDisk -n Image -d ../ramdisk.gz ../uRamdisk
A script with the the commands above is attached. Also attached is a rooted uRamdisk with the rc.local ability already build in. To replace the uRamdisk file, boot with your "Rooted Forever" sdcard, and copy the uRamdisk file to the nook's boot directory.
What's this good for? That's up to you. I'm using it to automatically start dropbear so I can ssh in my Nooks and also use rsync to keep them synced with my ebook library. This is also one of the steps in building a kernel for the Nook ST.
jocala said:
Extracting the N2 root filesystem and adding rc.local
These instructions assume using a linux console.
The root filesystem lives in a u-boot/PPCboot ramdisk. These instructions tell you how to extract it.
Boot your nt with the "rooted forever" sdcard while connected with usb.
Make a copy of the boot partition. After this you may reboot your nt normally.
$ tar -cf boot.tar boot/
$ tar xvf boot.tar
$ cd boot
Extract the uRamdisk file. first 64 bytes is the u-boot header, we need to skip it.
$ dd if=URamdisk bs=64 skip=1 of=ramdisk.gz
ramdisk.gz now contains the root file system.
Copy ramdisk.gz to a work directory, then extract it:
gunzip -v ramdisk.gz
cpio -iv < ramdisk
The root file system will populate your work dir. Delete the ramdisk file. You can now make changes to the root file system.
The change I'm going to make is a simple one: adding the ability to run an rc.local file at boot.
edit the init.rc file in your work directory, adding at the bottom:
Code:
service rclocal /etc/rc.local
enabled
user root
oneshot
rebuilding the uRamdisk file is simple, once you know how (thanks to JesusFreke for pointing me in the right direction). cd into your working directory, issue these commands:
Code:
find . -regex "./.*"| cpio -ov -H newc | gzip > ../ramdisk.gz
mkimage -A ARM -T RAMDisk -n Image -d ../ramdisk.gz ../uRamdisk
A script with the the commands above is attached. Also attached is a rooted uRamdisk with the rc.local ability already build in. To replace the uRamdisk file, boot with your "Rooted Forever" sdcard, and copy the uRamdisk file to the nook's boot directory.
What's this good for? That's up to you. I'm using it to automatically start dropbear so I can ssh in my Nooks and also use rsync to keep them synced with my ebook library. This is also one of the steps in building a kernel for the Nook ST.
Click to expand...
Click to collapse
dd if=URamdisk bs=64 skip=1 of=ramdisk.gz
Click to expand...
Click to collapse
"uRamdisk" instead of "URamdisk"
Thanks again.
Hi guys,
All is in the question, i'm currently ussing doomkernel but i'm a bit bored of the splash 1. That's why i'd like to know if it' possible ( i guess yes of course ) and how can i do that ?
thank's
the first splash from the kernel the second from the rom at "/system/media/bootanimation.zip"
I am talking about splash 1 (bootanimation is not a problem), is there a way to change it via fastboot like for my htc or do I have to modify .img (and how?)
thi3um said:
I am talking about splash 1 (bootanimation is not a problem), is there a way to change it via fastboot like for my htc or do I have to modify .img (and how?)
Click to expand...
Click to collapse
you have to change the kernel see [Tut] Building your own Xperia Play Kernel
paxChristos said:
16) Getting the ramdisk
F1) Download a working copy of FXP's kernel (either through my zips or fxp zips)
F2) Goto here: http://forum.xda-developers.com/showthread.php?t=1477845, download the xperiaboottools.zip that's attached.
F3) Now what I did (you don't have to) is chmod 755 mkbootimg & split_bootimg.pl & (sudo) cp to /bin for easy calling.
F4) Navagiate in terminal to where you downloaded fxp kernel
F5) mkdir <working_folder>
F6) cp <fxp_kernel> <working_folder>
F7) cd <working folder>
F8) split_bootimg.pl <fxp_kernel>
F9) mkdir ramdisk
F10) cd ramdisk
F11) gzip -dc ../<fxp_kernel>.img-ramdisk.gz | cpio -i
F12) Now you have the ramdisk, let's futz with it.
F13) First (easiest step) is to goto default.prop & change ro.secure=1 to ro.secure=0
F14) That's mainly what we want to do with it, if you want to change the boot image, go here: http://forum.xda-developers.com/showthread.php?t=1494076 for how to do it manually, or here: http://forum.xda-developers.com/showthread.php?t=1513146 for the automatic way.
F15) now that we're done with the ramdisk, we'll go back to terminal
F16) find . | cpio -o -H newc | gzip > ../ramdisk.img
F17) cd ../
Click to expand...
Click to collapse
Has anyone installed self signed ROMs using the method described in this blog http://mjg59.dreamwidth.org/31765.html? The goal is to install a self signed image that allows you to only install images signed by a key you generate yourself to avoid the giant security hole caused by custom recoveries that don't check signatures.
Here's the overview :
First: Unlock your bootloader. /data will be wiped.
Second: Get a copy of the stock recovery.img for your device.
Third: Grab mkbootimg from here and build it. Run unpackbootimg against recovery.img.
Fourth: Generate some keys. Get this script and run it.
Fifth: zcat recovery.img-ramdisk.gz | cpio -id to extract your recovery image ramdisk. Do this in an otherwise empty directory.
Sixth: Get DumpPublicKey.java from here and run it against the .x509.pem file generated in step 4. Replace /res/keys from the recover image ramdisk with the output. Include the "v2" bit at the beginning.
Seventh: Repack the ramdisk image (find . | cpio -o -H newc | gzip > ../recovery.img-ramdisk.gz) and rebuild recovery.img with mkbootimg.
Eighth: Write the new recovery image to your device
Ninth: Get signapk from here and build it. Run it against the ROM you want to sign, using the keys you generated earlier. Make sure you use the -w option to sign the whole zip rather than signing individual files.
Tenth: Relock your bootloader
Eleventh: Boot into recovery mode and sideload your newly signed image.
Click to expand...
Click to collapse
I have the 8" Tab (SM-T310) and want to try it. Anyone know if there's an official source of stock recovery images? I have the 4.4.2 update.zip from an OTA update I never installed (my tablet's still on stock 4.2.2), can the recovery somehow be extracted from that? Since I'm still on 4.2.2, I don't need to unlock the bootloader, right? Can I use Heimdall to put the new recovery on the tab?
Here's my step by step if anyone else is crazy enough to try this.
First: Unlock your bootloader. /data will be wiped.
Click to expand...
Click to collapse
Skipped so far, running 4.2.2 which from what I've been reading I think isn't locked.
Second: Get a copy of the stock recovery.img for your device.
Click to expand...
Click to collapse
Grabbed the update from Kies (on Windows VM):
Agreed to Kies update when I plugged in the tablet.
Watched my temp folder (from windows search bar enter %temp%) until tmp*.tmp.zipfolder showed up (wait for tmp*.tmp file to download and get converted to a zip, then it unzips into zipfolder automatically), unplugged the tablet immediately as it booted into download mode, copied tmp*.tmp.zipfolder somewhere else (desktop) before Kies cancelled the update process and deleted the temp files.
Third: Grab mkbootimg from here and build it. Run unpackbootimg against recovery.img.
Click to expand...
Click to collapse
Source is on github: osm0sis/mkbootimg From here on I'm using linux.
cd into mkbootimg folder and run "make"
run
Code:
./unpackbootimg -i recovery.img -o rec
(rec is the folder I unpacked to, make the folder first or it'll segfault)
Fourth: Generate some keys. Get this script and run it.
Click to expand...
Click to collapse
Saved script (posted below, can't post links yet...) to "make_key.sh", then
Code:
chmod +x make_key.sh
to make it executable.
Ran script, usage: /make_key.sh <name> <subject> [<keytype>]
subject must be in the format "/C=GB/ST=London/L=London/O=Global Security/OU=IT Department/CN=example.com" (look up "Create CSR using OpenSSL Without Prompt (Non-Interactive)" for what all that means)
Fifth: zcat recovery.img-ramdisk.gz | cpio -id to extract your recovery image ramdisk. Do this in an otherwise empty directory.
Click to expand...
Click to collapse
Make a directory, cd into it, run
Code:
zcat recovery.img-ramdisk.gz | cpio -id
with recovery.img-ramdisk.gz pointing to where your file is (mine was ../recovery.img-ramdisk.gz).
Sixth: Get DumpPublicKey.java from here and run it against the .x509.pem file generated in step 4. Replace /res/keys from the recover image ramdisk with the output. Include the "v2" bit at the beginning.
Click to expand...
Click to collapse
Not sure why he's using a different DumpPublicKey.java than the one that's in the mkbootimg git... but it's in the "libmincrypt/tools/DumpPublicKey.java" that was in the mkbootimg git, I didn't see any differences using diff.
Running
Code:
javac DumpPublicKey.java
tells me I need BouncyCastleProvider. And now I'm stuck.
Downloaded the Bouncy Castle jar and put it in the same folder as DumpPublicKey.java and ran
Code:
javac -cp bcprov-jdk15on-152.jar DumpPublicKey.java
echo "Main-Class: DumpPublicKey" > manifest.txt
jar cvfm DumpPublicKey.jar manifest.txt DumpPublicKey.java
Then running
Code:
java com.android.dumpkey.DumpPublicKey
gave me various class not found errors and I ended up with a file structure like this trying to make it find the bouncy castle. Annnnnd I'm stuck.
.
├── bcprov-jdk15on-152.jar
├── com
│** └── android
│**** └── dumpkey
│****** ├── bcprov-jdk15on-152.jar
│****** ├── DumpPublicKey.class
│****** ├── DumpPublicKey.jar
│****** ├── DumpPublicKey.java
│****** └── manifest.txt
├── DumpPublicKey.class
├── DumpPublicKey.java
└── manifest.txt
I obviously don't know how to java at all.... any suggestions?
I just needed to put the "-cp" in the java command as well as the javac command.
Code:
java -cp .:./bcprov-jdk15on-152.jar com.android.dumpkey.DumpPublicKey
The full command is
Code:
java -cp .:./bcprov-jdk15on-152.jar com.android.dumpkey.DumpPublicKey /path/to/key.x509.pem > keys
After deleting stuff and testing, I found I only needed files in these locations:
.
├── bcprov-jdk15on-152.jar
├── com
│** └── android
│** └── dumpkey
│** ├── DumpPublicKey.class
│** └── DumpPublicKey.jar
├── DumpPublicKey.java
└── manifest.txt
Then I replaced the "/res/keys" file with the "keys" file I just made.
Seventh: Repack the ramdisk image (find . | cpio -o -H newc | gzip > ../recovery.img-ramdisk.gz) and rebuild recovery.img with mkbootimg.
Click to expand...
Click to collapse
From the folder that the ramdisk image was extracted into, run
Code:
find . | cpio -o -H newc | gzip > ../recovery.img-ramdisk.gz
mkbootimg needs offsets that were printed when I ran unpackbootimg:
BOARD_KERNEL_CMDLINE
BOARD_KERNEL_BASE 10000000
BOARD_NAME
BOARD_PAGE_SIZE 2048
BOARD_KERNEL_OFFSET 00008000
BOARD_RAMDISK_OFFSET 01000000
BOARD_TAGS_OFFSET 00000100
Still in the folder where I unpacked the recovery image (mkbootimg is one directory up)
Code:
../mkbootimg --kernel recovery.img-zImage --ramdisk recovery.img-ramdisk.gz --base 10000000 --pagesize 2048 --kernel_offset 00008000 --ramdisk_offset 01000000 --tags_offset 00000100 -o newrecovery.img
Eighth: Write the new recovery image to your device
Click to expand...
Click to collapse
This thread says Heimdall 1.4.0 works for T31x: http://forum.xda-developers.com/showthread.php?t=2522091
Oh how nice, Heimdall 1.4.1 is in my package manager.
Connect device and restart in download mode (held the "HOME" button, "Volume Down" and "Power" all at the same time (for about 5 seconds). Hit the "Volume Up" to enter download mode when prompted.)
Code:
sudo heimdall flash --verbose --no-reboot --RECOVERY recovery.img
Ninth: Get signapk from here and build it. Run it against the ROM you want to sign, using the keys you generated earlier. Make sure you use the -w option to sign the whole zip rather than signing individual files.
Click to expand...
Click to collapse
signapk is on github in android/platform_build/tools. And it gives more bouncy castle errors. Put bcpkix-jdk15on-152.jar and bcprov-jdk15on-152.jar in the signapk folder and run
Code:
javac -cp .:./bcprov-jdk15on-152.jar:./bcpkix-jdk15on-152.jar SignApk.java
echo "Main-Class: SignApk" > manifest.txt
jar cvfm SignApk.jar manifest.txt SignApk.java
make directory com/android/signapk/ and move in all the *.class files and the SignApk.jar
Code:
java -cp .:./bcprov-jdk15on-152.jar:./bcpkix-jdk15on-152.jar com.android.signapk.SignApk /path/to/key.x509.pem /path/to/key.pk8 ../original.zip ../signed.zip
I just replaced the recovery in the OTA with the recovery with my keys from earlier, then rezipped it before signing. And after starting sideloading I noticed I left the "-w" option off the signing command, so I made another file with "-w".
Sideloaded with:
Code:
adb reboot recovery
(then volume down to select apply update from ADB)
adb sideload signed.zip
Then saw:
loading: 'update.zip'
sending: 'update.zip' <completion percent>
(might have to do some adb stopping/starting or adb usb beforehand to make it work, I was getting "error: closed" at first. If it just sits on "loading" something's wrong, as I found out last night when I waited hours for "loading" to turn into something else.)
After the file finished uploading, In terminal I got the response "* failed to write data 'protocol fault (couldn't read status): Success' *"
And on the device I got (for a few seconds before it showed only the sad robot on its back). Then after a couple minutes it rebooted back into recovery.
E: Footer is wrong
E: Footer is wrong
E: Signature verification failed
Installation aborted
So I tried again, but this time selected the option to wipe the cache before adb sideload. Then I tried again, using the update.zip that I forgot to add the "-w" option when signing. So far all fails.
I have no idea if the issue is how the recovery was flashed or what, so I'm doing it manual...
Code:
adb shell
su
#first backup current recovery
dd if=/dev/block/mmcblk0p10 of=/sdcard/recoverybk.img
adb pull /sdcard/recoverybk.img
# now push and dd my signed recovery
adb push /sdcard/recovery.img
dd if=/sdcard/recovery.img of=/dev/block/mmcblk0p10
And still having the same signature verification issue.
Edit: I went back and unpacked the recovery I pulled off the device (unpackbootimg), and it looks like somehow I managed to run mkbootimg with the old ramdisk image.
New problem with the new recovery: "E:failed to load keys". Maybe it had something to do with using ec keys just for funsies. So I remade the keys with the default, redumped into the ramdisk image, rebuild/reflashed recovery, resigned the update.zip. Now it's back to the "footer is wrong, signature verification failed" error.
But this is still trying to use the OTA 4.4.something update, not a full ROM. What's it do with Cyanogen?
First attempt: Download Cyanogen and sideload it (unmodified)
E:failed to verify whole-file signature
E:signature verification failed
Ok, expected behavior, it's not signed with my keys.
Attempt 2: sign Cyanogen with my keys and sideload it
Install from ADB complete!! Success!!
@user0002,
great thread! have you considered assembling a toolkit/suite for this process?
Thanks.
m
moonbutt74 said:
@user0002,
great thread! have you considered assembling a toolkit/suite for this process?
Thanks.
m
Click to expand...
Click to collapse
Hmmm... that's a good idea.
The instructions for Lineage OS don't seem to tally up with my Recovery menu (Team Win on the latest version 3.5.1_9-0) :
"2. Now, use the volume buttons to select “Advanced”, and then “Enable ADB”."
There's no option to enable ADB in the advanced menu,
"3. Now tap Factory Reset, then Format data / factory reset....."
There's no Factory Reset option
"5. On the device, select “Apply Update”...."
There is no apply update option.
Am I missing something simple?
replicon1 said:
The instructions for Lineage OS don't seem to tally up with my Recovery menu (Team Win on the latest version 3.5.1_9-0) :
"2. Now, use the volume buttons to select “Advanced”, and then “Enable ADB”."
There's no option to enable ADB in the advanced menu,
"3. Now tap Factory Reset, then Format data / factory reset....."
There's no Factory Reset option
"5. On the device, select “Apply Update”...."
There is no apply update option.
Am I missing something simple?
Click to expand...
Click to collapse
Yes you are. These are totally different recoveries so they look different.
TWRP menu vs Lineage menu.
2) If I'm not mistaken, adb should be turned on by default in twrp.
3) In twrp you find this on the "wipe" button
5) In twrp the apply update functionality should be under "advanced". Else, you could just adb push your file to your device and install via the "install" buttton.
User699 said:
Yes you are. These are totally different recoveries so they look different.
TWRP menu vs Lineage menu.
2) If I'm not mistaken, adb should be turned on by default in twrp.
3) In twrp you find this on the "wipe" button
5) In twrp the apply update functionality should be under "advanced". Else, you could just adb push your file to your device and install via the "install" buttton.
Click to expand...
Click to collapse
Thanks, I was starting to lose the will to live.
replicon1 said:
Thanks, I was starting to lose the will to live.
Click to expand...
Click to collapse
No need to. Hope you'll be fine!
Managed to get Lineage installed but I don't seem to be able to install MindTheGapps. Error states "Could not mount /mnt/system Aborting". I've tried searching for this issue but it I can't find a solution. Now it won't boot to Lineage. Should I wipe it and start again?
replicon1 said:
Managed to get Lineage installed but I don't seem to be able to install MindTheGapps. Error states "Could not mount /mnt/system Aborting". I've tried searching for this issue but it I can't find a solution. Now it won't boot to Lineage. Should I wipe it and start again?
Click to expand...
Click to collapse
You could try wiping it.
I didn't flash gapps, but as far as I know it should be flashed before booting into the OS for the first time.
replicon1 said:
Managed to get Lineage installed but I don't seem to be able to install MindTheGapps. Error states "Could not mount /mnt/system Aborting". I've tried searching for this issue but it I can't find a solution. Now it won't boot to Lineage. Should I wipe it and start again?
Click to expand...
Click to collapse
Any progress with installing MindTheGapps?
I got the same error message about not being able to mount system with my LG G2.
nexus212 said:
Any progress with installing MindTheGapps?
I got the same error message about not being able to mount system with my LG G2.
Click to expand...
Click to collapse
Do you have twrp or stock-lineageos-recovery installed?
If it cannot mount it, something isn't working as it's supposed to.
Can you try this from within your recovery?:
Code:
mkdir /tmp/system_b
Here I'm creating a mount point for my system_b (I have system a and b due to a a-b partitioned device) in the tmp folder.
Code:
mount /dev/block/by-name/system_b /tmp/system_b
I am mounting my system_b partition on the previously created mounting point.
Your system partition might be at a slightly different place somewhere in /dev/block/.
Code:
ls /tmp/system_b/
Just listing the content of system_b.
Spoiler: You should get an output similar to this one
Code:
acct default.prop init.zygote32.rc res
apex dev init.zygote64_32.rc sbin
bin dsp lost+found sdcard
bt_firmware etc mnt storage
bugreports firmware odm sys
cache init oem system
charger init.environ.rc persist tmp
config init.rc postinstall ueventd.rc
d init.recovery.qcom.rc proc vendor
data init.usb.configfs.rc product verity_key
debug_ramdisk init.usb.rc product_services
Code:
umount /tmp/system_b/
Unmount the system_b partition from that mounting point we created earlier, since it's not needed anymore.
Code:
rmdir /tymp/system_b/
Remove system_b directory we created at the beginning since we don't need it anymore.
Please note that I'm using 'rmdir' instead of 'rm -R' because 'rmdir' will fail if /tmp/system_b/ isn't empty (preventing you to accidentally delete your system partition).
If that works for you (especially the mounting part), then your recovery should be able to do it itself too.
Yes, I had(/have?) twrp installed and with that it didn't worked. Yesterday I pinned it down to the installation script not being able to find the system block by adding some additional ui_prints.
But today I followed upgrade instructions (https://wiki.lineageos.org/devices/d802/upgrade) again with installed LOS 18.1 image and somehow my device booted into lineageos-recovery instead of twrp and I was able to fully install LOS 18.1 (again, just to be save) and MTGapps.
Although my issue accidentally fixed itself, thank you for you attempt to help!
replicon1 said:
Managed to get Lineage installed but I don't seem to be able to install MindTheGapps. Error states "Could not mount /mnt/system Aborting". I've tried searching for this issue but it I can't find a solution. Now it won't boot to Lineage. Should I wipe it and start again?
Click to expand...
Click to collapse
try this twrp,it should be able to install MindTheGapps.
Any chance to get this modified twrp for herolte?
replicon1 said:
Managed to get Lineage installed but I don't seem to be able to install MindTheGapps. Error states "Could not mount /mnt/system Aborting". I've tried searching for this issue but it I can't find a solution. Now it won't boot to Lineage. Should I wipe it and start again?
Click to expand...
Click to collapse
I recently ran into this issue. In my case, it was due to /etc/recovery.fstab using tabs, while MindTheGapps was expecting spaces. I filed a merge request here, but you can try making the change yourself by editing META-INF/com/google/android/update-binary in the MindTheGapps zip file.
rkjnsn said:
I recently ran into this issue. In my case, it was due to /etc/recovery.fstab using tabs, while MindTheGapps was expecting spaces. I filed a merge request here, but you can try making the change yourself by editing META-INF/com/google/android/update-binary in the MindTheGapps zip file.
Click to expand...
Click to collapse
I got the same error. According to your hint, I tried to change the line in "update-binary": Unzipping all files, changing the file's content, zipping again, installing. Now I'm said the zip in invalid: "Invalid zip file format"
Can you please let me/us know how to zip a file TWRP accepts for installing?
was having issues installing gapps and searches brought me here, tomintpe i would avoid regenerating the zip file and just add the edited file back to the zip... Am working on that myself.... if i get it to work will attempt to attach the file
Okay, this was tested on a samsung galaxy s2 gt-i9100, this was going into the MindTheGapps-11.0.0-arm-20210412_124103 package for a lineage os 18.1 install. So, make sure this applies to you before you copy/paste anything ok?
The issue was the line "grep -v "^#" /etc/recovery.fstab | grep " $1 " | tail -n1 | tr -s ' ' | cut -d' ' -f1"
which i replaced with "grep -v "^#" /etc/fstab | grep "$1" | sed 's/ */!/g' | cut -d'!' -f1"
Am using sed to replace whitespace with !'s (unsure why cut -d' ' didn't work but, it didnt) and also looking at /etc/fstab instead of recovery although recovery would have probably worked fine.
Thanks for the answers so far.
When I want to update the original zip file with the edited "update.binary" I wonder how to get the file into the right directory in the zip file. A simple
Code:
zip MindTheGapps-11.0.0-arm64-20210412_124247.zip update-binary
just adds the new file to the archive's main directory.
How do I get the updated file where its belong to in the zip without newly building the zip file?
Ok, I found out myself how to update the zip file using the flag -u with the same directory structure.
But changing the "update-binary" 's line 44 into "grep -v "^#" /etc/fstab | grep "$1" | sed 's/ */!/g' | cut -d'!' -f1" or "grep -v "^#" /etc/recovery.fstab | grep "[[:blank:]]$1[[:blank:]]" | tail -n1 | tr -s [:blank:] ' ' | cut -d' ' -f1" does not help. I still get the TWRP error "Could not mount /mnt/system Aborting".
get_block_for_mount_point() {
#grep -v "^#" /etc/recovery.fstab | grep " $1 " | tail -n1 | tr -s ' ' | cut -d' ' -f1
grep -v "^#" /etc/recovery.fstab | grep "$1" | tail -n1 | rev | cut -f1 | rev
}
semellle said:
get_block_for_mount_point() {
#grep -v "^#" /etc/recovery.fstab | grep " $1 " | tail -n1 | tr -s ' ' | cut -d' ' -f1
grep -v "^#" /etc/recovery.fstab | grep "$1" | tail -n1 | rev | cut -f1 | rev
}
Click to expand...
Click to collapse
No, same error message.
You need to test the command with adb shell.
Can you send me the content of your : /etc/recovery.fstab
Or just past the result of this cmd:
grep system /etc/recovery.fstab