Re: Fedora 27 kernel updates make system unbootable (sort of)

On Tue, Apr 24, 2018 at 1:08 PM, François Cami wrote: >> On Fri, Apr 20, 2018 at 3:32 PM, Lennart Poettering >> > >> OK after a bunch of additional testing, one thing is certain; grubby >> and grub-mkconfig are not even remotely crash safe. They do

Re: Fedora 27 kernel updates make system unbootable (sort of)

> On Fri, Apr 20, 2018 at 3:32 PM, Lennart Poettering > > 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.

Re: Fedora 27 kernel updates make system unbootable (sort of)

On Di, 24.04.18 11:36, Chris Murphy (li...@colorremedies.com) wrote: > 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

Re: Fedora 27 kernel updates make system unbootable (sort of)

On Fri, Apr 20, 2018 at 3:32 PM, Lennart Poettering wrote: > On Fr, 20.04.18 12:20, Chris Murphy (li...@colorremedies.com) wrote: > >> I'm honestly mystified why the plymouth commit hasn't been reverted in >> the interim. But I'm also mystified why the bootloader folks don't

Re: Fedora 27 kernel updates make system unbootable (sort of)

On Fri, Apr 20, 2018 at 5:32 PM, Chris Murphy wrote: > On Fri, Apr 20, 2018 at 1:23 PM, Chris Adams wrote: >> Another solution might be to have a dnf plugin that forces a journal >> flush (not a bad idea in general after loading updates), but that

Re: Fedora 27 kernel updates make system unbootable (sort of)

On Fri, Apr 20, 2018 at 5:49 PM, Chris Adams wrote: > Once upon a time, Chris Murphy said: >> And sync() is only sufficient on non-journaled file >> systems, on journaled file systems sync() only ensures metadata is in >> the log, it's considered

Re: Fedora 27 kernel updates make system unbootable (sort of)

Once upon a time, Chris Murphy said: > And sync() is only sufficient on non-journaled file > systems, on journaled file systems sync() only ensures metadata is in > the log, it's considered acceptable to depend on log replay to make > the file system consistent, but of

Re: Fedora 27 kernel updates make system unbootable (sort of)

On Fri, Apr 20, 2018 at 3:32 PM, Lennart Poettering wrote: > On Fr, 20.04.18 12:20, Chris Murphy (li...@colorremedies.com) wrote: > >> I'm honestly mystified why the plymouth commit hasn't been reverted in >> the interim. But I'm also mystified why the bootloader folks don't

Re: Fedora 27 kernel updates make system unbootable (sort of)

On Fri, Apr 20, 2018 at 1:23 PM, Chris Adams wrote: > Once upon a time, Chris Murphy said: >> On Fri, Apr 20, 2018 at 6:15 AM, Florian Weimer wrote: >> > I'm trying to pin down what exposed this bug: >> > >> >

Re: Fedora 27 kernel updates make system unbootable (sort of)

On Fr, 20.04.18 12:20, Chris Murphy (li...@colorremedies.com) wrote: > I'm honestly mystified why the plymouth commit hasn't been reverted in > the interim. But I'm also mystified why the bootloader folks don't > give a shit to commit their configuration files to disk when they know > they can't

Re: Fedora 27 kernel updates make system unbootable (sort of)

Once upon a time, Chris Murphy said: > On Fri, Apr 20, 2018 at 6:15 AM, Florian Weimer wrote: > > I'm trying to pin down what exposed this bug: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1569970 > > > > The immediate trigger seems to be

Re: Fedora 27 kernel updates make system unbootable (sort of)

On Fri, Apr 20, 2018 at 6:15 AM, Florian Weimer wrote: > I'm trying to pin down what exposed this bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=1569970 > > The immediate trigger seems to be that all shutdowns on my system leave the > XFS root file system in an unclean

Fedora 27 kernel updates make system unbootable (sort of)

I'm trying to pin down what exposed this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1569970 The immediate trigger seems to be that all shutdowns on my system leave the XFS root file system in an unclean state, so that GRUB cannot read recently written files under /boot (assuming that