URL: <http://savannah.gnu.org/bugs/?52657>
Summary: grub-mkconfig does not guarantee changes are on disk before exiting Project: GNU GRUB Submitted by: chrismurphy Submitted on: Wed 13 Dec 2017 11:58:08 AM UTC Category: Installation Severity: Major Priority: 5 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Originator Name: Originator Email: Open/Closed: Open Discussion Lock: Any Release: Release: 2.02~rc1 Reproducibility: Intermittent Planned Release: None _______________________________________________________ Details: Summary: grub-mkconfig does not call sync() or FIFREEZE() to ensure data and fs metadata are completely committed to disk before exiting. As a result if the system is uncleanly rebooted, the system might not be bootable at all due to missing or zero byte length grub.cfg. Reproducibility: Intermittant and somewhat rare. Example: So the example I have is actually with grubby doing the modification of grub.cfg. I understand grubby is not at all related to GRUB but it does a similar read, modify in memory, write a new file, delete old file, move/rename new to old. [1] And I have a roughly 8 out of 10 failure rate in a particular setup: a. /boot/grub/grub.cfg is on XFS which uses delayed allocation and journal b. plymouth is exempting itself from being killed by systemd at reboot c. due to b. systemd fails to remount read-only /boot/grub and eventually does a force reboot Result is a grub> prompt. Inspection of the file system without journal replay shows zero byte grub.cfg or sometimes missing grub.cfg entirely. However if the journal is replayed, the file system metadata is fixed up, and now GRUB works again. grub2-mkconfig does not call either sync() [2] or FIFREEZE() [3] after writing out and renaming the new grub.cfg. I suspect that the grub-mkconfig case will run into the same problem as grubby, even though I haven't reproduced tried to reproduce it yet. XFS devs have explicitly said both grubby and grub-mkconfig are responsible for fully committing their bootloader configuration changes to disk before exiting in order to ensure the new configuration is available should an unclean reboot happen immediately after bootloader configuration changes.[4] GRUB can't replay the journal, therefore it's not sufficient for grub-mkconfig to depend on XFS journaling to save things in this case. [1] grubby bug already filed. https://github.com/rhboot/grubby/issues/25 [2] applies to non-journaled file systems) [3] applies to journaled file systems were sync is only guaranteed to write out metadata to the journal not complete file system metadata commit [4] (note that this patch starts the conversation of the problem, the patch is ultimately not being applied in the kernel, and later in that long long thread they also are fairly certain the exact same problem happens on ext4. Btrfs is probably going to manifest with the old grub.cfg which might contain a stale kernel entry and thus still fail to boot. https://www.spinics.net/lists/linux-xfs/msg06883.html _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?52657> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ _______________________________________________ Bug-grub mailing list Bug-grub@gnu.org https://lists.gnu.org/mailman/listinfo/bug-grub