[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #52657] grub-mkconfig does not guarantee changes are on disk before
From: |
Chris Murphy |
Subject: |
[bug #52657] grub-mkconfig does not guarantee changes are on disk before exiting |
Date: |
Wed, 13 Dec 2017 06:58:09 -0500 (EST) |
User-agent: |
Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 |
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/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [bug #52657] grub-mkconfig does not guarantee changes are on disk before exiting,
Chris Murphy <=