[One (M8) Original Android Development] doublehp:
reboot on write

I, and other people from XDA had the same issue. Module loads fine, but phone reboots when trying to write. Can't be 100% we all have the same issue, but, just in case, I will share my experience.

My issue was simple. insmod was fine. remount was fine. But when trying to write NEW DATA on /system, phone rebooted. Phone did not read when trying to create empty files, or rename existing ones. Also, sometimes, I could create files with content. Always works for the same file name, always failed for same file names. So, it was not a matter of data, but of file names.

This, and other details leaded me very fast to think ... that my FS was corrupted.

A classic Linux box always performs fsck -a at boot. As Android assumes /system to be an unchangeable ROM, I thought that maybe ... the boot process did not perform this fsck -a. And there may be many reasons for that:

- phones are provided with write restrictions, from day 0

- ROM does include fsck, but not fsck.ext*

- fsck -a takes times; and Android 4 is optimised to boost the boot time; I found they had removed many time eating things. Especially in our M8 by HTC.

So, if after remount,rw any occurs in the FS, HTC did not put any kind of mechanism to fix it.

And my guess was write. When I ran fsck on /system, fsck found several errors, and fixed them. Why would there be errors in /system ? Again, many reasons. Really many.

I guess that this issue may, or may not happen in custom ROMs. If a custom assumes the user will be able to write to /system, then, the author SHOULD perform fsck -a at boot. But I have also met several stupid and bad coders on XDA. And people helping other people setting their house on fire. So, fsck may be a too delicate detail for some.

Where to get fsck ? I forgot where I got it exactly, because I have several fsck in my M8 ATM. It was either fsck from busybox ( busybox-arm.png-1.22.1-Stericson ), or, installed via Armel, via Linux-Installer (by Galoula, available on Play).

How to run it ? From Recovery; TWRP for me; but other recovery should do. The busybox one is easy to run. If you could not install busybox properly, there are several ways to run it. Go in the directory where busybox is stored, create the apropriate symlink

ln -s fsck busybox ; ./fsck /dev/block/mmcblk0p45

or run it directly

busybox fsck /dev/block/mmcblk0p45

Absolute path will also work. Recovery should allow you to run stuff from /data. Otherwise, remount /data with the exec flag (make sure to NOT have the noexec flag).

Using fsck from Armel is a bit more complicated. Chrooting to Armel may be complicated in Recovery. I bet the classic linuxchroot script will fail, so you will probably have to chroot it manually:

cd /data/local/mnt/Linux
mount -o bind /proc/ proc
mount -o bind /sys sys
mount -o bind /dev dev
chroot . /bin/bash
fsck /dev/block/mmcblk0p45

You can also take fsck from any other place. Taking fsck directly from Armel, without chroot, will fail, because of dynamix linking. You need a static version. I will ask Galoula to build one for us. But several busybox should ship one; not all, I am sure of this: maby busybox won't; but somme do. Install several busbox untill you find it.

fsck from live Android will always fail. For many reasons. If you REALLY want to try it ... load the module (to get write perm on block device), but make sure /system is mounted RO. It's often possible to run fsck on RW filesystems on classic Linux, but the ones we find in busybox usually don't offer this possibility; for better chances on this, try first fsck from Armel (or any other Linux distribution that is provided a similar way); these distributions should provide a fsck very close to desktop versions, with similar features (they may shout and cry about missing fstab).

If some of you ever get UMS (USB Mass Storage) working, and can set it to share the /system block ( mmcblk0p45 for me, and should be the same for all M8 users) (may require tricks, since UMS on Android is designed to share /data; but it should not be impossible to alter UMS to make it share /system block, or even the whole mmcblk0 on completely unlocked phones), then, you can also run fsck from your desktop, by running it on the apropriate partition. Should be, for most of you, something like

fsck /dev/sdb
or
fsck /dev/sdb1
or
fsck /dev/sdb45

depending on details.

So, having UMS available will be a good workaround if you already have UMS, and find it hard to install fsck.ext2 inside the phone.

Don't forget to run

sync

before reboot, after any write, either in recovery and/or Android.

The root issue of breaking /system may even be the fact the phone does not try to ever sync it. Since stock ROM assumes /system can never be mounted RW, it is possible that mount options, or even kernel ... never runs sync on system block. To avoid any further issue, when remounting /system RW, you could either add the sync flag (with noatime), dirsync, or for better performance, commit=5.

If you intensively write to /system, you will want to care about other options: noatime,commit=60,barrier=0, and maybe journal_async_commit=<val>, barrier=<val>, max_batch_time=<val>. A bigger commit value increases perf. But increases the chances of FS breakage in the event of reboot, if reboot occurs short after a change on disk. There are also several perf improovers on Play for internal memory and SDcard; most of them just increase the disk cache; they will eat a few megs of RAM, permanently, but, who cares a few megs when you have 2G, and see your phone twice faster than default. Caching does not improove max raw speed of disk (write of large files), but hugely helps random access on small files; mainly for write; a bit for reads. Cache increase is recommended for /data, even if you never write to /system. Some tools also handle external USB storage (EXTERNAL disks you plug on USB port via OTG/MHL). Default cache size sux. Cache size is customized in /system, for Android, and does not affect Recovery; if you want custom cache size in recovery, you have to set it manually each time. It's somewhere in /sys. You may find settings per disk, per partition, and/or per filesystem.