URL: <https://savannah.gnu.org/bugs/?57652>
Summary: minix filesystem detection too optimistic Project: GNU GRUB Submitted by: seife Submitted on: Wed 22 Jan 2020 08:24:04 AM UTC Category: Filesystem Severity: Major Priority: 5 - Normal Item Group: Software Error Status: None Privacy: Public Assigned to: None Originator Name: Originator Email: Open/Closed: Open Discussion Lock: Any Release: Release: 2.02 Reproducibility: Every Time Planned Release: None _______________________________________________________ Details: I encountered an intermittent issue where grub-install would fail with "not a directory" error after trying minix_be detection: grub-core/kern/fs.c:79: nilfs2 detection failed. grub-core/kern/fs.c:57: Detecting newc... grub-core/kern/fs.c:79: newc detection failed. grub-core/kern/fs.c:57: Detecting minix_be... grub-core/osdep/hostdisk.c:408: reusing open device `/dev/loop0' grub-core/kern/fs.c:79: minix_be detection failed. grub2-install: error: not a directory. The reason for this (I found this after days of debugging...) is, that the minix filesystem detection in grub-core/fs/minix.c:grub_minix_mount() is overly optimistic. It just checks for the FS magic number and sanity-checks some other size fields, then decides "this is minix". The problem is, that grub_fs_probe calls the dir() function of every file system as dir(device, "/", ...) and if this does not return an error other than GRUB_ERR_BAD_FS, then this is considered fatal. Now the grub_minix_dir(.., path, ...) function (which is dir() for minix) does the following (pseudocode): grub_minix_mount() || return GRUB_ERR_BAD_FS # this is the detection if it is a minix fs ... data = grub_minix_find_file(path) || return grub_errno if (MODE(data) != ISDIR) return "not a directory" if grub_minix_mount would have failed, this would be a non-fatal error, but it only fails afterwards when checking if "/" is a directory, which is then considered fatal, and causes grub-install to abort with the strange (if you do not know all the circumstances :-) "not a directory" message. Now how can the MINIX FS magic number appear? The answer is easy: the on-disk location of grub_minix_sblock.magic is the same as the on-disk location of grub_ext2_sblock.free_inodes, so if you happen to install grub onto a file system with a matching number of free inodes, you can trigger this reliably. Any you'll never guess what the problem is ;-) I wrote about this with more hints and a workaorund on https://seifesrants.blogspot.com/2020/01/fun-with-grub2-install.html The attached patch fixes the issue for me. It is not ready for inclusion and includes some additional debug code, which of course can be omitted. What it does is put the additional steps that "dir('/')" does directly into the grub_minix_mount() code, and only return successfully if this succeeds and finds that "/" actually is a directory. In the long run, it would be beneficial if grub-install got an option to specify "--filesystems=ext2,xfs,btrfs" to skip probing for unrelated filesystems. I'm quite sure there are more possibilities to get this autodetection wrong for different filesystem types. I'll try to craft a script to reproduce this easily. Note that I have encountered and debugged this on a SUSE Linux Enterprise Server 15 SP1 code base. However, I checked the current git masterand the minix fs code is identical, so I'm pretty sure the problem is still present in the current code base. _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Wed 22 Jan 2020 08:24:04 AM UTC Name: grub2-minix-probe-fix.diff Size: 4KiB By: seife POC fix (with debug code) <http://savannah.gnu.org/bugs/download.php?file_id=48271> _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?57652> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/