Thx @Ganth,
here is what I just did (for now just with my second Fairphone 2 
).
(the facts: LOS17.1 / A10; encrypted; no gapps installed; Magisk is installed)
At the end it is just sending commands to the phone via adb (root) shell. So this is a pre-requirement and will not be described here.
The short version / summary:
- Find out/verify the block device or more exact the partition of the sd-card (here
/dev/block/mmcblk1p1) - umount everything which has something todo with your sd-card (I greped /proc/mounts for the sd’s
UUID) - fortmat the found block device to the format you like (for ext4 →
mkfs.ext4 /dev/block/mmcblk1p1) - mount the sd-card again (here
mount -t ext4 -o rw,noatime /dev/block/mmcblk1p1 /mnt/media_rw/<new folder>) - reboot the phone
The details:
I tried to follow your post, but it did not fully work like this.
At least it was not that easy as expected.
I checked this first:
adb shell ls /dev/block/
and indeed the block device /dev/block/mmcblk1 and it’s first and only partition:
/dev/block/mmcblk1p1
is gone when I remove the sd-card (note this takes a while until the system has realized that you have removed the sd-card … so the first view ls commands it was still visible)
If you try to directly format it with:
adb shell mkfs.ext4 /dev/block/mmcblk1p1
you will fail and you will get something like
this
mke2fs 1.44.4 (18-Aug-2018)
/dev/block/mmcblk1p1 is mounted; will not make a filesystem here!
So I checked several things to understand where it is mounted:
adb shell mount | grep /dev/block/mmcblk1
adb shell cat /proc/mounts | grep /dev/block/mmcblk1
adb shell cat /system/vendor/etc/fstab.qcom | grep /dev/block/mmcblk1
→ no results for all of them
I tried a different approach to find the sd-card mountpoint. With a root file explorer (I currently use File Manager) I saw (and also remember) that my sd-card is visible under the path:
/storage/<cryptical-Nr> while cryptical number is probably the current UUID.
in my case 78D9-1E20
So I searched the mounts again for this UUID:
adb shell cat /proc/mounts | grep 78D9-1E20
As result I saw a lot of mounts:
list of mounts
/dev/block/vold/public:179,65 on /mnt/media_rw/78D9-1E20 type vfat (rw,dirsync,nosuid,nodev,noexec,noatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
/mnt/media_rw/78D9-1E20 on /mnt/runtime/default/78D9-1E20 type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,mask=6)
/mnt/media_rw/78D9-1E20 on /storage/78D9-1E20 type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,mask=6)
/mnt/media_rw/78D9-1E20 on /mnt/runtime/read/78D9-1E20 type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,mask=18)
/mnt/media_rw/78D9-1E20 on /mnt/runtime/write/78D9-1E20 type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,mask=18)
/mnt/media_rw/78D9-1E20 on /mnt/runtime/full/78D9-1E20 type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,mask=7)
I was a bit confused a this point. I started to umount everything which has something to-do with my sd-cards UUID. The shortcut here is probably to just umount it via the UI. I did not check this. So I had to execute a lot of adb shell umounts.
After this I was able to format the sd-cards partition.:
adb shell mkfs.ext4 /dev/block/mmcblk1p1
the sd-card of the second phone is just 30GB so it took only a few seconds.
mkfs.ext4 output
mke2fs 1.44.4 (18-Aug-2018)
Discarding device blocks: done
Creating filesystem with 7745019 4k blocks and 1937712 inodes
Filesystem UUID: 1b056e2e-6962-4d17-800c-1ca7724cf9a4
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
After that I probably made the mistake, that I mounted it under the very same media_rw UUID path like the vfat (fat32?) formated one.
adb shell mount -t ext4 -o rw,noatime /dev/block/mmcblk1p1 /mnt/media_rw/78D9-1E20
Of course you see it there
adb shell cat /proc/mounts | grep 78D9-1E20
but in the phones UI it had a size less than 1GB.
After I rebooted the phone it has the correct size and automatically get a new UUID which is much longer than the old one adb shell ls /storage/
→ 1b056e2e-6962-4d17-800c-1ca7724cf9a4
The mounts look like
this
/dev/block/vold/public:179,65 /mnt/media_rw/1b056e2e-6962-4d17-800c-1ca7724cf9a4 ext4 rw,dirsync,context=u:object_r:sdcard_posix:s0,nosuid,nodev,noatime,data=ordered 0 0
/mnt/media_rw/1b056e2e-6962-4d17-800c-1ca7724cf9a4 /mnt/runtime/default/1b056e2e-6962-4d17-800c-1ca7724cf9a4 sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,mask=6 0 0
/mnt/media_rw/1b056e2e-6962-4d17-800c-1ca7724cf9a4 /storage/1b056e2e-6962-4d17-800c-1ca7724cf9a4 sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,mask=6 0 0
/mnt/media_rw/1b056e2e-6962-4d17-800c-1ca7724cf9a4 /mnt/runtime/read/1b056e2e-6962-4d17-800c-1ca7724cf9a4 sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,mask=18 0 0
/mnt/media_rw/1b056e2e-6962-4d17-800c-1ca7724cf9a4 /mnt/runtime/write/1b056e2e-6962-4d17-800c-1ca7724cf9a4 sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,mask=18 0 0
/mnt/media_rw/1b056e2e-6962-4d17-800c-1ca7724cf9a4 /mnt/runtime/full/1b056e2e-6962-4d17-800c-1ca7724cf9a4 sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,mask=7 0 0
now
So again a lot of mountpoints (6), but I finally have a ext4 sd-card.
I still don’t fully get the connection between the block device /dev/block/mmcblk1p1 which has to be formated and the media_rw path /mnt/media_rw/1b056e2e-6962-4d17-800c-1ca7724cf9a4. Looking to the list of mounts again only the first one mounts a block device (but the it is /dev/block/vold/public:179,65) the rest is just referencing sdcardfs.
If someone is able to explain this relation - thanks in advanced
Still I will repeat this for my daily driver phone to fix the storage space issue