Can anyone answer this relatively simple question: "Why grubby?" I've seen a number of discussions on various topics surrounding the boot loader that all seem to devolve into "We would love to support that, but grubby doesn't, so we can't." 

At what point does the maintenance burden of using grubby outweigh its own benefits?

I don't ask this rhetorically, or because I particularly want to see grubby gone. I just don't see the benefit that we get from having grubby when other distros seem to get by just fine without it, or if they do use it, it doesn't seem to be getting in their way.


On Oct 6, 2016, at 12:12, Chris Murphy <> wrote:

On Thu, Oct 6, 2016 at 7:43 AM, Tomasz Kłoczko <> wrote:

So how problem of consistent upgrade have been solved on Solaris using ZFS
and IPS?
ZFS has ability to create snapshot of the vol (RO resource) and create on
top of the shapshot clone (RW resource).
Whole upgrade process consist from few steps:
- find volumes which needs to be snapshoted and cloned
- create clones
- mount clones as separated tree and perform upgrad

This is what OSTree is effectively doing now.

/usr is read only. And updates aren't ever applied to the current file
system tree. A new tree is created and updated, the bootloader
configuration is changed, and the system is rebooted (at the user's
leisure) to get the updated system. i.e. it makes it clear your system
is not running updates until it's rebooted, which it maybe probably
who knows.

rpm-ostree integrates RPM support into OSTree.

 This part is crucial. If anything wrong will happen during upgrade still
working system is not affected. It is possible to observe state of broken
upgrade and produce very precise diagnostic data allowing to fix upgrade
process on layer of packages. In other words impact of during upgrade on top
of still working system is NULL/ZERO!!!

Yes, it's the same for rpm-ostree, i.e. the basis for the various
Atomic Host products Fedora creates. And there's going to be a
Workstation version of it for Fedora 25 (for very early adopters, it
won't be at

On Linux at the moment is available btrfs which provides possibility of RW
snapshots (equivalent of ZFS clones). All what needs to be added to this
layer is btrfs volume attribute indicating that volume needs to be cloned
during upgrade in case of more complicated scenarios.

It's actually kinda complicated to handle the changes that occur from
the time the current tree is snapshot, the update and reboot happens.
The current root tree can have changes to /var and /etc happening
during the update and before reboot, so those need to get merged such
that you can reboot either the old or new tree and have log and
journal continuity, and so on. rpm-ostree does this.

Another small bit which needs to be sorted is related to install procedures
implemented in anaconda and post installation procedures in kernel package.
What is missing here? anaconda does not allow now to use /boot on btrfs. It
forces use ext3/4.

It's a grubby bug. It doesn't understand Btrfs subvolumes. Any brave
person who wants to fix grubby? Someone else already tried, so there's
code available to look at to help grok the logic of what needs to be
done; but needs to be implemented in a different way to get approved
by upstream.

Chris Murphy
devel mailing list --
To unsubscribe send an email to