My device gets the following error when flashing an factory image. Posted about this in the 4 XL thread, but maybe people here might run into this issue (hopefully not)
Erase successful, but not automatically formatting.
File system type raw not supported.
https://forum.xda-developers.com/pixel-4-xl/how-to/device-locked-fastboot-unlocked-t4018757
Thread closed. Do not cross-post.
Related
We have identified a rare bug in XDArit that will cause it to erase vital parts of the information stored on your harddrive in certain rare conditions. We were made aware of 1 instance where XDArit was correctly told to write to SD-card, would susequently warn the user was about to overwrite the boot-disk ("are you really sure?"), it would overwrite when the user answered yes after checking that really his SD-card was selected.
The error has something to do with a disk (in this case a second flash-disk in a printer) reporting as visible even when there was no media inserted.
Anyway: the new version fixes this problem. And we threw in a progress bar for good measure.
Hi,
I had this problem.
It erases the partition table.
Very Uncool.
I had fortunately everything as images backed up.
:shock:
Hi,
Sorry forgot to log in for the last message.
Silver
First of all, hello. I'm new to tinkering with Android, but I've flashed firmware on dumbphones 68 ways to Sunday, so I'm not new to phone modding nor am I worried about technical answers, so fire away.
To start, this phone has not been rooted (yet) and has the stock 2.3.4 ROM.
I've screwed around for the last six hours or so in fear of bricking the phone only to realize I should have followed a different set of instructions after Step 1 of Downgrading in this guide, because now that I've read other guides, I find this one unnecessarily complicated compared to directly pushing PD15IMG.zip to sdcard.
Since I'm already calling it quits on going any farther with this tonight, I just need a few questions answered before I give this another shot.
1. Is ADB supposed to see the phone when it is in recovery or bootloader mode? When the phone is in recovery or bootloader, entering adb devices in the Windows Command Prompt returns an empty list of devices attached.
2. I have the bad eMMC in my phone. In addition, once in recovery mode and I press Vol Up+Power, I see an error message that says E:Can't open /cache/recovery/command. I also get additional "can't open" error messages when I select Wipe data/factory reset from the recovery menu:
Wiping data...
Formatting /data...
E:Can't open /data/cwpkg.zip
E:Can't open /data/cw.prop
E:Can't open /cache/cwpkg.zip
E:Can't open /cache/cw.prop
Formatting /cache...
Data wipe complete...
Are those errors a concern? Are they a product of a failed eMMC or a corrupted file system? If they are because of the eMMC, would it be safe to say that I should leave this phone alone? If they are because of the file system, what I can do to fix these errors?
3. Now that I've read other, more MT4G-specific downgrading guides, will pushing PD15IMG.zip to sdcard and fastboot take care of the "can't open" errors in question 2 as well?
you need clockwork recovery if you want to flash.
You need to downgrade then root with s-off and have eng bootloader to attempt the wipes you've been trying. I just downgraded, last night, just follow the instructions. It's really easy. don't see how you can brick the phone while downgrading unless your phone dies during the flashing step.
Btw you shouldn't worry too much about the bad chip. Both good and bad have been known to brick. All bad chips aren't bad, it's only more susceptible to bricking. I have a bad chip and been flashing since forever
Sent from my HTC Glacier using XDA App
Snakecharmed said:
First of all, hello. I'm new to tinkering with Android, but I've flashed firmware on dumbphones 68 ways to Sunday, so I'm not new to phone modding nor am I worried about technical answers, so fire away.
To start, this phone has not been rooted (yet) and has the stock 2.3.4 ROM.
I've screwed around for the last six hours or so in fear of bricking the phone only to realize I should have followed a different set of instructions after Step 1 of Downgrading in this guide, because now that I've read other guides, I find this one unnecessarily complicated compared to directly pushing PD15IMG.zip to sdcard.
Since I'm already calling it quits on going any farther with this tonight, I just need a few questions answered before I give this another shot.
1. Is ADB supposed to see the phone when it is in recovery or bootloader mode? When the phone is in recovery or bootloader, entering adb devices in the Windows Command Prompt returns an empty list of devices attached.
2. I have the bad eMMC in my phone. In addition, once in recovery mode and I press Vol Up+Power, I see an error message that says E:Can't open /cache/recovery/command. I also get additional "can't open" error messages when I select Wipe data/factory reset from the recovery menu:
Wiping data...
Formatting /data...
E:Can't open /data/cwpkg.zip
E:Can't open /data/cw.prop
E:Can't open /cache/cwpkg.zip
E:Can't open /cache/cw.prop
Formatting /cache...
Data wipe complete...
Are those errors a concern? Are they a product of a failed eMMC or a corrupted file system? If they are because of the eMMC, would it be safe to say that I should leave this phone alone? If they are because of the file system, what I can do to fix these errors?
3. Now that I've read other, more MT4G-specific downgrading guides, will pushing PD15IMG.zip to sdcard and fastboot take care of the "can't open" errors in question 2 as well?
Click to expand...
Click to collapse
are you talking about the stock recovery? because the stock recovery is supposed to say "E: can't open /cache/recovery/command". not sure why but it does. happened on every stock recovery i've seen.
Yes, I'm on stock recovery, and that's good to know that it appears to be normal.
Currently, I have successfully downgraded to stock 2.2.1 with the .86 bootloader.
Now, in following this guide, I've gotten to the end of Step 10 and I get the following:
Code:
[B]# ./gfree -f[/B]
./gfree -f
--secu_flag off set
--cid set. CID will be changed to: 11111111
--sim_unlock. SIMLOCK will be removed
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x000138b4 (80052)
Section index for section name string table: 41
String table offset: 0x000136fb (79611)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x00000a14 (2580)
-- size: 0x000000cc (204)
Kernel release: 2.6.32.21-g899d047
New .modinfo section size: 204
Attempting to power cycle eMMC... OK.
Write protect was successfully disabled.
Searching for mmc_blk_issue_rq symbol...
- Address: c02a63a4, type: t, name: mmc_blk_issue_rq, module: N/A
Kernel map base: 0xc02a6000
Kernel memory mapped to 0x40002000
Searching for brq filter...
- Address: 0xc02a63a4 + 0x34c
- 0x2a000012 -> 0xea000012
Backing up current partition 7 and patching it...
Backing up partition /dev/block/mmcblk0p7 to /sdcard/part7backup-1319315128.bin
...
Error opening backup file.
What should I do with the backup not being written?
Upon rebooting into bootloader, it still says S-ON.
Also, to back up a bit, in Step 5, I was supposed to unplug the phone from the computer and use the Android Terminal Emulator. I didn't and executed the commands through ADB because the soft keyboard input wasn't working at all in Android Terminal Emulator.
EDIT: Fixed the problem with backup not working and I now have S-OFF. The microSD card in my phone wasn't being detected properly, so instead of seeing the correct permissions d---rwxr-x with ls -l for directory /mnt/sdcard, it was being seen as read-only. When gfree attempted to write the backup to /sdcard, it failed because the SD was read-only.
I took out my 16GB card and put in my 8GB and this time, the gfree backup saved. I can't recall if I had the phone plugged in when I rebooted the phone or plugged it in afterward, but I'm slowly realized that the SD card gets remounted when you plug and unplug the phone from the computer due to the different file systems. That's why I had issues saving files to /sdcard through ADB. Now I understand why the commands were supposed to be entered in Android Terminal Emulator, but I couldn't get the soft keyboard to function in it. Hopefully, that won't be a problem after flashing the new ROM, but that will be the next concern for me.
EDIT 2: I have now installed CWM Recovery 5.0.2.0. Also, it looks like the Android Terminal Emulator developer borked the keyboard input with today's update. Read comments from October 22, 2011:
https://market.android.com/details?id=jackpal.androidterm&hl=en
remember to perm root your phone and flash the engineering bootloader i think it was like .85 something
Thanks. I had it perm-rooted and installed the engineering bootloader by the end of the weekend. I'm looking forward to flashing VU after I get some more free time and take note of settings and apps I might want to keep from the stock ROM.
your apps should be restored by google
but just in case, use titanium backup or my backup. I personally prefer my backup to backup my sms/mms, apps and settings because its quicker when you restore.
I use titanium backup to backup and restore system apps.
Oh yeah you shouldn't try to backup your settings from your stock and restore it when you flash VU, they're different OS so might cause problems. BUT it's useful when you flash new updates.
Other than VU, you might want to try TDJ's Darkside if you want to test out sense 3.5. However, i might go back to virtuous once they release a final build for sense 3.5
happy flashing
I actually didn't have any settings to back up because I haven't been using the phone as my primary phone since I bought it, but I backed up the stock Froyo ROM and flashed to VU 2.39 two nights ago. Everything appears to be running well. I reinstalled Swype 3.7 from the stock Gingerbread ROM and I still need to reinstall Genius with Button Shortcut.
I don't really like the trouble of going back and forth between ROMs, so thankfully, I'm quite pleased with VU and Sense 3.0. The rest is just customization at this point. I may eventually take a look at Virtuous Trentacinque after it goes gold, but I didn't want to wait around for it nor run a beta ROM on what will soon become my main phone. I have no problem with flashing files and making tweaks all day, but it gets old after a while and I'd rather just use the equipment instead.
So far, battery life on VU seems to be pretty good and is much better than stock. I'm enjoying the new ROM so far as well as finally getting to use the phone rather than just backing up files and testing features.
fyi, Swype 3.25 beta is out. I think Swype 3.26 beta is out too. I think there was a thread with themed Swypes somewhere. But I forget.
Sent from my HTC Glacier using XDA App
Last night I tried to use FireParted to change the partition on my Kindle Fire but ran into issues. Reading the thread was not clear on what happened and how to fix it. But I finally figured it out based on several sources and wanted to share how to solve it.
It seems that FireParted partitions your SD card but screws up the cache and userdata partition. It does not brick the KF and you can recover. You'll need to boot into custom recovery (I used TWRP) and and use ADB to manually create the partition.
Step 1: Boot into recover mode.
Step 2: In command prompt go to your adb folder of Android SDK tools (platform tools)
Step 3: Type: adb shell
Step 4: Type: parted /dev/block/mmcblk0.
Step 5: Type: print. This will now show your partition. You will most likely have partition 10 (userdata) and partition 11 (cache) missing. You'll need to create those partitions
Step 6: Here you can follow instruction for creating the partition from eldarerathis thread. Start with step 3.2 to the end but don't reboot yet.
Step 7: If you saved your data using FireParted then after fixing partition you can fire up FireParted again and use the restore to get your data back. You can now reboot and should be back to normal. Hope that helps.
Credit: Most of the work was figured out by eldarerathis with the manual partition.
Ideally I'm going to add a few changes to allow FP to try to backout changes if the SD card resize doesn't work, but it's been hard to debug/test since the error doesn't occur for me and it's become something of an "inexact science". I still can't make the SD card constraint error appear without very purposefully causing it, but I'm inclined to leave the FP thread up anyway for now (without links to the binaries, though I haven't deleted them from Github) in case anyone else wants to poke around in the source.
eldarerathis said:
Ideally I'm going to add a few changes to allow FP to try to backout changes if the SD card resize doesn't work, but it's been hard to debug/test since the error doesn't occur for me and it's become something of an "inexact science". I still can't make the SD card constraint error appear without very purposefully causing it, but I'm inclined to leave the FP thread up anyway for now (without links to the binaries, though I haven't deleted them from Github) in case anyone else wants to poke around in the source.
Click to expand...
Click to collapse
Are you on a custom ROM on the KF. Reading through your thread it might be the stock ROM that is having these issues.
Android Cowboy said:
Are you on a custom ROM on the KF. Reading through your thread it might be the stock ROM that is having these issues.
Click to expand...
Click to collapse
I use a stock rooted ROM on mine, the same one I post in my threads.
I'm going to try to install a couple of different ROMs this weekend to try some of the changes I've been making (since I think I'll have some free time) and see if I can reproduce the error with any of them. If I can at least do that then I might be able to pin down some sort of commonality.
eldarerathis said:
I use a stock rooted ROM on mine, the same one I post in my threads.
I'm going to try to install a couple of different ROMs this weekend to try some of the changes I've been making (since I think I'll have some free time) and see if I can reproduce the error with any of them. If I can at least do that then I might be able to pin down some sort of commonality.
Click to expand...
Click to collapse
One message I got before it tried to partition and got stock was the regarding the "e2fsd" saying that it might need to be updated. The message showed up twice before it begin the attempted partition and got stuck. I hope that helps.
After working without a glitch for four years, my Nexus 7 (grouper) got stuck in a bootloop after I started it today. Thinking that something is probably wrong with cashe or dalvik cache I've cleared them. Now the bootloop is gone, but the device gets stuck on "Starting apps" after it finishes "optimizing" (filling in the dalvik cache). I would like to see what's going on but I have a problem doing that.
The problem is that I can't get the logcat to do the job. I've tried two "solutions" that seemed obvious, but (for some reason), none of them works.
First "solution": make a simple script and put it in /system/etc/init.d/:
#!/system/bin/sh
logcat > /sdcard/log.txt (set to 755)
I get the file, but even if I leave "Starting apps" to run for some time, when I turn off the tablet and look at the file it only has 65 lines and it still didn't finish initializing the hardware part. No information about started apps or anything. I can retrieve dmesg log from recovery but nothing interesting there as well.
Second "solution": I've tried to make it work trough init.rc, by following this https://stackoverflow.com/questions/17406209/enabling-logcat-in-init-rc (switched /cache/ to /sdcard/). But this also produces no results. Txt file is not generated at all
I don't know what I'm doing wrong.
I don't want to do a factory reset unless absolutely necessary (bunch of games with save files and other apps as well).
I can't do logcat trough adb since device is "unauthorized".
Any help is appreciated.
Thx in advance!
P.S. Using OmniROM (4.4.4)
Boot into TWRP and see if you can create or edit a text file. Reboot back into TWRP again and see if the change you made is still there. If it isn't, your flash memory has gone bad and you are in read only mode. This cant be fixed without a new motherboard. Hopefully this is not your issue.
Sent from my LGLS992 using Tapatalk
Sorry for the late reply, I was on vacation and I left the tablet at home.
The script I've mentioned was inserted trough TWRP so I think this confirms that you can write.
Also there is a log file created, as I've mentioned, it's just super short (I guess if it's in read-only mode there would be no output).
Hi,
I do have some MK903V TV Sticks that came with Android 4.4.2 and some with Android 7.1.
I thought I could potentially just clone the complete flash from one device to another using AndroidTool v2.3, but that failed.
I used "ExportImage" from "Advanced Function" to export the flash from 0 to 0x00E90000. I then selected the exported file and flashed it to Address 0x00000000 and name "system" using the "Download Image" tab.
The AndroidTool said it uploaded the file and verified okay. But after that I re-exported few blocks from 0x0 and found that the flash was not overwritten. The device did not boot (no HDMI signal).
I re-exported the system partition and found that it wrote the full backup into the system partition instead.
So basically the Tool used the "name" column and completely ignored the "address" column?
Is there a way to just write the complete flash using AndroidTool v2.3 ignoring partitions? I basically just want to mirror a device to another.
Okay, so I guess I understood that "LOADER" is actually aware of all partitions on the device and also their use/format. The "Address" column seems to be ignored completely. I guess this is only relevant for "MASK ROM" mode devices?
I found out by trying to write to "parameter" partition, hoping it would write to 0x00. But instead it wrote into the first partition at 0x08 and properly wrote the header in front of it with the size of the written data.
So, I now know how to properly extract the "parameter" image from another device and I assume all other partitions can be simply dumped and written without any magic happening to them? But I need to write them partition by partition?
For my understanding... The LOADER mode / the green "Loader" row in AndroidTool is something that is not on the flash, right? But it obviously reads the flash and its partitions.
If I'm right, I cannot brick the device as long as I don't flash a different "Loader" (which I don't have anyways as I cannot extract it from another device).
But: When I mess up the "parameter", will LOADER mode still boot fine and allow me to rewrite "parameter"?
Is "Loader" always booting "uboot" next, which then decides on booting into "kernel" or "recovery" if "R" is pressed?
Okay, I have so many questions and I can't really find any documentation :/
So at least I'll continue my self conversation here.
The bootloader of the RK3288 - and I'm still not sure what exactly it is - has two modes, LOADER and MASKROM.
I think in LOADER mode it is aware of partitions and makes sure users can only flash data to specific partitions. However, you can also update the partitions (and other stuff?) by writing to "parameter", which is part of the first few blocks of the flash.
In MASKROM mode it is not aware of any contents of the flash and you can basically write over the complete flash. In this mode the AndroidTool will actually use the Address column to flash data (I think).
I'm not exactly sure what triggers MASKROM mode but I guess the bootloader boots MASKROM mode if it cannot find "valid" data on the flash.
For example
erases the Flash and IDB, which forces the device from LOADER into MASKROM mode.
I also found lots of instructions that tell you to short two pins on the NAND Flash chip of the device to trigger MASKROM mode. None of these instructions tell you why you do it and how it works, but I guess it just disables the Flash so the bootloader reads back all zeroes or anything like that?
I also cannot find any information what IDB is, what it stands for and where it is stored, but it seems to play an important role here :/
There are multiple Versions of the "bootloader". e.g. https://github.com/neo-technologies/rockchip-bootloader / https://forum.xda-developers.com/t/rk-bl-rockchip-bootloader-collection.3739510/ lists RK3288Loader_uboot_Apr182014_155036.bin, RK3288Loader_uboot_Apr212014_134842.bin, RK3288Loader_uboot_V2.17.02.bin, RK3288Loader(L)_V2.17.bin, RK32xxLoader(L)_uboot_V2.15_replace_ddr.bin
They obviously do some things differently, but I'm not sure if this is relevant for "normal" operation of the device or just if you need to do special things. e.g.
Running Android or Linux from an SD card on a RK3288 device - An easy way to dual boo
If you are interested in dual booting Android and Linux on your RK3288 device or you simply want to try a different Android ROM or Linux distro without flashing the device, then use this method of booting from an SD card. You will need a PC...
forum.xda-developers.com
says that RK3288Loader_uboot_V2.17.02.bin is required to boot from SD card. So earlier versions can't do that?
Can I flash these Loaders to any RK3288 device (I guess?) or are they device specific? Can I downgrade? Can I flash them in LOADER and MASKROM mode? Many things I don't understand properly...
The filenames usually contain "uboot". I guess that's not because they include uboot, but because the bootloader starts U-Boot from the "uboot" partition on a regular boot?