Related
I used the latest leaked update and flashed my droid 3 to Version 5.6.890, but now I having problem with my camera, so I decided to enter the Recovery mode and do the Data Wiping, but I found out I cannot enter the recovery mode...the screen shows AP FASTBOOT MODE and "BOOT FAILURE"...
So have I half bricked my Droid 3...? is there any way I can solve this problem and safe the Recovery Mode?
Thanks.
Read this post and this thread.
limaxray said:
Read this post and this thread.
Click to expand...
Click to collapse
Thanks for the information, I tried the method, but still failing to fix the problem, this is what the screen shows after i run the commend.
PHP:
[email protected]_solana:/# sh /etc/install-recovery.sh
sh /etc/install-recovery.sh
blk: partition "emstorage" size 12203196416 not a multiple of io_buffer_size 524
288
contents of partition "recovery" didn't match MTD:recovery:2048:ed2ac38df0bab0b2
382dc3330707ff884981f335
file "MTD:recovery:2048:ed2ac38df0bab0b2382dc3330707ff884981f335" doesn't have a
ny of expected sha1 sums; checking cache
failed to stat "/cache/saved.file": No such file or directory
failed to stat "/data/saved.file": No such file or directory
failed to load cache file
applying patch to MTD:boot:8388608:c2c527aa31b9e529de6c6a574e4e589f1d2965d9
LoadPartitionContents called with bad filename (MTD:recovery)
blk: partition "emstorage" size 12203196416 not a multiple of io_buffer_size 524
288
contents of partition "recovery" didn't match MTD:recovery
partition read matched size 8388608 sha c2c527aa31b9e529de6c6a574e4e589f1d2965d9
543948800 bytes free on /cache (8388608 needed)
[email protected]_solana:/#
What's the output of
Code:
df /system
limaxray said:
What's the output of
Code:
df /system
Click to expand...
Click to collapse
It shows:
PHP:
Filesystem Size Used Free Blksize
/system 320M 310M 9M 1024
and I have also extract "install-recovery.sh" from the latest OTA package, and push to system/etc, now when i run the commend it shows:
PHP:
[email protected]_solana:/# sh /etc/install-recovery.sh
sh /etc/install-recovery.sh
blk: partition "emstorage" size 12203196416 not a multiple of io_buffer_size 524
288
partition read matched size 2048 sha ed2ac38df0bab0b2382dc3330707ff884981f335
EDIT: Solved, maybe after the space is freed up a little, I was able to enter the recovery mode again, and I re-flashed the OTA update again, everything is working now!
If you were able to enter recovery, then you were successful in running install-recovery.sh.
In any case, I'm glad you were able to get it to work.
Well, since i'm not aware of anyone else doing it, and it will be necessary for any real development to occur, I have decided to try porting Clockworkmod Recovery to the Ouya. I am downloading ubuntu right now and I'll start trying to build it from source against our current recovery tonight or tomorrow night depending on how long the setup and prerequisites take.
The reason I'm posting this now, is to solicit help. I've never built CWM before, but XDA has a really great tutorial I'm going to follow, but if anyone here has had experience in the past I'd love some help/tips, and other than that I would like a few brave souls to volunteer and try flashing it on their Ouya when/if I have a build that works on my own.
I'll update this thread with my progress, if I make any, and please let me know if any of you are willing to help in any way.
Update 1:
I have compiled a version of CWM recovery that theoretically should work, but I'm unable to flash it. I have installed flash_image onto the ouya and it works fine, but i normally would have used "flash_image recovery recovery.img" however there is no "recovery" partition on the ouya. This is what I get:
./flash_image recovery recovery.img
error scanning partitions: No such file or directory
Mount reveals the following info:
mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xatt
r,acl,barrier=1,data=ordered 0 0
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 rw,nosuid,nodev,noatim
e,errors=panic,user_xattr,acl,barrier=1,journal_async_commit,nodelalloc,data=wri
teback 0 0
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 rw,nosuid,nodev,noatime
,errors=panic,user_xattr,acl,barrier=1,journal_async_commit,nodelalloc,data=writ
eback 0 0
/dev/fuse /storage/sdcard0 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1
023,default_permissions,allow_other 0 0
This is the script from the OTA update:
#!/system/bin/sh
if ! applypatch -c EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS:5906432:f80238c4f4a53888b547e4463fb4751343f23412; then
log -t recovery "Installing new recovery image"
applypatch EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5277696:5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS f80238c4f4a53888b547e4463fb4751343f23412 5906432 5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff:/system/recovery-from-boot.p
else
log -t recovery "Recovery image already installed"
fi
but I can't make any sense of it. If anyone can help out i'd much appreciate it...
sonofskywalker3 said:
but I can't make any sense of it. If anyone can help out i'd much appreciate it...
Click to expand...
Click to collapse
This seems to be the magic lines in the update script:
if ! applypatch -c EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS:5906432:f80238c4f4a53888b547e4463fb4751343f23412; then
log -t recovery "Installing new recovery image"
applypatch EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5277696:5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS f80238c4f4a53888b547e4463fb4751343f23412 5906432 5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff:/system/recovery-from-boot.p
Click to expand...
Click to collapse
I don't know much about the applypatch program. It might just be another script. Since it isn't being called with a "./", I'd imagine it is installed somewhere that the path mentions. Try looking for "applypatch" to see if it is a program or script. In a terminal running on the Ouya, try running "echo $PATH". Hopefully you get a list of directories containing program locations (e.g. /usr/bin/ ...etc). Applypatch might be in one of those directories.
UPDATE 1:
applypatch is a binary, not a script. It is located in /system/bin/
I tried running it without arguments on my Nexus 7 (to see if we would luck out with a nice "usage" message), but for some annoying reason I can't give it execute permissions, even as root. I'll look deeper into the scripts
UPDATE 2:
I need to verify this on my Ouya, but from the updater-script in the latest OTA, the kernel partition is /dev/block/platform/sdhci-tegra.3/by-name/LNX (I'm going out on a limb here boys, but I think LNX stands for Linux, aka, our kernel, lol).
UPDATE 3:
Seems like the recovery partition is /dev/block/platform/sdhci-tegra.3/by-name/SOS
I don't know much about the details of "applypatch", but the recovery script you posted above seems to first check to see if the recovery partition hashes to f80238c4f4a53888b547e4463fb4751343f23412 (the hash of the latest and greatest recovery). If it doesn't, then we flash the latest recovery, which from the looks of it consists of the kernel (in LNX) with a patch applied to it from recovery-from-boot.p (another mess of binary). In other words, it looks like they build a recovery from the existing kernel, as the name "recovery-from-boot" implies (the kernel is packaged in a file called boot.img).
Long story short, it looks like you can write to the block device /dev/block/platform/sdhci-tegra.3/by-name/SOS to write a new recovery. Aka, in a hacked version of the OTA script, include the line
package_extract_file("recovery.img", "/dev/block/platform/sdhci-tegra.3/by-name/SOS");
where recovery.img is the name of your new recovery. They did something very similar to the kernel (LNX). I'm pretty sure that the correct way to do something like this is to use "dd" after verifying the image is correct (by running a hash against the image). I'm not sure why the Ouya team is using package_extract_file() instead of dd. I'm not in front of my Ouya though, LNX and SOS could be folders rather than block devices (although /dev/block seems to imply otherwise).
You can remove most of the other lines in the script that install the actual OTA update files. If you need help, let me know. I can make a custom update-script for you.
WARNING!!!!!!!! The above is just my take on things from looking at the scripts for 20 minutes. This could total brick your device if your recovery isn't of the right format or is not correctly built. Don't say I didn't warn ya.
You might want to read off the contents of the SOS to compare in a hex editor to your recovery. We might find out some things that would prevent a brick.
Sent from my Nexus 7 using xda premium
Thank you for all your detailed information. I assumed that if my cwm recovery build failed I could just flash the boot.img from the ota and restore it, but it sounds like that might not be correct if the update is dependent on a hashed, preexisting recovery/kernel. I used the boot.img from the ota to build the recovery at http://builder.clockworkmod.com/ and it showed successful and gave me these four files:
https://dl.dropboxusercontent.com/u/7653846/Archive.zip
So to test, should I be able to flash_image /dev/block/platform/sdhci-tegra.3/by-name/SOS recovery.img?
my concern is that particular block doesn't show up on a mount command...
sonofskywalker3 said:
Thank you for all your detailed information. I assumed that if my cwm recovery build failed I could just flash the boot.img from the ota and restore it, but it sounds like that might not be correct if the update is dependent on a hashed, preexisting recovery/kernel. I used the boot.img from the ota to build the recovery at http://builder.clockworkmod.com/ and it showed successful and gave me these four files:
https://dl.dropboxusercontent.com/u/7653846/Archive.zip
So to test, should I be able to flash_image /dev/block/platform/sdhci-tegra.3/by-name/SOS recovery.img?
my concern is that particular block doesn't show up on a mount command...
Click to expand...
Click to collapse
I'm putting together an zip to flash in the stock recovery. This way we mimic what the stock updates do to flash over partitions.
I'm reading http://forums.ouya.tv/discussion/1380/recovery-mode right now in order to figure out how to get into the stock recovery.
One thing that I noticed is that I think your recovery is slightly larger than the stock one. I'm not sure how large SOS is, but I wouldn't want to flash over adjacent blocks (i.e. write out of bounds).
Makes sense. You must know something I don't if you can get it to flash in stock recovery... I tried simply adding files to the ota zip and flashing it and it failed.
sonofskywalker3 said:
Makes sense. You must know something I don't if you can get it to flash in stock recovery... I tried simply adding files to the ota zip and flashing it and it failed.
Click to expand...
Click to collapse
It probably doesn't work because the update.zip we're using is signed.
Just a thought, but an easier way to go, albeit dangerous, is to do the following. You need root access over adb to do this. Using dd is VERY dangerous. THIS MIGHT NOT WORK. We need to make sure that what we are writing to (/dev/block/platform/sdhci-tegra.3/by-name/SOS) is truly the block device containing the recovery partition or else this might brick the Ouya. In the past, I've seen recovery written to /dev/block/mmcblk0pX, where X is the recovery partition for the particular device. I'm not much of a tegra guy. I know more about Samsung's stuff.
1) place the recovery.img on your ouya (let's say in /sdcard/recovery.img)
2) open a terminal running on your Ouya (over adb would probably be best, e.g. "adb shell")
3) enter a root shell, type "su"
4) make a backup of your existing recovery partition with "dd if=/dev/block/mmcblk0p1 of=/sdcard/origRecovery.img"
5) write the new recovery to the recovery partition with "dd if=/sdcard/recovery.img of=/dev/block/mmcblk0p1"
6) perform the following from user mbm in the Ouya forums to get into recovery (thread http://forums.ouya.tv/discussion/1380/recovery-mode)
This is a hack, an unintended sequence of events that results in recovery mode; what you need to do is crash the startup using sysrq.
For this you'll need a usb keyboard with the sysrq key, this is usually the printscreen button if your keyboard isn't labeled. As the OUYA starts to boot, hold down the alt-sysrq keys and press i, wait a few seconds and then repeat. This key combination is kill-all-tasks; thanks to whoever left this enabled in the kernel. Each time you kill the tasks the init process will restart them, after about 5 or 6 times init will print a warning on the console that one of the processes marked critical has been restarted too many times -- this then triggers an automatic reboot into recovery mode.
Unfortunately it's not always obvious when the ouya is in recovery mode. You might get screen with the ouya logo and a large red exclamation mark, or the screen might be entirely black; usually I got a black screen. Press the home button on the keyboard to bring up the recovery menu; it's actually a toggle so feel free to press the home button repeatedly until you see the menu since the timing isn't otherwise obvious.
Click to expand...
Click to collapse
There are two big unknowns here:
1) We don't know for sure that the new recovery (CWM) will actually work
2) We don't know for sure that /dev/block/platform/sdhci-tegra.3/by-name/SOS is the correct place to be writing a recovery
I'll see what I can dig up regarding /dev/block/platform/sdhci-tegra.3/by-name/SOS
---------- Post added at 02:53 PM ---------- Previous post was at 02:30 PM ----------
/dev/block/platform/sdhci-tegra.3/by-name/SOS is a link to /dev/block/mmcblk0p1
So far, it appears that the layout is the following:
Kernel (boot.img) is mmcblk0p2
Recovery is mmcblk0p1
System is mmcblk0p3
Sent from my SCH-I535 using xda premium
---------- Post added at 02:56 PM ---------- Previous post was at 02:53 PM ----------
I would imagine that if the recovery partition really is SOS, then the above steps would work if you could run them as root.
Sent from my SCH-I535 using xda premium
Some definite info:
SOS is recovery
OUYA firmware updates patches the boot partition on the fly (binary patching) - silly and error prone, but *shrug*. Don't need apply patch at all. dd is fine
It's much safer to use 'fastboot boot recovery.img' while in fastboot mode. This allows loading recovery or boot.img's into ram and execute them from there. Once that works 100%, you can flash it to SOS.
As most people already know, it's not possible to force the device into recovery. It has to be done with something like 'adb reboot recovery'.
mybook4 said:
I'm putting together an zip to flash in the stock recovery. This way we mimic what the stock updates do to flash over partitions.
I'm reading http://forums.ouya.tv/discussion/1380/recovery-mode right now in order to figure out how to get into the stock recovery.
One thing that I noticed is that I think your recovery is slightly larger than the stock one. I'm not sure how large SOS is, but I wouldn't want to flash over adjacent blocks (i.e. write out of bounds).
Click to expand...
Click to collapse
It's 8MB. If you dd to the block device (e.g. mmcblk0p1), you can't write out of bounds. The linux kernel knows the size and refuses it.
rayman said:
Some definite info:
SOS is recovery
OUYA firmware updates patches the boot partition on the fly (binary patching) - silly and error prone, but *shrug*. Don't need apply patch at all. dd is fine
It's much safer to use 'fastboot boot recovery.img' while in fastboot mode. This allows loading recovery or boot.img's into ram and execute them from there. Once that works 100%, you can flash it to SOS.
As most people already know, it's not possible to force the device into recovery. It has to be done with something like 'adb reboot recovery'.
Click to expand...
Click to collapse
I did the following with skywalker's recovery.
1) Attached a usb keyboard to the Ouya's full size usb port
2) Attached my computer to the Ouya's micr usb port
3) Ran "adb reboot bootloader" (the Ouya rebooted to a blank screen)
4) Waited 30 seconds and ran "fastboot boot recovery.img" (skywalker's recovery file)
The Ouya rebooted into CWM Recovery v6.0.3.2!
Error messages were encountered on the recovery screen (image attached)
5) Navigated around CWM with the arrow keys and the enter key
6) Rebooted with "reboot system now". Ouya booted right up.
When we flash the recovery to mmcblk0p1, we should rename /system/etc/install-recovery.sh (and maybe /system/recovery-from-boot.p) to prevent the recovery partition from being overwritten.
Looks like we need to adjust the recovery so it properly mounts the partitions. Hopefully after that we are good to go.
Wow, that's awesome progress! So I'll try the same steps when I get home tonight and then try building another recovery with proper mount points.
sonofskywalker3 said:
Wow, that's awesome progress! So I'll try the same steps when I get home tonight and then try building another recovery with proper mount points.
Click to expand...
Click to collapse
I think it should be a matter of placing the proper partitions in the fstab prior to creating the recovery image. From the error messages it looks like /cache and /data are the culprits.
If you get a chance to, please post the fstab you use so we can double check everything (want to avoid the potential for bricks).
Sent from my SCH-I535 using xda premium
I did the build without a custom fstab first to see if it would work. I'll make one tonight, or if anyone here has done it before feel free to make sure it's done right, this will be my first try at it.
Update:
Started making the fstab and got rid of the errors on my second build, seems it still can't mount some. making progress though.
Update2:
I have compiled a new recovery using the following recovery.fstab:
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard fuse /dev/fuse
this is based on information gathered from the mount command in an adb shell. it no longer gives the long string of errors, or complains that it can't mount any partitions except i get the following errors now:
can't mount /cache/recovery/command
can't mount /cache/recovery/last_log
can't open /cache/recovery/last_log
and a few others. not sure how to proceed at this point. I'm searching Google, but has anyone run into this before?
sonofskywalker3 said:
I did the build without a custom fstab first to see if it would work. I'll make one tonight, or if anyone here has done it before feel free to make sure it's done right, this will be my first try at it.
Update:
Started making the fstab and got rid of the errors on my second build, seems it still can't mount some. making progress though.
Update2:
I have compiled a new recovery using the following recovery.fstab:
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard fuse /dev/fuse
this is based on information gathered from the mount command in an adb shell. it no longer gives the long string of errors, or complains that it can't mount any partitions except i get the following errors now:
can't mount /cache/recovery/command
can't mount /cache/recovery/last_log
can't open /cache/recovery/last_log
and a few others. not sure how to proceed at this point. I'm searching Google, but has anyone run into this before?
Click to expand...
Click to collapse
I'm still new at making a recovery.fstab, but I noticed the following:
From running "ls -l /dev/block/platform/sdhci-tegra.3/by-name/"
lrwxrwxrwx root root 2013-05-25 02:23 APP -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2013-05-25 02:23 CAC -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2013-05-25 02:23 LNX -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2013-05-25 02:23 MDA -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2013-05-25 02:23 MSC -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2013-05-25 02:23 SOS -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2013-05-25 02:23 UDA -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2013-05-25 02:23 UPP -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2013-05-25 02:23 USP -> /dev/block/mmcblk0p7
Click to expand...
Click to collapse
Since the APP, CAC, LNX files are links to mmcblk0pX devices, maybe we should be using the mmcblk0pX names?
We should look at more examples to see what the recovery.fstab for other devices looks like. From what I've seen of other devices, mmcblk0pX devices are listed in recovery.fstab.
P.S. So far, I think we are fairly certain that
APP is the system partition
CAC is the cache partition
LNX is kernel boot.img
SOS is the recovery partition
I'm not sure what the rest are (data, etc). Is there a definitive list somewhere?
Here's what I was able to find based on your suggestion, it's the recovery.fstab from the nexus 7:
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA length=-32768
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/boot emmc /dev/block/platform/sdhci-tegra.3/by-name/LNX
/recovery emmc /dev/block/platform/sdhci-tegra.3/by-name/SOS
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
Obviously this isn't exactly right, but it's a start until we can find more about the mounts.
I tried making the recovery.fstab using the mmcblk numbers but that made no difference... Cache always mounts empty. I'm going to try one more thing, then I'll post my final results and go to bed.
Update:
Well still no love, and no noticeable progress between recovery 2 and 7, but I feel like we're chipping away in the right direction. I'll seek some help from some more experienced recovery people tomorrow.
sonofskywalker3 said:
Here's what I was able to find based on your suggestion, it's the recovery.fstab from the nexus 7:
/systemext4/dev/block/platform/sdhci-tegra.3/by-name/APP
/cacheext4/dev/block/platform/sdhci-tegra.3/by-name/CAC
/dataext4/dev/block/platform/sdhci-tegra.3/by-name/UDAlength=-32768
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/bootemmc/dev/block/platform/sdhci-tegra.3/by-name/LNX
/recoveryemmc/dev/block/platform/sdhci-tegra.3/by-name/SOS
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
Obviously this isn't exactly right, but it's a start until we can find more about the mounts.
I tried making the recovery.fstab using the mmcblk numbers but that made no difference... Cache always mounts empty. I'm going to try one more thing, then I'll post my final results and go to bed.
Click to expand...
Click to collapse
Good stuff.
Not sure how we are going to get the field length= . I noticed the same field being used in the US Galaxy S III recovery https://raw.github.com/CyanogenMod/android_device_samsung_d2-common/cm-10.1/recovery.fstab
length= field is probably not needed, as the stock recovery doesn't list it.
Sent from my SCH-I535 using xda premium
Here's the recovery.fstab from my Ouya's recovery partition.
# mount point fstype device
/recovery emmc /dev/block/platform/sdhci-tegra.3/by-name/SOS
/boot emmc /dev/block/platform/sdhci-tegra.3/by-name/LNX
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
/metadata emmc /dev/block/platform/sdhci-tegra.3/by-name/MDA
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard vfat /dev/block/platform/sdhci-tegra.0/by-num/p1
Click to expand...
Click to collapse
I tried doing CWM build with this recovery.fstab. /system, /data, and /cache all mounted.
Couldn't mount /sdcard automatically (trying to choose zip from sdcard) or manually (in mounts and storage, mount /sdcard).
I tweaked the recovery.fstab to the following:
/recovery emmc /dev/block/platform/sdhci-tegra.3/by-name/SOS
/boot emmc /dev/block/platform/sdhci-tegra.3/by-name/LNX
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
/metadata emmc /dev/block/platform/sdhci-tegra.3/by-name/MDA
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard datamedia /dev/null
Click to expand...
Click to collapse
This one mounted /sdcard correctly. I can "choose a zip from sdcard". I didn't actually choose a zip yet. I didn't format any of the partitions. I suppose we could try making a quick cwm zip to write something to the sdcard to test it out.
I've attached the stock Ouya recovery.img (from SOS partition). THIS IS NOT A CWM FLASHABLE ZIP, it only contains a zipped up version of the stock recovery.img. The md5 hash of the unzipped recovery.img is a6c1a6962984e9080ed8821628c4cc3f.
I've attached the CWM recovery.img that worked for me. THIS IS NOT A CWM FLASHABLE ZIP, it only contains a zipped up version of a newly built CWM recovery.img. The md5 hash of the unzipped recovery.img is c6b37906f280b16cd200503c3cde6dfb.
well, when I build using your suggested recovery.fstab i'm still getting the same error about the cache, but i booted the cwm you built and saw what you meant. can you post your actual recovery.fstab file so I can try to build with it? where did you get the boot.img you are using?
Update!
It worked!! I booted to your attached cwm and I'm running a nandroid backup right now. I'll try a restore next. In the meantime I'm putting together a Playmusic.zip flashable zip with the files necessary to get play music up and running and I'll try flashing it. Awesome work tracking down those partitions!
sonofskywalker3 said:
well, when I build using your suggested recovery.fstab i'm still getting the same error about the cache, but i booted the cwm you built and saw what you meant. can you post your actual recovery.fstab file so I can try to build with it? where did you get the boot.img you are using?
Click to expand...
Click to collapse
I edited the comment right above yours.
Recovery Builder wants the stock recovery.img, so I used adb to copy my Ouya's recovery partition to the sdcard, then I used adb pull to copy the recovery partition to my computer.
1) adb shell
2) su
3) cd /dev/block/platform/sdhci-tegra.3/by-name
4) dd if=SOS of=/sdcard/stockRecovery.img
5) exit
6) adb pull /sdcard/stockRecovery.img .
I used the recovery.fstab attached to this post. I obtained the stock Ouya recovery.fstab by doing the following:
I used split_bootimg.pl to split up the recovery.img into kernel and ramdisk (see Alternate Method in http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images). I used gzip to unzip the ramdisk and saw the stock recovery.fstab in /etc.
Here's what I did step by step:
1) split_bootimg.pl stockRecovery.img
2) mkdir ramdisk
3) cd ramdisk
4) gzip -dc ../stockRecovery.img-ramdisk.gz | cpio -i
in the ramdisk directory is etc/recovery.fstab
I then copied this file and edited the last line (/sdcard stuff). I used the new recovery.fstab with the Recovery Builder.
sonofskywalker3 said:
It worked!! I booted to your attached cwm and I'm running a nandroid backup right now. I'll try a restore next. In the meantime I'm putting together a Playmusic.zip flashable zip with the files necessary to get play music up and running and I'll try flashing it. Awesome work tracking down those partitions!
Click to expand...
Click to collapse
Awesome! Let us know how the backup/restore and zip flashing goes.
Once we verify that this CWM works correctly, people should be able write the new recovery by doing the following (NOTE this wasn't tested yet. I need to test it out first):
1) adb reboot bootloader
2) wait 30 seconds (blank screen is normal)
3) fastboot flash recovery recovery.img
4) fastboot reboot recovery (need a usb keyboard to navigate CWM)
5) flash a CWM zip to prevent stock recovery overwrite (we need to make this. The zip file should mount /system, rename recovery-from-boot.p to recovery-from-boot.bak, and unmount /system)
6) profit
Most of this could potentially be automated into a root/install CWM script.
Backup worked fine, flash worked and I'm booting now to make sure it put the files where it was supposed to and see if they work. Then i'll reboot and restore and make sure those files go away.One thing to note is that when i choose reboot system now it asked me to disable recovery flash,so I took the plunge and said yes, we'll see if it goes back to stock or not...
Update:
The .zip I built said it flashed correctly (unless i'm reading wrong the parts i could see with the overscan problems i'm having) but the files did not go to /system/app. I have attached the .zip file to see if I did something wrong with it, I just grabbed a sample from online and changed the files, haven't checked updater-script yet. I am restoring now, will post update on if that works.
It rebooted to stock recovery, as I expected, so still haven't flashed it just yet.
Well my oversensitive keyboard just hit enter twice so I'm actually backing up again, but I have to leave and take my daughter to a muesuem now, so I won't be able to continue until later. Good luck, i'll be keeping up with this thread on my phone.
Edit: removed non working zip
I was in the process of installing another OS as a dual boot option on my touchpad along with webOS.
When I remounted the boot partition rw using the command...
mount -o remount,rw /boot
a special character was accidentally inserted into the mount point name.
Now I had two boot mounts showing with the ls command, one with a special character showing as "boot?".
To fix this, I unmounted the boot partition, which left a file named "boot" in the root directory and a directory named "boot?". I was able to rename the" boot?" directory to "abcd" since the root name was taken by the file.
At this point, I'm not sure what the command should be used to remount the boot directory correctly. Please help quickly as I am unable to reboot at this time...
duh1 said:
I was in the process of installing another OS as a dual boot option on my touchpad along with webOS.
When I remounted the boot partition rw using the command...
mount -o remount,rw /boot
a special character was accidentally inserted into the mount point name.
Now I had two boot mounts showing with the ls command, one with a special character showing as "boot?".
To fix this, I unmounted the boot partition, which left a file named "boot" in the root directory and a directory named "boot?". I was able to rename the" boot?" directory to "abcd" since the root name was taken by the file.
At this point, I'm not sure what the command should be used to remount the boot directory correctly. Please help quickly as I am unable to reboot at this time...
Click to expand...
Click to collapse
What OS are you trying to install? What other commands did you run that's preventing you from booting? (based on what you've said you've run above, you should still be able to reboot since you haven't actually changed anything in /boot yet?) .
You could try: "rm /boot ; mkdir /boot ; mount -o remount,rw /boot" I guess.
If you told me more about what you are trying to do and what you have already done, I could help more.
And don't worry even if you have modified /boot such that it won't boot normally. I can help you correct that, but I'd like yo know more about what you are trying to do and what you have done so far.
jcsullins said:
What OS are you trying to install? What other commands did you run that's preventing you from booting? (based on what you've said you've run above, you should still be able to reboot since you haven't actually changed anything in /boot yet?) .
You could try: "rm /boot ; mkdir /boot ; mount -o remount,rw /boot" I guess.
If you told me more about what you are trying to do and what you have already done, I could help more.
And don't worry even if you have modified /boot such that it won't boot normally. I can help you correct that, but I'd like yo know more about what you are trying to do and what you have done so far.
Click to expand...
Click to collapse
I was reinstalling LuneOS and was in the process of making the /boot partition writable using the command....
mount -o remount,rw /boot
I had accidentally inserted a special character after /boot in the above command. This created two /boot entries as seen using the ls command.
One entry was /boot same as before, and a new entry shown as /boot? (the ? replaces the special character that cannot be displayed).
It seems I had created a second mount point with an undisplayable name.
I then issued an unmount command. to try to fix the issue...
umount /boot
This turned the /boot partition into a 6MB file named boot, and an empty directory named /boot? which I was able to rename to /abcd.
I cannot create or rename the directory to /boot since the file that now contains the boot filesystem currently has that name.
Deleting that 6MB boot file would delete the entire boot filesystem.
The command mount -o remount,rw /boot says can't find /boot in /proc/mounts
There is currently no /boot partition, just the file containing the filesystem, so I shouldn't reboot the system since there is no accessible bootloader.
I need to know the command to correctly mount the file as the /boot partition to the mount point /abcd, and then perhaps rename the mount point to /boot, or maybe rename the boot file to something else and then mount it to the /boot directory.
The mount command by itself would show how your /boot partition is currently mounted. and with what options -- maybe that would help recreate what mount command I should use to mount the boot file.
Thanks so much jc for your help in getting this fixed!
duh1 said:
I was reinstalling LuneOS and was in the process of making the /boot partition writable using the command....
mount -o remount,rw /boot
I had accidentally inserted a special character after /boot in the above command. This created two /boot entries as seen using the ls command.
One entry was /boot same as before, and a new entry shown as /boot? (the ? replaces the special character that cannot be displayed).
It seems I had created a second mount point with an undisplayable name.
I then issued an unmount command. to try to fix the issue...
umount /boot
This turned the /boot partition into a 6MB file named boot, and an empty directory named /boot? which I was able to rename to /abcd.
I cannot create or rename the directory to /boot since the file that now contains the boot filesystem currently has that name.
Deleting that 6MB boot file would delete the entire boot filesystem.
The command mount -o remount,rw /boot says can't find /boot in /proc/mounts
There is currently no /boot partition, just the file containing the filesystem, so I shouldn't reboot the system since there is no accessible bootloader.
I need to know the command to correctly mount the file as the /boot partition to the mount point /abcd, and then perhaps rename the mount point to /boot, or maybe rename the boot file to something else and then mount it to the /boot directory.
The mount command by itself would show how your /boot partition is currently mounted. and with what options -- maybe that would help recreate what mount command I should use to mount the boot file.
Thanks so much jc for your help in getting this fixed!
Click to expand...
Click to collapse
None of the commands you mention above would have created a FILE in / named boot.
If there is a FILE in / called boot, it is NOT your boot partition.
Also, the bootloader does not live in /boot.
Just reboot - nothing you mention above would prevent it from booting.
jcsullins said:
None of the commands you mention above would have created a FILE in / named boot.
If there is a FILE in / called boot, it is NOT your boot partition.
Also, the bootloader does not live in /boot.
Just reboot - nothing you mention above would prevent it from booting.
Click to expand...
Click to collapse
I no longer have access to moboot or the boot partition. If I reboot how can the system find the boot files?
Shouldn't I be able to see the boot partition it in fstab and remount the partition -- right now, it's not in there.
Can you test this on your own system, umount /boot then either see if you can regain access to it or reboot and see if there are no issues? Do you now have a file named boot in /?
duh1 said:
I no longer have access to moboot or the boot partition. If I reboot how can the system find the boot files?
Shouldn't I be able to see the boot partition it in fstab and remount the partition -- right now, it's not in there.
Can you test this on your own system, umount /boot then either see if you can regain access to it or reboot and see if there are no issues? Do you now have a file named boot in /?
Click to expand...
Click to collapse
I have absolutely no need at all to test it to know that it works.
If it's unable to boot, it's because of something other than what you mentioned above.
* Assuming you removed the /boot file and recreated the /boot dir. (i.e. "rm /boot ; mkdir /boot")
jcsullins said:
I have absolutely no need at all to test it to know that it works.
If it's unable to boot, it's because of something other than what you mentioned above.
* Assuming you removed the /boot file and recreated the /boot dir. (i.e. "rm /boot ; mkdir /boot")
Click to expand...
Click to collapse
Thanks jc and kudos -- you were right! The file named boot was an aberration, created by the badly formed mount command and a file I then copied to that location. I deleted the file and recreated the dir /boot.
I found the correct mount point /dev/root from another device, was able to mount /boot and device rebooted fine. Perhaps I didn't need to remount /boot before rebooting, but without some indication that it would be recreated, I didn't want to chance it.
Linux at times can be a painful learning experience, thanks for being here with the first aid, it's appreciated...
I've got a freshly installed Magisk v14, with manager 5.6.0, running on an Oukitel K10 with Android 7.1.1.
Version 15+ of Magisk causes a boot loop on this device, so I'm stuck on 14.
Anyway, installing downloaded Magisk modules from the zip file, or from the Downloads section in the manager, I get logs like:
Code:
- Copying zip to temp directory
- Installing Emoji_one-v1.311.zip
- Mounting /system, /vendor, /data, /cache
! Unable to extract zip file!
Failed!
! Installation failed
The MagiskManager directory does exist. I also deleted it and let the manager recreate it by downloading the magisk zip again. No change.
What can I do?
Might be an issue with unzip. Try if installing the Busybox module from the Downloads section works, and if it does, try installing modules again (after rebooting).
Installing BusyBox worked, but even after a reboot I get the same result when attempting to install other stuff. Also, BusyBox is listed under "Update Available" in the downloads section even though I already installed 1.27.2, twice.
norbolt said:
Installing BusyBox worked, but even after a reboot I get the same result when attempting to install other stuff. Also, BusyBox is listed under "Update Available" in the downloads section even though I already installed 1.27.2, twice.
Click to expand...
Click to collapse
That most likely means it did not work. Post the install log from installing the Busybox module.
Hm. Yes, the log doesn't seem as fine.
Code:
- Copying zip to temp directory
- Installing Busybox_for_Android_NDK-1.27.2.zip
Busybox Installer Script
by osm0sis @ xda-developers
Mounting...
mount: bad /etc/fstab: No such file or directory
mount: bad /etc/fstab: No such file or directory
mount: bad /etc/fstab: No such file or directory
Extracting files...
update-binary[110]: unzip: not found
Installing...
Using architecture: arm64
Creating filesystem with parameters:
Size: 67108864
Block size: 4096
Blocks per group: 32768
Inodes per group: 4096
Inode size: 256
Journal blocks: 1024
Label:
Blocks: 16384
Block groups: 1
Reserved block group size: 7
Created filesystem with 11/4096 inodes and 1294/16384 blocks
umount: /dev/magisk_merge: No such file or directory
mount: losetup failed 1
mknod: /dev/block/loop0: File exists
losetup: /dev/block/loop0=/data//magisk_merge.img: Device or resource busy
mknod: /dev/block/loop1: File exists
Using path: /dev/magisk_merge/busybox-ndk/system/xbin
cp: busybox-arm64: No such file or directory
cp: bad 'busybox-arm64': No such file or directory
chown: /dev/magisk_merge/busybox-ndk/system/xbin/busybox: No such file or directory
chmod: /dev/magisk_merge/busybox-ndk/system/xbin/busybox: No such file or directory
cp: module.prop: No such file or directory
cp: bad 'module.prop': No such file or directory
cp: module.prop: No such file or directory
cp: bad 'module.prop': No such file or directory
Cleaning...
update-binary[189]: /dev/magisk_merge/busybox-ndk/system/xbin/busybox: not found
update-binary[191]: /dev/magisk_merge/busybox-ndk/system/xbin/busybox: not found
update-binary[210]: /dev/magisk_merge/busybox-ndk/system/xbin/busybox: not found
Creating symlinks...
Unmounting...
umount: /system: Device or resource busy
umount: /data: Device or resource busy
umount: /cache: Device or resource busy
Done!
- All done!
Yeah, there's an issue with unzip:
Code:
update-binary[110]: unzip: not found
Might be an issue with your Magisk installation or a device thing, hard to say....
Have you tried installing a zip through recovery? If you can install the Busybox module in recovery it might fix things.
Didgeridoohan said:
Have you tried installing a zip through recovery? If you can install the Busybox module in recovery it might fix things.
Click to expand...
Click to collapse
I have not tried that. I currently have the stock recovery flashed. So I guess this means flashing TWRP, then flashing Busybox, and perhaps also attempting to flash Magisk itself through the recovery?
Hopefully I got that right. I'm a bit new to this.
norbolt said:
I have not tried that. I currently have the stock recovery flashed. So I guess this means flashing TWRP, then flashing Busybox, and perhaps also attempting to flash Magisk itself through the recovery?
Hopefully I got that right. I'm a bit new to this.
Click to expand...
Click to collapse
You don't have to install TWRP, you can just boot it:
Code:
fastboot boot recovery twrp.img
I attempted to install both Magisk and Busybox from TWRP, and while the Magisk installer seems to run fine, I get to allow root access to stuff in Android afterwards and I get the Magisk Manager and such, I still can't install Busybox. Also, it seems from the log that Magisk itself is also having some issues the UI isn't telling me about.
The main issue seems to be the following error:
Code:
I:[MTP] MtpServer::run fd: 26
E:[MTP] got unsupported command UNKNOWNE:[MTP] response write returned -1, errno: 19, exiting MtpServer::run loop
Searching Google for the above error returns very little help.
I pasted the entire log here, from me booting TWRP and attempting to install Magisk and Busybox a few times. The Busybox installer claims Magisk isn't installed.
I can't post links yet, so this is code:
Code:
http://paste.debian.net/1010746/
norbolt said:
I've got a freshly installed Magisk v14, with manager 5.6.0, running on an Oukitel K10 with Android 7.1.1.
Version 15+ of Magisk causes a boot loop on this device, so I'm stuck on 14.
Anyway, installing downloaded Magisk modules from the zip file, or from the Downloads section in the manager, I get logs like:
Code:
- Copying zip to temp directory
- Installing Emoji_one-v1.311.zip
- Mounting /system, /vendor, /data, /cache
! Unable to extract zip file!
Failed!
! Installation failed
The MagiskManager directory does exist. I also deleted it and let the manager recreate it by downloading the magisk zip again. No change.
What can I do?
Click to expand...
Click to collapse
hello,
Very simple solution for me at least.
i found this thread because the same thing just happened to me on g900t s5 running lineageOS. Magisk said couldnt extract Zip everytime.
My problem i believe was that i installed busybox from Apkpure and not playstore
Because when i uninstalled Busybox from apkpure then installed busybox from playtore the unzip errors are gone!
Maybe its because i has a bad copy of busybox?
Idk but that was the solution for me!
Hope this helps someone
Me helps install again magisk by twrp.
Install the es file explorer once and extract the zip at least once, It will show a list of programs by which to extract, select es file extractor and check the always button now go back to the magisk manager and try again you should be good to go.
magisk zip
My problem solved by typing real path.
I was use command to install a module using this code
Code:
twrp install sdcard/module.zip
Give an error, so i change to
Code:
twrp install /sdcard/module.zip
Everything ok.
alfanveykov said:
My problem solved by typing real path.
I was use command to install a module using this code
Code:
twrp install sdcard/module.zip
Give an error, so i change to
Code:
twrp install /sdcard/module.zip
Everything ok.
Click to expand...
Click to collapse
where I must try this command?
because I have same problem
Assalamu alaikum people,
I have seen many people complain that stock ROM is ruined or XYZ feature is missing or OTA has broken down their devices. It is safer to just backup your stock ROM before playing around. Some say that twrp backup is not working. So, we can use a fail-safe method that definitely works. I personally tested on my device. And since you are backing up your own system partition, it will definitely work for you too.
To do this, you need to have a rooted device. It is just one line of code. You can run it in terminal emulator app for android or you can connect your phone to PC.
Note:This command works with Honor 9 lite. For non-Honor devices, you must do "cat /proc/mounts" and understand the results to modify your code.
Steps to be taken
1. If you connect it to your PC, you need to do "adb shell". If you don't know what adb shell means, you better download Terminal emulator on your Honor phone and open it.
2. Then type "su" without the inverted commas inside terminal app or your adb shell. It will ask for root permissions. Grant it.
3.Paste the following code
Code:
dd if=/dev/block/platform/hi_mci.0/by-name/system of=/storage/emulated/0/system.img
The code will take some time and then display a result that it has succeeded and the bytes copied. Your system is backed up to your internal storage with the file name system.img. Now you can play around and if anything goes wrong, you can simply re-write your system.img and everything will be fine. Enjoy!!!
@aveemashfaq
Assalamu alaikum return to you.
have we a chance with this procedure to save "userdata" ? i think, it's encrypted.
your code work, i have now system.img, doing other test's with other rom's, reflash this system.img and this work ! nice way if not twrp installed !
JamesBott said:
@aveemashfaq
Assalamu alaikum return to you.
have we a chance with this procedure to save "userdata" ? i think, it's encrypted.
your code work, i have now system.img, doing other test's with other rom's, reflash this system.img and this work ! nice way if not twrp installed !
Click to expand...
Click to collapse
You can save everything byte by byte... But that dont helps to decrypt it... I suggest to save everything from /sdcard to the external sd and after that wipe data, deactivate encryption and let the system recreate data unencrypted. Don't forget to save hw_init before...
@Darkest-Dark
i need not decrypted. i mean : if i make "dd if= .../userdata of= .../userdata.img "can i flash stock.system and flash this userdata.img AND phone WORK
with my userdata ! if encrypted or decrypted : that's no important. important is working ?
JamesBott said:
@Darkest-Dark
i need not decrypted. i mean : if i make "dd if= .../userdata of= .../userdata.img "can i flash stock.system and flash this userdata.img AND phone WORK
with my userdata ! if encrypted or decrypted : that's no important. important is working ?
Click to expand...
Click to collapse
I don't understand why you would like to save data partition because there isn't any important... To save data of apps you could use titanium backup...
Here is what you wanna have:
Code:
dd if=/dev/block/platform/hi_mci.0/by-name/userdata of=/youwanttosave/userdata.img
Hey,
If you want to save userdata, it is not /something/userdata but it is /something/data. It is a good idea to backup all partitions before you start. I have accidentally formatted my /data partition using twrp and now the stock system will not boot at all. That is because stock data partition is in f2fs format and twrp reformatted it to ext4 format. I am not telling not to install twrp. I am just warning you that don't format data partition using twrp.
And also, remember that you cannot execute this code unless you have root access. And to get root access, you have to install twrp in the first place.
So, the code is
Code:
dd if=/dev/block/platform/hi_mci.0/by-name/data of=/storage/emulated/0/userdata.img
It will save your data in the internal storage with the name userdata.img
aveemashfaq said:
Hey,
If you want to save userdata, it is not /something/userdata but it is /something/data. It is a good idea to backup all partitions before you start. I have accidentally formatted my /data partition using twrp and now the stock system will not boot at all. That is because stock data partition is in f2fs format and twrp reformatted it to ext4 format. I am not telling not to install twrp. I am just warning you that don't format data partition using twrp.
And also, remember that you cannot execute this code unless you have root access. And to get root access, you have to install twrp in the first place.
So, the code is
Code:
dd if=/dev/block/platform/hi_mci.0/by-name/data of=/storage/emulated/0/userdata.img
It will save your data in the internal storage with the name userdata.img
Click to expand...
Click to collapse
There is no data image at all. It's called userdata.
You can "erase" userdata by using fastboot or tell twrp to run rm - rf instead of format data Partition.
Hi,
i did tests. dd system work.
dd if=/dev/block/platform/hi_mci.0/by-name/userdata | gzip > /mnt/media_rw/8457-1CE9/dd-backup/stock-userdata.img
49274880+0 records in
49274880+0 records out
25228738560 bytes transferred in 824.913 secs
now flash system.img (developer-rom)
don't work by me
boot to bootloader
flash backup-system.img "ok"
flash backup-stock-userdata.img "fail"
target reported max download size of 471859200 bytes
Invalid sparse file format at header magi
error: write_sparse_skip_chunk: don't care size 857477578 is not a multiple of the block size 4096
error: write_sparse_skip_chunk: don't care size 385622474 is not a multiple of the block size 4096
fastboot: ../libsparse/sparse.c:144: write_all_blocks: Assertion `pad >= 0' failed.
Abgebrochen (Speicherabzug geschrieben)
in principle can work if solve "gzip or what here break"
now i have info, that new twrp is available and i "must" test this
if this twrp work then i open new thread
this backup with dd is in principle a simle way (thank's to @aveemashfaq for your thread here) :good:
i think if new twrp working - this info is more important (my opinion) :angel:
JamesBott said:
Hi,
i did tests. dd system work.
dd if=/dev/block/platform/hi_mci.0/by-name/userdata | gzip > /mnt/media_rw/8457-1CE9/dd-backup/stock-userdata.img
49274880+0 records in
49274880+0 records out
25228738560 bytes transferred in 824.913 secs
now flash system.img (developer-rom)
don't work by me
boot to bootloader
flash backup-system.img "ok"
flash backup-stock-userdata.img "fail"
target reported max download size of 471859200 bytes
Invalid sparse file format at header magi
error: write_sparse_skip_chunk: don't care size 857477578 is not a multiple of the block size 4096
error: write_sparse_skip_chunk: don't care size 385622474 is not a multiple of the block size 4096
fastboot: ../libsparse/sparse.c:144: write_all_blocks: Assertion `pad >= 0' failed.
Abgebrochen (Speicherabzug geschrieben)
in principle can work if solve "gzip or what here break"
now i have info, that new twrp is available and i "must" test this
if this twrp work then i open new thread
this backup with dd is in principle a simle way (thank's to @aveemashfaq for your thread here) :good:
i think if new twrp working - this info is more important (my opinion) :angel:
Click to expand...
Click to collapse
I asked why you would like to save it... Its an f2fs partition not ext4... Its not quite easy...
Fastboot can handle it since Merge of 02/18... Isnt in honor9...
Even TWRP cant handle is safety...
JamesBott said:
Hi,
i did tests. dd system work.
dd if=/dev/block/platform/hi_mci.0/by-name/userdata | gzip > /mnt/media_rw/8457-1CE9/dd-backup/stock-userdata.img
49274880+0 records in
49274880+0 records out
25228738560 bytes transferred in 824.913 secs
now flash system.img (developer-rom)
don't work by me
boot to bootloader
flash backup-system.img "ok"
flash backup-stock-userdata.img "fail"
target reported max download size of 471859200 bytes
Invalid sparse file format at header magi
error: write_sparse_skip_chunk: don't care size 857477578 is not a multiple of the block size 4096
error: write_sparse_skip_chunk: don't care size 385622474 is not a multiple of the block size 4096
fastboot: ../libsparse/sparse.c:144: write_all_blocks: Assertion `pad >= 0' failed.
Abgebrochen (Speicherabzug geschrieben)
in principle can work if solve "gzip or what here break"
now i have info, that new twrp is available and i "must" test this
if this twrp work then i open new thread
this backup with dd is in principle a simle way (thank's to @aveemashfaq for your thread here) :good:
i think if new twrp working - this info is more important (my opinion) :angel:
Click to expand...
Click to collapse
Two things for you. First you should not compress them in gzip. It is only dd if=original_file of=destination.img. You have added |gzip in the middle which ruins things for you.
Second point. You can install images using twrp. I can confirm it works. fastboot flash does not work unless it is sparse image. so, you can restore using twrp.
aveemashfaq said:
I have accidentally formatted my /data partition using twrp and now the stock system will not boot at all. That is because stock data partition is in f2fs format and twrp reformatted it to ext4 format. I am not telling not to install twrp. I am just warning you that don't format data partition using twrp.
Click to expand...
Click to collapse
Hi @aveemashfaq just red this post, like you i formatted my data partition and now my Honor 9 lite LLD-L31 C432 is in a bootloop ( data partition is formatted as f2fs not ext4).
I've tried restoring a backup, restoring with HuRupdater and flashing a custom ROM but it's still bootlooping.
Could you tell me how you got it fixed.
Edit: I found this thread by you:
https://forum.xda-developers.com/9-lite/how-to/guide-unbrick-device-recover-bootloop-t3772563
and i'm trying it out.