Fedora 20 Final blocker bug status report (ACTIONS REQUIRED: karma from QA, fixes from devs)

[Gene Czarcinski]

On 11/28/2013 06:10 PM, Adam Williamson wrote:
> On Thu, 2013-11-28 at 17:19 -0500, Gene Czarcinski wrote:
>> On 11/28/2013 12:17 AM, poma wrote:
>>> On 28.11.2013 03:25, Adam Williamson wrote:
>>>
>>>> * https://bugzilla.redhat.com/show_bug.cgi?id=864198 "grubby fatal error
>>>> updating grub.cfg when /boot is btrfs" - grubby - the problem here is
>>>> clearly defined. We are waiting on pjones to decide how to move forward
>>>> with this. Gene Czarcinski has posted a proposed change to
>>>> new-kernel-pkg to use grub2-mkconfig instead of grubby for updating
>>>> bootloader config, which would address this bug but be a late, major
>>>> change in our behaviour. The alternative would be to fix the problem in
>>>> grubby. Either way, this is waiting on Peter as the bootloader guy.
>>> "grub2-mkconfig" for the EXTLINUX too!?
>>> You should share whatever you have.
>>> LoL!
>>> Bee awesome.:!
>>>
>>>
>> I am going to regret opening my mouth here but being foolish has never
>> stopped me before ;)
>>
>> Actually, no, I would never use grub2-mkconfig to update a extlinux.conf
>> file.  However, I do have this 308 lines bash script "program" which can
>> "edit" a extlinux.conf file to add or remove a kernel entry.
>>
>> Right now, about the only thing I really propose is to use the patch I
>> created to handle the grubby/BTRFS problem and that only.  Yes, I
>> "solve" the problem by not using grubby at all and instead use
>> grub2-mkconfig to update (actually it completely rebuilds) the grub.conf
>> file.
>>
>> It works.  I believe with a little code inspection (it is all
>> bash-script) you can "prove" it only effects BTRFS.  Since BTRFS
>> currently does not work, how could this be worse?
> FWIW, in previous discussion on the bug, I missed that your change only
> applies if the /boot partition is on btrfs...that does make it a less
> significant change that we might plausibly be able to take for final,
> though it introduces a significant difference in behaviour
> between /boot-on-btrfs and /boot-on-anything-else. I do wish pjones
> would chime in soon.
Since I made those last statements, a couple of things have occurred 
which you may want to consider.

1) I found that although my code works, I should have been using 
grub2-set-default and not grub2-editenv.  Next, when I said that is 
"only" if /boot was on a BTRFS filesystem, that was true.  But, if your 
rootfs was BTRFS, then regardless of what /boot was, it would handle it.

2)  After much digging and research I found what appears to be the 
future plan for kernel installation and bootloader configuration 
update:  systemd with the kernel-install software and the BootLoaderSpec:
http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/

When (and it is not there yet by anyones idea) this is all implemented, 
there is no need for grubby and it just fads away.   A basic part of 
this idea is that /boot will be a common partition to ALL installs on a 
hardware platform and all of their kernels, etc. would be located in 
this common partition.  Initially this partition could be vfat or ext234 
but now there is a push for vfat only. There are bootloader config 
parameters that are in the /boot/loader directory and the bootloader is 
responsible for handling those. Grub2 has a patch to support this.

Anyway, in light of this, it seems to me that a reasonable approach 
might be to restrict the /boot partition to a separate ext234 partition 
as being consistent with this future plan.

I do believe that this future play needs to be described better along 
with a Fedora Release target specified.

That said, you might still want to consider using my "btrfs patch" 
depending on how long it will take to get the "new stuff" implemented 
and tested.

There is also one more little wrinkle to the BTRFS thing: to work 
correctly, both os-prober and grub2 need some fixes applied.

Over to you folks.  I have this stuff which I have created and it is 
working for me.  I am considering making my updated rpms (x86_64 and 
i386) available for others if there really is interest.

But, I hope that you all do understand just what your goals are because 
it sure seems to me that there could be more communications about the 
plans for handling kernels, bootloaders, etc.

Gene