Auto filesystem type configuration

[wongck68]

Noticed that in Mint my USB thumb drive was displaying in 8.3 format.

Why not have Mint automatically enumerate the filesystem type at boot and set VFAT long files name for it if it detects FAT32 automatically ?
I know it can be done by Fsetter on the fly.

Just a thought.

[mikrosk]

I can only speculate but maybe the reason was backward compatibility? I.e. show as 8+3 by default and if you're sure your desktop/fileselector/whatever can handle more, enable it. Also performance may be a reason.

But yeah, having an option in mint.cnf to do that automatically for FAT32 would be nice. It's actually not that much work.

[ps68060]

Why not set the type automatically unless it is overriden in mint.cnf to set it to 8+3 ?

On a related thought, if I disconnect my second IDE HD, then fstab is wrong and that causes boot issues. I think it is because the fs checker fails. I have found that I can abort the fs check and booting continues.

Similarly if I change HD to one with different partition assignments then it is a struggle to get in and modify fstab to get it to boot cleanly. I don't think there could be a simple solution to this.

[mikrosk]

On a related thought, if I disconnect my second IDE HD, then fstab is wrong

It may come as a surprise but on you'll have the same problem on every Unix compatible system possible. /etc/fstab is the list of persistent mount points.

It took ages to have auto mount/unmount even in the Linux world.

The real problem here is the lack of mount command -- which would in turn create /etc/mtab and this would be parsed by your init scripts.

[ps68060]

I have suspected that it was the lack of mount/unmount but I don't do a lot of that on linux.

[wongck68]

on my system, I add e2fsck in my mint.cnf file, but it complains cannot find /etc/fstab... but carries on to check my e2fs. This checking of /etc/fstab seems to be inside e2fsck but it does not stop or loops. It seems that it is just an information statement.

I suspect that there may be a script that is checking and cannot find /etc/fstab and cause your boot problem.

[ps68060]

It's not a regular boot problem, it's a problem when periodically adding or removing hard drives. Linux copes with this better using /etc/mtab as Mikro pointed out.

[paulwratt]

the addition of mount & umount would keep things in line with other OS's. It appears the issue with checking /etc/fstab is a lack of "failing gracefully", /etc/mtab would help solve that, but then the filesystem tools need to be updated too. Note there is another issue posted regarding ext2 check tools.

You have to remember that ext2fs was added 20 years ago this year, and back then, apart from CD-ROM's & floppy's, removeable media was not really a thing, especially on AtariST/MiNT platforms.

MiNT's kernel filesystem "technology knowledge" is currently far behind other POSIX OS's, but the addition of USB drivers means there is now a gap due to modern usage. Has anyone tried replication these issues with USB mounted ext2 partitions? Maybe that would shed light on a solution.

It is possible that the MiNT step-boot option should be more visible at boot time. Possibly the addition of a falback config as boot option to allow users to be able to edit /etc/fstab when filesystem mount point do change.

[skaftetryne]

the addition of mount & umount would keep things in line with other OS's.

Yes, and that's a good reason for avoiding the messy, outdated "mount" philosophy. MiNT does it much better already. Why would you need to "mount" drives (I'm talking about actual drives, not network shares and stuff like that) at all under MiNT? It does so automatically when the drive/partition is detected, and with decent harddisk drivers also for removable devices.

[ps68060]

Mint doesn't mount drives automatically. fstab has to be edited to include new drive partitions.

[skaftetryne]

MiNT autodetects all readable drives/partitions. Maybe you're talking about linking directories to /? True, the standard scripts used in e.g. SpareMiNT/EasyMiNT does not handle this automatically. But this could be improved. Writing a separate program to replace the super-slow shell-scripts could be a solution.

Possibly the addition of a falback config as boot option to allow users to be able to edit
/etc/fstab when filesystem mount point do change.

The kernel does not - and SHOULD not - care about this. This belongs in a separate program, like today, for those that needs such (dys)functionality. "Mount points" is irrelevant in a TOS/GEM environment, the way the kernel currently handles drives is much better than anything "unixy", current Linux distros included.

[th-otto]

Writing a separate program to replace the super-slow shell-scripts could be a solution.

Of course the shell scripts are rather slow, but writing separate programs for all such tasks would be tedious. Maintaining small shell scripts is much easier, and it also allows users with some knowledge to change them.

[paulwratt]

I get that alot of people dont like shell scripts on AtariST/MiNT, but there is no standard, easily accessible, and common alternative. MiNT is POSIX compliant after all, and that should be used to advantage, not to detriment. BTW we are talking abould a _working_ temporary (and intermediate) solution, until someone can provide a cleaner permanent solution. Some might mention GFA, but the compiler and editor can _not_ and will _not_ be included in any ditribution, already documented on AtariST mailing-lists. In the meantime your solution provide no _working_ solution. There is already a "mintloader", so as far as MiNT Kernel boot time, someone has already taken the time to create an AtariST solution, but atm it is hardcoded on a per build basis, so it is inappropriate for more general Kernel boot time options. I am not saying @skaftetryne argument is invalid, I am just reminding everyone that the history of AtariST community project development is littered with "no _working_ solutions". The same arguments have cause a lot of developers to leave "the scene" over the years (Zorro is probably the most famous of them) And when someone does go ahead with there own solution, they often "re-invent the wheel", but only for a specific task, and often closed source. Where it is open source (or a fork) there also runs the risk of become unusable, unstable, quirky and/or abandoned (Osk & Helmet XaAES forks are examples) I am still waiting on solutions since 2009, because people said (and other agreed) "no not that way. I will do it this way" and they just never had the time to forefill that promise. To say "no" is not enough anymore, you have to also provide an alternate way to get things done, and then someone has to have time to do it. A _working_ solution is NOT more important than a AtariST/MiNT soultion that every one agrees on and finds useful, it its the 1ST step in getting that permanant solution.

[paulwratt]

From other threads and issues, there is are already problems with fsck script. Where is it held, I will take a look at it.

NOTE: AFROS-LiveCD has a different boot process than EasyMiNT, SpareMiNT, GentooMiNT, while still allowing access to all mounted partitions and providing POSIX tools

[skaftetryne]

To answer the original post: The solution is to enable VFAT on ALL drives (A-Z, 0-9) except those that you specifically don't want it enabled for. MiNT will then automatically enable VFAT when you insert a removable device with a FAT(32) filesystem.

@paulwratt I really don't understand what you want fixed. MiNT will always "automount" all disks/partitions as long as they have a filesystem that MiNT understands. If you're actually talking about linking directories to u:\ then this is a completely different thing and must be handled from userspace and not from the kernel. Shell scripts, C code, BASIC, whatever that works.

If the problem is that you can't get to /etc/fstab to edit it because the fstab file is located on an ext2 partition and you can't successfully boot because you for some reason has changed your partition order, then I suggest to simply put fstab on a FAT partition and symlink it to /etc. The fstab can easily be edited from TOS if needed.

@th-otto Shell scripts may be easy to maintain for those that knows how. But the fact is that these scripts has not been changed since the early days of SpareMiNT, and that's more than 20 years ago. So either the scripts are perfect as they are, or maintenance is maybe not so easy anyway.

[mikrosk]

I was inclined to say that it still makes sense to add a code to FreeMiNT which would look at the partition type and set sane defaults but on the second thought, I couldn't find any meaningful example where it would make sense than the VFAT flag.

So yes, go with @skaftetryne's suggestion, no need to complicate life more.

I'm totally fine with the approach that removable media's /etc/fstab entries are handled by whatever tool, we certainly don't need all that mount/unmount stuff only for this feature.

[paulwratt]

for some reason I thought fsck was a shell script that executed the correct binary on a per filesystem basis. it is not, and yes updating packages atm is not so easy

[paulwratt]

turns out it was C:\MINT\BIN\FSCHECK.SH I was thinking of