Use sd card as internal storage and stop writing to internal memory for good

Question

Smartphones seem to die after two years of usage, as if they knew that you just have paid the last instalment.
The common reason seems to be the failure of internal memory.
I'm desperately trying to have my phone escaping from this cruel destiny.
The idea I initially had seemed simple, but the web didn't seem to share my optimism.
This is the idea:
- create ext4 partitions in sd card
- mount at boot sdcard partitions to /data and /cache (and maybe /preload and /efs if they ever get written)

I'd like to know what's wrong with this idea and why it cannot work, but the main question is:
Can I stop writing to internal memory for good?

I've seen all the apps out there (app2sd, link2sd, DirecoryBind, s2e , you name it) and all of them seem to relocate subdirectories, never the main /data .
Any help will be highly appreciated.
Thank you!

Answer 1

Eureka!
Here is how I've done it:

SD card partition and format

Unsure about which partitions I would have been able to relocate, I decided to recreate my sd card with the exact same layout of my Samsung Galaxy S III internal memory.
USERDATA is the last partition and there is a good reason for it:
my sd card size is greater then the internal memory and the best option has been to widen USERDATA till the possible furthest sector.

The following work has been done in my linux pc:

parted /dev/sdb mklabel gpt \
mkpart  BOTA0      ext2     8192s          16383s \
mkpart  BOTA1      ext2    16384s          24575s \
mkpart  EFS        ext2    24576s          65535s \
mkpart  PARAM      ext2    65536s          81919s \
mkpart  BOOT       ext2    81920s          98303s \
mkpart  RECOVERY   ext2    98304s         114687s \
mkpart  RADIO      ext2   114688s         180223s \
mkpart  CACHE      ext2   180224s        2277375s \
mkpart  SYSTEM     ext2  2277376s        5423103s \
mkpart  HIDDEN     ext2  5423104s        6569983s \
mkpart  OTA        ext2  6569984s        6586367s \
mkpart  USERDATA   ext2  6586368s       60749824s

Good, partitions created.
Now, still mimicking my Android device, I format partitions accordingly:

# /efs
mkfs.ext4  /dev/sdb3   -E root_owner=1001:1000
# /system
mkfs.ext4  /dev/sdb9   -E root_owner=0:0         -L system
# /cache
mkfs.ext4  /dev/sdb8   -E root_owner=1000:2001
# /preload
mkfs.ext4  /dev/sdb10  -E root_owner=0:0
# /data
mkfs.ext4  /dev/sdb12  -E root_owner=1000:1000

The sd card is ready, now I can "backup" files from emmc to the appropriate sd card partition, taking care to preserve file attributes.

Edit fstab

In the not too old versions of Android, fstab file seems to be always located at /.
Files in / are stored in the BOOT partition (boot.img);
it's time to learn to edit the boot.img.
Here are two very helpful tutorials that will get you going:
HOWTO: Unpack, Edit, and Repack Boot Images
Android boot.img manipulation
a little hint:
Do edit the ramdisk in your Android device.
I spent three days in frustration trying to do so in my pc, I guess is a matter of "endianness".
When editing the ramdisk, do sort name-list(standard input) for cpio.
I spent three years in frustrating randomly recurring failures.

---

My fstab before:

/dev/block/mmcblk0p3        /efs            ext4        noatime,nosuid,nodev,journal_async_commit,errors=panic      wait
/dev/block/mmcblk0p9        /system         ext4        ro,noatime      wait
/dev/block/mmcblk0p8        /cache          ext4        noatime,nosuid,nodev,journal_async_commit,errors=panic      wait
/dev/block/mmcblk0p10       /preload        ext4        noatime,nosuid,nodev,journal_async_commit       wait
/dev/block/mmcblk0p12       /data           ext4        noatime,nosuid,nodev,noauto_da_alloc,journal_async_commit,errors=panic      wait,check,encryptable=footer

My fstab after:

/dev/block/mmcblk0p3        /efs            ext4        noatime,nosuid,nodev,journal_async_commit,errors=panic      wait
/dev/block/mmcblk1p9        /system         ext4        ro,noatime      wait
/dev/block/mmcblk1p8        /cache          ext4        noatime,nosuid,nodev,journal_async_commit,errors=panic      wait
/dev/block/mmcblk1p10       /preload        ext4        noatime,nosuid,nodev,journal_async_commit       wait
/dev/block/mmcblk1p12       /data           ext4        noatime,nosuid,nodev,noauto_da_alloc,journal_async_commit,errors=panic      wait,check,encryptable=footer

All I have changed is the block number (from 0 to 1).
I couldn't dare yet to relocate EFS, someone said that somehow you may brick the device playing around with that, still studying the subject; I do know that Android keeps writing EFS (I'm monitoring it).

Conclusions and further queries

This is how I relocated the most of my internal storage data to my external sd card.
Things are slightly sluggish, as expected, but Android seems to be in perfect working order;
I can always invest in a faster sd card in the future.
I did all of this with my Samsung Galaxy S III stock ROM, you will obviously have to adapt to your circumstances.
When I finally installed CyanogenMod 13 (we don't want stock firmware, do we!?) things were a bit different.
With a wiped /data, CM is spending some time at boot populating /data and at a certain point it just give up, reboot and goes to recovery mode.
After several attempts I gave up and relocated /system in internal memory, now everything is fine.
I do know that /system is mounted as read only, but I noticed that emmc lifespan is defined as amount of read/write cycles, maybe suggesting that, unlike hard drives, reading is as detrimental as writing.
If that's the case I'd be most grateful if someone could tell me why in CM I cannot successfully relocate /system.

Answer 2

@Claudio you have raised a very good concern. Having some embedded knowledge, I can give some idea about this:

When you switch ON a device, it is programmed to boot from specific memory location. This memory location is hardwired to internal memory.

Usually in demo embedded devices, we have a small switch which we can use to switch between different BOOT devices - it may be internal, external, even serial port.

But in production or commercial devices, this switch will be removed.

So, it is next to impossible to boot directly from external memory.

I wish some companies can provide a option(like switch) to boot from external memory even if internal memory goes wrong.

Answer 3

I have been successfully able to boot from SD card on QMobile Z8 by:

• Replicating eMMC partition table by partitioning SD card on a Ubuntu machine using parted and fdisk
• Flashing factory firmware images to these newly created partitions using dd
• Modifying fstab.qcom & init.tegra.rc files in kernel (boot.img) and recovery.fstab and uneventd.rc files in TWRP recovery to initiate mounting and booting from SDCard instead of internal memory

It was successful after some experiments. I think this method should be applicable to any device with similar configuration. However, files to be edited may vary from device to device.

If you want to put only apps' external data to SD card and not the whole partition, you can edit fstab in boot.img and storage list in framework-res.apk on Android 5 and older.

For more details: [HOW TO] BOOT FROM SD CARD [SUCCESSFULLY] on QMobile Z8 with BRICKED/DEAD eMMC