Some android partitions from a complete block dump is not mountable, or at least i'm having no luck .
I did a complete copy of the entire disk image (mmcblk0 in my case, using this thread's instructions http://forum.xda-developers.com/showthread.php?t=1818321).
Now i can mount the raw image on windows, but i'm having no luck ubuntu, on which i do most of the work. I'm also unable to view the aboot and a lot of other partitions when i extract the images partition-wise.)
Any advice/help?
Some partitions simply do not contain mountable file systems.
Related
the s3 has a couple partitions that have no filesystem.
in log files their filesystems are named as emmc.
the device is able to boot from this partitons(recovery, bota0, bota1)
my question is. how to get access to the files on this partitions?
i tried to mount the recovery partition after copy it with dd on a ubuntu system,
but no chance. response was something like: give me a filesystem.
[Caveat emptor: adopt/follow this guide at your own risk].
Rooting and especially running a custom firmware (commonly referred to as “ROM”) on an NT unlock the NT’s full potential as a Android tablet. However these undertakings entail a significant risk: accidents or errors in the Rooting or Custom ROM Flashing process can render the NT unusable (aka “bricked”), potentially permanently. This risk can be mitigated by:
developing a basic understanding of the essence of the Rooting and ROM Flashing processes – in particular which parts of the NT storage/content get modified or replaced, and which parts do not
choosing an effective yet low risk rooting/flashing process, and most importantly,
making preparation in advance for a recovery process in the event something goes wrong: by far the most common cause of permanent bricking is not the initial bad rooting/flashing process but rather the subsequent use of unsuitable recovery (“unbrick”) procedures/tools.
NT Internal Storage (EMMC) Partitions and Associated Content (approximated partition sizes on a 16GB NT w/ 8GB allocated for user media)
/xloader (128KB, /dev/block/mmcblk0p1): first stage bootloader (MLO)
/bootloader (256KB, /dev/block/mmcblk0p2): second stage bootloader (u-boot.bin)
/recovery (15.3MB, /dev/block/mmcblk0p3): recovery process (recovery.img)
/boot (16.3MB, /dev/block/mmcblk0p4): boot process (boot.img)
/rom (49.1MB, /dev/block/mmcblk0p5): a set of 15 files containing factory installed device info (ProductID, manufactured data, etc.) and individual device data (serial no., MAC address, security encryption keys, etc.)
/bootdata (49.1MB, /dev/block/mmcblk0p6): boot control and status data (BCB, BootCnt, max17042.bin)
/factory (378.8MB, /dev/block/mmcblk0p7): backup copy of stock ROM as well as backup copy of device data in /rom partition (romdata.zip)
/system (628.6MB, /dev/block/mmcblk0p8): running copy of ROM (system and base apps)
/cache (436.2MB, /dev/block/mmcblk0p9): storage area for temporary data by system/user apps
/media (7.8GB, /dev/block/mmcblk0p10): user media content
/userdata (often referred to as /data, 5.8GB, /dev/block/mmcblk0p11): user-installed apps
For information on the roles of some of these partitions in the NT boot process: see http://omappedia.org/wiki/Bootloader_Project and http://forum.xda-developers.com/showthread.php?t=1444630.
Rooting
Rooting essentially adds a number of system files and apps to the stock ROM on the /system and /data partitions. The simplest routing method which uses CWM recovery running on bootable SDcard and which contains relatively the most current rooting content package can be found at http://forum.xda-developers.com/showpost.php?p=31271965&postcount=240. To get a sense of what get installed into /system and other changes to the stock ROM file-system, take a peek at the two folders “data” and “system” and the "updater-script" file in the folder "META-INF\com\google\android" inside the rooting content package "update.zip" referenced in that post.
Custom-ROM Flashing
Flashing custom ROM replaces the boot.img in /boot with a copy of boot.img from custom ROM zip file and the stock ROM in /system with the custom ROM and Gapps from the custom ROM and Gapps zip files, and wipes out /data (where user-downloaded apps from Google Play store will be installed) as well as /cache. Some custom ROM builds, such as Succulent’s CM10.x or 11.x builds (which are posted on his Blog http://iamafanof.wordpress.com/) also include copy of CWM or TWRP recovery.img which replaces the stock recovery.img in the /recovery partition. To get a sense of what get installed onto the NT and where, take a peek at the folders (except for "META-INF") and the "updater-script" file in the folder "META-INF\com\google\android" inside the ROM and Gapps zip files.
A method for flashing CyanogenMod (CM) ROM using CWM or TWRP recovery running on bootable SDcard is outlined at http://forum.xda-developers.com/showpost.php?p=51377882&postcount=163 (CM10.x ROM) and http://forum.xda-developers.com/showthread.php?t=2692403 (CM11 ROM).
An alternative to installing CyanogenMod (CM) ROM intenally on emmc is to install and run it off an SDcard, leaving the NT entirely unmodified. See http://forum.xda-developers.com/showthread.php?t=2098419 for info on how to create CM10.x SDcard images using Succulent's CM10.x builds.
Recovery from a Bad Rooting and ROM Flashing
It should be clear from the above discussion that the Rooting and custom ROM Flashing processes only involve /system, /data, (and in the case of ROM Flashing) /boot and /recovery. Thus, a logical approach for recovery is to make a backup copy of these affected partitions prior to Rooting and ROM Flashing. This approach makes even more sense since the very same CWM or TWRP recovery tool used to install the content of the Rooting/ROM/Gapps zip packages can also be used to make a backup copy of the affected partitions’ content and subsequently restoring these partitions using the content backup copy if needed. For this reason, while there are various approaches to Rooting and ROM Flashing, the most pragmatic and prudent one is to use CWM or TWRP Recovery tool running off a bootable SDcard, as this enables using the SDcard for content backup and, more importantly, using the SDcard to boot the NT and restore the backup content even when the NT becomes un-bootable on its own.
The remaining partitions of the NT – namely: /xloader, /bootloader, /rom, /factory, and /media – are not involved and should not be affected at all by Rooting and ROM Flashing. Hence there is absolutely no reason to use any “unbrick” process/tool that would flash/reformat/repartition/wipe/zero-out any one of these partitions – unless it has been determined with certainty that these partitions have been irreversibly corrupted. In particular the two partitions /rom and /factory which contain factory-installed individual device data must never be reformatted/wiped/zeroed-out without first backing up their content in a restorable form -- therefore refrain from using any “unbrick” tool that reformat/overwrite/wipe these two partitions without first backing up and subsequently restoring their content.
Making a Bootable Recovery SDcard
There are two approaches to making a bootable SDcard with Recovery tool for Rooting and ROM Flashing: using a pre-made SDcard image (download, unzip and write the image to the SDcard using a disk-image writer program), and creating the SDcard from scratch. The first approach is convenient, while the second although a bit more time-consuming (and potentially frustrating) provides the flexibility in customizing the card: e.g., selecting particular version of Recovery tool (i.e., for its features, or its compatibility with the particular ROM release), sizing the SDcard boot partition to provide adequate space for backing up current ROM).
The TI OMAP processor used by the NT is very fussy about the cylinder/head/sector geometry of its “boot disk” (i.e., the SDcard in this case) – see http://processors.wiki.ti.com/index.php/SD/MMC_format_for_OMAP3_boot for more info). Fortunately its requirements can be met using many disk-partition management tools such as MiniToolPartition or EASEUS Partition Master simply by selecting the approriate menu options in creating the boot partition: cylinder aligned, primary/FAT32 with partition ID type 0x0C and with LBA and Active flags set.
Next the boot partition needs to contain a specific set of boot files: MLO, u-boot.bin and boot.img and/or flashing_boot.img (aka Cyanoboot); these can be found in SD_boot.zip compiled by Succulent and posted at http://iamafanof.wordpress.com/2012/11/11/how-to-guide-bootable-cm7cm9cm10-sdcard-for-nook-tablet/). I have also found that it helps to first copy MLO (to the freshly made boot partition) before copying the other files, since it appears that the NT OMAP processor only scans the first couple of entries in the partition looking for this file (see http://www2.sakoman.com/OMAP/preparing-a-bootable-sd-card.html and http://permalink.gmane.org/gmane.comp.embedded.openbricks.scm/515).
In my experience, the two most common symptoms of failed SD boot and their likely causes are:
The NT boots straight to stock -- most likely the boot partition's type and/or flags are not correctly set, or the NT cannot find the MLO in the boot partition (see comment re: the ordering in file copying above).
The NT screen stays dark for several minutes then eventually boots to stock -- most likely the MLO or u-boot.bin are corrupted. Check the exact size of these two files in bytes, they should be respectively 38,356 and 179,812.
Also, it should be noted that many NTs will boot off a SD card only from the power-off state and upon insertion of a powered USB cable.
To complete the making of the Recovery SDcard, download a recovery program .img file for sdcard (such as cwm_6012_sd.img or twrp_2220_sd.img from http://forum.xda-developers.com/showthread.php?t=1640958), rename it to recovery.img, and copy it to the SDcard boot partition.
Info/Tools for Restoring to Stock
For situations with absence of a working DYI backup copy, attempts can still be made to restore the NT to stock.
Restore to Stock ROM from Rooted Stock ROM (NT with intact stock Recovery and /factory partition): consider using the “8 failed boots” method documented at http://nookdevs.com/NookColor/RestoreToStock (it was written for the Nook Color but should be applicable to the Nook Tablet as well).
Restore to Stock ROM from Custom ROM:
A good source for resource/tool for restoring to stock is Succulent's repository at https://github.com/succulent/acclaim_recovery_sdcard; see its README file for an annotated index/description of the resource/tools and usage instructions. Another potential recovery tool is the repart.img described at http://raywaldo.com/2012/06/how-to-un-brick-a-nook-tablet-8gb-or-16gb/.
HOW-TO Guides for Installing CyanogenMod on Nook Tablet
Installing CM11 Internally on Nook Tablet
Installing CM10.x Internally on Nook Tablet
Updating NT Internal Emmc to CM11 from CM10.x
Building a CM10.1 (JB 4.2.x) SD card for Nook Tablet
Hi!
Partitioned my 32GB sdcard, and put CM10.2 on it, but when I check it I have only about 400mb of space or something like that. I had the same amount of space on a 4GB sdcard I used before. Why am I not able to use up the rest of the GB's?! Can someone tell me how to fix it, I don't know if I'm partitioning wrong or doing something wrong, but I want to be able to have lots of extra space for music, apps, etc. Please help! Thanks!!!
I believe you used a low level utility like dd or similar to flash an image onto a partition.
You need to run fsck on that partition, then run resize2fs to expand the ext2/3/4 partition.
Let's say your partition is /dev/block/mmcblk1p1
You would do (in a terminal):
adb reboot recovery
adb shell
# umount /dev/block/mmcblk1p1
# e2fsck /dev/block/mmcblk1p1
# resize2fs /dev/block/mmcblk1p1
After that, your partition will get expanded to whatever size you made it.
It takes a while so be patient. The larger the partition, the longer it will take.
Zenile said:
Hi!
Partitioned my 32GB sdcard, and put CM10.2 on it, but when I check it I have only about 400mb of space or something like that. I had the same amount of space on a 4GB sdcard I used before. Why am I not able to use up the rest of the GB's?! Can someone tell me how to fix it, I don't know if I'm partitioning wrong or doing something wrong, but I want to be able to have lots of extra space for music, apps, etc. Please help! Thanks!!!
Click to expand...
Click to collapse
if you got a prebaked image of a bootable cm card from somewhere, then it usually has 4 partitions on it that were set to the sizes the author of the card specified.
/boot
/system
/data
/sdcard
You would need to put the card in a PC, and use a disk partitioning utility to resize the partitions
some of the images include additional flash files that you install to expand the card's partitions for you. (succulent's), but
you have to do it as you install for the first time.
I prefer to build the card empty first, and load the boot files and zips manually.
linux tools like gparted, Parted Magic , booting from a live USB or CD work pretty well.
Windows based ones like Easus Partition master, or Paragon, not so good.
Mini Tool partition wizard (windows/free) sometimes works
this looks to be a decent write up
http://www.mobileread.com/forums/showthread.php?t=202660
mikeataol said:
...
I prefer to build the card empty first, and load the boot files and zips manually.
linux tools like gparted, Parted Magic , booting from a live USB or CD work pretty well.
Windows based ones like Easus Partition master, or Paragon, not so good.
Mini Tool partition wizard (windows/free) sometimes works
this looks to be a decent write up
http://www.mobileread.com/forums/showthread.php?t=202660
Click to expand...
Click to collapse
The write-up is also posted on XDA at http://forum.xda-developers.com/showthread.php?t=2098419. It was written back in the days of CM10.1, so to use it for CM10.2 or CM11:
Obtain the boot files: MLO, u-boot.bin, and flashing_boot.img -- as well as the files boot.img and recovery.img, from the /boot partition of the pre-made SD CM image. Make sure that MLO is the first file to copy to the freshly made /boot partition.
Substitute in the appropriate ROM and Gapps zip files corresponding to the particular CM build of interest.
So I got tired of my weird configuration of running the apps in a mounts2sd with a second ext4 partition on my sdcard and technically nothing should prevent us from running safestrap on the sdcard. So I looked around and it took me a while but I found Hashcode's source code and spent some time studying all the voodoo he does, and most of it is fairly straight forward. Small breakdown:
* Extend TWRP with ifdef statement to add new buttons
* sh scripts get called to perform the functionality for those button
* Swap out some links in /dev/block when you switch between slots and stock
* The entire boot partition including scripts, TWRP, etc are stored in boot image
* The boot image is stored in the stock system under /etc/safestrap
Like I said before, most of the functionality is done in borne shell scripts, but there is some hardcoding in TWRP like creating the .img file to /ss. I really don't want to try to recompile TWRP at this time. As such, I want to limit my changes to the borne shell and configuration INI files only. The simplest answer is to remap /ss from internal storage to the sdcard storage. Another option is to have "system" and "cache" in the internal storage and moving "data" to the sdcard. The difficulty here is since TWRP is hardcoded to create the .img file under /ss, I need to move it during the format stage which happens in the script. The danger with the first option I don't know if the phone will boot if the sdcard is removed. safestrap looks for that directory to figure out the mappings in /dev/block. I think if the directory is missing then it will attempt to create it. After that, things might go bad.
Anyway, what are your thoughts?
i wish and hope your still working on this..my phone is so low in internal storage..i cant even use a rom slot other than stock,,ive been useing stock slot ,flashing custom rom in stock slot....anyways hope you continue to figure this out..i know lots of people would appreciate it..thanks
So I've tried multiple ways and have had to step away, think about it some more, and come back to it. Essentially I was not able to get system to boot off of the sdcard. However, the good news is today I was able to have system and cache on internal storage and data on sdcard. So here are the keys to the kingdom that I have found....
The CM11 (and I assume other) ROMs there is a /system/etc/kexec/ramdisk.img file. This file is extracted (gunzip < ramdisk.img | cpio -iu) into the root directory "/" (rootfs). There is a shell script "/sbin/fixboot.sh" that gets executed by /init at the start of the android (on fs). That script essentially mounts /ss to /emstorage and does all the loop storage links to the system.img, cache.img, and data.img files. I was able to mount another /ss2 to my sdcard and point the userdata to /ss2/safestrap/rom-slot?/userdata.img. The limitation is that vfat limits all files to 4 GB max, so the userdata.img cannot be more than 4 GB of storage.
So an option is I can create an updated ramdisk.img file. You would just drop this into your /system/etc/kexec directory on the slot-rom you want to use it. The only file changed in ramdisk.img is /sbin/fixboot.sh. ramdisk.img is part of the CM11 distribution so you would need to replace it each time you perform an update on that rom slot. Other than that, safestrap would by default create userdata.img to be in internal storage.
The next part I'm going to look at is to create a f2fs partition on my sdcard and have my userdata use that f2fs partition. I figure I should good considerable more I/O as f2fs is suppose to be a good amount faster than ext3/4 and we wouldn't be going through a loop device from ext3 to vfat for all I/O. In addition, my data partition would no longer be limited to 4GB due to the file limitation size of vfat.
Thoughts...
So Spyder doesn't have f2fs on it so I've been running ext4. The kernel would need to be setup to be compiled with it. I have a second 6Gb partition formatted with ext 4 with writeback journaling but per my timing tests I don't think it has made a difference. Now I have more than enough space left in both the data and internal partitions. I don't know if it is just a placebo effect but my apps do seem to start slightly faster.
There doesn't seem much interest in this but it was a fun exercise for me. This will be good enough for me as I'll probably upgrade my phone sometime in the future.
Sent from my XT912 using XDA Free mobile app
Hi guys
Using ADB copied all the individual partitions (boot, aboot, system, recovery, etc) from my device to my sd card and then to my pc (Linux). Device is a Hisense Infinity H6 (HS-U800).
I am unable to mount any of the files, and have tried gdisk, fdisk, mount. I get a mount error or wring filesystem type.
Also trying to dd the entire block directly makes a single image that i am unable to read. I tried using gdisk to repair the gpt or recreate an mbr but to no avail.
I would prefer to work with the individual partitions as it appears that they have different filesystems for each. But when I specify the filesystem using mount i get a wring filesystem error.
Would appreciate any help, thanks.
PS
I'm using Ubuntu 14.04 LTS.
###
EDIT
###
Never mind, it turns out that if you dd directly from phone memory to pc android corrupts the files. Fixed it by using the sdcard as an intermediary step.