Comment 7 for bug 1579609

This bug can be particularly brutal on systems with a large amount of storage. I am running a storage server with 24 drives in ZFS pools. Every single one of those drives generates many messages; there's 19 lines per drive so in my case, 456 lines of filesystem errors in my dmesg every time os-prober is triggered. This is really excessive!

[718229.072210] EXT4-fs (sdy9): VFS: Can't find ext4 filesystem
[718229.079832] EXT4-fs (sdy9): VFS: Can't find ext4 filesystem
[718229.087112] EXT4-fs (sdy9): VFS: Can't find ext4 filesystem
[718229.094677] squashfs: SQUASHFS error: Can't find a SQUASHFS superblock on sdy9
[718229.102045] FAT-fs (sdy9): bogus number of reserved sectors
[718229.105299] FAT-fs (sdy9): Can't find a valid FAT filesystem
[718229.119139] XFS (sdy9): Invalid superblock magic number
[718229.125407] FAT-fs (sdy9): bogus number of reserved sectors
[718229.127797] FAT-fs (sdy9): Can't find a valid FAT filesystem
[718229.136511] VFS: Can't find a Minix filesystem V1 | V2 | V3 on device sdy9.
[718229.138940] hfsplus: unable to find HFS+ superblock
[718229.142165] qnx4: no qnx4 filesystem (no root dir).
[718229.148684] ufs: You didn't specify the type of your ufs filesystem

                mount -t ufs -o ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ...

                >>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old
[718229.164301] ufs: ufs_fill_super(): bad magic number
[718229.172406] hfs: can't find a HFS filesystem on dev sdy9