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@xxxxxxxxx> wrote: > I'm just thinking out loud here, but, given that rpm-ostree does not use > 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 where > 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 snapshots there. > If it's not a path we want to walk anymore, then let's announce an > "Intention To Deprecate" to give all interested parties (RHEL) plenty of > warning, and start figuring out what all will break by the removal of > grubby. 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 support, > 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 other > 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 initramfs's. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
