Non-VFAT SD card, modifying files in root filesystem

[conrad]

I’ve a big ext4-formatted SD card which I’d like to use with my FP2 running FPOOS. I’ve found instructions which suggest I need to fix /fstab.qcom, changing the FS type for the SD card from vfat to ext4. Having installed terminals so I can ‘su’, I realise now that since fstab is in / and not in /etc, the root filesystem is read-only and rebuilt from the boot image on every restart. There are two problems here:

1. Even though I can remount / read/write and modify /fstab.qcom, that doesn’t survive a reboot. So do I have to build my own custom root filesystem image in order to make persistent changes to files such as /fstab?
2. Even when I make the suggested change to /fstab.qcom, the SD card won’t mount. In fact it doesn’t even appear to mount directly from the command line (“mount -o ro -t ext4 /devices/msm_sdcc.2/mmc_host /storage/sdcard1” says “mount: no such file or directory”, though it’s a faithful reflection of what is otherwise in fstab, and also works from my PC (modulo paths)).

Any suggestions please?

Also, FPOOS devs, whatever happened to “auto” as a filesystem type in fstab? Wouldn’t that open us out to all kinds of useful FS options?

[Edit: the manual mount fails because there’s no such thing as /devices, which seems kindof bonkers]

[conrad]

Just for anyone else reading this: after a bit more research, as far as I can tell non-VFAT SD cards are a no go: the effort involved in making them work (custom boot image which would need to be rebuilt on every OS upgrade, etc.) is far too high if you just want to be a FPOOS user, rather than a developer. I’ve given up and am converting it to VFAT.

Would be delighted if anyone could demonstrate otherwise. It does also seem to me that the official FPOOS release could fix this trivially by simply changing the SD card fstab entry from “vfat” to “auto”.

[retsifp]

I read your post yesterday but didn’t have much time - glad you found some things out on your own.

But one thing is not quite true:

@conrad

the effort involved in making them work (custom boot image which would need to be rebuilt on every OS upgrade, etc.) is far too high

It’s not that hard to do such thing, at least for FPOS (with GMS), I did this.
I just included these lines into changes.sh:

sed -i 's/vfat/auto/g' fstab.qcom
addFile fstab.qcom

Before, fstab.qcom looks like this:

# Android fstab file.
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK

#TODO: Add 'check' as fs_mgr_flags with data partition.
# Currently we dont have e2fsck compiled. So fs check would failed.

#<src>                                                <mnt_point>  <type>  <mnt_flags and options>                     <fs_mgr_flags>
/dev/block/platform/msm_sdcc.1/by-name/system         /system      ext4    ro,barrier=1,discard                                wait
/dev/block/platform/msm_sdcc.1/by-name/userdata       /data        ext4    nosuid,nodev,barrier=1,noauto_da_alloc,discard      wait,check,encryptable=footer
/devices/msm_sdcc.2/mmc_host*                          /storage/sdcard1   vfat    nosuid,nodev         wait,voldmanaged=sdcard1:auto,encryptable=footer
/dev/block/bootdevice/by-name/pad                  /frp        emmc    defaults             defaults
/devices/platform/xhci-hcd/usb*                       /storage/usbotg    vfat    nosuid,nodev  wait,voldmanaged=usbotg:auto 

Afterwards, it looks like expected:

# Android fstab file.
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK

#TODO: Add 'check' as fs_mgr_flags with data partition.
# Currently we dont have e2fsck compiled. So fs check would failed.

#<src>                                                <mnt_point>  <type>  <mnt_flags and options>                     <fs_mgr_flags>
/dev/block/platform/msm_sdcc.1/by-name/system         /system      ext4    ro,barrier=1,discard                                wait
/dev/block/platform/msm_sdcc.1/by-name/userdata       /data        ext4    nosuid,nodev,barrier=1,noauto_da_alloc,discard      wait,check,encryptable=footer
/devices/msm_sdcc.2/mmc_host*                          /storage/sdcard1   auto    nosuid,nodev         wait,voldmanaged=sdcard1:auto,encryptable=footer
/dev/block/bootdevice/by-name/pad                  /frp        emmc    defaults             defaults
/devices/platform/xhci-hcd/usb*                       /storage/usbotg    auto    nosuid,nodev  wait,voldmanaged=usbotg:auto 

I’m not sure if you are aware what super-bootimg does. It injects some modifications to the boot.img in order to gain root on FPOS (NOT FP Open!). So my generated boot.img has these modifications inside.
I don’t know what happens if you try this with a FP Open image, but it could work (maybe with some modifications to changes.sh)

But, here are the bad news: It doesn’t seem to work (At least for USB-OTG, don’t know if it’s the same for SDCard)
I tried this on my phone and my SD-Card was mounted as always, so it didn’t break anything, but since I don’t want to take out my SD-Card, I tried to mount a USB-Stick (As you may have noticed, I changed the vfat for the OTG, too). Worked fine with FAT32, but didn’t for ext4:

[conrad]

Thanks for all of that information @retsifp — interesting to know about and potentially super useful if I need to make other root partition modifications.

I kindof think I stand by my analysis though: if you want to be more of a FPOOS user than a developer, then this level of effort seems quite high compared to what it could be. I’ve put a request in to FP Support to change the “vfat” to “auto” in fstab.qcom; the respondent said they’ve passed the request on and they’re sure it’ll get “serious consideration”. Will see what happens on that front.

While it would have been nice, this is a pretty minor thing compared to stuff like encrypting the SD card or adding TWRP backup support for encrypted filing systems etc.