Re: boot failure after kernel update, imap claims in-use inode 661690 is free, would correct imap

[Dave Chinner <david@fromorbit.com>]

On Wed, Mar 22, 2017 at 09:36:21AM -0600, Chris Murphy wrote:
> On Tue, Mar 21, 2017 at 10:34 PM, Dave Chinner <david@fromorbit.com> 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?

Sounds supremely fragile and fucked up. Sure, lets add another
layers of hacks to systemd to work around the problem that systemd
can't remount-ro the root filesystem because systemd holds open
write fds on the root fs. Fix the problem that causes open write fds
on the root fs at the end of shutdown? Nah, that's stupid talk -
just hack a bandaid over the top....

And let's also ignore the fact that, in this case, the remount-ro is
effectively working around bootloader updates not providing
durability guarantees.  i.e. the bootloader doesn't do guaranteed
safe updates and requires 3rd party action to provide update
integrity.  The distro update scripts are all different because the
bootloader doesn't provide the necessary update infrastructure the
distros require, and it's extremely naive to expect the developers
of those scripts to understand that they need to provide integrity
guarantees that the bootloader itself doesn't provide.

Really, the bootloader needs fixing, then we can go back to
blissfully ignoring all the stupid bugs in the steaming pile we know
as systemd...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com