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. Cheers! Eric On Thu, Oct 6, 2016 at 7:43 AM, Tomasz Kłoczko <kloczko.tomasz@xxxxxxxxx> 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 filesystem tree. A new tree is created and updated, the bootloaderconfiguration is changed, and the system is rebooted (at the user'sleisure) to get the updated system. i.e. it makes it clear your systemis not running updates until it's rebooted, which it maybe probablywho 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 variousAtomic Host products Fedora creates. And there's going to be aWorkstation version of it for Fedora 25 (for very early adopters, itwon't be at getfedora.org).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 fromthe time the current tree is snapshot, the update and reboot happens.The current root tree can have changes to /var and /etc happeningduring the update and before reboot, so those need to get merged suchthat you can reboot either the old or new tree and have log andjournal 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 braveperson who wants to fix grubby? Someone else already tried, so there'scode available to look at to help grok the logic of what needs to bedone; but needs to be implemented in a different way to get approvedby upstream.https://bugzilla.redhat.com/show_bug.cgi?id=864198-- Chris Murphy_______________________________________________devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxxTo unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
|
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
