Modern Linux distros aren't really affected by this. At least in a drive-by sense. Auto-mounting is handled in a safer way than simply telling the kernel to mount the filesystem you just plugged in.

For example, compare the Ubuntu 22.04 behavior (complain that the filesystem is corrupt) vs. Ubuntu 20.04 (panic and reboot). For modern Linux to see the panic, you'd have to manually mount the filesystem (as root/sudo).

ChromeOS, on the other hand, chooses the more YOLO route of auto-mounting via the kernel.

@wdormann weirdly enough, I foresaw the "logic flaw" due to weird issues with VMs and moving disks around where the policy of the source would affect the destination

I just forgot that "cause a kernel panic" was an option instead of "fail to mount/lazy unmount"

@wdormann I thought that is only for errors during operation…

… let me guess, the OS is trying to access things on the fs to do things like provide icons and stats?

@wdormann I can even see the use case for such a feature - if filesystem integrity is more critical than availability

but honestly, I see very little use case for a desktop operating system respecting -e panic, and almost no use case for anything to respect it on removable media unless explicitly opted into by the user - fall back to -e remount-ro or unmount it IMO, but not a panic.

I remember testing that feature before I had a computer with USB. It also works with floppies.

There is a mount option which can override that behavior. If that mount option is specified the value specified on the file system itself has no effect.

It's a questionable feature. I think it would make sense to remove the ability to specify it on the file system. Having the mount option makes some kind of sense.

@ferrix
This particular machine will display a login prompt when it first turns on, at which point it's fine.

I suppose if it auto logged on, it would be in a reboot loop.