slackware64-current, /etc/rc.d/rc.6 doesn't umount efi partition
 

It looks like /etc/rc.d/rc.6 doesn't have logic to umount EFI partions, e.g. /boot/efi

# Unmount local file systems:
echo "Unmounting local file systems:"
/bin/umount -v -a -t no,proc,sysfs,devtmpfs,fuse.gvfsd-fuse,tmpfs

I don't know if adding vfat to the -t list is the appropriate fix, or if needs to be more complicated.

I just noticed the issue after a reboot...

[ 16.959016] FAT-fs (nvme0n1p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

and the related /etc/fstab entry as an example...

/dev/nvme0n1p1 /boot/efi vfat defaults 1 0

The "no" at the start of that list means that umount ignores the filesystem types that follow, i.e., unmounts everything else. This can be verified by rebooting or halting from tty, which should show that /boot/efi is unmounted at that point.

So far as I know, the message is harmless. A dirty bit just gets set for some reason.

slackware64-current, /etc/rc.d/rc.6 doesn't umount efi partition
 

I always put ',noauto' after defaults.

There is no need to mount the EFI partition every time you reboot.

In fact, my thoughts are that you only need to mount it if you're upgrading the kernel. It probably shouldn't be auto-mounted by default.

Well, I watched a reboot, and /boot/efi does get cleanly unmounted, so the fsck complaint was probably old.

In any case, fsck'ing the filesystem is easy enough to get rid of the complaint, and it's better to not ignore it.

Funny, /boot/efi is added to /etc/fstab by the installer, there's no harm in mounting it, and manually mounting it (to copy /boot/{vmlinuz,initrd.gz} to /boot/efi/EFI/Slackware for kernel upgrades sounds silly to me.

Seeing /boot/efi mounted on a system is a pretty good hint/reminder that a system is using EFI, so I like that it gets added to /etc/fstab by default.

Not so silly. In case it is mounted and your computer crashes the crappy FAT filesystem may get corrupted. Running fsck on it may or may not repair it. Why risk with all this trouble and keep it mounted unnecessarily?

That's a good point; maybe I've been too casual about this. Removed from fstab :)

Better put it back in fstab with noauto option, then it is easy to mount from command line.

I use GRUB with an unchanging configuration file, so no need to mount for kernel installations.

Right, but some may put EFI stub kernels there, I do.

Fair enough!

I think you can get banned from the slackware forum for admitting to using grub over lilo or elilo.

I would agree with you if it used any other file system, (except possibly NTFS).

FAT is among the most flaky file systems around, and easily corruptible. Linux support for it (much like NTFS) has had to be reverse-engineered. FAT has a terrible track record when it comes to data loss, corruption and recoverability. If it were up to me, we wouldn't be using it anywhere... but here we are, so we have to make do with what we have.

If there is a sudden interruption in electricity supply and your computer crashes as a result of it, there is an increased possibility that your computer won't boot due to a corrupted EFI partition if this all happened while it was mounted.

Personally, I don't find it that difficult to type 'mount /boot/efi' whenever I want to access it.

Windows 10 doesn't mount the EFI partition by default. I can't help but wonder if even a small part of Microsoft's reasoning is that they know how flaky the file system is.
Yes, me too. But I think it should have the 'noauto' option included by default as well.

Too. much. tuna.

Not tuna. Violin.

Anyway, do you honestly disagree?