/etc/filesystems needs to be created/updated

[jonathanbrickman0000]

I am amazed that after quite a lot of TCing, I think I have found just the very first of what i would dimly call a bug.

The gist of it is, /etc/filesystems is not being created and/or updated.  If this is done appropriately, 'mount' has a good order in which to test filesystems.  This solves several problems:

1.  UDF disks mount -t auto without problem, if udf is listed before iso9660.
2.  ext3 disks mount -t auto as ext3 and not ext2, if ext3 is listed before ext2.
3.  ntfs disks mount as ntfs-3g, if ntfs-3g is listed before ntfs.

I did google it, and busybox 'mount' does appear to support /etc/filesystems if it exists. 

J.E.B.

[maro]

A quick look into the relevant source code of BusyBox indicates that it indeed checks first all (appropriate) entries in '/etc/filesystems' before taking into account '/proc/filesystems'.

So I could imagine something could be done via the extension startup file in the relevant extensions (e.g. 'ntfs-3g.tcz' and the two 'filesystems-KERNEL.tcz') to achieve those outcomes listed in the OP. Albeit I have not done any testing myself and will probably not embark on such an exercise any time soon, as I'm lacking a bit the motivation to thoroughly test such a change.

This looks to me to be a rather simple change in the first place that should not be released to the unsuspecting TC users without careful consideration (and testing) of it's consequences. Otherwise I'm happy to help with the initial scripting (if that would be at all required).

[jonathanbrickman0000]

Perhaps I should have thought of this earlier -- how about a separate .tcz ?

[tinypoodle]

Perhaps I should have thought of this earlier -- how about a separate .tcz ?

It doesn't seem to make much sense to have a single optional sample configuration file which per definition needs to be writable in a .tcz extension.
Just adding it to backup seems to have plenty of advantages.

On a sidenote: I couldn't understand what exactly you think is a bug about it.

[maro]

... how about a separate .tcz ?

Nope, that would be overkill IMHO. I was more thinking along the lines of adding something like

Code: [Select]

    [ -f /etc/filesystems ] || touch /etc/filesystems
    ! grep -q '^[[:blank:]]*ext[2-4]$' /etc/filesystems 2> /dev/null \
        && grep '^[[:blank:]]*ext[2-4]$' /proc/filesystems | tr -d [:blank:] \
            | sort -r > /etc/filesystems
to for example '/opt/bootlocal.sh' to put the EXT[2-4] file systems in reverse order.

Likewise

Code: [Select]

    [ -f /etc/filesystems ] || touch /etc/filesystems
    sed -i -e '/^[[:blank:]]*ntfs$/s#ntfs#ntfs-3g# ; te' -e '$a ntfs-3g' -e :e \
        /etc/filesystems
could be added to the extension startup file of the 'ntfs-3g.tcz' extension (as it would either change a 'ntfs' entry in '/etc/filesystems' to become 'ntfs-3g' or simply appending 'ntfs-3f' to that file).

And to stay with that theme

Code: [Select]

    [ -f /etc/filesystems ] || touch /etc/filesystems
    sed -i -e '/^[[:blank:]]*iso9660$/s#iso9660#udf# ; te' -e '$a udf' -e :e \
        /etc/filesystems
could be added to the extension startup file of the two 'filesystems-KERNEL.tcz' extensions (again either changing a 'iso9660' entry to 'udf' or appending the same to '/etc/filesystems').

As I indicated earlier: none of this has really been tested. I believe the code snippets on their own are working as intended, but no testing was done with mounting any filesystem whatsoever.

And finally: I don't think that having a static list in '/etc/filesystems' is a good idea as not all modules listed in such a list might be present all the time, hence I went for this more "dynamic" approach.

[jonathanbrickman0000]

"Bug" might be the wrong word, but when we have a Linux setup with UDF drivers installed by package, which tries to load UDF disks as iso9660, I call that a distro-level bug :-) 

If 'mount' will cleanly tolerate nonexistent modules, I like static better, because mount has to be so utterly stable.  Otherwise, certainly, dynamic :-)

You are, by the way, clearly much better at sh logic than I :-)  Adding lines between others is not something I have tried yet!!!

J.E.B.

[curaga]

I'll note the ext? issue is irrelevant, since everything is mounted by ext4 now.