Database Info

[Q] Understanding unlocking... (Not rooting)

I'm assuming that "unlocking" is not talking about a carrier lock. I got my Xoom a few days ago. It's my first Android device although I did play with Honeycomb on the ultra slow emulator with the SDK. I also have some Unix/Linux background but am VERY rusty but I think I get it now...
So, does unlocking mean giving us the ability to remount the system partition in RW (read/write) mode?
Also, I see Beagleboy has been able to extract the boot and system partitions (but had to trash his recovery partition to do so). Is this similar to ripping a data CD image in Linux by outputting the "cat" (or "dd"?) of a device (/dev item) to a file? In our case, it looks like items beginning with "/dev/block/mmcblk". I used "mount" to see how the system and userdata partitions were mapped. Just followed the symbolic links in "/dev/block/platform/sdhci-tegra.3/by-name" to figure out boot and recovery.
Simply unlocking (without rooting) doesn't affect anything, does it? I mean, the userdata partition is left as-is, right? Meaning I could back up my Xoom by extracting that? And could I simply use "adb pull" directly on the device to rip my userdata? And would I have to remount it in RO first?
Sorry for all the questions. I'm not ready to unlock until Motorola decides to release the Xoom Wi-Fi (MZ604) image files.

unlocking the bootloader allows you to run custom kernels - so if you know what a bootloader is from linux...
pretty much allows new functionality, ie SD card to be run

But the SD card functionality isn't there until you run that custom kernel, right? Just unlocking the Xoom by itself doesn't change it's functionality, right? Except for the bootloader part I mean.
I won't have root, but could I use adb to remount system as RW? Even if I don't have permissions to write to it without root? I'll have to give these a try later.
Right now, I just want to back up my userdata (and virtual SD card).
Anyone know what /dev/fuse is?

An unlocked device gets you nothing out of the box. You still have to be root to remount system as rw.

Gotcha. But that's enough to reflash the boot and system partitions, right?

[Q] Installing ClockworkMod Recovery on G2x manually (i.e. via adb shell / "dd")?

[Q] Installing ClockworkMod Recovery on G2x manually (i.e. via adb shell / "dd")?
Hi all,
There is a thread about installing ClockworkMod Recovery on the LG Optimus 2X, but of course the block device is not correct for the G2x:
(Optimus-2X-only method): dd if=/data/local/clockworkmod.img of=/dev/block/mmcblk0p7
On the G2x, /dev/block/mmcblk0p7 is where /data is mounted, so this is a no-go.
I rooted my G2x, but I would like to use such a manual install method for CWM (and before I do, I would, of course, like to backup my old recovery to an image file, in case I ever need to go back to stock). I am running Linux, so I do not want to use any of the methods involving a .exe file, etc. (plus, I feel more comfortable doing it fully under my control).
Does anyone here know the right block device to use? Even better, has anyone figured out what all block devices on the G2x are for?
Thanks!

I think it's in mmcblk0p5. But verify it first before you do anything. I prefer flashing the recovery image via nvflash. They say you can brick your phone if you flash incorrectly via dd.
Check my post here (http://forum.xda-developers.com/showpost.php?p=14130496&postcount=91).
Sent from my LG-P999 using XDA App

joackie27 said:
I think it's in mmcblk0p5. But verify it first before you do anything. I prefer flashing the recovery image via nvflash. They say you can brick your phone if you flash incorrectly via dd.
Click to expand...
Click to collapse
Thanks for the info - I did see mmcblk0p5 labeled as "boot" in one thread...
One way to see if this is potentially the affected block device (from when you flashed it) would be to dump it, via dd, to a .img file and check the md5sum (I can get the md5sum of mine [stock] later and compare to yours). Also, if the dump matches the clockworkmod.img file you used, then that's more verification.
I am sure you can, indeed, brick via dd if the wrong data is applied - what I would do is re-dump the device to a file and compare that to the flash image (at a minimum) before trusting that it worked.

LavaJoe said:
Thanks for the info - I did see mmcblk0p5 labeled as "boot" in one thread...
One way to see if this is potentially the affected block device (from when you flashed it) would be to dump it, via dd, to a .img file and check the md5sum (I can get the md5sum of mine [stock] later and compare to yours). Also, if the dump matches the clockworkmod.img file you used, then that's more verification.
I am sure you can, indeed, brick via dd if the wrong data is applied - what I would do is re-dump the device to a file and compare that to the flash image (at a minimum) before trusting that it worked.
Click to expand...
Click to collapse
I remember a tweet by ChrisSoyars before that the recovery partition is being hidden by the kernel. I tried dumping mmcblk0p5 and it's way bigger than the recovery image that I've flashed recently.

[Q] Flashing stock via fastboot error message

Hi, I want to (re-)flash the stock 4.1.2 rom on my Photon Q, because I recently run into some problems of the phone sending messages to the number 8737 even after I had removed the stock sms app.
This should be the right rsd file:
Code:
asanti_c_sprint-user-4.1.2-9.8.2Q-122_XT897_FFW-5-6-release-keys-cid9.xml.zip (MD5: 88f43a03d313bbcc262db78f15ac957c)
I'm on linux and I don't have any Windows system I could install and run RSDLite on. So I decided to take the fastboot way: I unzipped the above file and tried flashing the rom manually. But I always run in to the following error output:
Code:
# fastboot flash cdrom cdrom
(bootloader) Variable not supported!
target reported max download size of 31457280 bytes
Invalid sparse file format at header magi
error: write_sparse_skip_chunk: don't care size 22923264 is not a multiple of the block size 4096
fastboot: ../libsparse/sparse.c:143: write_all_blocks: Assertion `pad >= 0' failed.
Note that "fastboot devices" lists the Photon Q as "T069503UAP fastboot". The same or a similar error messages applies to "fastboot flash system system.img" etc. I use fastboot from the Fedora 20 "android-tools" package (version 20130123git98d0789-2).
Any ideas what's the problem here? Solution?
Thanks in advance!

It's dangerous to try and fastboot the items yourself. Would be better to borrow a Windows PC or something to use RSD (virtual machines are also NOT recommended for this).
But perhaps you should just try to fastboot the other partitions. Not sure 'cdrom' is needed. Either way, I strongly, STRONGLY advise against doing what you are doing.

Okay, thanks for your advice!
The same or similar error messages appear when flashing the other partitions (as already mentioned in the first post). Unfortunately, it's really hard to find somebody with a Windows system, at the moment. I thought RSDLite uses fastboot internally anyway.

I'm not sure if the FXZ images can be flashed as they are, via fastboot.
I believe they should be converted to the standard ext4 format via the simg2img.py pytoon script, before being usable.
I repeat I'm not sure, but I believe that hardly motorola's own format is handled correctly by the fastboot command.
Whatever, for your convenience, I attach the mentioned converter script.
Aside fastboot, can be used for a variety of other purposes, the ext4 images can be mounted straight in Linux via loopback device or extracted in windows with a bunch of tools, personally I use Ftk Imager.

Thanks, that tool is great! After conversion, I was indeed able to mount the system partition as follows:
Code:
# mount -o ro,loop system_converted.img /some/mnt/path
But it doesn't help with the other files (cdrom, boot.img, recovery.img), because they seem to have a different format. However, the system partition was all I wanted. Now, instead of reflashing, I'm going to compare the system partition's files (especially in the "app" folder) and see what might have caused my problem.

tuxor1337 said:
But it doesn't help with the other files (cdrom, boot.img, recovery.img),
Click to expand...
Click to collapse
The boot, recovery and similar partitions aren't written on top of a filesystem like /system or /data.
they are written as they are on top of the physical media.
you can safely flash them in any way: fastboot, restore by recovery and so on.
unlike the filesystem based partitions, they are always in the same format.
If you need to edit the boot or recovery content you need a special script to unpack and repack them, many android kitchens have it

I was just wondering whether flashing on Linux will work when using "moto fastboot" like this one: http://forum.xda-developers.com/showthread.php?t=1138092
I don't really need this functionality anymore. But out of curiosity: What do you think?

My photon has a broken USB connector, so I can't test it in first person.
Btw, I believe that testing is the only way to understand what is flashable and what not, obviously taking handy a good full nandroid backup.

[Q] Building a recovery.img from scratch

Here is the theory I want.
Given a mobile phone that has a lock on it wether pin code, pattern or password, If the mobile's bootloader was unlocked I can install a custom recovery and then boot to that recovery in which I can run the adb and have access to the data in the phone. If my hypothesis is correct then how I can build a recovery.img ??
I have been reading for the recover.img for 2 weeks and almost understood how it works and most of the files in it. However, I couldn't find a tutorial of how can I build my own recovery.img
What I decided to do it to modify on the CWM recovery.img.
So I downloaded the CWM and then I unpack it to see the kernel and the initrd. After decompressing the initrd, I found many files. I made a simple test which is to run a script from the init.rc. Inside the init.rc I added two lines. The first one to mount the /data partition and then I just echoed "test" to a file called text.txt then I rebooted my device to normal boot connected to adb and checked the /data partition, but unfortunately I didn't find anything.
I would like to know what I am missing and if my theory is correct or not and how can I build my OWN recovery and have something like adb running from the start.
Thank you

Incremental OTA Payload Extractor - Linux Only currently - Op8T 11.0.9.9.KB05AA Posted

FIRST OFF - THIS IS HIGHLY TECHINICAL AND NOT FOR NON-TECH INCLINED PEOPLE. YOU CAN REALLY MESS UP YOUR PHONE IF YOU DO IT WRONG. SO PAY ATTENTION OR FIND SOMEONE SMARTER THAN YOU WITH THIS ANDROID / LINUX STUFF. YOU DO THIS ON YOUR OWN - NO WARRANTIES EXPRESSED OR IMPLIED. IT'S FOR PEOPLE THAT DON'T WANT TO WAIT FOR THEIR VENDOR TO POST A FULL ROM AND UPDATE RIGHT WHEN AN OTA COMES.
So I wanted to update my rooted Op8T OOS version, and you CAN'T (haha) do it if you're rooted. That's kind of a misconception. I knew there had to be a way... so I found a dead repo out there that used to work on Incremental OTAs. And I read the issues - did not actually work. Why? Because you need to extract the prior firmware (full ROM) first with a Payload extraction tool (most are in Python, and most are Linux-only). Well, they got stuck because the original ROM has one signature (encryption), and the OTA update has another signature, so the program would break when they didn't match. So what did I do??? Well I have to give credit to the dev I forked this from, because he mentioned - of course the signatures don't match, they are different releases! So I did something kind of... well... let's put it this way, you aren't verifying any signatures anymore. So if you screw up and put the wrong ROM base (prior full ROM) and Payload extract the payload.bin, then apply the Incremental OTA, well, you're in for trouble. BE POSITIVE YOU ARE USING THE VERSION OF THE ROM THE OTA IS INTENTED TO INCREMENTALLY UPDATE!!!!
In this case, it was quite clear. I was trying to update an A11 Op8T from OnePlus. It was on 11.0.8.3 ROM and an OTA was posted that was for 11.0.9.9. SO I used a Windows tool to extract the first set of files (the full ROM is huge BTW). The incremental update came as a 150mb file zipped up, but it modified the BIG files. Once it finished, I found that system and system_ext are not flashable (grew in size, can't resize super on active slot, not updated), the rest are. And you MUST flash from fastbootd - this is kind of a mysterious new place with modern AB devices. It can be a pain to actually get there. The standard steps if you're on stock recovery are to enable developer options, USB debugging, install the Latest ADB and Fastboot https://github.com/fawazahmed0/Latest-adb-fastboot-installer-for-windows/releases/tag/v1.7 (this script will update it for you). Ignore the God references it's a batch file you can just modify it, and I don't judge. It will pull the latest versions (Minimal ADB and Fastboot are super outdated). Next steps...
Now, getting an incremental update off a rooted phone is not easy. 1) you have to flash a stock boot.img and recovery.img. 2) you have to basically uninstall Magisk, or at least the images 3) then you MAY be able to download with Oxygen Updater or the system app. It won't install though because root is fully exposed. Once it's downloaded, it appears in some very strange location with a random character string.zip I believe. So now you have to reinstall Magisk (to get adb shell SU access). So after I confirmed it downloaded (but wouldn't flash), I had to hook my phone up to the USB cable, go to the PC and Latest ADB and Fastboot folder, adb shell, su, then cd /; find . -name *.zip > /dev/null 2>&1; to cut out some of the garbage output and scroll until I found a logical zip stored somewhere (a folder than sounded like a OnePlus update folder). Then I did a: cp [random characters.zip] /sdcard/Download/OTA_Update.zip, which I could then transfer from my phone to PC with a USB cable. Developer options / default mode USB File Transfer FYI.
Okay that was one of the hard parts. Now next to more hard parts. You need a Linux environment (I used WSL2 Debian Buster). The easiest setup (after spending hours attempting to get the correct packages loaded) was to install the personal version of Anaconda Python x64 for AMD64 processors for Linux. Then I could use conda install [package name] for missing dependencies as the program would throw errors. Yes you have to read the errors or you won't be able to figure out what is actually not installed. Anyhow, the modded forked repo of python files is here: git clone the repo: git clone https://github.com/mrslezak/update_payload_extractor.git - now if git isn't setup on your Linux box, well, you're in for some trouble.
So once it's installed, you need to actually use python3 commands for each step - so anywhere you see "python" put "python3" instead as most machines have both 2.7 and 3.X installed. I used Python 3.8 something, so ignore the 3.6 it's not required. So here I took a payload.bin extracted with a Windows.exe file (available somewhere on XDA, there are severel, one is Go based) and copied them once extracted from the original ROM to the WSL instance on my Win10 PC. Now there come issues here. They need to go into an "old" directory you must create (in update_payload_extractor directory), and copying from Windows will make them root access only, so a: sudo chown user:user old/ is required to get it writable. I believe the program will make the rest of the files on its own. They will end up in "output." You just need to extract the payload.bin and payload.properties files from the incremental update you extracted and place them in the update_payload_extractor directory.
Now there is some strange stuff going on, this was always beta, and never working. So I took the note of the issues and blocked a Google certificate validation routine (just commented it out) so it doesn't verify anything. I say it again BE EXTREMELY CAREFUL THAT YOUR PRIOR FULL ROM AND OTA UPDATE ARE MEANT TO BE USED TOGETHER. Anyhow, run what it says if your system is setup:
Incremental OTA​
Copy original images (from full OTA or dumped from devices) to old folder (with part name without file extension, ex: boot, system) - I put an .sh script here if your files are .img called remove_img_extension_old.sh - note that GitHub sometimes loses the execute permission so you may have to type: sudo chmod +x remove_img_extension_old.sh. It is meant to be run from the root of the project. ./remove_img_extension_old.sh
LD_LIBRARY_PATH=./lib64/ ./extract.py --output_dir output/ --old_dir old/ payload.bin
The above line will start the extract and combine process the OTA usually does on your phone, and output the files to the output directory. Once those are generated, then you can run another helper script I wrote to add back .img to each file called add_img_extension_output.sh again meant to be run from the root folder. Now you need to copy these output files (no guarantee all are updated, it will have all of them - on Op8T system and system_ext couldn't be flashed because they grew in size, and I don't know how to expand the super partition space to enable them to flash, so they aren't in the linked file - it still updates). The files on Op8T ending in lp5 are RAM files for the newest devices that are running LPDDR5 memory, the flash.bat script will need to be modified if you have one of these (2 flashes). The way I made the file will work in 98% of devices.
Okay I run the rest from Windows, so now it gets a little tricky. You need to get into Fastbootd, which means flash boot.img (you just extracted it), flash recovery image (same), using fastboot flash boot boot.img, fastboot flash recovery recovery.img. Now getting to fastbootd can be quite perplexing. You may just have your phone on, type adb reboot bootloader, then type fastboot reboot fastboot, and be in fastbootd (it will look like stock recovery but say fastbootd on top). The other way is to boot to recovery (developer options extended boot menu makes this much easier), then select Fastboot. Sometimes you get Fastboot and sometimes Fastbootd. It seems quite random. DON'T START THE FLASH_ALL.BAT UNTIL YOU KNOW YOU ARE IN FASTBOOTD!!!!
The fastboot command to tell you if you are in fastbootd (it will report yes if so: fastboot getvar is-userspace
Otherwise, those files will NOT be allowed to flash to your device, and you will end up with some random combination of prior and updated files. That could end badly. Once you DO get to Fastbootd, run the flash_all.bat, and DON'T SWITCH SLOTS. Yes, this is an OTA, but you already patched the files. Upon successful flashing, you can reboot to fastboot and flash a patched kernel with Magisk already enabled such as my forked Radioactive here: https://github.com/mrslezak/Radioactive_kernel_oneplus8/releases/tag/v2.2.5-MOD - the .img file is a Magisk patched custom kernel, you can also flash the twrp alpha (that seems to work in my experience, it's just slow, on OOS works fine despite warnings it doesn't). https://forum.xda-developers.com/t/recovery-11-alpha-teamwin-recovery-project-8t-kebab.4302449/ fastboot commands for the kernel: fastboot flash boot image_name.img; recovery fastboot flash recovery twrp_name.img.
I successfully updated while rooted from the prior ROM version. I'm sure it will work on many phones. Best of luck to you!!! I did find out how to install "the full ROM" unreleased on a rooted phone, there is some undocument fastboot stuff I had to figure out (temp system-cow and system_ext-cow files that use up all the space in the super partition) so I added them to my batch file. Now install for whatever device you have, and watch out for those weird temp files that aren't documented anywhere that I could find. Took literally hours to get it working, but it does now!!!

BTW if anyone knows how to resize the super partition, that would complete this project. I.e. you could flash the patched system and system_ext on an Op8T.
Your phone may have no issue or no super partition, then you don't care, it's not needed. I can't recall when dynamic (resizable) partitions came out but I think in Android 10 some devices started to use them. They are developer hell in my opinion.
Some TWRP versions allow you to just resize the partition on the fly, while on my phone, it's not an added feature yet. I'm also not sure if the resize does an auto-wipe either then you could also find yourself in trouble if you couldn't immediately get to Fastbootd. Some ROMs will boot to "Device is corrupt" if things like this change, just a warning, which I tried by switching A/B slots, but I had luckily installed TWRP on the other partition and was able to switch slots there and go back to booting.
UPDATE: I was able to eventually locate why the Super partition was getting full - there are temp files created as dynamic partitions when trying to install an OTA - I had to delete any logical partitions with the extension "-cow" which existed for system and system_ext (on the Op8T I was using), I was on slot A, so they were called system_a-cow and system_ext-cow, I deleted them like this:
fastboot delete-logical-partition system_a-cow
fastboot delete-logical-partition system_ext_a-cow
To see if you have any temp files present, you type:
fastboot getvar-all
And scroll through them and see if any of these mystery -cow files are present.
(bootloader) is-logical:system_a-cow:yes
(bootloader) is-logical:system_ext_a-cow:yes
Whew! That was a pain. But no more waiting for incremental updates to become full ROMs anymore on a rooted phone!
Oh, and I put the update for OOS here: https://forum.xda-developers.com/t/...install-from-fastbootd.4316147/#post-85441161