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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
