Add e2fsck to the initrd and use it when mounting stowaways

[UniversalSuperBox]

This builds a statically linked e2fsck binary and adds it to /bin. mount_stowaways is changed to mount, then unmount, then fsck /data before using it for anything important. The mount of /data is performed with data=journal. This will cause a performance hit, but should also mean less file corruption in the long run.

Side note, the mount-unmount-fsck pattern causes the kernel to replay the ext4 journal rather than e2fsck. Canonical engineers stated that the kernel was faster at this task.

Pros:

• This is almost exactly how Canonical solved issues with file corruption breaking AppArmor profiles on Ubuntu Phone devices in the very early days of the project: launchpad #1387214

• Only adds a small amount of time to the boot process, normally one second or less.

Cons:

• This will cause the RW reference and Plasma Mobile rootfs's to be deleted slightly more often as fsck will realize that something is wrong with them. I experienced this while testing. I feel that this is better than allowing silent corruption to the image, but the result is undesirable.

• The boot.img is now > 8MB on my device, sitting at 9.2MB. This shouldn't be a concern except for very old devices with ridiculously small boot partitions.

To test this:

Just pull the branch for this PR and build hybris-boot or hybris-recovery. Flash them to the device's boot partition. You'll find the fsck output after [...]## mounting stowaways in the logs. Boot the device.

[bhush9]

+1 to this request in general, I want to however test this for at least a week on Plasma Mobile and see how it behaves.

Another additional comment, it seems to me that we are creating rootfs in ext2 format instead of ext4

https://github.com/Halium/halium-scripts/blob/b2dab37705eff070a321f058349e7b2d1fc78d81/halium-install#L69

I wonder how it affects the rootfs stability?

[UniversalSuperBox]

I think that the only advice I can give for making it ext4 is to try it yourself. It's possible that the direct I/O features in ext4 (I was reading this page) are used for the loop device, so you shouldn't be taking too much of a performance hit from having two journals.

Really, if you must continue to have your root filesystem read-write, it might be a good idea to mount it with sync. You'll really slow things down, but it's the only sure way I see to keep from having a user's entire phone operating system deleted because it crashed. I just tested, you can do mount / -o remount,sync to achieve this from the running system.

Alternatively, it might be time to look into backporting aufs or (more likely) OverlayFS into the kernel for Halium devices where the porter wants to run Plasma Mobile.

[UniversalSuperBox]

You'll need to pull that change and rebuild, then reset your day counter. I was putting e2fsck in the hybris-recovery initramfs when building hybris-boot.img... rather useless.