[bug #52657] grub-mkconfig does not guarantee changes are on disk before exiting

[Chris Murphy]

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/