Database Info

Need FS Block Size: Bad Magic Block Error

SHORT: I need the filesystem block size (location would be nice too; however, I can guess that) so I can use e2fsck to restore my super-block.
LONG: I have been having issues for the past several days where I cannot umount /system. I thought it may have been a bad conversion going to/from or from/to rfs and ext4 and thought doing the conversion again had fixed it. But alas...it didn't.
I cannot umount the files system from adb ("device is busy" error) or CWMR ("Couldn't find valid filesystem superblock" in the log) on any version of ROM or using any kernel that I can find. Voodoo can seem to convert the filesystem (back/forth), but it only seem to work if I tell it to from the Voodoo Control and then reboot, which is odd. Still cannot umount.
When I try and use Navenedrob's Ext4 Formatter, it fails for /system. CWMR's log shows:
/tmp/tune2fs: Bad magic number in super-block while trying to open /dev/block/stl10
Couldn't find valid filesystem superblock
Should be fixable with e2fsck, if I can get the correct information from tune2fs.
Typically, the command should be:tune2fs -l /dev/block/stl10 OR tune2fs -l -L /system
That said, tune2fs is tell me "-l" is an unknown option.
Can someone who is familiar with tune2fs (or other filesystem tools) in the Android/BusyBox environment please post either the correct command or a list of the contents of the filesystem super-block? Please be sure to include if your /system is in EXT4 or RFS.
Man, I haven't see this **** in years. Even then, it was pretty exclusive to virtual/networked file system (e.g. LVM).
Any-who, much appreciated....

So, after sleeping on it, I came to realize an error in my thinking...
I cannot use e2fsck to fix an RFS filesystem. Even more upsetting is that I cannot seem to find anything on The Google about command line RFS tools. Guess I could try a conversion and EXT filesystem, then change the superblock, then convert back to RFS, but that seems awfully convoluted.
Suggestions?

I suggest you odin with pit and check repartition. That *usually* fixes everything.
Sent from my debloated ep1q charge......bro.

Thanks for the tip...I probably should have mention that I've used Pit+ED1 numerous times in a effort to fix this. It goes through successfully; however, it doesn't actually wipe the partition and I've found old files in /system.
UPDATE:
Last thing I tried is manually wiping everything from /system (in CWMR + adb shell). Also, wiped everything I could find having anything to do with voodoo or EXT4 (just in case). After power off then back to recovery, I found I could umount /system. Created a new partition, formatted, then wacked the partition.
I just (successfully) ran ED1+pit from the Samsung Flashing Utility (which I have NOT tried using before) and I am now in the process of upgrading. Once I have root back, I'll go see if the fix for /system was permanent.

[Q] Has anyone gotten encryption to work on Pyr'o'Ice ICS (or another ICS) ROM?

In the Pyr'o'Ice ICS Desensed 1.1.3 ROM, there is an option to encrypt the phone data. I would really like to do this, but unfortunately it does not seem to work. I have also tried the 1.1.0 ROM with similar results.
The UI allows me to start the encryption process, however one of the following happens (all of these happen within about 1 minute of starting the process, not over an hour like the informational message states it will take):
1. I am presented with a screen saying the encryption process failed, and I have to wipe the phone. The screen does not go away unless I do something.
2. I see the 'encryption process failed' screen, but only for a second and then the phone reboots into normal operation.
3. I do not see the 'encryption process failed' screen, and the phone boots into normal operation.
In case #2 and #3 I am able to use 'adb shell' to gain access to /data before I enter in the PIN on the device. Additionally, /proc/mounts is the same before and after the process.
I am running clockworkmod recovery 5.0.2.7 and have hboot 1.44.1107 with S-OFF. I always do a wipe before flashing any ROM.
Has anyone gotten this to work (even with another ROM), and if so how? Does anyone know how the encryption is supposed to work (e.g. is the filesystem supposed to be encrypted itself, or just some files)?
I really don't like the idea of having personal data on something that doesn't at least have data at rest encryption.

So far I've tried every ICS ROM I can find, and the ones that have an option for encryption all seem to have the same errors (from adb logcat):
D/Cryptfs ( 138): unmounting /data succeeded
E/Cryptfs ( 138): Cannot get block device name of extra partition
E/Cryptfs ( 138): Cannot load dm-crypt mapping table. (Invalid argument)
I/Cryptfs ( 138): Making empty filesystem with command /system/bin/make_ext4fs -a /data -l 1252770816 /dev/block/dm-0
E/Cryptfs ( 138): Error creating empty filesystem on /dev/block/dm-0
Which makes me think something is not right with my existing partitions or formatting, causing it to fail. Looking at the android crypto docs (which I can't post a link to currently, the forum won't let me), I got the idea to make the data filesystem a bit smaller than it's partition using make_ext4fs -l (at first I tried leaving an extra 16K at the end, then I tried 1M), but I got the same results. Previously I'd always used the wipe option in clockworkmod recovery, which I assume makes the filesystem stretch to the entire size of the partition.
Interestingly enough, doing both the inplace and wipe encryption methods seem to have the same results. Even though the inplace option is the only one presented in the UI that I can find, digging around through the code I found I could run "/system/bin/vdc cryptfs enablecrypto wipe <password>" to do the wipe+encrypt option.
Hasn't anyone gotten encryption to work on ICS?

Still no luck finding a build that this works on. Has anyone?
cuddlebug said:
So far I've tried every ICS ROM I can find, and the ones that have an option for encryption all seem to have the same errors (from adb logcat):
D/Cryptfs ( 138): unmounting /data succeeded
E/Cryptfs ( 138): Cannot get block device name of extra partition
E/Cryptfs ( 138): Cannot load dm-crypt mapping table. (Invalid argument)
I/Cryptfs ( 138): Making empty filesystem with command /system/bin/make_ext4fs -a /data -l 1252770816 /dev/block/dm-0
E/Cryptfs ( 138): Error creating empty filesystem on /dev/block/dm-0
Which makes me think something is not right with my existing partitions or formatting, causing it to fail. Looking at the android crypto docs (which I can't post a link to currently, the forum won't let me), I got the idea to make the data filesystem a bit smaller than it's partition using make_ext4fs -l (at first I tried leaving an extra 16K at the end, then I tried 1M), but I got the same results. Previously I'd always used the wipe option in clockworkmod recovery, which I assume makes the filesystem stretch to the entire size of the partition.
Interestingly enough, doing both the inplace and wipe encryption methods seem to have the same results. Even though the inplace option is the only one presented in the UI that I can find, digging around through the code I found I could run "/system/bin/vdc cryptfs enablecrypto wipe <password>" to do the wipe+encrypt option.
Hasn't anyone gotten encryption to work on ICS?
Click to expand...
Click to collapse

FYI I finally got it to work with the latest CM9 build, although the manual method I mentioned above was needed ("/system/bin/vdc cryptfs enablecrypto wipe <password>"), since the gui encryption option still didn't work.

[GUIDE][Using loop devices to workaround corrupt eMMC partitions]

Introduction
This workaround is for those of us (may only be me at this point?) who have bricked your Skyrocket by formatting a partition in an ICS-based kernel. This is where the kernel performed an MMC ERASE command and due to a bug in the eMMC firmware, the wear leveling data was corrupted.
The result is that accessing the affected section of eMMC causes the device to lock up. If we could find a way to avoid accessing those areas, the device might be usable again.
To further complicate matters, it seems that writing to the eMMC causes the problem to move around--probably because the eMMC tries to update the wear leveling data. As a result, any workaround needs to assume that no portion of the eMMC can be used for writable scratch space. That means it can't be used for /data, /cache, /tombstone, or "internal sd".
In this workaround, I create image files for the data, cache, and tombstone partitions on the external SD card. Then I modify the ramdisk to use the loop devices to mount these images as /data, /cache and /tombstone. The result is a bootable system.
The system obviously runs slower, but it is definitely tolerable. Usually the delay is noticed when opening an app for the first time. Another downside is that the "internal sd card" is gone and the "external sd card" is not USB mass storage mountable (since loop files are on it and therefore cannot be unmounted).
Thanks to seedub for the brainstorming session where we came up with this approach. I appreciate his Linux-fu.
Identifying If Important Partitions Work
On Skyrocket, for this workaround to be successful, we need at least the first 24 partitions to be okay. A few tests you should run:
Can you boot into download mode?
Can you boot into recovery mode?
In recovery, run "adb shell dd if=/dev/block/mmcblk0pX of=/dev/null" where X is 1-24. Do these all complete without error?
In recovery, can you install a ROM zip (e.g. CM9) without the device rebooting? (This is to test whether you can write to /system)
If the answer is "yes" to ALL of the questions above, then you are a candidate for this workaround.
Btw, always pull the battery and remove the USB cable before starting the above tests. Once the eMMC is locked up, it needs to be power cycled before it works again.
Creating The Image Files
You will need 1.5GB free. You can adjust the size of the data image to your liking. Boot into recovery and run the following commands in an "adb shell":
Code:
# Create an area on your SD card for the image files
mount /sdcard
cd /sdcard
mkdir emmc_workaround
cd emmc_workaround
# Create the data image file (1 GB - normally on /dev/block/mmcblk0p25)
dd if=/dev/zero of=/sdcard/emmc_workaround/data.img bs=1024 count=1048576
busybox losetup /dev/block/loop0 /sdcard/emmc_workaround/data.img
mkfs.ext4 -m 1 /dev/block/loop0
busybox losetup -d /dev/block/loop0
# Create the cache image file (297 MB - normally on /dev/block/mmcblk0p26)
dd if=/dev/zero of=/sdcard/emmc_workaround/cache.img bs=1024 count=304128
busybox losetup /dev/block/loop1 /sdcard/emmc_workaround/cache.img
mkfs.ext4 -m 1 /dev/block/loop1
busybox losetup -d /dev/block/loop1
# Create the tombstone image file (64 MB - normally on /dev/block/mmcblk0p27)
dd if=/dev/zero of=/sdcard/emmc_workaround/tombstone.img bs=1024 count=65536
busybox losetup /dev/block/loop2 /sdcard/emmc_workaround/tombstone.img
mkfs.ext4 -m 1 /dev/block/loop2
busybox losetup -d /dev/block/loop2
umount /sdcard
Modifying a ROM
We have to modify the ROM to make this work. With a lot of effort you might be able to modify a stock ROM, but I would recommend only modifying a built-from-source ROM. I used CM9 since, well, I am most familiar with it.
Here is the outline of the changes:
Disable the internal SD card on partition 28
Make the external SD card non-removable and disable USB mass storage for it
Rework the init scripts to mount the external SD card, attach the images to loop devices, and mount /cache, /data and /tombstone on their new loop devices
Apply patch #0001 (which is attached) to the device/samsung/skyrocket tree of CM9. See these build instructions: http://forum.xda-developers.com/showpost.php?p=25363482&postcount=3
Apply path #0002 if you want to move /cache to tmpfs instead of an image file. I'm still experimenting with this one.
Possible Improvements
I'm sure there are some ways to speed things up. I'll add to this list as we come up with more ideas.
Use smaller image files
Put /cache into a ramdisk -- probably would increase responsiveness a great deal (see patch #0002)
Repartition external SD card instead of using image files

so if some1 had a true brick where device can not turn on, this method still wont unbrick it

Mr. Top, you, sir, are a genius. Hopefully this will help us move forward with a possible unbrickable mod.
Sent from my SAMSUNG-SGH-I727 using XDA

Idea, What about cloning the whole emmc card boot partition and all to a microsd

vincom said:
so if some1 had a true brick where device can not turn on, this method still wont unbrick it
Click to expand...
Click to collapse
Yup. This is only for the Emmc lockup bug where it affects the data partitions,
Sent from my iPad using Tapatalk HD

tjsooley said:
Idea, What about cloning the whole emmc card boot partition and all to a microsd
Click to expand...
Click to collapse
That would definitely work if the boot partition of the Emmc was intact. I think partition #8. I don't know of a way to redirect the base kernel boot until it starts executing the init scripts.
Sent from my iPad using Tapatalk HD

In theory wouldn't you just have to change the memory address that the phone goes to when it first boots so it never looks at the original boot partition?
Sent from my SAMSUNG-SGH-I727 using XDA

Could you tell me what exactly causes this. So i can avoid it.
im currently on skyics latest leak with clock work mod touch recovery
i just would like to know what not to do. thanks

tpmullan said:
In theory wouldn't you just have to change the memory address that the phone goes to when it first boots so it never looks at the original boot partition?
Sent from my SAMSUNG-SGH-I727 using XDA
Click to expand...
Click to collapse
the memory address the pc points to on first boot/after resets is implemented in hardware iirc,,, bootstrapping etc.

Is there a way to unbrick this device without a JTAG using only the EMMC program? My answer to all the questions in this post is NO, my device does not turn ON at all but when I plug it into the computer, it shows on the Device Manager under COM7 port. I have installed the Qualcomm HS-USB QDLoader 9008 driver and it appears in EMMC software as in Download mode. I've searched on the internet and I cannot find a solution that is not using JTAG. Thanks for answering.

[Q] Asus Memopad ME301T CM11 encryption

In a thread under the TF300T devices, nikybiasion, started a thread for the Unofficial Cyanogenmod 11.0 for ME301T. It's a beautiful ROM, with all the Cyanogenmod goodness I love in my Android devices.
I notice one issue in that although I can encrypt the data partition my device will not boot further after I entered the password. It gets stuck showing the little Android picture and never proceeds to the CM boot animation. I suspect it may be something specific to my device (something I did while playing with other roms). I'd appreciate it if someone can point me in the right direction in analysing this problem.
Usually I perform adb logcat to see what error messages pop up (very useful once when the data partition had no space left for the encryption metadata in the footer on the stock rom - my fault) but I have no idea how to get logs after rebooting when encryption successfully finished. So first step is I'd like to get to the logs - any idea how I can do this having rebooted after encryption is done?
Regards
Paul

More information on ME310T encrypted boot problem
I flashed the Crombi-KK rom today (wow, what an awesome compilation) but unfortunately I'm experiencing the same problem as before with booting with an encrypted data partition.
Fortunately adb responds as soon as Crombi starts to boot. Attached is the logcat.
Presumably the following points to the problem:
E/Cryptfs ( 131): unmounting /data failed
W/SocketClient( 131): write error (Broken pipe)
W/SocketClient( 131): Unable to send msg '200 6 -1'
Click to expand...
Click to collapse
I'm not sure what to make of it though. Any thoughts would be appreciated.
Regards
Paul

Possible cause for non boot with encrypted data partition on ME301T
I think I might have found a possible cause for this problem.
As indicated above the error indicates that data cannot be unmounted.
E/Cryptfs ( 131): unmounting /data failed
Click to expand...
Click to collapse
It turns out data is used for temporary space
tmpfs /data tmpfs rw,seclabel,nosuid,nodev,noatime,size=131072k,mode=771,uid=1000,gid=1000 0 0
Click to expand...
Click to collapse
however it cannot be unmounted as there is another partition mounted under /data/wifimac
/dev/block/mmcblk0p5 /data/wifimac vfat rw,relatime,fmask=0077,dmask=0077,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0
Click to expand...
Click to collapse
If I unmount this directory before I enter my password the device boots normally. I have just tried this with Crombi-KK rom and will attempt to do the same with CM11 Unofficial for the ME301T.
Regards
Paul

Problem solved ME301T now boots past encryption
I still can't get logcat output from CM11 Unofficial. What I did notice with the Crombi-KK ROM is that as in the previous post the failure occurs when the /data directory fails to unmount before the encrypted partition is mounted.
On Crombi it also appears that Wifi is broken. It looks like /data/wifimac does not unmount. An application that needs to run in order to build nvram.txt, wifimacwriter, fails because the file /data/wifimac/wifi_mac is missing (partition mmcblk0p5). Creating this file solved this problem and Crombi seems to boot past encryption.
It is possible that in my vigorous flashing and wiping of various roms I whacked or corrupted the partition mmcblk0p5 containing this information. Although strictly not necessary, it seems wifimacwriter fails if the files don't at least exist.
In short, the fix is as follows:
Code:
# mount -t vfat /dev/block/mmcblk0p5 /mnt/sdcard/tmp/ # Any convenient mount point will do
# touch /mnt/sdcard/tmp/wifi_mac
# reboot
So it seems my hypothesis in post 1, that the problem might be specific to my tablet, was correct - I broke it. You may all disregard these 4 posts. Carry on, nothing to see here...

Link2SD with S-ON? Yes, I did.

This was driving me up a tree the last few days. I've dealt with Link2SD on quirky devices before, but this one forced me to understand just how Link2SD implemented the mount script, and hooray, I got it.
Now basically, I'm assuming you already know what Link2SD is for, and I'm also assuming that your S-ON device is already rooted and you have a custom recovery partition to the likes of TeamWin or CWM installed and functioning. For my device, I have a recently rooted HTC Desire 510 acquired from FreedomPop.
With the help of DiskInfo, I determined that this device supports ext4, so that's the filesystem I'm using.
____________________
So, What's the magic file anyway? (or, How does Link2SD Work?)
Link2SD has to mount the second SD partition rather early to make sure the files on it are accessible before Android starts looking for the apps. It does this by replacing an existing binary file with its mount script. Don't worry though, before replacing it, it renames the binary file and calls it at the end of the script. The file is:
/system/bin/debuggerd
That's it, and if you want to use Link2SD on your S-ON device (without resorting to quick-reboot every other boot, which on my device at least was spitting an error for every moved app or directory), you'll need to manually do the steps Link2SD would normally do automatically. You'll need to gather some info and other preparation. I'll provide a sample script (which came from my Proscan tablet), which you must edit to match your device information before flashing.
Here's the sample script. Save as "debuggerd" :
Code:
#!/system/bin/sh
#added by link2sd
LOG=/data/link2sd-debuggerd.log
echo "$(date) mounting..." > $LOG
sleep 2
mount -t ext4 -o rw /dev/block/vold/179:2 /data/sdext2 1>>$LOG 2>>$LOG
mount -t ext4 -o rw /dev/block/mmcblk0p2 /data/sdext2 1>>$LOG 2>>$LOG
mount >> $LOG
echo "$(date) mount finished" >> $LOG
echo debuggerd.bin launched >> $LOG
exec /system/bin/debuggerd.bin
You'll notice two mount lines, these are the ones in need of edit. What you'll need to find out:
* The 2nd SD partition type. If you did the partitioning, you should already know this one. As I already mentioned, I used ext4.
* The block number of the second SD partition. I like DiskInfo for that one. The script might be okay for your device, or it might not depending on how storage is set up. The desire was mmcblk1p2.
* The vold id of the second SD partition. Vold is the standard method of managing partition mounts in Android, so is Link2SD's preferred mount method. The block number line is only included as a backup in case the mount by vold id fails. If Link2SD is already installed (and it should be) and the mount script (supposedly) created, it will have already mounted the second partition, so you should be able to go into terminal and type
mount | grep sdext2
to retrieve this number. 179:2 is typical, but my desire was something like 179:58. Best to look it up.
Make the necessary edits, then save the file somewhere accessible to your recovery, such as the root of the sd card (first partition).
Double check the mount info in the script.
____________________
The manual install.
Now for the fun part. Reboot into your custom recovery.
Make sure /system and the sd card are mounted.
Enter the file manager.
Navigate to /system/bin.
Rename debuggerd to debuggerd.bin .
..This is to match the last (exec) line in the script, and what makes the mount stage a seamless insertion into the boot process.
Navigate to where you saved the replacement debuggerd script. Select Copy.
Navigate back to /system/bin and Paste. Confirm if necessary.
Once the custom debuggerd script is copied, you'll need to make sure it's executable. Run chmod on it, something like 755 will be fine. Confirm if necessary.
You also need to make sure the mount directory exists. Navigate to /data , if it doesn't already exist, make a directory called sdext2 .
That should be it. Reboot into the system. If everything is correct, you should boot normally with the second SD partition already mounted before the apps are loaded. I have so far been running Link2SD on the Desire for about a week, and have not run into any *unusual* problems.
____________________
Disclaimer.
This method was successful for me. Your mileage may vary. Editing the system partition always has some inherent risk. What you do to your device is on you; I will not be held responsible for a boot-loop, bricking the device, random interplanetary calls, or any other damages incurred, physical, monetary, or otherwise following your reading of this post. Proceed at your own risk.
---
Sent from my HTCONE using XDA Free mobile app

Having revisited this thread, I noticed I forgot a step, now fixed.
I still use this phone. A couple small glitches have developed over time which may be related to using a cheap sd card, but, basically I have an app with a bad id, it's disabled anyway so I just ignore it on boot (the I'm feeling lucky button). Also, if there is a glitch that prevents a proper shutdown, the second partition may get corrupted. It is impossible to boot with the card unmounted without causing a bunch of other app related issues, so the only way to deal with it cleanly is shut down, remove the card, and fix it on another computer (preferably linux), then reinsert the card before booting the device back up.
Also, after another week, "app data" on the card stopped working right: existing moves caused errors and new moves failed, so I just moved all app data back to internal. Again, this may be just related to using a cheap card, and it was around the same time the bad id occurred, so I'm sure there's some unresolved corruption that just plain isn't getting fixed without a factory reset. It's getting about time to do that, so if I can score a new card and some time to set it up, I'll post how it goes. Apps themselves, dolvik, and libraries continue to work on the sd card without issue on most apps.