Develop Bugs

Exploring how to get Android to cleanly unmount /data

Several of us are exploring how to change an Android build so that it unmounts the /data partition cleanly when shutting down. This thread is dedicated to discussion of how to do that. Solutions may eventually appear here, but will work their way into the various build and/or kernel threads.

reserved
Watch this space for a summary of answers and solutions.

Roughly how it works today
The Shutdown thread stops applications, and then tells the Volume Manager to shutdown. After that, the Shutdown thread calls reboot() which calls _reboot() which turns off power.
I think the key is in Volume Manager.
Volume Manager's Java code works with the C++ application "vold".
Volume Manager gets a list of mounted filesystems from vold.
Vold returns a list that it manages, not the same as "df" or "mount" from the command line. That list (at least in Fresh Froyo) does not include /data or /cache.
Volume Manager then, for each filesystem in the list, tells vold to unmount the filesystem. Each filesystem has a timeout, and Volume Manager eventually either finds success or gives up.
The "vold" application can be controlled with a command-line executable called "vdc". Commands like : "vdc volume unmount /sdcard" or "vdc volume list", use the same syntax as Volume Manager uses to talk to vold.
Perhaps the answer to all of this is to get /data registered with vold at startup.
What I have tried, with great failure, is a terrible hack where I modified the implementation of reboot() to call system("/system/bin/rosysdata") before calling _reboot(). Then I created /system/bin/rosysdata to remount /system and /data as r/o. That worked for a couple of shutdowns, but after that caused extreme filesystem failure a few times. It was a bad hack anyway, so I have never committed that.

If we can get the /data filesystem mounted by vold instead of just mounting it in the bootup scripts, it should get unmounted at shutdown, since VolumeManager gets a list of mounted volumes from vold and unmounts each of them.
I am trying this but don't have much success yet.
Another idea is to get android to execute a shutdown script as it shuts down.

The old initrd create severl problems with mounting because there was several binding to the data partition.
Now there is only one /data mounted to the partition.
The old script files has the problem with the binding but now they should work.
I think that vold can't be used with data so we need to exec:
Code:
sync
mount -o remount,ro /data
in a shutdown script.

energy cut
what about when the system crashes and battery has to be removed?
anergy cut ...
What about use different partitions?
/system, /data and /cache as different partitions...
the highest activity of reading and writing happens in /cache. Am I right?
I'll change the nbh and sysinit.rc to meet this.

tiagoclc said:
what about when the system crashes and battery has to be removed?
anergy cut ...
What about use different partitions?
/system, /data and /cache as different partitions...
the highest activity of reading and writing happens in /cache. Am I right?
I'll change the nbh and sysinit.rc to meet this.
Click to expand...
Click to collapse
Isn't /cache a symlink to /data/tmpcache ? couldn't we redirect to /mnt/sdcard/cache ? (or anywhere else ?)

Due to these issues I can reboot normally only if I clear Dalvik cache. Maybe it could be automatic on boot lol

drvitorino said:
Due to these issues I can reboot normally only if I clear Dalvik cache. Maybe it could be automatic on boot lol
Click to expand...
Click to collapse
I second this or how about we manually enter mount -o remount, ro /data on terminal before turning it off?

ohohoh, apparently L1qu1d fixed my issue with the new kernel and the update from http://forum.xda-developers.com/showthread.php?t=848921
Unfortunately wi-fi and data connection is still not working with the update in my kaiser. But L1qu1d may be happy to know that his code inside the update has something that fix data corruption when turning off/on the device.

drvitorino said:
ohohoh, apparently L1qu1d fixed my issue with the new kernel and the update from http://forum.xda-developers.com/showthread.php?t=848921
Unfortunately wi-fi and data connection is still not working with the update in my kaiser. But L1qu1d may be happy to know that his code inside the update has something that fix data corruption when turning off/on the device.
Click to expand...
Click to collapse
In my test, some data corruption still exists (when lots of widgets and data partition close to full) but is easily corrected by clearing the dalvik-cache, but some apps are lost in the launcher. I still think that unmounting the data partition before turning off or reboot is the best way to prevent this.

n2rjt said:
The Shutdown thread stops applications, and then tells the Volume Manager to shutdown. After that, the Shutdown thread calls reboot() which calls _reboot() which turns off power.
I think the key is in Volume Manager.
Volume Manager's Java code works with the C++ application "vold".
Volume Manager gets a list of mounted filesystems from vold.
Vold returns a list that it manages, not the same as "df" or "mount" from the command line. That list (at least in Fresh Froyo) does not include /data or /cache.
Volume Manager then, for each filesystem in the list, tells vold to unmount the filesystem. Each filesystem has a timeout, and Volume Manager eventually either finds success or gives up.
The "vold" application can be controlled with a command-line executable called "vdc". Commands like : "vdc volume unmount /sdcard" or "vdc volume list", use the same syntax as Volume Manager uses to talk to vold.
Perhaps the answer to all of this is to get /data registered with vold at startup.
Click to expand...
Click to collapse
Since our data is installed in NAND, I don't think "vold" can mount Nand partition. Not too sure though.

clemsyn said:
Since our data is installed in NAND, I don't think "vold" can mount Nand partition. Not too sure though.
Click to expand...
Click to collapse
from: http://osdir.com/ml/android-porting/2010-06/msg00279.html
Vold doesn't mount Nand.
Mounting of Nand partitions is done in init.rc
mountd: mount all fs defined in /system/etc/mountd.conf if started,
receive commands through local socket to mount any fs. The source is
in device/system/bin/mountd.
-
Sreekanth
On Jun 24, 5:47 pm, "Dennis.Yxun" <[email protected]> wrote:
> HI Community:
> I'm using donut branch, and my system have two block devices, I want them
> all mounted
> 1) nand flash: /dev/block/sdb
> 2) MMC/SD card: /dev/block/mmcblk0
>
> Current, I successfully use vold mount the MMC/SD card
> (/dev/block/vold/179:0 -> /dev/block/mmcblk0)
>
> My question here is :
> Does vold support to mount the Nand Device too? like
> mount /dev/block/sdb to /sdcard/nand
> mount /dev/block/mmcblk0 to /sdcard/mmc
>
> Dennis
is this true?

[DEV][Proof-of-Concept] Boot from SD on Optimus V

I've tested this and it works. I only have a class 2 SDcard, so my testing shows it's really slow, a faster card would probably help.
With just this class 2 SD card, the boot-from-sd process is really only useful to see if the ROM being tested will straight-up brick your device or not.
Edit!
A class 6 card works fabulous! I'm posting from a tweaked version of mmarz's port of ath3nos' port of cm7 running from my brand-new class 6 card right now.
This process is hacked together from multiple other devices' howtos here on xda, sorry I don't know who to credit for the bits and parts. All of it is pretty generic, actually, and might well be applicable to other devices when tried as a whole.
For the moment, I'm only posting a brief skeleton how-to without specific walkthroughs for the steps, and I don't really want to upload many files until more of the bugs are swatted.
The following info should be enough for you, the savvy dev, to put the ROM of your choice on your SD card and boot it (or watch it fail to boot) without risk of bricking your device!
noobs, don't you dare, bricking is always a risk if you don't know your way around fastboot and adb!
Of course, savvy dev or not, a fresh nandroid backup is MANDATORY before hacking at your phone like this.
Standard disclaimer:
There is always a possibility of bricking your phone when messing with adb and fastboot.
If you're not willing to take that risk, don't try this at home (or at work, or school....)
Here goes:
The basic plan I followed was:
1) make and format 3 extra ext2 partitions after the default fat32 on the SD card, in this order: data (at least 180Mb) , system (170Mb to match stock), and cache (102Mb stock).
2) split up the boot.img from your chosen ROM so you can mod the ramdisk.
edit: turns out this next step in the quote is not required, there is an easier way.
A nifty command called devwait for init.rc
3) compile a modified init, adding a "pause (5);" after the ANDROID text. It goes on line 569 in the gingerbread init.c from a recent repo of google source.
use the newly compiled init in place of the init from the ramdisk.
since getting the android source uses so much time and bandwidth, I'm being nice and attaching a modified gingerbread init. If you test it with a froyo ROM and it doesn't work, don't blame me. If it does work with froyo ROMS, let me know!
Click to expand...
Click to collapse
3) change your init.rc from the ramdisk as follows:
replace the "mount yaffs2 [email protected] /system" , cache, and data lines with
Code:
devwait /dev/block/mmcblk0p3
mount ext2 /dev/block/mmcblk0p3 /system nodev noatime nodiratime
mount ext2 /dev/block/mmcblk0p3 /system nodev noatime nodiratime ro
devwait /dev/block/mmcblk0p2
mount ext2 /dev/block/mmcblk0p2 /data nodev nosuid noatime nodiratime
devwait /dev/block/mmcblk0p4
mount ext2 /dev/block/mmcblk0p4 /cache nodev nosuid noatime nodiratime
be sure to comment out any other mounts which go to /system anywhere, like the "mount squashfs [email protected]/system/blahblah/blah.sqf /blah/blah" lines in the aospCmod init.rc
4) repack your boot.img, with the correct cmdline ("mem=477M console=ttyMSM2,115200n8 androidboot.hardware=thunderc" works,) etc.
5) prepare the ext2 /system partition with your target ROM /system files.
How to load the ROM:
steps a) to f) done on your PC. step g) is done on the phone.
a) Unzip the ROM on your PC, to get at the files to copy to the new /system directory in adb, and allow you to modify the updater-script.
b) Mod that ./META-INF/com/google/android/updater-script as follows:
As an example, I removed the following from the aospCmodOV-5-16-11 updater-script:
everything except the "ui_print" "symlink" and "set_perm" lines, including the "unmount" line at the end of the script.
I thinned it down because the update-binary wants to write to MTD partition for /system, and I didn't want or need that to happen.
I did need it to install the symlinks and permissions, though.
Without those, the keyboards kept FCing, and the phone couldn't connect to the network.
c) rezip the ROM with the modified updater-script.
d) boot phone into recovery and connect to PC with cable.
e) adb push or otherwise copy the modified ROM.zip to your sdcard.
f) next, copy /system from the unzipped ROM to the new partition with adb
Code:
adb shell
mount -t ext2 /dev/block/mmcblk0p3 /system
exit
adb push /path/to/unzipped/ROM/system /system
g) on phone, in recovery: install .zip from sdcard
select the new ROM.zip you reassembled and pushed to the SD card
select yes, you really want to install the .zip
this should write the /system symlinks and permissions to the new /system partition.
Click to expand...
Click to collapse
6) back on your PC, still connected to phone with cable in recovery;
Code:
adb reboot bootloader
fastboot boot /path/to/boot.img
Step 6 is important!
this will boot from your modified boot.img without actually flashing it into the phone's NAND, so a reboot (or restart after battery pull in case of issues) just goes to your regular installed ROM in the phone.
That's about it for now. It's pretty much a hack as yet, but it's cool in a geeky way to be able to do this.

<reserved for future use>

Thanks! This should be very helpful to devs and those of us who are adventurous with our phones!

Very interesting concept, I'd love to see how many uses this could have!

bump...
with a class 6 card, ath3nos/blarf cm7 runs great off sd.
even feels a little snappier than running from the phone mtd partitions.
I must benchmark soon to verify.
I'm really surprised no-one seems interested, I guess this is too old-hat, like a debian chroot

bigsupersquid said:
bump...
with a class 6 card, ath3nos/blarf cm7 runs great off sd.
even feels a little snappier than running from the phone mtd partitions.
I must benchmark soon to verify.
I'm really surprised no-one seems interested, I guess this is too old-hat, like a debian chroot
Click to expand...
Click to collapse
This is good work, but I think people require a bit more hand holding. How about publishing some of the modded files?
I personally still have problems recompiling a ramdisk.

mmarz said:
This is good work, but I think people require a bit more hand holding. How about publishing some of the modded files?
Click to expand...
Click to collapse
I can post files one rom at a time, because the ramdisk and kernel will be a bit different for each rom, and so will the permission/symlink updater-script.
first, I'll have to get rom-dev permission, because they get modded, and also cause it's nice to have permission.
I personally still have problems recompiling a ramdisk.
Click to expand...
Click to collapse
fastboot provides a fantastic shortcut for that, if you cpio-gzip the ramdisk together after editing it to your specs
from http://android-dls.com/wiki/index.php
in a command line linux shell, from the directory containing your unpacked ramdisk,
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
will put newramdisk.cpio.gz in the directory above the one containing your ramdisk
Click to expand...
Click to collapse
fastboot can make the boot.img for you and either dump it into the phone (assuming your shell current directory contains your kernel (zImage) and ramdisk (newramdisk.cpio.gz))
Code:
fastboot -c "mem=477M console=ttyMSM2,115200n8 androidboot.hardware=thunderc" flash:raw boot zImage newramdisk.cpio.gz
or boot your phone from the assembled image without actually flashing it in.
Code:
fastboot -c "mem=477M console=ttyMSM2,115200n8 androidboot.hardware=thunderc" boot zImage newramdisk.cpio.gz
those fastboot lines assume an optimus v (or s.)
looking at all the great work you've posted on the forums, I'm surprised you have trouble handling anything to do with these phones!
I'm slowly working up to a modded recovery to install-to-sd directly and avoid all this hacking.

Nice, thanks for that. I had no idea fastboot could do that.

mmarz said:
Nice, thanks for that. I had no idea fastboot could do that.
Click to expand...
Click to collapse
happy to share.
I only learned fastboot could do that when I seriously started in kernel testing after finally getting one to compile without errors. I didn't feel like bricking my phone to test the fresh kernel, and researching fastboot showed me its capabilities... I could've just typed fastboot with no arguments and that makes it list its parameters.
it's really helpful for this mod, because you can just reboot into your stock rom without having to reflash anything.
plus it's nice to just tweak the ramdisk and let fastboot do the work making a new boot.img for you when testing weird stuff like this.

bigsupersquid said:
happy to share.
I only learned fastboot could do that when I seriously started in kernel testing after finally getting one to compile without errors. I didn't feel like bricking my phone to test the fresh kernel, and researching fastboot showed me its capabilities... I could've just typed fastboot with no arguments and that makes it list its parameters.
it's really helpful for this mod, because you can just reboot into your stock rom without having to reflash anything.
plus it's nice to just tweak the ramdisk and let fastboot do the work making a new boot.img for you when testing weird stuff like this.
Click to expand...
Click to collapse
Very cool i loved this idea when it was executed in a way over at Ubuntdroid for the intercept when i was doing alpha testing. Very convenient for many of the scarier tests when i wanted to keep my existing system intact. The big difference was that on the intercept the bootable partitions were written into the kernel. Downside you couldn't use it to test kernels but could switch kernels from the phone and flip-flop between completely isolated systems on the go without a computer. Which was great when i wanted to test a new ROM on the way to work but i needed my phone when i got there and had to have a painless method of switching to my usual running system. So i'd flash a "non SD" kernel and i was back up and running in just a minute or so.
I'm excited to play with this when i have some free time.
Thanks dude!

you could easily use an update.zip for each of the sd-boot and regular phone boot.img files and swap between working systems with those in recovery.
before getting the fast sd card, I was looking at this more as for testing foreign roms than two-system operation, but now I see that would work too.
for a second-system option I was looking at a market-enabled rom on sd since I don't use g-apps on my daily driver.
note: the GB rom I'm running on won't 'see' a card with more than four partitions properly, and won't mount the vfat partition with vold, although you can manually mount and access the first four partitions including the vfat. android just won't admit it's there. and I couldn't get at a fifth partition through the phone os, even though my pc could see it fine (to get 5 partitions I had to use an extended partition to contain most of the virtual partitions)
android could read virtual partitions in an extended partition just fine as long as the total number on the card didn't exceed four.

I learned a neat trick today.
going through the init.rc from the stock rom, I noticed a section at the beginning which was labeled 'on emmc' which would imply running from a card if the device hardware lacked nand flash memory.
I'd read on xda while researching this concept of boot-from-sd about an unspecified wait-for-device command in init.rc, but most of the info I've gotten on init scripting language has come from picking apart init scripts, as google has not documented the available commands very well.
long story short, I tried using devwait with the regular init and it worked just fine to mount the ext partitions. yay!
first post edited to reflect the improved method.
I've also been testing a recovery mod. if recovery.fstab is modified in the recovery ramdisk (or a fakeflash recovery) then the recovery will copy a tweaked rom.zip to the ext /system partition with some minimal modifications to the updater-script and a few commands in the adb shell.
the recovery with the modded recovery.fstab can also back up from and restore to the sdcard ext /data and /system partitions.
I will update the first post with more specific instructions as I hammer them into something consistent.
soon I'll be ready to release a modded fakeflash recovery to make experimentation easier, as well.

[Guide]Functional ext4 for external microSD with just a few bumps left

Y.G. said:
I formated my sd card to Ext4 and when insert it in to my phone, it says that's it's blank and has unsupported files. Any reasons for that?
Sent from my SPH-L710 using xda premium
Click to expand...
Click to collapse
The SPH-L710 Samsung Stock LJ7 TW 4.1.1 Android doesn't understand/support the change to ext4 external SD card (microSD) without a few things being done.
I'm working this out right now. So far I have manually been able to mount the newly created ext4 partition on the microSD card through adb, and after some chown/chmod I was able to go back to "Settings and Storage" and the "Mount SD Card" picked it up, and I was up and running ext4. But this didn't persist after a restart. So I'm looking into: /etc/vold.fstab MODS to keep it after restart right Now !!
If Some one else already has this perfected please chime in. I'm wanting to do most of the devices in the house this way when I get time because better performance, having a file system with a journal, and getting rid of thins like 4 Gig per file limitations is pretty Sweet in my humble opinion *Grin*
0) Assuming you already have your microSD card formatted ext4. I also happened to label mine extSdCard for the volume label within gparted
1) Can mount with:
mount -w -t ext4 /dev/block/mmcblk1p1 /storage/extSdCard/
2) To get the correct owner and permissions run:
chown root:sdcard_rw /storage/extSdCard
chmod 775 /storage/extSdCard
3) Should make the extSdCard owner/permissons match the regular internal sdcard you can verify this like so:
cd /storage/ && ls -l
drwxrwxr-x root sdcard_rw 2013-01-12 18:16 extSdCard
drwxrwxr-x root sdcard_rw 2013-01-12 17:05 sdcard0
4) After that you can go to the "Settings and Storage" to run "Mount SD" and you will have ext4 extSdCard Show up and it bring up the File System Status !! --> Until you reboot and it goes to crap because I don't have the vold.fstab edit/MOD complete _yet_ ... So, for now a boot script has been put in place to bring our external SD card back online during restart, so the system will acknowledges it, making the world a better place.
Example of how things look file system wise: mount | grep extSdCard
/dev/block/mmcblk1p1 /storage/extSdCard ext4 rw,relatime,user_xattr,barrier=1,data=ordered 0 0
5) Have not been able to resolve the vold.fstab to make this ext4 extSdCard matter fully Legit (in my opinion), but I did manage to make it remount the card on boot, so its online when the system comes up instead of having to manually mount it. Did this by -->
Added the following lines to the very bottom of: /etc/init.qcom.post_fs.sh
## sponix MOD to match with ktoonz kernel for better power management
stop mpdecision
## sponix MOD to mount extSdCard prior to GUI work around to make ext4 function
## read and write extSdCard mount
chown root:sdcard_rw /storage/extSdCard
chmod 775 /storage/extSdCard
mount -w -t ext4 /dev/block/mmcblk1p1 /storage/extSdCard
chown root:sdcard_rw /storage/extSdCard
chmod 775 /storage/extSdCard
## if you want read only extSdCard mount
## mount -r -t ext4 /dev/block/mmcblk1p1 /storage/extSdCard
Still attempting to automate the process so the Stock+root LJ7 can pick up the extSdCard _normally_ without having to do the mount command manually, but so far its kicking my butt. Also this is more a "General, or Question and Answer type Topic" the Kernel(s) obviously support ext4 the system fs uses/requires it *Grin*.. So we might get Our Friendly Neighborhood Moderator to Migrate it to the proper place to help others. Just hoping to get the last few bumps smoothed out, or find someone that already documented the process that I've overlooked *Grin*..
Current Known Issues: If you unmount the card through the "Settings | Storage | Umount SD" or by hand with umount, you will either need to reboot for it to reattach through the /etc/init.qcom.post_fs.sh boot script script addition, or will have to mount it manually if you want to keep the system up and running. Guess you could also probably just run the /etc/init.qcom.post_fs.sh as root from a terminal emulator (or adb).
Still searching for vold.fstab bits of wisdom but that will have to continue next weekend -->
Sexy and You Know it,
Keep on Flashing,
sponix2ipfw (sponix
:fingers-crossed:

Ha! Sorry. Deleted: Didn't understand that you had it running on boot (can't read properly )

Great idea
Am I really the only one who also thinks this idea is the nuts?
Am I the only one who longs to transform the mess that passes for a filing system on the internal sd using symbolic links into a beautifully organized, encrypted and cloud synced system on my external sd?
Is it just me and a few others that want to be able to achieve the above so that we can move from one ROM to another or recover from a lost phone with the minimum of fuss?
Are we freaks? :cyclops:
Say it isn't so XDA!! :crying:
I'm gonna try this on my international S3 running Null_ Rom 25 JB 4.1.2
PS do you have any idea how the entire ExtSD or just a folder can be enrypted using Cryptonite and automatically mounted at boot time?

emp111 said:
PS do you have any idea how the entire ExtSD or just a folder can be enrypted using Cryptonite and automatically mounted at boot time?
Click to expand...
Click to collapse
Is this along the lines of what you're looking for?
http://forum.xda-developers.com/showthread.php?t=1141467
Also your idea is pretty insane, but also genius
If you get that to work please do come back and share

Insane ideas are the best lol
CNexus said:
Is this along the lines of what you're looking for?
http://forum.xda-developers.com/showthread.php?t=1141467
Also your idea is pretty insane, but also genius
If you get that to work please do come back and share
Click to expand...
Click to collapse
Thank you for your prompt reply, yes it is asking a lot I know but I think that it can be done.
Now if you really thought that idea was insane......check this out:
Imagine that we asked every Android app developer to submit the various paths used for their config (and config backup) files to a central database and had the ability to add or own custom paths (which could be added to the central database once approved).
We could build an script/app that would retrieve a list of currently installed apps on your phone then automatically build a symbolically linked file system (and/or backup file system) in the location of your choice that you could either encrypt and/or sync using your current tools or even incorporate this functionality into the app itself along with the ability to choose what was encrypted/backed up and how i.e. either synced to the Cloud or (S)FTP or SMB as either a dd copy or even a cwm flashable zip.
Could I dare hope for a Tasker module or the ability to add custom scripts?
I wish I could do this myself but my coding skills are non existent
Anyway the LUKS manager app won't automatically mount a file system, but I really like it anyways, thank you for pointing me to it!
And on the Ext4 front, the mount command (yes the 1st one ) failed, maybe the op could offer a suggestion. :angel:
BTW is there a place for people to suggest ideas for apps here?

Wait really it wont? I couldve sworn I remembering that it did
But dude....
You need to learn yourself some java and start whipping stuff up
Idk about the whole central database thing, but the rest could definitely be done with root access
I think the main problem with that is the proprietary aspects...i mean even here on XDA where binaries released are supposed to be GPL compliant, many of them arent and its sad because it deteriorates the overall quality of work thats released afterward

This whole thing is just hard work!
CNexus said:
Wait really it wont? I couldve sworn I remembering that it did
Click to expand...
Click to collapse
Doesn't seem to unfortunately
But dude....
You need to learn yourself some java and start whipping stuff up :D :D[/QUOTE said:
You make it sound soooo easy lol, and at another point in my life maybe it would have been but right now I'm operating at a reduced level due to some unforeseen circumstances that have left me lacking focus, motivation etc
You know all the things you need to be creative, learn etc lol
Anyway back to the matter at hand, I have got my ext4 SD card to the stage where I have to manually mount it from within the Settings/Storage as I'm using the international S3 and don't have the init.qcom.post_fs.sh, I think the qcom refers to Qualcomm chipset in US S3's.
As for modifying vold.fstab so we can avoid the above workaround it would seem that maybe thats a dead end as according to a German guy on android-hilfe. de, Vold may have been modified by Samsung to only deadl with exFAT on External SD's.
Looks like I'm not gonna be in Android nirvana for a while :crying:
Unless anyone else on XDA fancies getting in on this !!!!
Click to expand...
Click to collapse

Got it working ..... kinda
Got an app called ezymount (by ezynow) that automounts my ext4 64GB microSD at boot time.
I have to wait a few seconds for the boot process to complete but it's automatic, am pretty happy!!
Now gotta get symlinks, encryption and cloud synchronization sorted :/

Linux on Android binding ./usr to a folder on extSdCard

Let me preface this by saying this is my first ever real post in a forum, so if im doing something wrong, please tell me. I would post this in the linux on android forum, but I am apparently not allowed to do that. Hopefully this helps some people out.
I have been experimenting with the ubuntu.sh script and various linux images. After getting an image to work I attempted to expand the image file by using dd. This would create a 12 gb (or whatever size) image, but on copying the file system from kali.img to the new .img, the new image failed to execute and ended up wiping my kali.img, my modified ubuntu.sh script and my new .img (my fault for rebooting with the images mounted). This and subsequent attempts all failed to create a 12 gb image that would run kali.
Before I go further, I should state that I'm mounting my images to /storage/extSdCard/mnt
So all this got me thinking on other ways to expand the file and I thought why not move ./usr to a folder on extSdCard and use mount to bind it to the kali.img file. That way you'd get about 2gb extra on the image and installed programs could be installed to space on the extSdCard. If this works it could be applied to the entire linux filesystem, and just use a small .img to mount everything to when you wanted to start it.
That being said I'm having difficulty implementing this. Kali will boot and I can execute commands from it after running:
busybox mount -o bind ../kali/usr/usr ./usr
And
busybox mount -o remount,exec ./usr
It would appear that things work, but I can't connect through vnc as vncserver isn't installed and I can't install things because of an error with dpkg: error setting ownership of ... Operation not permitted.
That is where I'm at right now. I figured I would make a post and hopefully get some more input on this, or maybe help someone out with the whole image file size thing.
Sent from my SM-N900V using xda app-developers app

I have made some progress, but this idea as a whole would appear to be impractical at this moment. The permission errors occur because of the exfat file system used on android devices. This implementation does work on ext(4) formatted sdcards, as tested by my linux box running backtrack. However, the android system, at least for the note3 does not easily support ext4 formatted anything, despite /system maybe being ext4. I haven't looked too far into that as it is read only and would also be a hassle to configure. This may become an effective means of running linux on android systems once ext4 is widely supported, but not likely until then.
If I were more skilled I would try to set up a raid system with ext4 image files, since exfat has a 4gb file size limit. Unfortunately though, I do not have the skill to do this at the moment nor the time to take on such a task.
I wish you all the best of luck with your projects.
Sent from my SM-N900V using xda app-developers app

Move app to system android 10

I can't figure out how to move an app I installed from the playstore to the system/app. I rooted and installed magisk. And the app I am using requires it is moved to the system partition. I tried mounting rw in root explorer. It says it was granted permission but nothing changes.
What do I need to do to move this app to the system?
Thanks in advance!

As of Android 10 the system partition is read-only, due to Google changing the file system to EXT4 dedup. So, you'll have to do without the app unless you can find or create a custom ROM that doesn't set the system partition to EXT4 dedup.

@phhusson
I have an issue with rw on Android 10 & 11 that you might know something about. It's my understanding that I can use your lptools to make this possible. The problem with that is, I can't find a copy of it that will work. I tried pulling the binary from your GSI, but it fails and throws an error because it's dependant on fs_mgr, which doesn't exist anywhere. Alternatively, I found this statement from you about using fastboot.
Code:
fastboot resize-logical-partition system $((2*1024*1024*1024))
I tried that command, and it just says "fastboot: invalid option --2". Not sure why it doesn't work. I think I should mention however, that the following does work.
Code:
mk2fs -E unshare_blocks /dev/block/dm-3
It's just the steps before, that I can't complete. If you have any insight or suggestions, I'd love to hear it.