>> >> What's it going to take to fix this? Ubuntu supports it, openSUSE >> >> supports it, GRUB 2 has supported it for many years now. >> >> >> >> This is a 2.5 year old bug, with patches to fix the problem for ~9 >> >> months, which have been tested and work >> >> https://bugzilla.redhat.com/show_bug.cgi?id=864198 >> >> >> >> The short version of that bug (and the next one) is that on live >> >> installs, Anaconda copies the kernel with rsync, excluding the install >> >> media's initramfs, then calls grub2-mkconfig. The resulting grub.cfg >> >> lacks an initrd line for the primary entry, because there's no >> >> initramfs yet. This happens on all file systems. >> >> >> >> Next, the installer execute new-kernel-pkg, which creates the >> >> initramfs, and executes grubby which updates the grub.cfg to include >> >> the initrd line. Except on Btrfs. >> >> >> >> Every now and then the installer starts permitting /boot on Btrfs, >> >> which then causes blockers like this: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1200539 >> >> >> >> But due to the dependency on grubby, anaconda folks have fixed such >> >> blockers by disallowing /boot on Btrfs. >> >> >> >> This email basically constitutes the harassment approach to getting a >> >> really old bug fixed. But it's like, everything that should be done >> >> has been done, and yet we're stuck in the mud on this while other >> >> distros have totally bypassed this because they don't depend on >> >> grubby, and instead use upstream tools for generating grub.cfg. >> >> >> >> Now what? >> >> >> > >> > Why are we even using grubby? I was under the impression that the grub2 >> > tools did all of the same work, so why keep maintaining it? Seems silly >> > something this easy to fix still hasn't been fixed. Thanks, >> >> Because there's still usecases and architectures that don't use grub2? > > What usescases? And what architectures don't have boot tools that handle > their own configuration? Specifics would be helpful so I have a scope of > what I need to fix. AFAIK yaboot can handle its own config stuff, not sure > what ARM uses. If they really need this help then by all means let's > continue using grubby for those arch's and fix the scripts where we use > grub2 to simply use grub2's tooling. Thanks, Well there's u-boot on ARMv7 and probably on aarch64 (uEFI is for the server spec, not necessarily other form factors), what about those users interested in using gummiboot instead of grub2? How would you handle non grub tools with grub2-tools, ultimately there will need to be some glue between the two, although it's possible that it might be a tool other than grubby or a refactored grubby (I think pjones has plans here). Peter -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
