fstrim --all failing on ext2 /boot filesystem

ext2 does not support trimming, only ext4 or btrfs do.

Right, which causes fstrim --all (in the cron.weekly file installed by util-linux) to throw this error since /boot is created as ext2. So is it correct for the --all to try to check ext2 even though ext2 doesn't support it, i.e. should fstrim be changed to not try to fix ext2 when --all is used?

Got the same issue with a low-capacity mountpoint partition (used ext2 and 100MB to get capacity errors if NFS mounts break).
Are there any "--ignore" switches for `fstrim --all` ?

This still appears to be broken. Here's a workaround, just replace the fstrim command in the cron file:

df -t ext4 --output=target | sed 1d | while read target; do fstrim $target; done

Actually the /sbin/fstrim-all script on Ubuntu 14.04 still appears to work fine, so copying it from there and updating the cron job accordingly should also suffice.

I think this should be filed as a bug, as we've rolled out a bunch of Ubuntu 16.04 VMs in our environment, and most of them are Hyper-V Gen 2, meaning they're booting UEFI and have an ext2 /boot and a vfat /boot/EFI. I'm having to make a salt state just to muzzle the weekly flood of emails from these hosts. My pain comes from the handful of bare metal servers in my salt minion set that really do have SSDs in them, yet boot from UEFI and so still produce this error.

The man page says fstrim is supposed to ignore file systems it doesn't support, yet it's not ignoring ext2 partitions like it should be.

On the VMs I used dpkg-divert to rename the /etc/cron.week/fstrim file to fstrim.disabled, which muzzles the VMs. I still need to copy fstrim-all to all of the Ubuntu 16.04 bare metals to muzzle them, too.