This probably should have its own thread but I'm just changing the subject.
On Thu, Oct 6, 2016 at 10:18 PM, Eric Griffith <egriffith92(a)gmail.com> wrote:
I'm just thinking out loud here, but, given that rpm-ostree does
grubby, and we do have the Bootloader Spec, and no other distro uses grubby,
would it be prudent to take a really hard look at whether grubby is still a
path we want to walk?
It's a question for pjones or his clone :-D
My recollection is grubby was going to get a rethink, but I don't know
the scope. There are test cases built-into grubby that are considered
valuable, I'm not sure about the rest. Gene found the code difficult.
I think the main issue is, whether grubby or something else, it needs
to be easier to follow the trail of breadcrumbs, self describing. If
it's too easy, of course, it just means telling different people "no"
about their use case. If you're going to support all use cases that's
hard to invent and maintain. See GRUB.
If it is, then more work obviously needs to be put into it to get it
we want/need it. Personally, I would love to see btrfs subvolume support, so
that we could have snapshotting like on Suse, though it appears rpm-ostree
would negate the need for it, correct?
Single Btrfs volume that includes /boot runs into the encryption
problem. An unencrypted /boot is still needed until someone does the
Anaconda and GRUB work to bring GRUB's existing LUKS support to
Fedora. It would probably be disposable work because of the VFS per
file and Brfs per subvolume encryption work happening, but I still
think worth while.
rpm-ostree doesn't need Btrfs, but it leverages Btrfs for some things
and more optimizations are possible. rpm-ostree is well positioned to
support dm thin snapshots, overlayfs (which is what Cloud/Atomic WG
folks are looking into for F26), or Btrfs and take advantage of each.
The opensuse implementation works really well. But it's a bit
complicated to explain and understand it all. Conventional backup and
restore doesn't apply. Right now only the OS installer understands how
to create the unique layout they're using. So really, you just backup
home and maybe some system settings, and bet on doing a fresh
installation if your drive dies or the system face plants beyond the
ability to recover with snapshots. Also, home is still on XFS, so no
If it's not a path we want to walk anymore, then let's
"Intention To Deprecate" to give all interested parties (RHEL) plenty of
warning, and start figuring out what all will break by the removal of
It's a lot simpler to just let it wither away slowly into the night,
and not worry about Btrfs on /boot. Or someone figures it out and
patches grubby to support it. Deprecation and starting over is a lot
of work with essentially zero glory.
Adam, the only other distro that has serious alternate architecture
AFAIK, is Debian. How do they handle grub2 + non-x86? Likewise, the
alternate architectures that we support, how do we handle their bootloaders?
Are they grub-based? Ext/Syslinux based? Grub-legacy?
Nothing in Fedora uses GRUB legacy.
ARM is using Das U-Boot. I'm not sure if grubby is involved here or not.
Fedora uses isolinux, extlinux, grub2, yaboot (power7 and older), and
zipl (s390). If the last two are gone or going away then it's syslinux
(and variants), grub2, and uboot.
I agree with Kevin that grub2 is.... nonintuitive. But the only
serious option we have is bootctl, and I am not sure if that's even a
possibility for a distro like Fedora. I know Arch has it as an install time
option, but I don't know it's limitations.
systemd-boot (gummiboot) is UEFI only. It depends on kernel and
initramfs being on the EFI system partition, which if we're reusing an
existing one will be too small. Starting in Fedora 25 /boot is 1GiB,
mainly because RHEL folks are running out of space due to kdump being
used by default and putting its little gems on /boot - to give an idea
how much space is needed for an ESP to start holding kernels and