On Tue, Mar 21, 2017 at 10:34 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > FYI, I've ranted previously over many years about how broken grub's > kernel update and retreival process is fundamentally broken, but > it's never been fixed(*). As a result, I don't use grub on any of my > systems, nor do I recommend that anyone else use it. OK I follow all the previous comments, thanks, but here is where there's a departure. On Ubuntu systems, maybe all Debian systems, they are using grub-mkconfig script, possibly in the form of update-grub, to create a completely new grub.cfg. That script writes out grub.cfg.new and then renames it to grub.cfg. Fedora/RH systems don't use that at all. They don't use anything from upstream GRUB to do updates in fact. The kernel RPM uses new-kernel-pkg which in turn calls things like dracut, and eventually it has grubby modify the grub.cfg in place. The grubby package has no relationship at all with upstream grub. Directly modifying grub.cfg and overwriting it seems risky, but I'm pretty sure that's how it works. > (*) The simple fix for grub to freeze/unfreeze the filesystem rather > than/after calling sync() - this does the same thing as remount-ro, > but unlike remount-ro it does not fail if there are writable file > descriptors open. OK. It looks to me like systemd eventually gives up on the remount-ro, and then just reboots. That strikes me as a flawed design. Systemd needs to wait longer (which is vague advice), or maybe after the 3rd failed remount-ro, insert a freeze/unfreeze, then reboot. How does that sound? -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
