You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 28, 2022. It is now read-only.
User with /boot directory on an XFS root fs, experiences an unbootable system (no grub menu, just a grub prompt). The short version of the cause is plymouthd exempts itself from forced kill by systemd at reboot time, which prevents systemd from remounting rootfs ro, which prevents grubby's modifications of grub.cfg (or presumably extlinux.conf or anything else) from being flushed to fs metadata. The modification is only flushed to the journal, which GRUB and other bootloaders cannot read or playback. So the modified grub.cfg is not locatable by the bootloader binary.
Merely mounting and umounting this rootfs is enough to cause journal replay and now the bootloader can see the grubby modified grub.cfg.
XFS developers basically ding the thing modifying the bootloader configuration generator/modifier for not ensuring the file is fully committed to disk. So if grubby itself can't umount, or remount ro, (which seems likely it can't), then it needs to freeze/unfreeze the file system. It's not sufficient to sync() as this only guarantees data and journal entries are on disk it does not guarantee the dirty journal entries are flushed to fs metadata.
"Yup - I've been trying to tell you that these are the exact
guarantees that freezing the fs will provide the bootloader
installer...." https://www.spinics.net/lists/linux-xfs/msg07051.html
"files were sync()d then the file size updates are still
in the journal which has not been replayed. This is what we've been
saying is the problem all along and that a post-update freeze will
work around." https://www.spinics.net/lists/linux-xfs/msg07084.html
# if /boot is a mountpoint, force the meta data on disk
# to by-pass writeback delay.
# PPC64LE-only to deal with Petitboot issues
if [ "$ARCH" = "ppc64le" ]; then
sync && mountpoint -q /boot && fsfreeze -f /boot && fsfreeze -u /boot
fi
The text was updated successfully, but these errors were encountered:
Thank you for your interest. We are retiring non-BLS grubby at this point and don't plan to address this. For BLS-only grubby, please send PRs to https://src.fedoraproject.org/rpms/grubby
User with /boot directory on an XFS root fs, experiences an unbootable system (no grub menu, just a grub prompt). The short version of the cause is plymouthd exempts itself from forced kill by systemd at reboot time, which prevents systemd from remounting rootfs ro, which prevents grubby's modifications of grub.cfg (or presumably extlinux.conf or anything else) from being flushed to fs metadata. The modification is only flushed to the journal, which GRUB and other bootloaders cannot read or playback. So the modified grub.cfg is not locatable by the bootloader binary.
Merely mounting and umounting this rootfs is enough to cause journal replay and now the bootloader can see the grubby modified grub.cfg.
XFS developers basically ding the thing modifying the bootloader configuration generator/modifier for not ensuring the file is fully committed to disk. So if grubby itself can't umount, or remount ro, (which seems likely it can't), then it needs to freeze/unfreeze the file system. It's not sufficient to sync() as this only guarantees data and journal entries are on disk it does not guarantee the dirty journal entries are flushed to fs metadata.
Detailed bug and troubleshooting:
https://bugzilla.redhat.com/show_bug.cgi?id=1227736
XFS list, most relevant emails:
"Yup - I've been trying to tell you that these are the exact
guarantees that freezing the fs will provide the bootloader
installer...."
https://www.spinics.net/lists/linux-xfs/msg07051.html
"files were sync()d then the file size updates are still
in the journal which has not been replayed. This is what we've been
saying is the problem all along and that a post-update freeze will
work around."
https://www.spinics.net/lists/linux-xfs/msg07084.html
Code already exists to do this but is restricted to PPC64LE only:
https://github.com/rhinstaller/grubby/blob/master/new-kernel-pkg
The text was updated successfully, but these errors were encountered: