[Q] [Webtop] Move /osh/usr/share to /preinstall? - Atrix 4G Q&A, Help & Troubleshooting

Hello everyone!
Is it possible to enlarge free space on /osh by moving the biggest directory (/osh/usr/share) to /preinstall directory to symlink/mount it to previous location?
Thanks!

It should be possible, if you do it right.

Well, something is not right. I moved /usr/lib to /preinstall and symlinked it. Everything is fine!.. until a reboot
I changed /osh/ubuntu.sh, added remount lines from Gentop
/bin/mount -o remount,rw /
/bin/mount -o remount,rw /preinstall
Click to expand...
Click to collapse
but after reboot /preinstall is always "Device is busy".
Can someone help me? This is just a great possibility to get more space for webtop without SD - and it works much faster! If I could free some more space via uninstalling unused apps - I could even install OpenOffice =)

I am told that android partitions are somewhat special/different than what you see on standard linux hard drives.
Maybe an expert can step forward and point us to some good information on how android does things, until then I think trial & error is the only option.
You could try: /bin/mount -o rw,remount /dev/block/mmcblk0p17 /usr/lib
One other thought, it may be possible to create a fstab entry instead of putting a mount command in /osh/ubuntu.sh

tamuin said:
I am told that android partitions are somewhat special/different than what you see on standard linux hard drives.
Maybe an expert can step forward and point us to some good information on how android does things, until then I think trial & error is the only option.
You could try: /bin/mount -o rw,remount /dev/block/mmcblk0p17 /usr/lib
One other thought, it may be possible to create a fstab entry instead of putting a mount command in /osh/ubuntu.sh
Click to expand...
Click to collapse
That's a good idea. Will write back in minutes!

Hi. If you really need more space, best way is to use WebtopToSD apk. I have 14GB for osh with a linuxdisk chroot and it works great.
Send from my Atrix 4G

tamuin said:
I am told that android partitions are somewhat special/different than what you see on standard linux hard drives.
Click to expand...
Click to collapse
Kinda. Yes, the partition layout and partition handling is unusual and unconventional (at least compared to the PC world), but the partition contents (ie. the filesystem) is perfectly normal, exactly what you'd expect to find.
As far as this idea goes, I'd recommend not using the preinstall directly but instead creating a folder on preinstall dedicated to osh. So probably something like this:
Code:
#-- just the first time
mkdir -p /preinstall/osh-lib
cp -a /osh/usr/lib/* /preinstall/osh-lib
rm -rf /osh/usr/lib/*
#-- every time
mount --bind /preinstall/osh-lib /osh/usr/lib
This is just an idea, though it is completely untested.

jisse44 said:
Hi. If you really need more space, best way is to use WebtopToSD apk. I have 14GB for osh with a linuxdisk chroot and it works great.
Send from my Atrix 4G
Click to expand...
Click to collapse
Of course I know that techique =) My goal is to build small and usable Webtop without any SD cards
ravilov said:
Kinda. Yes, the partition layout and partition handling is unusual and unconventional (at least compared to the PC world), but the partition contents (ie. the filesystem) is perfectly normal, exactly what you'd expect to find.
As far as this idea goes, I'd recommend not using the preinstall directly but instead creating a folder on preinstall dedicated to osh. So probably something like this:
Code:
#-- just the first time
mkdir -p /preinstall/osh-lib
cp -a /osh/usr/lib/* /preinstall/osh-lib
rm -rf /osh/usr/lib/*
#-- every time
mount --bind /preinstall/osh-lib /osh/usr/lib
This is just an idea, though it is completely untested.
Click to expand...
Click to collapse
Thank you for your ideas.
So, I must make a conclusion:
1. I forgot to disable load_pia.sh in /system via ADB/Terminal
Code:
$ su
# cd /
# mount -o remount,rw /dev/block/mmcblk0p12 /system
# mv /system/bin/load_pia.sh /system/bin/load_pia.sh.disabled
This prevents mmcblk0p17 mounting to /preinstall
2. I used webtop2sd's mount and mount.orig - and added /preinstall mounting there just befor last mounting attemps of ubuntu.disk
After all everything works like a charm
Uninstalled most of apps, used gnome-appearance-properties to change metacity and gtk2 themes, saved that theme as my own, uninstalled every other theme... The only cons of this techique - still no enough of free space to install OpenOffice, and I decided:
1. to stop with this experiment - as everithing works as I expected;
2. not to symlink folders to /data for OpenOffice - because I will lose everything after first wipe.
If I could resize /osh or /preinstall partition via shrinking /data

I like your idea...
NemeZZiZZ said:
If I could resize /osh or /preinstall partition via shrinking /data
Click to expand...
Click to collapse
Changing the partition sizes has been other devices, see this post:
http://forum.xda-developers.com/showpost.php?p=22157605&postcount=25
I asked if anyone had tried it with the Atrix 4G in this post:
http://forum.xda-developers.com/showthread.php?t=2207918
...but I was strongly cautioned against it, I still might try it someday when I have the time.
Thanks for the info on what you did.

Hello! I already read that before, and I tried to "parted" mmcblk0 - but no success: as I remember, I can't get partition list because of error, and after googling that error I concluded, that partitions are made with error or overlapped.

Related

Using all of the NTs storage

I posted this in the nook touch forum by mistake. Please read below and let me know what you think.
One of the biggest issues I had with my nook was the 16/1GB division between content I can load and content from B&N/etc. Not being able to use that 16GB how I wanted was something I set forth to fix. Here is my solution to make this usable to non-rooted apps.
1) Root if not already rooted.
2) Make a directory inside of /data. I chose /data/usrdata.
3) remount / as RW with the command mount -o remount,rw -t rootfs rootfs / (credit to Indirect for this, as I could't find the command to do so)
4) mkdir /mnt/internal . We need somewhere to mount /data/usrdata/ and /mnt is public enough.
5) busybox mount -o bind /data/usrdata /mnt/internal. Mounts /data/usrdata to /mnt/internal.
6) For good measure, chmod 777 /mnt/internal and chmod 777 /data/usrdata.
Now, /mnt/internal should have whatever free space /data has, and should be read/write accessible from any program. A quick test with touch+terminal emulator shows new files as being created with RW permissions for all.
Alternatives: When I was initially thinking about ways to do this, my first reaction was to just open up /data to be read only to all, then have my usrdata folder be read/write all. However, I know part of android's app security model depends on some of these permissions. While I can't think of anything breaking or sensitive data being leaked, I decided against it. If anyone has any thoughts as to that scenario, I am very interested in hearing about it.
USB support: This will *not* be mountable under USB. Unfortunately you are still limited to transfering the data from a computer to the B&N internal storage or SDcard first, then moving the data internally. The problem that I see with this is similar to my understanding of the galaxy nexus situation, where the system can't unmount its /data partition and let the USB host take over. Another alternative to this could be to write an image file and mount that over usb (I've done this on my Evo, it worked so-so). Problem with that is that it really wouldn't grow/shrink with the storage. I suppose you could do some shell trickery and pipe it through gzip somehow, but that wouldn't help very much.
Let me know what you think and if you have any ways to improve this.
UPDATE: Persistance:
To make this persistant across reboots, run these commands as root:
1) mount -o rw,remount -t ext4 /dev/block/platform/mmci-omap-hs.1/by-name/system /system
2) echo mount -o remount,rw -t rootfs rootfs / >> /system/bin/clrbootcount.sh
3) echo mkdir /mnt/internal >> /system/bin/clrbootcount.sh
4) echo busybox mount -o bind /data/usrdata /mnt/internal >> /system/bin/clrbootcount.sh
5) echo mount -o remount,ro -t rootfs rootfs / >> /system/bin/clrbootcount.sh
All this does is put the following at the end of clrbootcount.sh
mount -o remount,rw -t rootfs rootfs / #Remounts root as RW. Root is regenerated at each reboot, so /mnt/internal is never going exist on a fresh startup
mkdir /mnt/internal #make /mnt/internal, see above
busybox mount -o bind /data/usrdata /mnt/internal #Binds the directory
mount -o remount,ro -t rootfs rootfs / #remounts root as RO. Unsure if this is necessary, but since it runs as RO, its probably better safe than sorry.
Thanks to eded333 for mentioning a good place for the script.
Click to expand...
Click to collapse
I was the one who wrote the script gameman. >.>'
Very nicely done.
Does Android possess a fstab? If so, could these changes (also) be made there and still be persistent?
this is a good work around
Am I understanding this correctly in that if I follow these guidelines I can move my data over to the Barnes and noble alotted storage that we were complaining about not having available?
Sent from my Nook Tablet using Tapatalk
downsay said:
Am I understanding this correctly in that if I follow these guidelines I can move my data over to the Barnes and noble alotted storage that we were complaining about not having available?
Sent from my Nook Tablet using Tapatalk
Click to expand...
Click to collapse
That is correct, from what I understand as well.
Sent from my BNTV250 using Tapatalk
liquidzoo said:
Very nicely done.
Does Android possess a fstab? If so, could these changes (also) be made there and still be persistent?
Click to expand...
Click to collapse
From what I could tell, it does, but its not the normal /etc/fstab. It looks like they have a daemon or something that mounts the sdcard and the media (1gb) drive. When I first looked at its version of the fstab, it looked like it only took a block device, which doesn't quite work for the directory binding.
downsay said:
Am I understanding this correctly in that if I follow these guidelines I can move my data over to the Barnes and noble alotted storage that we were complaining about not having available?
Click to expand...
Click to collapse
Yes that is correct. You still cannot mount it under USB, however. If you have some other way of getting the files there, however, its open as an option. I've been using swiFTP (in the market) to do that. Could also copy and move from the media/sd cards that do mount to the PC, but thats a two step process. I've thought about getting MTP setup so that you can see that folder via USB, but haven't really had a chance to look into how that would work.
*Note, when using swiFTP and other programs more than likely, you may get some file permissions errors or other odd errors about corrupt files. These are just the file permissions that the program defaulted to, and can be fixed by doing a 'chmod -R 777 /mnt/internal/'. Don't have this problem on sdcard or media because they are just FAT32 formatted, which don't support permissions.
Trying to understand ...
gameman733 said:
I posted this in the nook touch forum by mistake. Please read below and let me know what you think.
Click to expand...
Click to collapse
I don't understand the purpose of the mounts. Why not just create /data/usrdata and put your stuff in there?
I know /data has "access-only/no-read" access for non-system apps, but anything in /data/usrdata/ should be visible (and no need to modify clrbootcount.sh).
If you need "/mnt/internal" (I don't see the need for that either), why not just use a soft link (which is permanent)???
The primary reason for using the mounts was that I was originally planning on trying to mount it in a way that would ignore file permissions, but didn't know at the time that you can't do that with a bind mount. Using a simple link would be just as effective in this case.
However.. / is Read only. Even when remounted read-write, this filesystem is actually regenerated every boot. So nothing in /mnt would stay past the next restart.
The purpose for having it in /mnt (could have been anywhere, I suppose, but it seemed a little more appropriate) was for apps that can't browse /data. For example, gameboid and related programs would get to /data and show nothing, because you can't browse it as a non-rooted app. Having a symlink or bind mount elsewhere in the filesystem where they can browse helps with that. The alternative was to remove the no-browsing permissions from /data. I didn't feel comfortable with doing this, however, as I'm sure there are some security risks to doing this. It probably isn't a big deal, but since we have the tools to do it while maintaining those existing permissions, why not go ahead and do that?
Is there a solution that does not require being rooted?
[I was gonna start a thread about this 1.0 GB vs 16GB issue. Glad someone
beat me to it. ]
A day or two ago, I side-loaded a couple of movies, each about 400-MB in size,
and was surprised to notice that I had only 20% of my 1.0GB remaining.
I haven't 'bitten the bullet', and got brave enough to 'root' my Nook yet.
(Still not sure yet whether my wife will keep it, and it's an XMAS-gift for her.)
But, I'm quite fluent in Linux, so if we DO keep it, I'll definitely get around
to doing the 'root'.
Meanwhile, if anyone does find a way, without rooting, to re-allocate these
built-in assigned storage quotas, please post it in this thread.
Cheers...
gameman733 said:
The primary reason for using the mounts was that I was originally planning on trying to mount it in a way that would ignore file permissions, but didn't know at the time that you can't do that with a bind mount.
Click to expand...
Click to collapse
To solve this issue I've compiled fuse kernel module and bindfs userspace utility. Bindfs is similar to "mount -o bind" but can override permissions and ownerships. I can share how-to instruction and compiled binaries if you want

Change streak's innersd to 3 partitions,without disassembling phone,keep old data

Remember to fully backup your system first
do 1 -4 after streakmod 0.3.2.8
do 5 with newest mke2fs、e2fsck、busybox (or from the Attach Files )
1.mount data、sdcard
mkdir /datas
mount -t ext3 /dev/block/innersd0p6 /datas
mount -t vfat /dev/block/mmcblk1p1 /sdcard
2.backup
mkdir /sdcard/LOST.DIR/
tar -cpf /sdcard/LOST.DIR/data.tar /datas
3.del old partition ,add new partitions
umount /cache
umount /datas
fdisk /dev/block/innersd0
d
6
n
l
+1G
n
l
t
7
b
w
4.format new partitions
mke2fs -F -j -b4096 -m0 /dev/block/innersd0p6
e2fsck -yf /dev/block/innersd0p6
busybox mkfs.vfat /dev/block/innersd0p7
5.restore
mount -t ext3 /dev/block/innersd0p6 /datas
rm -r datas
tar -xpf /sdcard/LOST.DIR/data.tar
6.use new added partition
mkdir /sdcard/usbdisk
mount -t vfat /dev/block/innersd0p7 /sdcard/usbdisk
Remember to fully backup your system first
video
http://player.youku.com/player.php/sid/XMzQ4NjY2Mzg0/v.swf
the Attach Files can change partitions automaticly
View attachment 2to3.zip could add new partition
View attachment 3to2.zip could change it back to 2 partitions
View attachment 3to3.zip is used to change the partition size
(change “+1G” in part.sh of the zip packages )
View attachment AutoMount.zip could mount the new partition after boot
in DSC 0.71, it will be mounted to /mnt/usbdisk ,the real u-disk will be mounted to /sdcard/usbdisk
in other systems,it will be mounted to /sdcard/usbdisk ,then you cann't umount your sdcard before umount /sdcard/usbdisk
After added new partition , you must not do Factory Restart or fastboot userdata.img , otherwise it will change the partitions back
so when you have flashed a new ROM or if you want to do factory restart ,you may need to fastboot my View attachment userdata.zip the other way is to do "wipe data /factory reset" and "selective restore View attachment firstboot.zip" by StreakMod 0.3.2.8
full restore by SreakMod is safe,it won't change partitions
Remember to fully backup your system first
What is the advantage of this? Also, there appears to be some formatting problem with your post, with some lines of single letters. Makes it really confusing looking.
lordmorphous said:
What is the advantage of this? Also, there appears to be some formatting problem with your post, with some lines of single letters. Makes it really confusing looking.
Click to expand...
Click to collapse
Those are likely the commands to use fdisk itself. It's basically "what to press" so you could literally do it blind.
The innerSD is sometimes large enough to forgo using the outerSD completely, esp if you have a larger innerSD.
Given it's age, the S5 has an absolutely huge /data partition, it's nearly 2gb when comparable devices are 1gb tops (such as the venue)
Have you considered making your new partition and naming it /sdcard instead?
The correct way on HC and newer is to make /data/media a symlink to /sdcard and use MTP to mount it. The actual sdcard becomes /sdcard2
The S5 kernels do not support mtp so you cant do this.
But what if you took that new partition you made? innersd0p7 becomes /sdcard and the actual sdcard becomes /sdcard2. Then you could also use your partition for apps that refuse to work without an sdcard present (like titanium backup) Still you wouldnt be able to mount it.
The GNote does /sdcard/sdcard2 or something as a hack to support both without MTP, but it's hack and ultimately different from the standardized sdcard/sdcard2 in newer android.
ALso if you're repartitioning the innerSD, not only is a backup a good idea, but it's recommeneded to have access to the card itself. If for some reason the repartition goes wrong you might end up not being able to boot. Reformatting the sdcard externally will fix it.
OK, at first glance this line
fdisk /dev/block/innersd0
d
6
n
l
looked like it should have been fdisk /dev/block/innersd0p6
Like I said, first glance. Guess that is what I get for replying to posts this late at night....time for bed.

[Q] Unable to change permissions or delete a specific file WITH root

Hello Gentlemen. Sorry to disturb you with a noob question but I cannot solve it for the life of me and I have tried everything I could find on the forums. I have an Aluratek Cinepad AT107F. I have successfully rooted it. I have full super user permissions and I have no problems deleting any files or folders EXCEPT one directory. Let me explain the situation.
I recently did a firmware update and it included brand new APKs for Youtube, also added Google Play Support, and added Angry Birds.
I am unable to update Youtube to the latest version. It gives a "Package file was not signed correctly. Uninstall the previous copy of the app and try again.".
So I attempted to do just what it had asked. I rooted just to do this. I tried removing it with Titanium Backup, I tried Root Uninstaller, I tried Root Explorer, I tried deleting using the "adb shell rm" command. I still get a "Read-only file system".
Even though I have root and granted root access to Root Explorer, I am unable to change the permissions for this /oem/apps/ directory. It's on the top level of the internal memory. I have no external SD card.
I've spent 10+ hours trying to figure this out and I'm sure someone knows something that I don't and can fix this super easy. I'm asking for your help, you're my only hope!
Your issue is that the update gave you modded files that the OEM doesn't want deleted. Most likely do to them not have permission from Google to do so. You will be hard pressed to find help here as we mainly deal with official releases and apks.
Wayne Tech S-III
zelendel said:
Your issue is that the update gave you modded files that the OEM doesn't want deleted. Most likely do to them not have permission from Google to do so. You will be hard pressed to find help here as we mainly deal with official releases and apks.
Wayne Tech S-III
Click to expand...
Click to collapse
Am I in the wrong sub forum? Is there another forum at XDA-Developers that could help?
Vindicoth said:
Am I in the wrong sub forum? Is there another forum at XDA-Developers that could help?
Click to expand...
Click to collapse
No nowhere on the site really deals with unofficial android versions and knock of devices. Your best bet will be the OEM
Read the error message again. The file is on a read-only filesystem. That is why you cannot delete it. In other words, you lack permission to write to the partition.
System partitions get mounted readonly to prevent modification. To remount /system as read-write,
Adb shell mount -o remount,rw /system
If you get "not permitted" error, your ROM's ro.secure means you cannot execute mount operations passed with adb command. So instead you must first open the shell,
> AdB shell
# mount -o remount,rw /system
Now you can delete:
Adb shell rm /system/file
If it is a directory
Adb shell rm -rf /system/dir
If you accidentally mistype that last command with a space beyween that first forward-slash and "s" you will have a very unworkable device....and that's why it is mounted read-only.
If the file is on a different read only filesystem, identify the partition the file is on and
Adb shell mount -o remount,rw /dev/block/id /LocToMountTo
You may have to specify the type
-t fstype
Adb shell mount
will tell you this
Don't forget to remount it as read-only (ro) when you are done
anotherguy19 said:
Read the error message again. The file is on a read-only filesystem. That is why you cannot delete it. In other words, you lack permission to write to the partition.
System partitions get mounted readonly to prevent modification. To remount /system as read-write,
Adb shell mount -o remount,rw /system
Now you can delete:
Adb shell rm /system/file
If it is a dir
Adb shell rm -rf /system/file
If you accidentally mistype that last command with a space beyween that first forward-slash and "s" you will have a very unworkable device....and that's why it is mounted read-only.
If the file is on a different read only filesystem, identify the partition the file is on and
Adb shell mount -o remount,rw /partition/id /folder
You may have to specify the type
-t fstype
Adb shell mount
will tell you this
Don't forget to remount it as read-only (ro) when you are done
Click to expand...
Click to collapse
Well I can access /system just fine. The problem is the /oem/apps folder is not in the /system folder. It's in the top level folder.
/system and /oem/apps are in the root directory. I can change the permissions on /system just fine using Root Explorer, but when trying to change the permissions using any method possible, /oem wont change.
This happens alot on Devices out of China and other places that sell knock offs. They make it so you cant delete their apps and if you do then it bootloops which only a reflash will fix.
Vindicoth said:
Well I can access /system just fine. The problem is the /oem/apps folder is not in the /system folder. It's in the top level folder.
/system and /oem/apps are in the root directory. I can change the permissions on /system just fine using Root Explorer, but when trying to change the permissions using any method possible, /oem wont change.
Click to expand...
Click to collapse
/system and /oem are different partitions then
mount | grep oem
or
adb shell mount | grep oem
Will tell you what /dev/block/xxxx the /oem is on and if it is mounted as read-only (ro)
> adb shell
# mount -o rw,remount /oem
zelendel said:
This happens alot on Devices out of China and other places that sell knock offs. They make it so you cant delete their apps and if you do then it bootloops which only a reflash will fix.
Click to expand...
Click to collapse
Ever get the feeling that you're writing in invisible ink lol?.. Eventually he will listen! You have great patience!
zelendel said:
This happens alot on Devices out of China and other places that sell knock offs. They make it so you cant delete their apps and if you do then it bootloops which only a reflash will fix.
Click to expand...
Click to collapse
Referencing zelendel's post, the device could fail to boot because it is looking for the removed app in /oem
So you could try to remove it from being referenced by the startup scripts.
Try doing a search for files that could be referencing the apk you want to remove.
> adb shell
# grep -r AppName.apk /system/etc
CtrlAltDelIrl said:
Ever get the feeling that you're writing in invisible ink lol?.. Eventually he will listen! You have great patience!
Click to expand...
Click to collapse
If it bootloops then I'll just flash it again, but its worth a try isn't it? Thanks anyways.
anotherguy19 said:
Referencing zelendel's post, the device could fail to boot because it is looking for the removed app in /oem
So you could try to remove it from being referenced by the startup scripts.
Try doing a search for files that could be referencing the apk you want to remove.
> adb shell
# grep -r AppName.apk /system/etc
Click to expand...
Click to collapse
Thank you for your very helpful posts and willingness to help me possibly bootloop my device
when I type the grep command it says it is not found, so I will download busybox onto my tablet and try those commands.
Vindicoth said:
Thank you for your very helpful posts and willingness to help me possibly bootloop my device
when I type the grep command it says it is not found, so I will download busybox onto my tablet and try those commands.
Click to expand...
Click to collapse
So after running mount | grep oem it shows this
[email protected]:/ # mount | grep oem
/dev/block/nandi /oem cramfs ro,relatime 0 0
So is it possible to change this directory to rw? I tried the mount -o rw,remount oem but it doesnt show anything after i input the command
[EDIT]
So it seems that the cramfs file system is read-only.
Vindicoth said:
Thank you for your very helpful posts and willingness to help me possibly bootloop my device
when I type the grep command it says it is not found, so I will download busybox onto my tablet and try those commands.
Click to expand...
Click to collapse
I love breaking things. It's only then we can figure out how it works.
Busybox is exactly what you need.
grep will search for strings within all files and subdirs of /system/etc; matching whatever you type for "AppName.apk"
It is a case-sensitive search unless you add
-i
So
grep -ri ....
or
grep -r -i....
Both would work.
But you don't even know if you need to be searching for a file to modify.
You may want to go ahead and delete the file and reboot.
If it fails, note the file(s) you deleted and know the system is looking for them and then proceed with seeing if you can identify a file in /system/etc that is looking for it's presence.
---------- Post added at 11:59 PM ---------- Previous post was at 11:53 PM ----------
Vindicoth said:
So after running mount | grep oem it shows this
[email protected]:/ # mount | grep oem
/dev/block/nandi /oem cramfs ro,relatime 0 0
So is it possible to change this directory to rw? I tried the mount -o rw,remount oem but it doesnt show anything after i input the command
[EDIT]
So it seems that the cramfs file system is read-only.
Click to expand...
Click to collapse
Commands that complete "quietly" mean they were successful.
If you type
# mount | grep oem
After
# mount -o rw,remount /oem
/dev/block/nandi /oem cramfs ro,relatime 0 0
Should have changed to
/dev/block/nandi /oem cramfs rw,relatime 0 0
anotherguy19 said:
I love breaking things. It's only then we can figure out how it works.
Busybox is exactly what you need.
grep will search for strings within all files and subdirs of /system/etc; matching whatever you type for "AppName.apk"
It is a case-sensitive search unless you add
-i
So
grep -ri ....
or
grep -r -i....
Both would work.
But you don't even know if you need to be searching for a file to modify.
You may want to go ahead and delete the file and reboot.
If it fails, note the file(s) you deleted and know the system is looking for them and then proceed with seeing if you can identify a file in /system/etc that is looking for it's presence.
---------- Post added at 11:59 PM ---------- Previous post was at 11:53 PM ----------
Commands that complete "quietly" mean they were successful.
If you type
# mount | grep oem
After
# mount -o rw,remount /oem
/dev/block/nandi /oem cramfs ro,relatime 0 0
Should have changed to
/dev/block/nandi /oem cramfs rw,relatime 0 0
Click to expand...
Click to collapse
Followed those steps and its still
/dev/block/nandi /oem cramfs ro,relatime 0 0
Apparently the cramfs is a read only filesystem by design.
Vindicoth said:
Followed those steps and its still
/dev/block/nandi /oem cramfs ro,relatime 0 0
Apparently the cramfs is a read only filesystem by design.
Click to expand...
Click to collapse
You need to create an image of the partition, mount the partition on a system with tools to edit it, extract the contents, and re-create the cramfs.
You would need a linux box or linux virtual machine like Virtualbox, or maybe cygwin has the tools. I would just download and burn a Linux LiveISO and run it from VirtualBox, creating a shared folder to get access to the image file (oem partition).
With debian system, you would do
# apt-get install cramfsprogs fusecram
fusecram allow you to mount the cramfs partition on Linux PC via
# mount -t loop cramfsOEM.partition /mnt/workingdir
However since we cannot simply mount the filesystem on the device by plugging into the usb port of the linux machine and mounting from there, we must first create an image (file) of /dev/block/nandi.
> adb shell
# dd if=/dev/block/nandi of=/nandi.img bs=4k
And then copy it to our pc so we can work with the file.
# exit
> adb pull /nandi.orig.img .
Now we can transfer this file to a machine with the requisite cramfs tools to modify the file.
If you look back, I wrote
# mount -t loop cramfsOEM.partition /mnt/workingdir
replace cramfsOEM.partition for nandi.orig.img, or whatever you named it.
Workingdir needs to exist, so
# mkdir /mnt/workingdir
Now you will have to look up cramfsprogs which will allow you to extract the contents to modify. On the Debian or Ubuntu linux machine "/mnt/workingdir" would be the equivalent of "/oem" on your Android device.
However, all this is could very well be for naught, as it is likely the firmware has marked this partition as "signed" so if we try to write back our modified image, the system will fail to boot since the size will be different. On the other hand, the firmware may very well just check to see the partition size is correct. And since you are decreasing the size, the new cramfs image created with a linux box will (should) fit in the old partition.
Fyi, an image file is like a zip file without the compression.
After you modify the cramfs, you can write it back with something like
> adb push cramfs.mod.img /
> adb shell
Then write over the old partition. However, you shouldn't write over a mounted file system so
# umount /dev/block/nandi
Then write over it.
# dd if=/cramfs.mod.img of=/dev/block/nandi bs=4k
Then reboot
# shutdown -r now
And see what happens.
anotherguy19 said:
You need to create an image of the partition, mount the partition on a system with tools to edit it, extract the contents, and re-create the cramfs.
You would need a linux box or linux virtual machine like Virtualbox, or maybe cygwin has the tools. I would just download and burn a Linux LiveISO and run it from VirtualBox, creating a shared folder to get access to the image file (oem partition).
With debian system, you would do
# apt-get install cramfsprogs fusecram
fusecram allow you to mount the cramfs partition on Linux PC via
# mount -t loop cramfsOEM.partition /mnt/workingdir
However since we cannot simply mount the filesystem on the device by plugging into the usb port of the linux machine and mounting from there, we must first create an image (file) of /dev/block/nandi.
> adb shell
# dd if=/dev/block/nandi of=/nandi.img bs=4k
And then copy it to our pc so we can work with the file.
# exit
> adb pull /nandi.orig.img .
Now we can transfer this file to a machine with the requisite cramfs tools to modify the file.
If you look back, I wrote
# mount -t loop cramfsOEM.partition /mnt/workingdir
replace cramfsOEM.partition for nandi.orig.img, or whatever you named it.
Workingdir needs to exist, so
# mkdir /mnt/workingdir
Now you will have to look up cramfsprogs which will allow you to extract the contents to modify. On the Debian or Ubuntu linux machine "/mnt/workingdir" would be the equivalent of "/oem" on your Android device.
However, all this is could very well be for naught, as it is likely the firmware has marked this partition as "signed" so if we try to write back our modified image, the system will fail to boot since the size will be different. On the other hand, the firmware may very well just check to see the partition size is correct. And since you are decreasing the size, the new cramfs image created with a linux box will (should) fit in the old partition.
Fyi, an image file is like a zip file without the compression.
After you modify the cramfs, you can write it back with something like
> adb push cramfs.mod.img /
> adb shell
Then write over the old partition. However, you shouldn't write over a mounted file system so
# umount /dev/block/nandi
Then write over it.
# dd if=/cramfs.mod.img of=/dev/block/nandi bs=4k
Then reboot
# shutdown -r now
And see what happens.
Click to expand...
Click to collapse
Wow that was very detailed. I thought I might have to do something like that. Thanks so much again. I'll try this in the morning since it's getting very late here. I'll go ahead and download a linux livecd tonight.

[Q] Can one mount an Android file system image?

So after a failed attempt to upgrade from CyanogenMod 10.1.3 to 10.2, I was unable to access /data or /sdcard because both systems were encrypted. I ended up having to factory reset my phone because it refused to co-operate or let me access my files. However, before I did that, I was able to run
Code:
adb shell "dd if=/dev/block/mmcblk0p2" > data.img
and
Code:
adb shell "dd if=/dev/block/mmcblk0p3" > sdcard.img
, which appears to have copied the raw partition images from the phone (at least, they're the right sizes).
According to my reading, Android (and, I'm inferring, CyanogenMod) encrypts filesystems using dm-crypt, with a AES-CBC ESSIV:SHA256 cipher, with the key being derived from the password using PBKDF2. Knowing the precious little I do about encrypted file systems, my guess is that if I configure the image in cryptsetup to create a drive mapping, I can mount the mapped drive and recover the data from the images.
According to /fstab.herring on my ahem, fresh, install of Android, the /data partition is in ext4 format whereas the /sdcard partition is vFAT. So, once I've gotten through the encryption on the partition images, they should mount normally, right?
I know that dm-crypt accepts plain, LUKS, LoopAES and TrueCrypt device formats. I'm inferring from the PBKDF2 extension that Android goes the LUKS route for encrypting. Is this conclusion correct?
Could someone explain whether it's possible to decrypt a dumped android image? I'm really hoping that the cypher information is stored on the file system and not on some key file that I nuked in the factory reset. If it can, in theory, be decrypted, am I using the right tools to approach the matter? If so, I'll continue fiddling with cryptsetup and mount, but no sense in wasting time if it's an impossible task.
Never did get a response to this question, so I'll try it again, but start with a simpler question:
If someone dds an Android (specifically Cyanogenmod 10.x) partition to an img file, is there any way to read that image from, say a Linux laptop? I dumped the contents of the /system partition using
Code:
adb shell "dd if=/dev/block/mmcblk0p1" > system.img
I expected system.img to be a normal ext4 partition. However, attempting to loopback mount it with
Code:
sudo mount -t ext4 -o loop,ro system.img ~/android/system
Gave me errors about corrupt group descriptors, bad magic numbers and other maladies indicative of a thoroughly corrupted file system. I'm assuming that:
/data has the same ext4 partition structure as /system; and
The process to mount /storage would be no different to mounting /system with the exception that the former uses vFAT as its file system
However, as my Android is currently working normally (well, as well as one can hope for Android to work), I know I don't have a corrupted file system.
So what's going on? Does Android use a special version of ext4 that other Linuxes don't recognise? Am I not dd-ing correctly? Is there a block-size issue I ignored to my peril?
Borden Rhodes said:
So after a failed attempt to upgrade from CyanogenMod 10.1.3 to 10.2, I was unable to access /data or /sdcard because both systems were encrypted. I ended up having to factory reset my phone because it refused to co-operate or let me access my files. However, before I did that, I was able to run
Code:
adb shell "dd if=/dev/block/mmcblk0p2" > data.img
and
Code:
adb shell "dd if=/dev/block/mmcblk0p3" > sdcard.img
, which appears to have copied the raw partition images from the phone (at least, they're the right sizes).
According to my reading, Android (and, I'm inferring, CyanogenMod) encrypts filesystems using dm-crypt, with a AES-CBC ESSIV:SHA256 cipher, with the key being derived from the password using PBKDF2. Knowing the precious little I do about encrypted file systems, my guess is that if I configure the image in cryptsetup to create a drive mapping, I can mount the mapped drive and recover the data from the images.
According to /fstab.herring on my ahem, fresh, install of Android, the /data partition is in ext4 format whereas the /sdcard partition is vFAT. So, once I've gotten through the encryption on the partition images, they should mount normally, right?
I know that dm-crypt accepts plain, LUKS, LoopAES and TrueCrypt device formats. I'm inferring from the PBKDF2 extension that Android goes the LUKS route for encrypting. Is this conclusion correct?
Could someone explain whether it's possible to decrypt a dumped android image? I'm really hoping that the cypher information is stored on the file system and not on some key file that I nuked in the factory reset. If it can, in theory, be decrypted, am I using the right tools to approach the matter? If so, I'll continue fiddling with cryptsetup and mount, but no sense in wasting time if it's an impossible task.
Click to expand...
Click to collapse
Can you give the result of the "file sdcard.img" and "file data.img" commands?
You are quite right. With regular LUKS container/partition, you would do (being root) the following. With the following commands, you can create a container named "safe", setup it, then format its content in ext3 and mount the partition:
Code:
dd if=/dev/zero bs=1M count=50 of=safe
losetup /dev/loop0 safe
cryptsetup luksFormat -c aes -h sha256 /dev/loop0
cryptsetup luksOpen /dev/loop0 safe
mkfs.ext3 /dev/mapper/safe
(losetup /dev/loop0 safe)
(cryptsetup luksOpen /dev/loop0 safe)
mkdir mnt
mount -t ext3 /dev/mapper/safe mnt
//HERE: do whatever you want in your mounted encrypted filesystem
umount mnt
cryptsetup luksClose safe
losetup -d /dev/loop0
For details, you can go there: http://blog.theglu.org/index.php/20...-couteau-suisse-du-chiffrement-de-partitions/
Sorry, the article is in French but you can translate it if you need to.
Here, using "hexdump", you can see the "safe" file has a LUKS magic at the beginning. And doing a "file safe" command, you can check it detects it as a "LUKS encrypted file".
If doing "file" on your .img files does not give you the same result, you may not be able to directly use the "cryptsetup" command and need to adapt it.
Finally: usually in Android the header containing the key is stored on another partition so you may have lost it when wiping your phone, sorry.
---------- Post added at 02:44 PM ---------- Previous post was at 02:41 PM ----------
Borden Rhodes said:
Never did get a response to this question, so I'll try it again, but start with a simpler question:
If someone dds an Android (specifically Cyanogenmod 10.x) partition to an img file, is there any way to read that image from, say a Linux laptop? I dumped the contents of the /system partition using
Code:
adb shell "dd if=/dev/block/mmcblk0p1" > system.img
I expected system.img to be a normal ext4 partition. However, attempting to loopback mount it with
Code:
sudo mount -t ext4 -o loop,ro system.img ~/android/system
Gave me errors about corrupt group descriptors, bad magic numbers and other maladies indicative of a thoroughly corrupted file system. I'm assuming that:
/data has the same ext4 partition structure as /system; and
The process to mount /storage would be no different to mounting /system with the exception that the former uses vFAT as its file system
However, as my Android is currently working normally (well, as well as one can hope for Android to work), I know I don't have a corrupted file system.
So what's going on? Does Android use a special version of ext4 that other Linuxes don't recognise? Am I not dd-ing correctly? Is there a block-size issue I ignored to my peril?
Click to expand...
Click to collapse
Can you give the result of the "file system.img" command?
Thanks, saidlike, for your reply:
saidelike said:
Can you give the result of the "file sdcard.img"...
Click to expand...
Click to collapse
sdcardPartitionDump.img: data
saidelike said:
... and "file data.img" commands?
Click to expand...
Click to collapse
data.img: data
saidelike said:
Can you give the result of the "file system.img" command?
Click to expand...
Click to collapse
system.img: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (needs journal recovery) (extents) (large files)
Again, attempting to run
Code:
mount -t ext4 -o loop systemimg mountpoint/
yields
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Click to expand...
Click to collapse
Ignoring the results of data.img and sdcard.img for the time being, the fresh dump of the system partition shows that it's an EXT4 filesystem, but that it's heavily corrupted. fsck.ext4 on that partition basically asks me to fix every single inode, so it's not a simple unclean journal issue. Therefore, is it fair to conclude that CyanogenMod (and maybe AOSP too) have modified the ext4 partiiton type?
@Borden Rhodes
Maybe, my reply is too late, but you could try to make the same experiment with backup of your current data.
If you get the same results as with the old pre-wipe backup, then you still have a hope.

How to auto mount cleanly a partiton on boot

I have a second partition on my SDCARD at /dev/block/mmcblk1p2, all I want to do is ensure that it is always mounted as /storage/sdcard0/mount seems simple I can do it in 5 second on Linux, on Android, it seems impossible I can try to add a hack, but that is lost every-time I update the ROM. There has to be some simple way to do it, that I'm missing. The best I have is to load up a terminal emulated su to root and run: mount -t ext4 /dev/block/mmcblk1p2 /storage/sdcard0/mount
Now in theory, the following would work but for 2 things:
mkdir /storage/sdcard0/mount
su - root -c 'mount -t ext4 /dev/block/mmcblk1p2 /storage/sdcard0/mount'
But for the fact the Android's su does not understand -c so that is out. as well as the fact that non-root users (u0_a216 in my case) can not access /storage/sdcard0.
All I want is a simple way to ensure that this is always mounted where I want it when I need it, yet this simple task is nearly impossible it appears on Android, so why is that?
The issue here is that the fat32 partition does not support large files so I need a separate partition that does such as ext4, in reality if the external sdcard could just be ext4 there would be no issues, and it would be faster, but that is Android for you.
Any suggestions?
Thanks,
ERIC
Insert mount script to init.d folder...
via XDA Premium
Ok, I have this mostly working with juicessh and tasker now for now
I have 2 shell scripts:
mountDev.sh:
Code:
mkdir /storage/sdcard2
chmod 777 /storage/sdcard2
mount -t ext4 /dev/block/mmcblk1p2 /storage/sdcard2
umountDev.sh
Code:
umount /storage/sdcard2
rmdir /storage/sdcard2
In Tasker I have 2 tasks defined:
I'm using the JuiceSSH plugin to open a terminal to localhost I then execute:
To Mount:
Code:
su -l --shell=/system/bin/sh --command='cd /storage/sdcard0 ; sh ./mountDSev.sh ; exit' ; exit
To umount:
Code:
su -l --shell=/system/bin/sh --command='cd /storage/sdcard0 ; sh ./mountDSev.sh ; exit' ; exit
I then created 2 icons, 1 for each operation on the home screen. I also created a Device Boot event to automatically execute and mount the task.
This works, mostly, however even though it is root, sometimes I get errors such as /storage/ is readonly, which makes no sense since it could create the directory at boot, but can not remove the directory later on, since it is readonly. Its a minor thing currently, but annoying.
The benefit of this is it is easy to transfer between ROM images and devices without worrying about it being wiped out every-time I update. In theory it also works without init.d support being enabled. Down side is it you need Tasker and the JuiceSSH plug-in so it costs money.
Hope this helps others.
ERIC

Categories

Resources