dracut/grubby fails to update grub.cfg

Chris Murphy lists at colorremedies.com
Mon Oct 20 15:14:23 UTC 2014


On Oct 16, 2014, at 7:23 PM, Stefan Huchler <stefan.huchler at mail.de> wrote:

> thx so far, I dont see one of the 2 solutions a good solution for me, I
> dont see packages for this grubby version,

There should be packages somewhere on http://czarc.org but I'm not sure where. If you can't find them lemme know and I'll go dig around.


> I dont want to compile it
> myself, it doesnt seem to be fixed soon, it seems that this patch will
> not land for fedora 21, so I have to deal with that manual update... for
> another year or more.

/boot on Btrfs isn't a priority for Fedora. In fact, /boot on LVM isn't either. And even things like rootfs on LVM integrated raid (rather than on md raid) isn't even possible in the installer. Since /boot on ext3/4 and XFS are working reliably, there just isn't a perceived strong need to get /boot on Btrfs working better.

> 
> Its such a retarded bug, it checks something and then does not exec
> grub-update becuase it thinks something is wrong while nothing is wrong.

The bug is in grubby, which is what's called from within kernel packages to update bootloader configuration scripts: GRUB legacy, GRUB2, syslinux, yaboot, and probably a bunch of other bootloaders are all supported by grubby. It looks at the existing "old" kernel entry to use as a guide for inserting a new entry for the new kernel. It fails because it doesn't understand subvolumes.

There is no grub-update or update-grub on Fedora or upstream. All it does is call 'grub2-mkconfig -o /boot/grub2/grub.cfg' (on BIOS systems, it's different on UEFI systems).

> 
> cant I not somehow disable this security-check or has this software a
> own fork of the update-grub command?
> 
> I dont know whats a good solution, have this at the moment on 2 pcs now
> because I copied my data on a new ssd and now startet to use a old pc
> with that ssd without reinstalling fedora.

The simplest solution for you is to create an ext4 volume, and copy the contents of /boot there, and update fstab accordingly. Then grubby will succeed updating grub.cfg.

> 
> I dont know doing a cronjob 1times per week would be maybe enough, just
> really stupid bug that will get fixed in fedora in 1.5-2 years from now
> on. really stupid.

Well, one could argue that multiple bootloader projects is really stupid, that there should be some way for all distributions to agree on how to boot a Linux system, and then have one bootloader that can make this happen. But the fact is people disagree on such fundamental things, and they go work on their own bootloaders. And even within GRUB2 the distros don't agree, and they hack GRUB2 and make it rather distinctly different so GRUB2 on Fedora isn't even the same thing as on Ubuntu.

So then Bootloaderspec came along to try to fix this, and still Fedora's implementation deviates from the official one, which is itself just a draft I think. And there's also a fork of the draft. I'm willing to bet there are over 500 ways to boot a Linux system among various bootloaders and filesystem layouts. Whereas Windows and OS X have maybe 10 ways each, 8 of which are so obscure they almost never come up. So the FOSS world fractures its limited resources into a bunch of projects, making the most mature project still incredibly user hostile by requiring some of the most esoteric knowledge imaginable. It's a farm versus a microwavable dinner.


Chris Murphy



More information about the users mailing list