On Tue, Apr 24, 2018 at 1:08 PM, François Cami <fdc@xxxxxxxxx> wrote: >> On Fri, Apr 20, 2018 at 3:32 PM, Lennart Poettering >> <mzerqung(a)0pointer.de> wrote: >> >> OK after a bunch of additional testing, one thing is certain; grubby >> and grub-mkconfig are not even remotely crash safe. They do not >> fsync() or sync() at all. That's not good no matter the file system. > > May I point you to https://github.com/rhboot/grubby/pull/24 which *should* fix most of that. Merged upstream almost a year ago, meanwhile Fedora is based on something 3 years old. I have no idea what's going on with that. I know for sure fsync() alone does not fully commit everything, most changes are in the journal. So while it is crash safe as far as kernel log replay code is concerned, it's not bootloader crash safe for ext4, XFS, or Btrfs. I've tested that. > > https://github.com/rhboot/grubby/pull/28 will fix *all* of that when /boot is a separate FS. It doesn't. 1. The biggest problem is when /boot is on / and when / can't remount-ro. 2. It still doesn't sync() when /boot is not separate. 3. I could be mistaken but, pretty sure on non-journaled file systems you need to fsync() the file and fsync() the containing directory for it to fully commit; or you need to use sync(). But I am confused how this is merged almost a year ago and Fedora's grubby appears to last be rebased three years ago, so it doesn't have this fix. > >> The best near term change that I think we should make is putting a >> sync() somewhere in grubby. I've tested modifying new-kernel-pkg to >> add a sync right before the last line, and >> >> # dnf update -y /path/to/kernelrpms && echo b > /proc/sysrq-trigger >> >> With very limited testing (dozens of reboots in multiple fs >> configurations of a VM only, using unsafe caching), all configurations >> including XFS are better off with sync() added. It a highly >> non-deterministic mess to sort out without sync(). >> >> But with sync() and with /boot on XFS: the kernel, initramfs, or >> grub.cfg - there is an unknown (let's say 50/50) probability the >> bootloader can't find or read those files despite the sync(). The most >> common outcome I ran into was a partially modified grub.cfg containing >> an incomplete default entry for the new kernel which is missing the >> grubby insertion for the initrd. So it can't boot. But if the grub >> menu appears at all, the previous kernel and rescue entries are still >> there, and they work. Log replay during boot fixes up everything and >> now the next boot works fine by default without user interaction. So >> even though sync() is still not good enough for XFS always, it's way >> better than no sync(). >> >> Meanwhile FAT, ext2, ext4, and Btrfs all appear to flush to disk with >> sync() sufficient for the bootloader to have no problems. >> >> Note that fsync() is actually insufficient at least some of the time >> on all journaled file systems. e.g. dracut -f only does fsync() on the >> copied over initramfs to /boot and that new initramfs is often not >> seen by the bootloader for journaled file systems. > > Not after https://github.com/dracutdevs/dracut/commit/58e3971b920fbb60e5a90edfd30aa887f9818100 OK but still doesn't work if the containing directory is not a mount point, so /boot directory on / is exempt *and* there is no sync() so even on ext4 and Btrfs it's not bootloader crash safe with the earlier fsync() alone. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
