Related
Hello All,
I need help from experimented people because while trying to reformat my YP-GB70 - 5.0 korean version (internal memory went wreck after some bad manipulations in testing new roms)
Problem: partition14 is no more available, same for 15 and above and have to be reformatted through adb/fdisk.
Reformatting: OK but!
This is a normal operation I've done it 3 times already ,but the issue I am facing now is because Fdisk does not want to open the main /dev/block/mmcblk0 where the partitions are located and visible (excepted n°14 to 17 that are no more linux formated).
I am root access and I am able to access and reformat /dev/block/mmcblk1 that is my external SD card, so problem seems to be somewhere around fdisk instruction to open main memory .
Here attached the overall listing for verification.
Your suggestions are welcome, i need this issue solved for me, sure, but for any other people that can face the same behavior.
Anybody knows the trick? or any advice to help?
The most efficient way to do this is getting a full dd dump of another device. From adb in a working device:
Code:
mount /dev/block/mmcblk0p1 /sdcard
dd if=/dev/block/mmcblk0 of=/sdcard/image.img
Then dumping on your device:
Code:
mount /dev/block/mmcblk0p1 /sdcard
dd if=/sdcard/image.img of=/dev/block/mmcblk0
This command usually takes about 45 minutes or more to complete (you have 32gb internal storage).
Another way you can recover your device, but it's more risky:
DON'T DO IT UNLESS YOU HAVE THE OUTPUT OF A WORKING DEVICE (http://forum.xda-developers.com/showpost.php?p=21915742&postcount=3 )
Using fdisk /dev/block/mmcblk0
Recreate the partition table (if i'm not mistaken the command is o).
Then, you need to create p1 (primary), which is extended and uses all the device storage. The rest of partitions are logical (inside p1).
Make sure you replicate exactly the partition table. DON'T WRITE THE PARTITION TABLE UNLESS YOU'RE DONE. DON'T REBOOT THE DEVICE UNLESS YOU'RE DONE. If you do it --> hardbrick.
Many thanks for your prompt and precise answer.
I am going to ask for a GB70 dump with low confidence in getting it...
I will investigate the "hard" repartitionning way you suggest, I am not sure fdisk will allow me to modify anything because the main memory access is permanently denied.
(/dev/block/mmcblk0)
I already have my device partition table from previous issue I had in march.
regards
memory Issue under control
rumirand said:
The most efficient way to do this is getting a full dd dump of another device. From adb in a working device:
Code:
mount /dev/block/mmcblk0p1 /sdcard
dd if=/dev/block/mmcblk0 of=/sdcard/image.img
Then dumping on your device:
Code:
mount /dev/block/mmcblk0p1 /sdcard
dd if=/sdcard/image.img of=/dev/block/mmcblk0
This command usually takes about 45 minutes or more to complete (you have 32gb internal storage).
Another way you can recover your device, but it's more risky:
DON'T DO IT UNLESS YOU HAVE THE OUTPUT OF A WORKING DEVICE (http://forum.xda-developers.com/showpost.php?p=21915742&postcount=3 )
Using fdisk /dev/block/mmcblk0
Recreate the partition table (if i'm not mistaken the command is o).
Then, you need to create p1 (primary), which is extended and uses all the device storage. The rest of partitions are logical (inside p1).
Make sure you replicate exactly the partition table. DON'T WRITE THE PARTITION TABLE UNLESS YOU'RE DONE. DON'T REBOOT THE DEVICE UNLESS YOU'RE DONE. If you do it --> hardbrick.
Click to expand...
Click to collapse
PROBLEM SOLVED:
I have applied your guide lines and I finally succeeded turning back the device to life.
This was only possible because of the work you and Adamoutler's team have done.
Was mandatory your RJ14 kernel (V5.02.7)(- 2.8 also working ) and the "Unbrickeable resurrector" stuff .
Rebuilt the device 17 logical memory partitions and back to life again.
(see attachement)
Details for interested people under request.
More than many thanks again for your great help.
Alright so here's the deal, my internal SDCARD is corrupted and the /data partition is unusable.
My device is i9003 and it's running on MIUI at the moment. By default MIUI didn't detect my external SD or my internal SD but after editing "vold.fstab" I was able to mount the first partition of my external SDCARD as external memory and everything was good, I could finally use the camera and pretty much do everything else.
But I was still unable to mount the second partition of my external SDCARD as my internal memory which meant none of my messages could be saved and the phone would pretty much go back to factory settings after a reboot, this apparently is because the /data partition (present on the internal memory) stores all the user data such as the time, the theme I'm using, etc and not having a /data partition meant none of these settings were really saved.
Having no internal memory also means I cannot install any apps such as Link2SD.
Moving on, after many hours of googling I found out that it might not be possible to mount the internal memory using "vold.fstab" and the only way to do it could be by mounting the memory manually during init.
So here's what I want again, I want to use the second partition of my external SDCARD as internal memory, this is likely to solve all my problems and make my phone usable again.
Thanks for all the help, appreciate it.
You need to edit /init.rc (or init.vendor.rc). To make the edits here stay, you'll need to create a new boot.img to flash your device with.
Have a look at an extract of mine init.<vendor>.rc:
Code:
on fs
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
#mount yaffs2 [email protected] /system
#mount yaffs2 [email protected] /system ro remount
# Use below two lines instead of above to run /system from SDcard instead of internal flash
mount ext3 /dev/block/mmcblk0p3 /system
mount ext3 /dev/block/mmcblk0p3 /system ro remount
#mount yaffs2 [email protected] /data nosuid nodev
mount ext3 /dev/block/mmcblk0p4 /data nosuid nodev
mount yaffs2 [email protected] /cache nosuid nodev
Compare the lines I've commented out with the others. Here both /data and /system resides on the SDcard, you only need to care about /data. Also remember your device nodes may not be named "mmcblk0p3" etc.
But you'll need to make those changes in the initramfs in your flashed boot.img to make them stay.
kuisma said:
You need to edit /init.rc (or init.vendor.rc). To make the edits here stay, you'll need to create a new boot.img to flash your device with.
Have a look at an extract of mine init.<vendor>.rc:
Code:
on fs
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
#mount yaffs2 [email protected] /system
#mount yaffs2 [email protected] /system ro remount
# Use below two lines instead of above to run /system from SDcard instead of internal flash
mount ext3 /dev/block/mmcblk0p3 /system
mount ext3 /dev/block/mmcblk0p3 /system ro remount
#mount yaffs2 [email protected] /data nosuid nodev
mount ext3 /dev/block/mmcblk0p4 /data nosuid nodev
mount yaffs2 [email protected] /cache nosuid nodev
Compare the lines I've commented out with the others. Here both /data and /system resides on the SDcard, you only need to care about /data. Also remember your device nodes may not be named "mmcblk0p3" etc.
But you'll need to make those changes in the initramfs in your flashed boot.img to make them stay.
Click to expand...
Click to collapse
Thanks for the reply man, mind telling me the how I can go about doing this?, I've got the ROM I flashed via CWM here with me, I could send it over to you if that would make things easier for you.
EDIT: would pulling init.rc via ADB, making the changes and pushing it back do the trick? or do I have to go for the boot.img? In case it's the latter, I'm going to need help doing it.
PhantomPhreek said:
Thanks for the reply man, mind telling me the how I can go about doing this?, I've got the ROM I flashed via CWM here with me, I could send it over to you if that would make things easier for you.
Click to expand...
Click to collapse
You'll find a good tutorial about how to work with boot images here: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
If you already got the ROM in a file, this should be easy! Got ADB and FASTBOOT as well?
kuisma said:
You'll find a good tutorial about how to work with boot images here: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
If you already got the ROM in a file, this should be easy! Got ADB and FASTBOOT as well?
Click to expand...
Click to collapse
I'm not sure I've got FASTBOOT but I've definitely got ADB and I've also got the ROM. Would pulling init.rc via ADB, making the changes and pushing it back do the trick? or do I have to go for the boot.img?.
PhantomPhreek said:
I'm not sure I've got FASTBOOT but I've definitely got ADB and I've also got the ROM. Would pulling init.rc via ADB, making the changes and pushing it back do the trick? or do I have to go for the boot.img?.
Click to expand...
Click to collapse
No. You need to reboot the phone for the init.rc script to execute, and once you reboot the phone, the root file system is overwritten by the flashed image ... Catch 22.
You'll NEED to create a new boot.img with a new initramfs containing your changes.
kuisma said:
No. You need to reboot the phone for the init.rc script to execute, and once you reboot the phone, the root file system is overwritten by the flashed image ... Catch 22.
You'll NEED to create a new boot.img with a new initramfs containing your changes.
Click to expand...
Click to collapse
Shucks, this explains why it didn't work. Alright, so I extract boot.img from the rom, follow the tutorial.What is it that I have to edit again? "/init.rc" or "init.<vendor>.rc"?.
Thanks for the help man, appreciate it.
EDIT: Looks like the tutorial is meant for Linux, I'm currently on Windows. I might be asking for a lot here but is there any chance I could get you to do it for me?
PhantomPhreek said:
Shucks, this explains why it didn't work. Alright, so I extract boot.img from the rom, follow the tutorial.What is it that I have to edit again? "/init.rc" or "init.<vendor>.rc"?.
Thanks for the help man, appreciate it.
Click to expand...
Click to collapse
Of course, MIUI may have some boot hooks you could use to re-mount /data after boot. I know nothing about that ROM. Also keep in mind that each time you update the ROM, you have to remake this edit.
Also, no idea what MIUI calls its init.rc, you'll just have to see for yourself. If you've got the mount commands in init.rc, fine. Else look elsewhere.
A good first step would to make sure you really are able to flash a new boot.img. Download fastboot and verify your device understands it. Else you have to use some proprietary flash program, and I'm not familiar with Samsungs bootloaders at all. Ask in the Samsung forum if so.
kuisma said:
Of course, MIUI may have some boot hooks you could use to re-mount /data after boot. I know nothing about that ROM. Also keep in mind that each time you update the ROM, you have to remake this edit.
Also, no idea what MIUI calls its init.rc, you'll just have to see for yourself. If you've got the mount commands in init.rc, fine. Else look elsewhere.
A good first step would to make sure you really are able to flash a new boot.img. Download fastboot and verify your device understands it. Else you have to use some proprietary flash program, and I'm not familiar with Samsungs bootloaders at all. Ask in the Samsung forum if so.
Click to expand...
Click to collapse
Looks like the tutorial is meant for Linux, I'm currently on Windows. I might be asking for a lot here but is there any chance I could get you to do it for me?. ADB and I do see the file init.rc and I also see the mount commands as well. I used adb shell to run the command you sent over with a few edits for second partition and it does mount but as you said, it all goes away after reboot.
PhantomPhreek said:
Looks like the tutorial is meant for Linux, I'm currently on Windows. I might be asking for a lot here but is there any chance I could get you to do it for me?. ADB and I do see the file init.rc and I also see the mount commands as well. I used adb shell to run the command you sent over with a few edits for second partition and it does mount but as you said, it all goes away after reboot.
Click to expand...
Click to collapse
Hmm... are you even able to create a second ext3 partition on the SDcard using Windos..?
kuisma said:
Hmm... are you even able to create a second ext3 partition on the SDcard using Windos..?
Click to expand...
Click to collapse
haha, I used CWM to create the partitions initially, but then I used a software called MiniTool, works well. Can I get you to to do it?
PhantomPhreek said:
Alright so here's the deal, my internal SDCARD is corrupted and the /data partition is unusable.
Click to expand...
Click to collapse
The ROM you are using requires an ext4 partition as partition #3 of the SDcard. This is mounted as /data. Repartition your SDcard #1 as FAT, #2 whatever, and #3 as ext4, and everything will work as intended. :victory:
I guess you've missed this in the ROM documentation ...
kuisma said:
The ROM you are using requires an ext4 partition as partition #3 of the SDcard. This is mounted as /data. Repartition your SDcard #1 as FAT, #2 whatever, and #3 as ext4, and everything will work as intended. :victory:
I guess you've missed this in the ROM documentation ...
Click to expand...
Click to collapse
Wah~ really?, I'll try that and get back here with the results. Thanks a lot!.
EDIT: Is it FAT or FAT32?
PhantomPhreek said:
Wah~ really?, I'll try that and get back here with the results. Thanks a lot!.
EDIT: Is it FAT or FAT32?
Click to expand...
Click to collapse
FAT32.
kuisma said:
FAT32.
Click to expand...
Click to collapse
Tried but didn't work out. I made three partitions, all primary - #1 FAT32, #2 FAT32, #3 EXT4. Plugged the SDCARD in and the external memory was detected as usual, but not the internal memory.
I tried changing the time, it was reset back after reboot.
After that I left the SDCARD as is and flashed the ROM again and now, neither the internal nor the external memory are detected. This is probably because the "vold.fstab" which was edited by me, was overwritten on re flashing.
I'm at a dead end, any ideas?
PhantomPhreek said:
Tried but didn't work out. I made three partitions, all primary - #1 FAT32, #2 FAT32, #3 EXT4. Plugged the SDCARD in and the external memory was detected as usual, but not the internal memory.
I tried changing the time, it was reset back after reboot.
After that I left the SDCARD as is and flashed the ROM again and now, neither the internal nor the external memory are detected. This is probably because the "vold.fstab" which was edited by me, was overwritten on re flashing.
I'm at a dead end, any ideas?
Click to expand...
Click to collapse
Attach an output of "df", "mount", the file "/init.latona.rc" and "/etc/vold.fstab" here, and I'll have a look at it. Hmm... include the output of "dmesg" as well, to be on the safe side.
kuisma said:
Attach an output of "df", "mount", the file "/init.latona.rc" and "/etc/vold.fstab" here, and I'll have a look at it. Hmm... include the output of "dmesg" as well, to be on the safe side.
Click to expand...
Click to collapse
What bugs me is the fact that the external SD is not detected, from what little knowledge I have, external SD is unrelated to the internal SD which I currently have problems with, meaning it should be detected without a problem.
Also I have to add, CWM doesn't detect my external SD right away, when I go to recovery and go over to "Choose zip from sdcard" it says "E:Can't mount /sdcard/". The solution I've found coincidentally is to go to "mounts & storage", mount "/emmc", pull the SDCARD out plug it in again and then "mount /sdcard" this works perfectly and I'm able to flash roms from the sdcard.
One problem at a time, please. Attach the files I requsted, so we can determine why /data failes to mount. Looking at your ROM:
Code:
$ grep " /data$" init.latona.rc
mount ext4 /dev/block/mmcblk0p3 /data
I want to know why this fails, and I guess the answer is in the dmesg output. And please before I'll get another whiskey.
kuisma said:
One problem at a time, please. Attach the files I requsted, so we can determine why /data failes to mount. Looking at your ROM:
Code:
$ grep " /data$" init.latona.rc
mount ext4 /dev/block/mmcblk0p3 /data
I want to know why this fails, and I guess the answer is in the dmesg output. And please before I'll get another whiskey.
Click to expand...
Click to collapse
I can't seem to find "/init.latona.rc" everything else you requested I've mailed them over already
EDIT: the dmesg output is AFTER I mounted "/sdcard" manually as explained in my previous post.
PhantomPhreek said:
I can't seem to find "/init.latona.rc" everything else you requested I've mailed them over already
EDIT: the dmesg output is AFTER I mounted "/sdcard" manually as explained in my previous post.
Click to expand...
Click to collapse
The files you mailed me does not correspond to the ROM you refereed.
The /etc/fstab show that /data is mounted as an rfs file system, not ext4. So either format partition #3 on the sdcard as rfs (Samsung proprietary), or edit /etc/fstab and change "rfs" to "ext4". I'd prefer the later, assuming your kernel supports ext4. Else use ext3.
Code:
/dev/block/mmcblk0p3 /data rfs rw
But you can't have flashed the ROM you told me you did. It excepted an ext4 file system ...
I jumped from stock to CM10 and have found an issue I need resolved, but am not sure how to go about it.
On stock, I didn't have
/sdcard/ is the path for the internal memory
/sdcard/external_sd/ is the path for the actual add-in slot you buy yourself.
This is great because the file explorer apps don't need special access to get to, and things are at least somewhat logical on how they're laid out.
On CM10:
/storage/sdcard0/ is internal memory
/storage/sdcard1/ is external memory
There are symbolic links of /sdcard and /external_sd but to access the latter, I need to tell apps like ES file explorer to change their base path rather than just having a nested mount structure.
I've tried using terminal emulator to go in and create a symbolic link, but I get 'operation not permitted' messages. I've also tried editing /etc/vold.fstab to have it change the mount from /storage/sdcard1 to /storage/sdcard0/external_sd, but the filesystem is read-only and 'mount -o remount,rw /' doesn't have an effect even though it doesn't complain.
How can I change the mount structure back to how I want it and how it's easier to access/navigate it in my apps?
Run into some situation, hopefully someone can shed some light
Did you mount this files as r/w?
Sent from my SAMSUNG-SGH-I717 using xda premium
johnrippa said:
Did you mount this files as r/w?
Sent from my SAMSUNG-SGH-I717 using xda premium
Click to expand...
Click to collapse
In my original post I mention trying to get it remounted as r/w, the command doesn't complain but the filesystem stays read-only.
Try busybox mount -o remount,rw /system
If that fails, use an app to do it.
ChronoReverse said:
Try busybox mount -o remount,rw /system
If that fails, use an app to do it.
Click to expand...
Click to collapse
Any particular apps to recommend? I had tried issuing the remount command on / and not /system. I will give that another try.
ChronoReverse said:
Try busybox mount -o remount,rw /system
If that fails, use an app to do it.
Click to expand...
Click to collapse
I was able to modify the mount point to be /storage/sdcard0/external_sd/ for the external SD slot, but when I rebooted CM it got stuck and would buzz every 10 seconds or so and stayed that way indefinitely. Not sure why this breaks CM so bad but there you have it. Oh well.
Might be a better idea to just add links so you get your old /sdcard/external_sd
I'm not currently on a CM10 ROM or else I'd test.
ChronoReverse said:
Might be a better idea to just add links so you get your old /sdcard/external_sd
I'm not currently on a CM10 ROM or else I'd test.
Click to expand...
Click to collapse
Symbolic links don't work on a FAT based filesystem (which the SD card mounts are), unfortunately.
So I have a 32GB Samsung Evo in my phone, and I'm having terrible problems, andi don't k ow where to put this at.
At first, it kept switching to a read only state, and now its bringing up a EXOENT error.
It's formatted for VFAT, and want to switch to EXT4, maybe that'll stop the problems.
So, how do I format it for EXT4?
mke2fs -T ext4 /dev/block/yourblockdevice
do 'mount' and find which block device is the sdcard (normally mmcblk1)
you need to have root and execute those commands with adb shell or any shell emulator in android
nagalun said:
mke2fs -T ext4 /dev/block/yourblockdevice
do 'mount' and find which block device is the sdcard (normally mmcblk1)
you need to have root and execute those commands with adb shell or any shell emulator in android
Click to expand...
Click to collapse
It didn' worked for me, pls help
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.