/boot on Btrfs still not supported, main problem is anaconda and grubby

[Peter Robinson]

On Fri, Mar 20, 2015 at 11:47 AM, Josef Bacik <josef at toxicpanda.com> wrote:
> On Mar 17, 2015 3:30 PM, "Chris Murphy" <lists at colorremedies.com> wrote:
>>
>> 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?