Google play and cache mount hack

[Toucan4267]

Here's an interesting one. I've got my Optimus S rooted and running Reborn Rom. Was using Link2sd to move apps to /data/sdext2 and was working great until my /cache couldn't take all the apps I was adding. So I read up on scripting and wrote a script--

#!/system/bin/sh

su
umount /cache
mount -o rw,remount -t rootfs rootfs /
rmdir /cache
mkdir /data/sdext2/cache
ln -s /data/sdext2/cache /cache

I placed the script in /etc/init.d/ and named it 11cache. Seemed to work great; was showing correct amount of cache space and all. Problem is, I can't download from google play anymore. I get error (492). Is my cache not writeable for some reason? Any ideas what's wrong or how to fix?

Thanks in advance for taking time to read through this lengthy and unusual post!

 

[vector84an]

I'm running CM9 right now, so I'm not sure it's the same... but it looks like my /cache directory is system:cache(1000:2001), and 771

I'm reasonably sure the default cache directory should be recreated if you remove your script? You could try checking ownership and permissions of the system default one
(though... not completely sure, since I haven't tinkered with stock based roms much... so I feel compelled to add... BOOTLOOP warning! make a nandroid first! etc etc )


A few other comments...

sd-ext is persistent, if you aren't swapping out sd cards you probably don't need to create the directory each time?
(and if you are swapping cards... you'd need to sync your sd-ext partition beforehand... and thus wouldn't need to create directories still)

I don't know much about stock based roms - so maybe it's different - but shouldn't init.d scripts already be running as root?

And I think Reborn ROM might include some sort of dalvik to cache script? Not sure how that would interact with this sort of thing... would probably want to skim through that code...

Maybe something more like this?
(this won't fix your permissions for you unless you delete your /data/sdext2/cache directory btw)

#!/system/bin/sh

busybox umount /cache
busybox mount -o rw,remount /
busybox rmdir /cache
if [ ! -d /data/sdext2/cache ]; then
    busybox mkdir /data/sdext2/cache
    busybox chown 1000.2001 /data/sdext2/cache
    busybox chmod 0771 /data/sdext2/cache
fi
busybox ln -s /data/sdext2/cache /cache
busybox mount -o ro,remount /

(busybox should work fine in Reborn? and seems to be strongly encouraged over toolbox for mounting scripts... though to be honest I don't really know much about why... it does take simpler mount command formats at least)


Otherwise... a few other thoughts...

A little googling seems to suggest that the usual fix for a various Play Store errors including 492 is:
in system settings, manage apps: wipe data + cache for Google Play Store and Google Services Framework
reboot to recovery, wipe cache + dalvik


Or maybe... Link2SD doesn't move app data - so you might actually be out of space to do the installing?
You need a certain amount of space available in /data to store the app, dalvik and libs before you link them, along with any app data that gets installed.

 

[Toucan4267]

Thanks for the quick and in-depth reply! Here's what I know.

my /cache directory is system:cache(1000:2001), and 771

Not sure exactly what this means or how to find out what mine is.

I'm reasonably sure the default cache directory should be recreated if you remove your script

True. And I can download apps after doing so. It appears that whether I use your script or mine, my created cache directory is empty and cannot be written to. I think the error (429) is referencing that play store can't write to cache, dalvik-cache, and can't even download and store the temporary file in the cache folder that it creates before installing. I'm confident this is the cause of the error and not anything else I'm reading on google.

Sd-ext is persistent, if you aren't swapping out sd cards you probably don't need to create the directory each time.

True. Didn't know how to write "ifs." I'm guessing that the "IF" statement in your script means that if it already exists, don't run script?

Shouldn't init.d scripts already be running as root?

I think you're right. I sometimes run the scripts in terminal, and so the su is needed, but probably isn't when it is run inside init.d.

And I think Reborn ROM might include some sort of dalvik to cache script?

I think you're right. "dalvik-cache" is located inside "/cache," and I'd tried just moving the dalvik and some funky stuff happened (Folders and links in places I wouldn't expect). How do I check this script and perhaps change it?

busybox chown 1000:2001 /data/sdext2/cache

This line (I'm not exactly sure what it does, or the line below it) seems to be causing trouble. When I run script in terminal I get an error: (Operation not permitted), even when I run superuser. And still, even running your script, I can't download apps and my cache directory is empty.

Where do I go from here?

P.S. I use SManager app to write script and it looks like it can change root and group permissions. What numbers should I put in these blanks?

Thanks again

 

[vector84an]

Oops... chown takes a . separator not a : ... *hangs head sheepishly*

That should read: (I fixed this above for easier copy-pasting btw)

busybox chown 1000.2001 /data/sdext2/cache

As for what it does, file permissions in linux are handled by chown (change ownership) and chmod (change properties)

The cache directory is owned by 'system' (1000) and its ownership group is 'cache' (2001) - and busybox usually can't handle named users and groups
(you could try using "toolbox chmod system.cache /data/sdext2/cache" instead if you can't figure out what your numeric users are)

File permissions are stored as a bit mask of sorts, but they're just read(4)-write(2)-execute(1) values added together, so for example 771 is
read+write+execute (7 for owner), read+write+execute (7 for group), execute (1 for other)


Try that first - directories created from the command line as superuser usually end up as root.root, which might be causing trouble.



As for Reborn ROMs dalvik2cache script, I believe it should show up as a relatively conspicuously named script file in the /system/etc/init.d/ folder - probably something along the lines of say 05dalvik2cache or 02dalvik2int ... something along those lines


PS: forgot to mention, you can see ownership and permissions with the command line "ls -l" (which functions like 'dir' in windows, if you're familiar, -l is long format)
"ls -l /cach*" should print out something like this:

(permissions) (owner) (group) (-size-) (date) (name)

drwxrwx--x system  cache	2008-08-01 06:00 cache

 

[Toucan4267]

Fixed chown to "." instead of ":". Tried it again in terminal. I still get an "Operation is not permitted" error. Something seems to be blocking me from getting permissions changed. My linked /cache shows root.root 777, data/sdext2/cache shows system.system 775 as SManager properties tells me. I tried changing using SManager, and I get "error" with no more information.

I looked for the Reborn script. The only one I think it could be is zipalign.
Here's the content of "zipalign," the only file with cache mentioned:

#!/system/bin/sh
mount -o rw,remount /dev/block/mtdblock5 /system

LOG_FILE=/data/zipalign.log
    if [ -e $LOG_FILE ]; then
        rm $LOG_FILE;
    fi;
 
echo "Starting Automatic ZipAlign $( date +"%m-%d-%Y %H:%M:%S" )" | tee -a $LOG_FILE;
    for apk in /system/app/*.apk ; do
        zipalign -c 4 $apk;
        ZIPCHECK=$?;
        if [ $ZIPCHECK -eq 1 ]; then
                echo ZipAligning $(basename $apk)  | tee -a $LOG_FILE;
                zipalign -f 4 $apk /cache/$(basename $apk);
                        if [ -e /cache/$(basename $apk) ]; then
                                cp -f -p /cache/$(basename $apk) $apk  | tee -a $LOG_FILE;
                                rm /cache/$(basename $apk);
                        else
                                echo ZipAligning $(basename $apk) Failed DC | tee -a $LOG_FILE;
                        fi;
        else
                echo DCZipAlign already completed on $apk  | tee -a $LOG_FILE;
        fi;
       done;
    for apk in /data/app/*.apk ; do
        zipalign -c 4 $apk;
        ZIPCHECK=$?;
        if [ $ZIPCHECK -eq 1 ]; then
                echo ZipAligning $(basename $apk)  | tee -a $LOG_FILE;
                zipalign -f 4 $apk /cache/$(basename $apk);
                        if [ -e /cache/$(basename $apk) ]; then
                                cp -f -p /cache/$(basename $apk) $apk  | tee -a $LOG_FILE;
                                rm /cache/$(basename $apk);
                        else
                                echo ZipAligning $(basename $apk) Failed DC | tee -a $LOG_FILE;
                        fi;
        else
                echo DCZipAlign already completed on $apk  | tee -a $LOG_FILE;
        fi;
       done;
echo "Automatic ZipAlign finished at $( date +"%m-%d-%Y %H:%M:%S" )" | tee -a $LOG_FILE;

mount -o ro,remount /dev/block/mtdblock4 /system

Still stuck. Any other ideas what the holdup might be?

 

[vector84an]

So, zipalign just restructures apk files to load more quickly...


Anyhow, I'd imagine the problem you're having is related to the ownership on the /data/sdext2/cache folder.

It's particularly strange that you can't use chown from the console to change the permissions - make sure you're running it as root, and if that won't work try toolbox instead, maybe something is wrong with busybox? Once you get proper permissions set things ought to generally work?


For using it as an actual init.d script, there might be some issues still - and I haven't a clue how it interacts with Reborn's dalvik2cache mod.

Also not sure if Link2SD's mount script is firing before yours - you need sdext2 already mounted to do this, so as an init script it needs to load after link2sd's.
(which isn't possible if Link2SD is loading from install-recovery.sh instead of init.d? But ... that about expends my knowledge of Link2SD... )


Just gonna toss this out there too: when Link2SD stops being sufficient for your needs... most people tend to recommend switching over to an actual init.d based script of some sort - Link2SD's major advantage is being able to remove the SD card still (and not needing proper init.d support... which is... often bad, not good...)

Then again, it's more that the dalvik2cache mod can't handle what Link2SD tries to feed it (or any sd-ext script really...)

And disabling the dalvik2cache mod in the boot.img isn't all that difficult... but it's generally a bit more than most users want to deal with... extract boot.img, unpack it, open up the inits, find the dalvik2cache mod, remove or comment out those lines, rebuild boot image, reflash boot image

 

[Toucan4267]

Thanks for all the help thus far! Found something! mvdalvik.sh located in /etc rather than /etc/init.d. I didn't know I needed to look here too. Here's the contents:

#!/system/bin/sh
#
# Move dalvik-cache to /cache
#
# Remove Debugger Mem Dumps

if [ ! -d /cache/dalvik-cache ]
then
	busybox rm -rf /cache/dalvik-cache /data/dalvik-cache
	mkdir /cache/dalvik-cache /data/dalvik-cache
fi

busybox chown 1000:1000 /cache/dalvik-cache
busybox chmod 0771 /cache/dalvik-cache

# bind mount dalvik-cache so we can still boot without the sdcard
busybox mount -o bind /cache/dalvik-cache /data/dalvik-cache
busybox chown 1000:1000 /data/dalvik-cache
busybox chmod 0771 /data/dalvik-cache

# remove debugger memory dumps
busybox rm -rf /data/tombstones/*

Does this change what direction I should go? I'm thinking of just moving my dalvik-cache to my sdext2. Could I do that by just changing every instance of "/cache/dalvik-cache" to "/data/sdext2/cache/dalvik-cache"?

 

[vector84an]

Well, as long as that script is on the system partition, not the ramdisk, changing it should work fine
(/etc should be just a link to /system/etc - if it's not, that would mean it's on the ramdisk and not as easily changeable)

That script is probably run long before anything Link2SD tries to do however - so your sd-ext partition won't be mounted at the time - to get around this, mount it before doing anything else.
I think Link2SD just puts some extra lines in /system/etc/install-recovery.sh - check there to see what command it uses to mount your sd-ext, it should look something like this:

busybox mount -t ext2 -o noatime,nodiratime,nosuid,nodev /dev/block/mmcblk0p2 /data/sdext2

Put that above the first if statement and add any subdirectories - i.e. mkdir /data/sdext2/cache /data/sdext2/cache/dalvik-cache /data/dalvik-cache - and then a find-and-replace should otherwise work.


PS: Link2SD can also link dalvik-cache files, though it probably can't deal with the dalvik2cache mod ? So you could just disable that and continue linking stuff... but ehm... trying to wipe dalvik-cache while things are linked could end up being a serious nightmare...

 

[Toucan4267]

Grrr... I've had to restore my phone way too many times. My "mkdir" line isn't working. I think it's because my "mount" isn't working. sdext2 isn't getting mounted until Link2sd mounts it. Tried your script (although my partition is fat, so should it be "vfat" instead of "ext2"?) Also found "install-recovery.sh" and tried copying it's script, but it is confusing.

I am currently re-installing reborn with only essential apps to try to mount without Link2sd even present on my phone. Will let you know if my mount script works. And I hope it does. All these wipes and restores are going to wear out my phone's storage.

 

[Toucan4267]

Made a lot of progress! Here's my script:

#!/system/bin/sh

# What does this do? Should I remove?
sync;
setprop 1k.filesystem.ready 1;

# empty mount permission sdext2
busybox mount -o rw,remount -t rootfs rootfs /
busybox rm -rf /data/sdext2
busybox mkdir /data/sdext2
busybox mount -o rw,nosuid,nodev,noatime,nodiratime -t vfat /dev/block/vold/179:2 /data/sdext2
busybox chmod 771 /data/sdext2

# move cache & bind-mounts it

busybox mkdir /data/sdext2/cache
cp -r /cache/* /data/sdext2/cache
umount /cache
busybox mount -o bind /data/sdext2/cache /cache

# edited from mvdalvik.sh
if [ ! -d /data/sdext2/cache/dalvik-cache ]
then
	busybox rm -rf /data/sdext2/cache/dalvik-cache /data/dalvik-cache
	mkdir /data/sdext2/cache/dalvik-cache /data/dalvik-cache
fi

#Still not working: fat
busybox chown 1000:1000 /data/sdext2/cache/dalvik-cache
busybox chmod 0771 /data/sdext2/cache/dalvik-cache

# bind mount dalvik-cache
busybox mount -o bind /data/sdext2/cache/dalvik-cache /data/dalvik-cache
busybox chown 1000:1000 /data/dalvik-cache
busybox chmod 0771 /data/dalvik-cache

# remove debugger memory dumps
busybox rm -rf /data/tombstones/*

All is working except the chown commands. I end up with data/dalvik cache bind-mounted to /data/sdext2/cache/dalvik-cache and /cache bind-mounted to /data/sdext2/cache (kinda interesting because I see my dalvik-cache in 3 places: /data/dalvik-cache, /cache/dalvik-cache, /data/sdext2/cache/dalvik-cache).

All read and write ok so far. No 492 errors in the play store.

However...

When an app finishes downloading (which shows it's writting to cache without difficulty) upon beginning to install I get "package file is invalid." Also, Titanium Backup hangs when I try to restore apps. I'm almost positive this is do to "chown" not working. And chown isn't working because: chown on SD card: Operation not permitted.

FAT

Problem is, Reborn Rom on LG Optimus S seemed to have problems running Link2sd right when I used another format (ext2? can't remember). I'm going to have to reformat, but was wondering if you or anyone else knew which formats would allow Reborn, Optimus S, Link2sd, and "chown" to all get along.

Thanks again for all your help! Home stretch now!

 

[vector84an]

Ohh my... a vfat sd-ext would do that... yipes...

I really don't feel like wiping my phone to load up my stock image... but I'm fairly sure my stock backup has Link2SD mount my sd-ext as ext3


Personally... I use an ext4 partition (ext4 is backwards compatible, ie it can be mounted and used as ext2 or ext3) - but ext4 could have potential data integrity issues on certain linux kernel versions
(the rom developers for this phone might have patched out the ext4 issues... otherwise, they didn't get pulled from linux kernel sources until after 2.6.30ish) - the data integrity issues are similar to ones that ext2 partitions will always face (and can be alleviated most of the time with an e2fsck on boot...) so I'm not too worried about them... but y'know... the more you know


So, if all that sounds somewhat complex to you... you might want to stick with ext3 - worked for me in stock roms, has high data integrity, but might run into some issues with certain custom roms - ex some of thekraven's kernels don't include ext3 support, and some of the older sources could potentially risk the above mentioned ext4 issues if they aren't patched (commit logs are long, no time to read through them)
(force mounting an ext3 as ext4 should be better than the auto-detect which picks ext2, but then you have to worry the ext4 kernel bugs again)


And if all else fails... you should be able to mount ext3 or ext4 partitions as ext2 - and except for crazy custom OEM kernels, ext2 should be supported by pretty much everything as it has long been linux's core filesystem format
(though ext2 lacks the journalling so personally I don't like to use it on embedded devices - others feel that the data integrity risk is worth the improved speed - and the data integrity should still be similar to vfat, though some of the tools to handle it can be missing in android roms)

 

[Toucan4267]

Yeah, apparently vfat wasn't designed with permissions/owners/groups in mind and thus doesn't get along well with Linux/Android. But....

The good news is, everything works now!

Reborn doesn't inherently have the ability to read any sd-ext partition not formatted as vfat. Vfat doesn't get along with "chown." I was roadblocked from the start.

So, I downloaded and flashed Zefie's v13 experimental kernel. This allowed full functionality of ext2, ext3, and ext4. I used MiniTool Partition Wizard to reformat my vfat to ext2, and changed vfat to ext2 in my code; double-checked my "chown" codes, and VIOLA. Dalvik-cache is located in cache which is located /data/sdext2/cache with 2GB of space, ext2 format (read up and thought this would be best), and ownerships and permissions are all correct. Apps download and install. I can wipe my cache and dalvik-cache with no issues (Unlike as you mentioned, when using Link2sd to link dalviks, hence one of the big reasons I did this in the first place). I've restored all my apps and how (153 and counting). Will let know of any other quirks.

Will need help cleaning up code. Then I'll make a flashable zip, write instructions for the method, post it, and we'll see where it goes from there, but I think this is something nearly EVERYONE with Reborn on an Optimus S will want. I'm just exited to contribute to the Android community. Here's my final (beta)code btw for /system/etc/mvdalvik.sh:

#!/system/bin/sh

# from A
sync;
setprop 1k.filesystem.ready 1;

# empty mount permission sdext2
busybox mount -o rw,remount -t rootfs rootfs /
busybox rm -rf /data/sdext2
busybox mkdir /data/sdext2
busybox mount -o rw,nosuid,nodev,noatime,nodiratime -t ext2 /dev/block/vold/179:2 /data/sdext2
busybox chmod 0771 /data/sdext2

# move cache & bind-mounts it

busybox mkdir /data/sdext2/cache
cp -r /cache/* /data/sdext2/cache
umount /cache
busybox mount -o bind /data/sdext2/cache /cache
busybox chown 1000:2001 /data/sdext2/cache
busybox chmod 0771 /data/sdext2/cache
busybox chown 1000:2001 /cache
busybox chmod 0771 /cache

# edited from mvdalvik.sh
if [ ! -d /data/sdext2/cache/dalvik-cache ]
then
	busybox rm -rf /data/sdext2/cache/dalvik-cache /data/dalvik-cache
	mkdir /data/sdext2/cache/dalvik-cache /data/dalvik-cache
fi

busybox chown 1000:1000 /data/sdext2/cache/dalvik-cache
busybox chmod 0771 /data/sdext2/cache/dalvik-cache

# bind mount dalvik-cache
busybox mount -o bind /data/sdext2/cache/dalvik-cache /data/dalvik-cache
busybox chown 1000:1000 /data/dalvik-cache
busybox chmod 0771 /data/dalvik-cache

# remove debugger memory dumps
busybox rm -rf /data/tombstones/*

Anyone willing and able to help clean up the code would be most appreciated. Again, thanks so much, vector84an. You were the only one who posted here, and I wouldn't have been able to get this working without your help.

 

[vector84an]

I'll try to take a longer look later and see if I can help clean it up a bit, but now that permissions work, a few quick thoughts to start you in the right direction at least

Moving the entire cache partition might be excessive, depending on your needs - I don't know what Reborn ROM stores there besides the dalvik though... so maybe you do need to move the whole thing?

you can use the -p option to cp to copy with file permissions; could probably save you some work in the script by copying the existing directory structure intact with permissions.

Bind mounting a directory twice shouldn't really be a problem, but if for no other reason than potential confusion, it should probably be avoided if possible, since bind mounts make the same data exist in multiple places on the file system - if other parts of Reborn expect to be able to find the dalvik at /cache/dalvik-cache then a setup of bind mounts like you have is probably ideal, but one would hope that everything in the rom references /data/dalvik-cache and lets the bind mount do the rest... in which case, having /data/dalvik-cache and /cache/dalvik-cache both bound to /data/sdext2/cache/dalvik-cache could be needlessly confusing
(if you're going to bind mount both the /data/dalvik-cache and /cache, consider using two separate directories? what you have is better than nesting bind mounts though, I think? so... if you do need /cache/dalvik-cache to also contain the dalvik, then your setup is appropriate)