Description of problem:

We just got a customer that wasn't able to execute grub2-install command, because his /boot file system was being detected "partially" as a Minix2 file system, even though it was EXT4. This caused grub2-install, when checking the file path, to fail with errno GRUB_ERR_BAD_FILE_TYPE, which is a fatal error:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

1. grub2-install -vv /dev/sda
   [...]
   grub-core/kern/fs.c:56: Detecting minix2_be...
   grub-core/kern/fs.c:78: minix2_be detection failed.
   grub-core/kern/fs.c:56: Detecting minix2...
   grub-core/kern/fs.c:78: minix2 detection failed.
   grub2-install: error: not a directory.
   • • • • • • • 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

After much struggling, I could find that the issue was really bad luck: it appears that lower bytes of the number of free inodes on the file system was matching the Minix2 magic number:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

1. hexdump -C /dev/sda3 -n 1024 -s 1024
   00000400 00 00 0a 00 00 00 28 00 00 00 02 00 58 af 19 00 |......(.....X...|
   00000410 68 24 08 00 00 00 00 00 02 00 00 00 02 00 00 00 |h$..............|
   ^^^^^
   • • • • • • • 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Here above those 2 bytes are the Minix2 magic number. The current free inodes count on that EXT4 file system is 0x00082468 (533608).

Since Minix and many other kinds of file systems are not seen on RHEL, as hardening, I'm proposing that we compile our Grub without exotic file system support.

Version-Release number of selected component (if applicable):

grub2-pc

How reproducible:

Always

Steps to Reproduce:
1. Have /boot file system have 533608 free inodes at time of mounting
2. Execute grub2-install

Actual results:

Failing due to bad detection as Minix2

Expected results:

No failure