Related
I made this to tide myself over until $auron can finish UrukDroid 0.6. This is a combination of the stock Archos 2.1.04 firmware, Ardatdat's Overclocked Kernel, and a manual EXT4 Conversion. It is permanently rooted and includes SuperUser. My main reason for making it was to enable read/write access to the filesystem, which rooting DOES NOT do on the stock Archos firmware, as the squashfs will still be mounted read only by /etc/mountpoints. Also, EXT4 is much faster than the compressed squashfs Archos uses. Quadrant gives ~2200 with the data partition converted to EXT4 as well, ~1800 without conversion. I have already updated Busybox to a fully compiled version, 1.16, another thing Archos decided to "secure" despite the supposed Open Source status. I have NOT edited the .hosts file to block ads, as I believe the app developers deserve to make some money, you'd be amazed how little they make, but you can do it yourself without Archangel scripts now, as the filesystem will be read/write again.
I designed it on an A101it, but it should work on any Gen8 with internal flash storage. A70H users, I can't remember your block allocations, it may work fine, but I'll need someone to post the storage layout of /dev/block/ to be sure.
For the power users, here's a quick install outline: First, make a second partition on your storage/sdcard in EXT4, extract the rootfs.tar.gz to it, and flash the appropriate initramfs and zimage. Pretty easy.
For the rest of you(probably most of you):
There is only one short step in Linux, which is setting up an EXT4 partition on your Internal Storage or your SD Card. You must make it as a second partition, not 1st, 3rd, or anything else. This means you can still use it as a storage device as well as running Android. I find it incredibly simple, and can be done in less than 3 minutes, but I will be relying on you guys to tell me what you don't understand, and I will update the instructions as needed.
This can be run off the SD Card or the Internal Storage, both versions are included in the download. It will use the existing data partition if you already have the SDE installed and 2.1.04 firmware. Otherwise, you will need to flash the SDE, which erases your data, so please use Titanium Backup first if necessary.
Step 1:
Download my files:http://www.multiupload.com/HR6SRRR8P8
And install the SDE from Archos: http://www.archos.com/support/download/firm_dev/firmware_archos_android_gen8.aos.
Step 2: Boot into stock Android and connect to a Linux PC. If you do not have Linux, download Tuxboot and use it to create a GParted Live Disk:http://gparted.sourceforge.net/liveusb.php
Step 3:
Mount your Internal Storage/SD Card from the Archos. It should now show up in GParted on the Linux PC, make sure you have the correct device selected, it should be called Archos A101T(make note of the location, e.g. /dev/sdb). Resize your existing partition with GParted, leaving about 300MB at the end of the Internal Storage/SD Card. Make a new partition in the empty space, and select ext4 as filesystem. Apply Changes. Now open a terminal, elevate yourself to root by typing
Code:
sudo -s
and format the new partition by typing
Code:
mkfs.ext4 -O ^huge_file /dev/sdb2
Substitute "sdb" for whatever your device location was in GParted. The "2" on the end of "sdb" denotes that it is the second partition. Do NOT format "sdb1" or any other "sd"s. Mount the new partition by opening Nautilus or any other file manager and double clicking on the "300MB Filesystem" entry on the left. Untar the rootfs.tar.gz from my files with the Archive Manager, it works just like winzip or winrar, into the root of the new partition. Eject the device from Linux, then reboot into the Developer Menu by holding vol- or vol+ while booting.
Step 4:
Flash the initramfs.cpio.gz and the zimage from my files. Use the files from the "internal" folder if you are running from Internal Storage, or the files from "sdcard" if you are running from the SD Card.
Step 5:
Use the Dev Menu to boot into Developer Edition. Let me know about any bugs. After I removed the Android Boot option from the Dev Menu, I had a few strange loops of the Archos animation while booting, but it did boot, and function, just fine.
Thanks go to Ardatdat for the kernel, Archos for the crappy "securing" of the squashfs, and $auron for motivating me to get back into development.
Hi msticninja ,
I did it It seems so smooth. I used my internal storage. But linux steps were not so simple for me I used a Fedora 14 VMWare image.
I'm at work so I can't play with it but it seems stable and it can awake.
Quadrant (I know it's not accurate) score is about 1900 (internal and ext4).
I think that you should add some descriptions about linux steps (for noobs like me).
Thanks...
PS: Did I move my DATA partition to EXT4? (I did all steps you wrote). If no how can I do?
Nice work! I'll be trying to add more instructions for the Linux section for the next couple of days.
Your data partition is still EXT3, I haven't found a very easy way to convert it yet. Basically, I made another partition on the Internal Storage, copied the data partition there, and flashed a new initramfs to boot off the new data partition. Then you fdisk and format the original partition from a terminal in the Archos or ADB, copy everything back, and flash ANOTHER initramfs to use the original, now EXT4, partition.
So far, I don't think the performance gain for the data partition is worth all that work.
It works and installs well but your guide how to install it is not complete. For example, I had to manually maintain write permissions of the partition and sudo is needed by the mkfs.ext4 -O ^huge_file /dev/sdb2
Hondaracer said:
It works and installs well but your guide how to install it is not complete. For example, I had to manually maintain write permissions of the partition and sudo is needed by the mkfs.ext4 -O ^huge_file /dev/sdb2
Click to expand...
Click to collapse
Sorry, i automatically elevate permissions when I do stuff like this. I've added sudo to the instructions. As far as manually maintaining the partition permission, what did you have to do there?
msticninja said:
Sorry, i automatically elevate permissions when I do stuff like this. I've added sudo to the instructions. As far as manually maintaining the partition permission, what did you have to do there?
Click to expand...
Click to collapse
I had to type this: sudo chown -R username:usergroup /media By the way thanks for the work you've done
Hondaracer said:
I had to type this: sudo chown -R username:usergroup /media By the way thanks for the work you've done
Click to expand...
Click to collapse
If that was before using mkfs.ext4, then that is strange. After mkfs though, the owner should be root. I should point out that the rootfs.tar.gz should be extracted as root, which means you have to open the archive manager from a terminal. I need to find an easy process that will work on all distros, as I don't know how many have nautilus installed.
Thanks for your replies, this is much needed feedback.
msticninja said:
If that was before using mkfs.ext4, then that is strange. After mkfs though, the owner should be root. I should point out that the rootfs.tar.gz should be extracted as root, which means you have to open the archive manager from a terminal. I need to find an easy process that will work on all distros, as I don't know how many have nautilus installed.
Thanks for your replies, this is much needed feedback.
Click to expand...
Click to collapse
I had to do this to be able to write the rootfs to dev/sdb2. But I must say I did a reboot before I copied the files cause Ubuntu started to act very weird. And for the beginner I'd might be good to mention that you have to unmount in GParted.
I've tried it and feels slower than Uruk 0.6RC2 on Scandisk SDHC 8GB Class 4 (without OC).
Thank you for your great work!
chisco said:
I've tried it and feels slower than Uruk 0.6RC2 on Scandisk SDHC 8GB Class 4 (without OC).
Thank you for your great work!
Click to expand...
Click to collapse
I'm not surprised. This is the stock firmware with none of Uruk's enhancements, other than ext4 and a new kernel. As i said, this is to tide people over until the official Uruk thread gets 0.6. You're already on the beta 0.6, so there's not much need for my firmware.
I just wrote an automatic install script. All you have to do is copy a file to your internal storage or sd card, and flash the initramfs/zimage in the Dev Menu. This one will replace the current Archos partition so you won't lose any space on your storage device. Should be uploaded tonight.
I tried this method with last OC Kernel (11 FEB): very good... With this method, we use same data as for stock ROM, so no need to reinstall all apps...
Thanks.
My sdcard(class 4 8gb sandisk) is causing problems with fat32 fs...i use debian all the time and wud like to have a much advanced fs like ext4 for saving my music,videos,pictures etc instead of fat32...how can i achieve taht...Does android use a fstab or something for mounting on boot ???
I'm quite sure android uses fstab for mounting, you just need to set the proper mounting option on your FS to force it to check fstab options. I have one question(since I don't use a linux machine), can you access your ext(2nd) partition(if you have one) when you connect your phone to the PC using debian?
Yep,Android uses fstab to mount all.
anybody interested in setting it up i dont have the requisite knowhow
I have not toyed with fstab myself... but I did find this page which seems to have want your looking for.
http://androidandme.com/2009/08/news/how-to-manually-partition-your-sd-card-for-android-apps2sd/
It isn't exactly what your explaining, BUT seems to go through the commands needed for what you are wanting to try.
Just remember to back up! Good luck!
Sent from my LG-P500 using XDA App
Instructions:
-Suggested at least fat32 partition to be 1gig and the rest to your ext partition. Also, try to use root explorer for everything else. Must have init.d support.
1. On your SD card, make a folder to serve as a door/portal to access your ext partition files.(When testing this, I just used the default "/sdcard/media" folder)
2. Make a blank text file and name it as "11usext"
3. Using root explorer, edit the file and add this line inside it:
Code:
#!/system/bin/sh
busybox mount -t auto /dev/block/mmcblk0p2 /mnt/sdcard/media
change media to the folder that you just made on step 1. Exit and save.
4. Using root explorer move this file to /system/etc/init.d
5. Again using root explorer, change the permission to "rwxrwxrwx"
6. Reboot and play. This would allow you to access your ext partition through the /media or the folder that you have created.
If this does not work, then you should give more details on what setup you are running.
ungaze said:
Instructions:
-Suggested at least fat32 partition to be 1gig and the rest to your ext partition. Also, try to use root explorer for everything else. Must have init.d support.
1. On your SD card, make a folder to serve as a door/portal to access your ext partition files.(When testing this, I just used the default "/sdcard/media" folder)
2. Make a blank text file and name it as "11usext"
3. Using root explorer, edit the file and add this line inside it:
Code:
#!/system/bin/sh
busybox mount -t auto /dev/block/mmcblk0p2 /mnt/sdcard/media
change media to the folder that you just made on step 1. Exit and save.
4. Using root explorer move this file to /system/etc/init.d
5. Again using root explorer, change the permission to "rwxrwxrwx"
6. Reboot and play. This would allow you to access your ext partition through the /media or the folder that you have created.
If this does not work, then you should give more details on what setup you are running.
Click to expand...
Click to collapse
That's a quite dirty implementation. All he want's is an ext4 partition mounted as /sdcard. I want to do the same, but right now I'm messing with the internal fs. I'll look into it.
That's a quite dirty implementation.
Click to expand...
Click to collapse
Dirty it might be(I even tried a dirtier one), but that's all he's got at the moment. If you have a better solution(even just a rough plan), please do share. Maybe we can exchange knowledge on stuff like these.
Using 2 Ext4 partitions on SD instead of one Ext+fat32
Click to expand...
Click to collapse
Would mean that no Fat32 partition exist, and I've never heard of anything like that.
I have one question(since I don't use a linux machine), can you access your ext(2nd) partition(if you have one) when you connect your phone to the PC using debian?
Click to expand...
Click to collapse
And since no one answered this, I have no idea how you could transfer files to your phone without using card readers.
ungaze said:
Dirty it might be(I even tried a dirtier one), but that's all he's got at the moment. If you have a better solution(even just a rough plan), please do share. Maybe we can exchange knowledge on stuff like these.
Click to expand...
Click to collapse
Probably it involves messing with the init.rc (and I think that involves messing with boot and recovery images, but, I'm not sure) or init.d scripts or fstab. Anyway, I'm not sure, but it should be possible.
ungaze said:
Would mean that no Fat32 partition exist, and I've never heard of anything like that.
Click to expand...
Click to collapse
Yes. The /sdcard partition would exist, just not fat32 formatted.
ungaze said:
And since no one answered this, I have no idea how you could transfer files to your phone without using card readers.
Click to expand...
Click to collapse
Linux systems can read and write to ext4 partitions without problems. In fact, it's a linux filesystem. I had problems once when I had a sd_ext partition (for Apps2SD), because both partitions would get mounted when using mass storage mode, while Android only unmounts the /sdcard (fat32) partition, leading to file corruption (because of the same partition being mounted on both systems at once).
We could create the partitions using gparted or cfdisk on a pc. I'm not sure, but maybe simply mounting it with different params (like the filesystem type and other options) at /sdcard would do the trick. Everything else that follows would be easy.
I've been doing some testing and research.
On recovery side:
I've done a little modification in Mik's ClockWork recovery to make it accept ext4 and vfat as valid file systems for the first partition on sdcard. It involves just a little change on /etc/recovery.fstab file, but then you need to rebuild the recovery image.
This is working fine.
On the OS side:
It's not an easy mod. It involves patching the vold (volume manager) and recompiling. There are some proposed patches to Cyanogenmod, but I don't know if it's been accepted and if it made it to Miks CM7 port.
I'll do some tests and post results.
ilarrain said:
I've been doing some testing and research.
On recovery side:
I've done a little modification in Mik's ClockWork recovery to make it accept ext4 and vfat as valid file systems for the first partition on sdcard. It involves just a little change on /etc/recovery.fstab file, but then you need to rebuild the recovery image.
This is working fine.
On the OS side:
It's not an easy mod. It involves patching the vold (volume manager) and recompiling. There are some proposed patches to Cyanogenmod, but I don't know if it's been accepted and if it made it to Miks CM7 port.
I'll do some tests and post results.
Click to expand...
Click to collapse
This got my interest
Mik's CM7 (beta 6.2) recognizes and mounts the ext4 partition just fine.
BUT:
As vfat is a non posix fs, there wasn't any need for the OS to manage permissions, so it's a mess.
Applications on the SD card (I'm not using Apps2SD or Data2SD) don't load, internal applications can't be moved to SD, and many apps can't store data on the SD, even I've set read+write permissions on all files and directories (chmod -R 777 /sdcard/). I have no idea why. I'm stuck.
Hi!
Partitioned my 32GB sdcard, and put CM10.2 on it, but when I check it I have only about 400mb of space or something like that. I had the same amount of space on a 4GB sdcard I used before. Why am I not able to use up the rest of the GB's?! Can someone tell me how to fix it, I don't know if I'm partitioning wrong or doing something wrong, but I want to be able to have lots of extra space for music, apps, etc. Please help! Thanks!!!
I believe you used a low level utility like dd or similar to flash an image onto a partition.
You need to run fsck on that partition, then run resize2fs to expand the ext2/3/4 partition.
Let's say your partition is /dev/block/mmcblk1p1
You would do (in a terminal):
adb reboot recovery
adb shell
# umount /dev/block/mmcblk1p1
# e2fsck /dev/block/mmcblk1p1
# resize2fs /dev/block/mmcblk1p1
After that, your partition will get expanded to whatever size you made it.
It takes a while so be patient. The larger the partition, the longer it will take.
Zenile said:
Hi!
Partitioned my 32GB sdcard, and put CM10.2 on it, but when I check it I have only about 400mb of space or something like that. I had the same amount of space on a 4GB sdcard I used before. Why am I not able to use up the rest of the GB's?! Can someone tell me how to fix it, I don't know if I'm partitioning wrong or doing something wrong, but I want to be able to have lots of extra space for music, apps, etc. Please help! Thanks!!!
Click to expand...
Click to collapse
if you got a prebaked image of a bootable cm card from somewhere, then it usually has 4 partitions on it that were set to the sizes the author of the card specified.
/boot
/system
/data
/sdcard
You would need to put the card in a PC, and use a disk partitioning utility to resize the partitions
some of the images include additional flash files that you install to expand the card's partitions for you. (succulent's), but
you have to do it as you install for the first time.
I prefer to build the card empty first, and load the boot files and zips manually.
linux tools like gparted, Parted Magic , booting from a live USB or CD work pretty well.
Windows based ones like Easus Partition master, or Paragon, not so good.
Mini Tool partition wizard (windows/free) sometimes works
this looks to be a decent write up
http://www.mobileread.com/forums/showthread.php?t=202660
mikeataol said:
...
I prefer to build the card empty first, and load the boot files and zips manually.
linux tools like gparted, Parted Magic , booting from a live USB or CD work pretty well.
Windows based ones like Easus Partition master, or Paragon, not so good.
Mini Tool partition wizard (windows/free) sometimes works
this looks to be a decent write up
http://www.mobileread.com/forums/showthread.php?t=202660
Click to expand...
Click to collapse
The write-up is also posted on XDA at http://forum.xda-developers.com/showthread.php?t=2098419. It was written back in the days of CM10.1, so to use it for CM10.2 or CM11:
Obtain the boot files: MLO, u-boot.bin, and flashing_boot.img -- as well as the files boot.img and recovery.img, from the /boot partition of the pre-made SD CM image. Make sure that MLO is the first file to copy to the freshly made /boot partition.
Substitute in the appropriate ROM and Gapps zip files corresponding to the particular CM build of interest.
I start this thread due to popular demand. This issue is brought up every once in a while in regards to the Galaxy S2 family of devices, but may be of interest to owners of other similarly old hardware. I have been sitting on this info for over a year without time to document it and develop it further, and finally decided to publish what i know so others can implement what is needed.
NOTE: This information applies to Android 6. In Android 7+ things could have changed.
EDIT: confirmed working on Android 7.1.1 (CM14.1) by the.gangster!
What is this?
Old hardware that originally shipped with pre-ICS Android (such as the Galaxy S2 and friends) that provides an "internal" SD card, do so by means of a dedicated FAT partition in the eMMC that is separate from the EXT4 /data partition. On the other hand, newer hardware comes with a single big EXT4 /data partition and "emulates" an SD card (or several) by storing their contents in the /data/media folder. This is called "emulated storage".
Advantages of emulated storage
Emulated storage has many advantages over non-emulated storage:
- EXT4 is a modern journaling file system that is much safer than FAT.
- Due to increased safety, mount-time full file system check is not necessary in EXT4; so it mounts much faster than FAT.
- FAT is limited to files that are less than 4GB in size.
- Emulated storage can be encrypted.
- Only devices with emulated storage can support multiple users.
Conventional wisdom
All over the net you can find discussions regarding switching to emulated storage. Basically a two step process:
- Repartition your device to a huge /data and a vestigial or deleted /sdcard.
- Build a modified Android from source for your device that uses emulated storage.
Discussions center on the fact that ROM maintainers do not want to switch to emulated storage to avoid forcing everyone to repartition and wipe their phones.
The big misconception
The reality is that emulated storage can be used with standard ROMs built for non-emulated devices. The ROMs do not even need to be patched and can be flashed and used as-is. The repeated discussions over whether CM should switch have always been unnecessary.
How does it work then?
Surprisingly, Android stores the flag determining whether storage emulation is enabled or not in /data, presumably to allow upgrades from non-emulated to emulated modes. The flag is stored in /data/system/storage.xml: non-emulated storage is signaled by the presence of XML attribute primaryStorageUuid="primary_physical". To enable emulated storage: just edit this file, remove said attribute, and reboot. It is that simple.
What happens if I upgrade my ROM?
Everything keeps on working as it should; the above change only affects /data.
What happens if I wipe /data?
Your device will return to non-emulated mode. If the /sdcard partition is missing, it might not be able to boot.
Can wipe be 'fixed'?
Yes, but it requires a change in the ROM. This change has to be reapplied somehow every time you upgrade your ROM.
After a wipe, Android will initialize /data/system/storage.xml based on the value of system property ro.vold.primary_physical. If set to 1, Android will use non-emulated storage. To fix wipe, set this property to 0.
Is that all there is to it?
Nope! Recovery will still think you are on non-emulated storage and format /data when you choose to wipe it. This means that "wipe /data" will also wipe your emulated SD card!!! This is very dangerous.
I recommend that someone like Arnab builds a TWRP image for emulated storage. Maybe a second official build could be configured: something like device 'i9100_emu'.
I made an on-device patcher for TWRP before, and a year ago I tried to adapt it to mod TWRP for emulated storage use. Unfortunately I seem to remember that it is not possible to mod a TWRP image as the emu/non-emu distinction apparently gets baked into the code during compilation. Nonetheless, i found a file called 'lanchon-emulated-sd-twrp-3.0.2-0-i9100.img' lying around in my hard drive, and i have no idea what it is. Maybe a failed attempt? Could it work? I don't know, i don't remember what it is; guess not, but i could post it.
Moving forward
A year ago I wanted to make some scripts to do these changes, then run them though Flashize and sign them to convert them to flashable scripts. I don't have time for any of this now, but if someone wants to follow up, here is what could be done:
- A script to convert to emulated storage.
- A script to mod the ROM to use emulated storage after a /data wipe.
- A script like the previous one that uses the 'addon' ROM flashing mechanism to auto-run after each ROM flash, just like GAPPS do.
Of course a modded TWRP image would also be a great thing to have.
What else?
There is the question of what happens to the partition that had been /sdcard before the conversion. I suppose it gets mounted as a secondary SD card. In the case of the S2, that has an actual SD card slot, you can probably have two secondary SD cards mounted simultaneously.
The vestigial internal SD card is useless and it would be preferable to have it disappear. Methods to try:
- Wipe the /sdcard partition area so that the file system is gone and it cannot be mounted. This might produce the desired outcome, or Android might just fail to boot.
- Mod the ROM so that it does not look for this partition.
- Configure Android to swap SD cards 0 and 1, so that at least /sdcard0 is the external, useful one. (There are several threads covering this.)
How to repartition
REPIT cannot move data from one partition to another. So unless you manually backup the data in /sdcard, you will loose it.
On the i9100, to enlarge /data and reduce /sdcard to the minimum, you can use this configuration after backing up the /sdcard:
lanchon-repit-XXXXXXXX-system=same-data=max-sdcard=min+wipe-preload=min+wipe-i9100.zip
If you want to try rendering /sdcard unmountable to see what happens, you can use this configuration instead:
lanchon-repit-XXXXXXXX-system=same-data=max-sdcard=min+wipe+swap-preload=min+wipe-i9100.zip
NOTE: REPIT does not work on encrypted phones! If your phone is encrypted, you will have to back up /data to an external SD card and then format it to get rid of encryption before using REPIT.
And that's all folks!
I believe this procedure is too involved for the average user. So IMHO the standard builds should not move to emulated storage, given that advanced users can convert by themselves. The big problem is that wiping /sdcard is unavoidable due to lack of spare space to hold the data, unless really smart scripts that reduce and enlarge the partitions incrementally while moving files are made. A TWRP build that is able to backup and restore both the emulated and non-emulated sdcards to the external sdcard would be a big hit for this operation. The other big issue is handling encrypted phones; TWRP backups can help in that regard too.
Please share your experiences on this thread. I cannot test any of this, but with your help a full solution can be found.
(reserved)
Thanks for these insights. I do hope someone with the needed skills will carry on ?
Namoi said:
Thanks for these insights. I do hope someone with the needed skills will carry on ?
Click to expand...
Click to collapse
well, you can carry on! just use a file manager in root mode, create a backup of /data/system/storage.xml, edit the live file, and remove the attribute. that's all there is to it. your sdcard will be /data/media/0 after a reboot. you can copy your current sdcard files there (better do it after the first reboot) using adb shell in TWRP. some (but not all) files can also be copied using a root file manager.
Lanchon said:
NOTE: This information applies to Android 6. In Android 7+ things could have changed.
Click to expand...
Click to collapse
I dared to try it.
Just to confirm:
Modifying the storage.xml still seems to do the job on Android 7.1.1 (CM14.1).
After extinguishing the mentioned attribute (and nothing else yet! ) in storage.xml:
- an emulated storage was created in /data/media/0
- default folder structure got created in there
- settings->storage shows "internal share storage" as well as the well-known "sdcard0" and "sdcard1"
- file manager (where I had bookmarks for sdcard0 + 1) now shows bookmarks to Internal shared storage + sdcard1
- camera app (set to store pictures on phone) automatically switched to the new folderstructure
- Total Commander still showed sdcard0+1 until deleting its app-data -> now it references SD-card to emulated/0 and USB to sdcard1
- After connecting the phone to a PC and switching USB connection from "charging" to "Transfer files" even the PC only shows "Internal shared storage" and "sdcard1"
So all in all, android seems to really kind of automatically hide the existing non-emulated one in most apps, while still allowing access to it thru /mnt/media_rw/UUID if needed.
That's it for today from my side.
I'll add some screenshots.
the.gangster said:
I dared to try it.
Just to confirm:
Modifying the storage.xml still seems to do the job on Android 7.1.1 (CM14.1).
After extinguishing the mentioned attribute (and nothing else yet! ) in storage.xml:
- an emulated storage was created in /data/media/0
- default folder structure got created in there
- settings->storage shows "internal share storage" as well as the well-known "sdcard0" and "sdcard1"
- file manager (where I had bookmarks for sdcard0 + 1) now shows bookmarks to Internal shared storage + sdcard1
- camera app (set to store pictures on phone) automatically switched to the new folderstructure
- Total Commander still showed sdcard0+1 until deleting its app-data -> now it references SD-card to emulated/0 and USB to sdcard1
- After connecting the phone to a PC and switching USB connection from "charging" to "Transfer files" even the PC only shows "Internal shared storage" and "sdcard1"
So all in all, android seems to really kind of automatically hide the existing non-emulated one in most apps, while still allowing access to it thru /mnt/media_rw/UUID if needed.
That's it for today from my side.
I'll add some screenshots.
Click to expand...
Click to collapse
so it seems everything works!!
strange that the system seems to show the size of sdcard0 as used spaced in internal storage...
so will you backup sdcard0 and REPIT? or go back to non-emulated? i'm curious about what would happen with the +wipe+swap options in sdcard=. will the phone boot or not? who knows...
Does someone have any link that explain the "'addon' ROM flashing mechanism"?
PS: Does using emulated SD affect read/write performance?
Lanchon said:
so it seems everything works!!
strange that the system seems to show the size of sdcard0 as used spaced in internal storage...
so will you backup sdcard0 and REPIT? or go back to non-emulated? i'm curious about what would happen with the +wipe+swap options in sdcard=. will the phone boot or not? who knows...
Click to expand...
Click to collapse
Free space: Yes, it looks like the size calculation simply shows the used space out of the whole emmc area (mmcblk0). So all partitions except /data (mmcblk0p10) are "used" space (even if they are free) and only the actual free space in the /data partition (1.5gb of 4.5gb) is shown as "not used".
Repit: Haven't made my mind up, yet. As I only started testing it out of curiosity. I wasn't even a friend of the idea to break up with all the well-known tools and reinventing everything from scratch. But as it turns out now, it might not be the big step that it was expected to be. Meanwhile I would rather consider preserving a small internalsd, not to break with the partition layout.
Whether formatted or not shouldn't make a big difference. There have been so many people here, who used the odin-with-pitfile-method to change their partitions and who where not instructed properly to format the internalSD in the recovery right away, that I can recall the only thing happend was, the s2 booted up and if an App wanted to access that storage it resulted in "sdcard0 is corrupted"-errors.
But maybe I'll also manage to test the rest within the next week.
@ale5000
just take a look into your /system/addon.d folder and you'll find some scripts that are executed automatically upon ROM upgrades. They should serve as good examples already.
the.gangster said:
Free space: Yes, it looks like the size calculation simply shows the used space out of the whole emmc area (mmcblk0). So all partitions except /data (mmcblk0p10) are "used" space (even if they are free) and only the actual free space in the /data partition (1.5gb of 4.5gb) is shown as "not used".
Repit: Haven't made my mind up, yet. As I only started testing it out of curiosity. I wasn't even a friend of the idea to break up with all the well-known tools and reinventing everything from scratch. But as it turns out now, it might not be the big step that it was expected to be. Meanwhile I would rather consider preserving a small internalsd, not to break with the partition layout.
Whether formatted or not shouldn't make a big difference. There have been so many people here, who used the odin-with-pitfile-method to change their partitions and who where not instructed properly to format the internalSD in the recovery right away, that I can recall the only thing happend was, the s2 booted up and if an App wanted to access that storage it resulted in "sdcard0 is corrupted"-errors.
But maybe I'll also manage to test the rest within the next week.
@ale5000
just take a look into your /system/addon.d folder and you'll find some scripts that are executed automatically upon ROM upgrades. They should serve as good examples already.
Click to expand...
Click to collapse
you should try it. when i migrated to unified storage many many years ago, it was a big hit. there is not big break up and nothing to invent, everything in android should work out of the box. take the plunge! and go for min sdcard. you dont need it! you have external SD if you need one. and in any case, if needed, using REPIT later to shrink data, and enlarge plus wipe sdcard should be almost instantaneous (no moving of any partition).
the only problem is TWRP:
-wipe data will wipe your sdcard too. but why would you wipe data? and you can adb shell to TWRP to manually wipe while keeping /data/media if you needed it.
-backup data will backup sdcard too. you'll need to backup to external storage of course.
-restore data will wipe and restore sdcard too.
i REALLY THINK an emulated official build for this device would be a great thing.
ale5000 said:
Does someone have any link that explain the "'addon' ROM flashing mechanism"?
PS: Does using emulated SD affect read/write performance?
Click to expand...
Click to collapse
addon is a channel between gapps (and whatever else) and custom roms. CM supports it. when you flash CM, it wipes system putting a new file system image there (in LP and later). but mysteriously if you had gapps before flashing, gapps remain. how's that?
well, CM runs hooks that might be present in /system/addon.d at several stages. i dont remember the details but at a minimum it's like this:
-run "before" hooks.
-install CM, completely wiping system.
-run "after" hooks.
so stuff you flash after flashing CM (eg: gapps) might add hooks in that folder. gapps in particular backs itself up from /system to somewhere in its "before" hook, then reinstalls itself from the backup in its "after" hook. where does it back itself up? i don't know, probably to /data, as REPIT gets /cache to be very small by default on many devices and i havent heard any complaints so far.
so when you flash stuff that uses addon, not only it flashes whatever it needs, but it also sets up hooks in the addon folder. and that's it.
for the life of me i can't understand why so many software doesn't use addon. examples that come to mind now: xposed and roots such as supersu. maybe rovo doesnt know about this mechanism? impossible, someone must have told him!
anyway, to get rid of existing addons, just format /system before flashing CM et al. pretty intuitive if you ask me.
@Lanchon: Thanks.
Does it work on both flashing ROM update manually through recovery and normal OTA updates inside Android or not?
ale5000 said:
PS: Does using emulated SD affect read/write performance?
Click to expand...
Click to collapse
yes but only when apps access storage, not when the system accesses it. this is because access goes though FUSE.
google's FUSE use in android is an abomination. samsung and moto both knew this and fixed their OSes by moving the FUSE functionality to a kernel driver. google is backporting samsung's implementation (sdcardfs) to the standard android kernel, and my guess is that FUSE will be retired on the next android version.
FUSE can have a performance impact going from 15 to over 50%. large numbers correspond to small files or small file operations.
BUT... maybe FUSE is used for the non-emulated sdcard too, to synthesize permissions, so there might be no extra hit if you switch. this is at least very probable. i think FUSE is used for external microSDs these days, so the internal ones would be handled in the same way.
there is a native process in your phone called sdcard (that's the binary's name). if you find it, kill it. it shouldn't respawn i guess. after the kill, apps such as the gallery should loose access to the sdcard until you reboot. if this happens, it proves that FUSE is already being used and you wont get a performance hit from switching to emulated sd.
well... strike all that! i remember from the FPBug days, sdcard WAS in fact used, and when it died, access to the sdcard WAS indeed lost. this was already happening in KK and maybe android 4.3 too. so yes, you are already running FUSE.
ale5000 said:
@Lanchon: Thanks.
Does it work on both flashing ROM update manually through recovery and normal OTA updates inside Android or not?
Click to expand...
Click to collapse
it works on both methods. the flashable zip never knows if it's manual or OTA.
Lanchon said:
there is a native process in your phone called sdcard (that's the binary's name). if you find it, kill it. it shouldn't respawn i guess. after the kill, apps such as the gallery should loose access to the sdcard until you reboot. if this happens, it proves that FUSE is already being used and you wont get a performance hit from switching to emulated sd.
Click to expand...
Click to collapse
And I thought, simply looking at the mount command would already tell, wouldn't it?
Code:
i9100:/ # mount
rootfs on / type rootfs (ro,seclabel,relatime)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt type tmpfs (rw,seclabel,relatime,mode=755,gid=1000)
none on /dev/memcg type cgroup (rw,relatime,memory)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/dev/block/mmcblk0p9 on /system type ext4 (ro,seclabel,noatime,us
/dev/block/mmcblk0p7 on /cache type ext4 (rw,seclabel,nosuid,node
/dev/block/mmcblk0p1 on /efs type ext4 (rw,seclabel,nosuid,nodev,
/dev/block/mmcblk0p10 on /data type ext4 (rw,seclabel,nosuid,node
/dev/block/mmcblk0p12 on /preload type ext4 (rw,seclabel,nosuid,n
tmpfs on /storage type tmpfs (rw,seclabel,relatime,mode=755,gid=1
/sys/kernel/debug on /sys/kernel/debug type debugfs (rw,seclabel,
/dev/fuse on /mnt/runtime/default/emulated type fuse (rw,nosuid,n
/dev/fuse on /storage/emulated type fuse (rw,nosuid,nodev,noexec,
/dev/fuse on /mnt/runtime/read/emulated type fuse (rw,nosuid,node
/dev/fuse on /mnt/runtime/write/emulated type fuse (rw,nosuid,nod
/dev/block/vold/public:179_11 on /mnt/media_rw/8C8D-EB5C type vfa
o)
/dev/block/vold/public:179_13 on /mnt/media_rw/E1C9-1514 type vfa
o)
/dev/fuse on /mnt/runtime/default/E1C9-1514 type fuse (rw,nosuid,
/dev/fuse on /storage/E1C9-1514 type fuse (rw,nosuid,nodev,noexec
/dev/fuse on /mnt/runtime/read/E1C9-1514 type fuse (rw,nosuid,nod
/dev/fuse on /mnt/runtime/write/E1C9-1514 type fuse (rw,nosuid,no
i9100:/ #
lol, i suppose, that too!
btw i found this lying on my harddrive. i dont know what it is, i dont remember. it is probably a attempt to hack official TWRP to work in emulated mode. i suppose it might not work because i dont remember success, but for sure it wont be anything malicious, so you guys can try it if you want.
Lanchon said:
btw i found this lying on my harddrive. i dont know what it is, i dont remember. it is probably a attempt to hack official TWRP to work in emulated mode. i suppose it might not work because i dont remember success, but for sure it wont be anything malicious, so you guys can try it if you want.
Click to expand...
Click to collapse
Thx. I would have taken a look at TWRP anyway so I'll have a look at that one as well.
If I only had more time....
Lanchon said:
.... and you can adb shell to TWRP ...
Click to expand...
Click to collapse
hm,
adb shelling to to both my i9100 devices doesn't work when in TWRP, as adb doesn't find my devices then.
Code:
error: no devices/emulators found
Tested that with four adb versions (1.0.31, 1.0.32, 1.0.35 and 1.0.36).
Also tested against TWRP 2.8.7.0.
MTP-mounting in TWRP works fine.
As I use it frequently it is needless to say that when booted into the ROMs (CM13+LineageOS14.1) both work fine with each of those adb versions.
Any idea? Special drivers needed for that?
the.gangster said:
hm,
adb shelling to to both my i9100 devices doesn't work when in TWRP, as adb doesn't find my devices then.
Code:
error: no devices/emulators found
Tested that with four adb versions (1.0.31, 1.0.32, 1.0.35 and 1.0.36).
Also tested against TWRP 2.8.7.0.
MTP-mounting in TWRP works fine.
As I use it frequently it is needless to say that when booted into the ROMs (CM13+LineageOS14.1) both work fine with each of those adb versions.
Any idea? Special drivers needed for that?
Click to expand...
Click to collapse
some adb operations require being root on the pc side. why? i don't know. it might be a strange safeguard in the adb client, i never understood that.
try:
sudo adb kill-server
sudo adb shell
if on linux.
on windows open an administrative cmd prompt and run those two same commands (without sudo of course).
Thank you but: No it's none of that. (Yes, I am still on Win7 x64 Pro)
Those were the first actions that I checked already even before trying with the other adb versions. And if you are switching from one version to another the old adb is also killed automatically.
It's not that simple.
But thanks anyway.
This may be simpler than I think or impossible, but I don't know enough to decide either way.
I am trying to salvage an abandoned sdcard-based CM 11 ROM for the B&N Nook Simple Touch e-reader. Mostly, I've been able to work around issues but I would like to enable some kind of boot option so the user could reboot into the CM 11 ROM from the stock OS and vice/versa. I have tested the idea in principle and know that if u-boot.bin in the boot partition of the sdcard is renamed to u-boot.bin.bak or similar, the device will not boot from the sdcard but instead from the internal OS.
If I expand the sdcard boot partition (FAT32) to fill up the vacant space on the sdcard, the internal OS sees this as a valid sdcard and will use it for user files, etc. And, indeed, I can still see the boot files using a file manager so un-renaming u-boot.bin in preparation for booting into the CM 11 system is easy. I can write a little app that will handle both restoring the file name to u-boot.bin and triggering a reboot.
It's the other direction that has me stumped. When the CM 11 ROM boots up from the sdcard, the boot partition becomes invisible as far as I can tell. How can I see the files there and (hopefully) rename u-boot.bin to disable it if the user wants to reboot back into the stock OS? If this can be done via shell commands, that would be ideal.
Any help?