When building a live image I see this when %posttrans is run: grubby fatal error: unable to find a suitable template grubby: doing this would leave no kernel entries. Not writing out new config. That might be because the image contains grub2 and grub2-efi - but not grub. IIRC I have seen the same when installing new kernels directly on an EFI machine. I don't know exactly what I would expect it to do - but a fatal error indicates that there is bag here or there. grubby-8.1-1.fc16.x86_64
*** Bug 735785 has been marked as a duplicate of this bug. ***
I think my issue can be explained by grub2-efi containing an empty grub.cfg, and grubby can obviously not find any suitable kernel there to clone. The best solution might be to make it %ghost instead. Alternatively the issue might be that I don't have a proper symlink in place at /etc/grub2-efi.cfg ... and how should I, considering that this is done in a shiny new chroot.
Marking this bug as Beta blocker from the same reason as in bug 735785.
grub2-efi is not an official feature and _this_ issue do thus perhaps not qualify for a beta blocker ... depending on what the root cause is. Bug 735785 looks more like a beta blocker ... and should thus perhaps not be a duplicate.
Reopening bug 735785, clearing blocker field.
I now understand that new-kernel-pkg really do try to update all the boot loader configuration files it can find. The error messages from grubby are however pretty useless and give no indication which configuration file caused problems, when it did it, and what the problem was. Both grub2 and grub2-efi do contain empty config files which obviously can't be patched by grubby. I think it would be better if they were %ghost.
Same issue with F16 Beta. install.log contains: 05:24:41 Installing setserial-2.17-27.fc15.x86_64 05:24:41 Installing rootfiles-8.1-7.fc15.noarch grubby fatal error: unable to find a suitable template grubby: doing this would leave no kernel entries. Not writing out new config. *** FINISHED INSTALLING PACKAGES *** This is after text mode install from DVD iso in KVM guest.
grubby-8.1-1.fc16.x86_64
grub2-mkconfig -o /boot/grub2/grub.cfg is the solution ?
(In reply to comment #9) > grub2-mkconfig -o /boot/grub2/grub.cfg > is the solution ? Not necessarily. The problem being discussed here is primarily cosmetic. There might however be situations where there is a real problem and where grub2-mkconfig can be used to recover.
hi, After install a new Fedora in a new machine , I realize that we just need grub2-1.99 and grubby, after edit /etc/default/grub and put this on old machine: GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="Fedora" GRUB_DEFAULT=saved GRUB_CMDLINE_LINUX="rd.md=0 rd.dm=0 rd.lvm.lv=VolGroup/lv_swap quiet SYSFONT=latarcyrheb-sun16 rd.lvm.lv=VolGroup/lv_root rd.luks=0 KEYTABLE=pt-latin1 LANG=en_US.UTF-8" yum reinstall kernel , no more complains about "grubby fatal error: unable to find a suitable template"
*** Bug 748952 has been marked as a duplicate of this bug. ***
*** Bug 751268 has been marked as a duplicate of this bug. ***
if you have /etc/default/grub with this parameters and use grub2 GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="Fedora" GRUB_DEFAULT=saved GRUB_CMDLINE_LINUX="LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=pt-latin1 quiet" no more complains about "grubby fatal error: unable to find a suitable template"
Sergio: I'm glad you don't see any ugly grubby error messages now, but I can guarantee that it has nothing to do with the content of /etc/default/grub.
After a preupgrade from F15 -> F16 followed by a yum update: Installing : kernel-3.1.4-1.fc16.x86_64 23/47 grubby fatal error: unable to find a suitable template The /boot/grub configuration is all preupgrade stuff (even though I have rebooted since the preupgrade). /etc/default/grub contains: GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="Fedora" GRUB_DEFAULT=saved GRUB_CMDLINE_LINUX=" KEYTABLE=uk rd.md=0 rd.dm=0 quiet SYSFONT=latarcyrheb-sun16 rhgb rd.lvm.lv=vg_debu/lv_swap rd.luks.uuid=luks-12396ac1-e088-4260-b439-b682535c9ed2 rd.lvm.lv=vg_debu/lv_root LANG=en_US.UTF-8" $ rpm -qa | grep grub grub-efi-0.97-84.fc16.x86_64 grubby-8.3-1.fc16.x86_64 grub2-1.99-12.fc16.x86_64 The machine still boots OK into 3.1.4-1.fc16 so I guess this scary message is just a warning.
(In reply to comment #16) > The machine still boots OK into 3.1.4-1.fc16 so I guess this > scary message is just a warning. The scary message is probably real in the context of grubby patching some other and unused boot loader configuration file. The simplest way to figure out what is going on is to add 'set -x' to /sbin/new-kernel-pkg .
(In reply to comment #16) > After a preupgrade from F15 -> F16 followed by a yum update: > > Installing : kernel-3.1.4-1.fc16.x86_64 23/47 > grubby fatal error: unable to find a suitable template > > The /boot/grub configuration is all preupgrade stuff (even though > I have rebooted since the preupgrade). > > /etc/default/grub contains: > > GRUB_TIMEOUT=5 > GRUB_DISTRIBUTOR="Fedora" > GRUB_DEFAULT=saved > GRUB_CMDLINE_LINUX=" KEYTABLE=uk rd.md=0 rd.dm=0 quiet > SYSFONT=latarcyrheb-sun16 rhgb rd.lvm.lv=vg_debu/lv_swap > rd.luks.uuid=luks-12396ac1-e088-4260-b439-b682535c9ed2 > rd.lvm.lv=vg_debu/lv_root LANG=en_US.UTF-8" > > $ rpm -qa | grep grub > grub-efi-0.97-84.fc16.x86_64 > grubby-8.3-1.fc16.x86_64 > grub2-1.99-12.fc16.x86_64 > > The machine still boots OK into 3.1.4-1.fc16 so I guess this > scary message is just a warning. please use this default, which is more correct : GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="Fedora" GRUB_DEFAULT=saved GRUB_CMDLINE_LINUX="LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=pt-latin1 quiet" after that try: yum reinstall kernel, to see if you still have the scary warning. Just for sure you need have 2 versions of kernel installed like this rpm -q kernel kernel-3.1.1-1.fc16.x86_64 kernel-3.1.1-2.fc16.x86_64
I'm also seeing the message, and it looks like it is benign, despite the severity of the text. I used preupgrade to upgrade from Fedora 15 to 16. In F15 I used grub, in F16 I use grub2. The upgrade didn't remove all traces of grub, and that is what causes the message (at least in my case). /sbin/new-kernel-pkg does the following (among much else): - it checks whether /etc/grub.conf exists and determines what that links to. - it also checks whether the linked to file (/boot/grub/grub.conf) exists. - if it exists, it calls grubby to update the file. It is this last step that causes the warning. Note that /sbin/new-kernel-pkg does the same for /etc/grub2.cfg (which links to /boot/grub2/grub.cfg which also exists) and calls grubby for that file as well. It is this latter behavior which makes the message benign. It seems to me that the solution is - remove /etc/grub.conf and /boot/grub/grub.conf. But first make sure that you don't use grub but use grub2 instead.
I can confirm comment #19 - renaming /boot/grub and /etc/grub.conf made the error go away.
(In reply to comment #20) > I can confirm comment #19 - renaming /boot/grub and /etc/grub.conf made the > error go away. I guess it's not quite correct to rename or remove /boot/grub directory entirely, as it contains file owned by another package now: $ rpm -qf /boot/grub/splash.xpm.gz fedora-logos-16.0.2-1.fc16.noarch
Oops, it seems you were right: $ LANG=C rpm -V fedora-logos missing /boot/grub/splash.xpm.gz It might be crude but it solved the problem, this should be filed as a bug against fedora-logos I guess.
Renaming/removing /boot/grub is bit a aggresive, but it shouldn't be a problem if you no longer use grub. splash.xpm.gz is only used by grub and it won't do any harm to remove it, but it is not a bug that the file is in fedora-logos and is missing after it has been removed. A more elegant solution is to remove /etc/grub.conf _or_ /boot/grub/grub.conf .
I agree that removing splash.xpm.gz won't damage the system itself, but the file should be removed from fedora-logos package as we don't need it anymore and it is a bug (of fedora-logos component). Otherwise, with the opposite approach applied as a rule, you can't easily assure the system integrity. Any package in its turn must not contain unnecessary/unused files.
The bug is that grub2 doesn't have any graphical theming yet, and there is thus no better place for the splash. But grub2 could use it even though it is in /boot/grub. It is also possible that Fedora one day will rename grub2 back to its real name and use /boot/grub/.
(In reply to comment #23) > A more elegant solution is to remove /etc/grub.conf _or_ /boot/grub/grub.conf . or have a grubby a little more intelligent ?
(In reply to comment #26) > or have a grubby a little more intelligent ? grubby-the-binary could give better error reports, and new-kernel-pkg could be "intelligent" enough to silently skip empty boot loader configuration files. But in general grubby can't know which boot loader is used and whether failing to update a boot load configuration file is fatal. I do for example have a system that I can boot with both BIOS/MBR grub2 and with grub2-efi, and where it would be "fatal" if grubby failed to maintain either of them. The core problem is that systems "often" have unused boot loader configuration files - the boot loader configuration files should not be created before they are seeded with a valid configuration that grubby can maintain, and the grub configuration should be removed (or moved away) when it no longer is used.
(In reply to comment #16) > After a preupgrade from F15 -> F16 followed by a yum update: > > > The machine still boots OK into 3.1.4-1.fc16 so I guess this > scary message is just a warning. I believe so myself. Do you have grub.conf still in /etc /boot/grub probably what I'm seeing: http://lists.fedoraproject.org/pipermail/kernel/2011-December/003568.html
Hello. I also saw the message "grubby fatal error: unable to find a suitable template". My problem was that I directly boot into the rootfs device and omitting the initrd totaly. I use this kernel command line: "root=/dev/sda2 rootfstype=ext4 rootflags=data=writeback ro quiet rhgb" This will result in these /etc/mtab entries: rootfs / rootfs rw 0 0 /dev/root / ext4 rw,seclabel,relatime,user_xattr,barrier=1,data=writeback 0 0 somehow grubby tries to determine the current root device in use and fails as /dev/root doesn't exists. symlinking /dev/root to /dev/sda2 makes grubby work correctly.
I'm also seeing this message in the last lines of install.log on freshly installed kickstart network installations of Fedora 16 == 18:27:35 Installing man-pages-3.32-14.fc16.noarch grubby fatal error: unable to find a suitable template grubby: doing this would leave no kernel entries. Not writing out new config. *** FINISHED INSTALLING PACKAGES *** == On the same systems yum is broken: == yum update Loaded plugins: langpacks, presto, refresh-packagekit Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again == Was wondering if that is a seperate issue or if it is related. E.g. does the error cause other scripts near the end of the installation process not to be run?
Ignore my last comment. Yum issue is unrelated, and was caused by selecting the wrong timezone setting. (which is fatal nowadays, as a wrong system time will make dnssec validation fail when looking up mirrors.fedoraproject.org)
Hm. I just got bitten by this issue. I did an update and couldn't boot the new kernel, because the initrd was missing. Manually reinstalling the kernel led to the error message: Running Transaction Installing : kernel-3.2.5-3.fc16.x86_64 grubby fatal error: unable to find a suitable template $ cat /etc/default/grub GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="Fedora" GRUB_DEFAULT=saved GRUB_CMDLINE_LINUX="rd.md=0 rd.dm=0 rd.lvm.lv=vg_bigbox/swap quiet SYSFONT=latarcyrheb-sun16 rhgb rd.lvm.lv=vg_bigbox/root rd.luks.uuid=luks-f5485ba1-6e67-49cd-837f-b5bd10cfc792 KEYTABLE=us-acentos LANG=en_US.UTF-8" $ rpm -qa | grep grub grub-efi-0.97-84.fc16.x86_64 grubby-8.8-2.fc16.x86_64 grub2-1.99-13.fc16.x86_64 after moving /etc/grub.conf{,.bak} and /boot/grub/grub.conf{,.bak} it seems to works again. At least I have an initrd.
I tried all suggestions - removed /etc/grub.cfg and /boot/grub, created /dev/root but nothing works. I have extra /boot partition, / partition is encrypted, every kernel update shows that error: grubby --grub2 -c /boot/grub2/grub.cfg --add-kernel=/boot/vmlinuz-3.2.7-1.fc16.x86_64 --copy-default --make-default --title 'Fedora (3.2.7-1.fc16.x86_64)' --args=root=/dev/mapper/luks-d3f472fd-bfa4-4822-8a62-f0f7c60aaacf '--remove-kernel=TITLE=Fedora (3.2.7-1.fc16.x86_64)' DBG: Image entry failed: no line found DBG: menuentry 'Fedora (3.2.6-4.fc16.x86_64)' { DBG: set root='(hd0,1)';setlegacy_hdbias='0' DBG: legacy_kernel '/vmlinuz-3.2.6-4.fc16.x86_64' '/vmlinuz-3.2.6-4.fc16.x86_64' 'ro' 'root=/dev/mapper/luks-d3f472fd-bfa4-4822-8a62-f0f7c60aaacf' 'rd_LUKS_UUID=luks-d3f472fd-bfa4-4822-8a62-f0f7c60aaacf' 'rd_NO_LVM' 'rd_NO_MD' 'rd_NO_DM' 'LANG=en_US.UTF-8' 'SYSFONT=latarcyrheb-sun16' 'KEYTABLE=us' 'rhgb' 'guiet' 'nopat' DBG: legacy_initrd '/initramfs-3.2.6-4.fc16.x86_64.img' '/initramfs-3.2.6-4.fc16.x86_64.img' DBG: } DBG: Image entry failed: no line found .... DBG: if sleep -i $timeout; then timeout=0; else timeout=-1; fi grubby fatal error: unable to find a suitable template Nothing helps. Any suggestions?
(In reply to comment #33) > I tried all suggestions - removed /etc/grub.cfg and /boot/grub, created > /dev/root but nothing works. The error discussed here is caused by new-kernel-pkg telling grubby to patch an empty boot loader configuration file. Your issue seems to be that you somehow ended up with a /boot/grub2/grub.cfg entry that grubby considers invalid. Your issue is thus different and better discussed on a new bugzilla issue. A workaround might be to remove grub.cfg and create a new boot loader configuration with grub2-mkconfig -o /boot/grub2/grub.cfg - perhaps after removing spurious files in /etc/grub.d . If you really need this legacy_kernel entry and it is valid then it could be considered a grubby bug that it can't handle it. A part of the problem might be that grubby and grub2 have different opinions on how the default kernel entry is found and which entry that should be used as template for future kernel updates.
*** Bug 809346 has been marked as a duplicate of this bug. ***
Problem not corrected in released product. It still occurs in released F17, when upgrading from an up-to-date and bone-stock F16 x86-64 platform.
(In reply to comment #36) > Problem not corrected in released product. It still occurs in released F17, > when upgrading from an up-to-date and bone-stock F16 x86-64 platform. Did you use grubby-8.12-1.fc17.x86_64 ? https://bugzilla.redhat.com/show_bug.cgi?id=826537 Just to know, if you had use lastest grubby released.
Sergio asked: > Did you use grubby-8.12-1.fc17.x86_64 ? Yes. The grubby used for the problem F16 to F17 upgrade is the one installed as part of the F17 DVD: $ rpm -q grubby grubby-8.12-1.fc17.x86_64
(In reply to comment #38) > Sergio asked: > > Did you use grubby-8.12-1.fc17.x86_64 ? > > Yes. The grubby used for the problem F16 to F17 upgrade is the one > installed as part of the F17 DVD: grubby from DVD is not grubby-8.12 yum list grubby grubby.x86_64 8.12-1.fc17 @updates grubby 8.12 is from updates, as far I know ...
Correct, this has not been fixed in f17. The primary issue is the wording of the message. It doesn't tell when and where it failed to find a template. The primary cause of the message is that there is some invalid and unused boot loader configuration around that grubby can't update. From grubbys point of view it is fatal, but usually everything that matters is fine.
*** Bug 833011 has been marked as a duplicate of this bug. ***
Created attachment 605360 [details] grub.cfg before update
Created attachment 605361 [details] grub.cfg after update
This appears to be bug #124246.
(In reply to comment #42) > grub.cfg before update (In reply to comment #43) > grub.cfg after update Yes, that is correct. No problem there.
(In reply to comment #44) > This appears to be bug #124246. Same symptom, different root cause.
I've got the same on my Fedora 18 (Mac Mini, UEFI, so no grub2 at all - only grub2-efi).
Doing preupgrade from Fedora 16 to Fedora 17 fails. I get this in the upgade.log: grubby fatal error: unable to find a suitable template grubby fatal error: unable to find a suitable template grubby: doing this would leave no kernel entries. Not writing out new config. /var/tmp/rpm-tmp.Pz1bIW: line 2: /etc/rc.d/init.d/rpcidmapd: No such file or directory /var/tmp/rpm-tmp.Pz1bIW: line 3: /etc/rc.d/init.d/rpcgssd: No such file or directory /var/tmp/rpm-tmp.Pz1bIW: line 4: /etc/rc.d/init.d/nfs: No such file or directory /var/tmp/rpm-tmp.Pz1bIW: line 5: /etc/rc.d/init.d/nfslock: No such file or directory warning: %postun(nfs-utils-1:1.2.4-3.fc15.x86_64) scriptlet failed, exit status 127 Running in chroot, ignoring request. grubby fatal error: unable to find a suitable template grubby: doing this would leave no kernel entries. Not writing out new config. grubby fatal error: unable to find a suitable template grubby: doing this would leave no kernel entries. Not writing out new config.
(In reply to comment #48) Your problems (if you have any) is probably not related to this. Please file another bug report (or several) and provide the logs and describe in details which actual problems you see.
I've seen this error message intermittently for some time now, and just got it again when updating to the latest F18 kernel. In this case the new grub.cfg was OK anyway. But sometimes, when removing an old kernel, I've got this message and it removed references to the current kernel from grub.cfg which would make the system unbootable, and I've had to reconstruct grub.cfg by hand. I protect against this by keeping grub.cfg in an RCS archive. Since not everybody does, maybe it would be good if grubby would make a backup copy of grub.cfg before it changes anything.
(In reply to comment #50) > I've seen this error message intermittently for some time now, and just > got it again when updating to the latest F18 kernel. Your problems are probably not related to this. Please file another bug report and describe in details which actual problems you see. > maybe it would be good if grubby would make a backup > copy of grub.cfg before it changes anything. 'grubby fatal error' means that grubby _didn't_ change the config file. Creating a backup file (and overwriting existing backups) would thus not be right in this case.
(In reply to comment #51) > (In reply to comment #50) > > 'grubby fatal error' means that grubby _didn't_ change the config file. > Creating a backup file (and overwriting existing backups) would thus not be > right in this case. In a specific case, I just had yum update install kernel kernel-3.7.2-204.fc18 while running 3.7.2-201.fc18 I got the error message about grubby fatal error could not find a suitable template, yet the grub.cfg file was in fact updated (correctly). so if it is not supposed to change the config file with that error then sometimes it is doing it anyway. I don't understand your objection to making a backup file before changing grub.cfg since the current file before the change is one that was just used to boot the system, and hence is known to be good. The case where it would be bad is when I manually remove an old kernel with yum -e and grubby also erroneously removes the new kernel from grub.cfg, as has happened to me a few times. Then the backup grub.cfg would reference a kernel that is no longer present. But at least the fatal error message would alert me that the system is likely to be unbootable; and I could edit the backup file to point to the new kernel.
(In reply to comment #52) > I got the error message about grubby fatal error could not find a suitable > template, yet the grub.cfg file was in fact updated (correctly). So grubby was run twice. One time it failed fatally patching some other file, one time it correctly patched the right config file. > I don't understand your objection to making a backup file before changing > grub.cfg since the current file before the change is one that was just > used to boot the system, and hence is known to be good. I don't object to making backups. But it is another issue. And it is hard to do in a meaningful way when grubby works through a symlink ... which might be another issue. I'm just saying that if grubby fails with a fatal error then it failed before it got as far as considering writing the file, and it should thus not have created a backup file anyway.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
still can be reproduced in rawhide.
(In reply to dgod.osa from comment #56) > still can be reproduced in rawhide. If you can reproduce it in Rawhide (I can't) then you should reopen the bug and set the Version from 17 -> Rawhide.
(In reply to Richard W.M. Jones from comment #57) > If you can reproduce it in Rawhide (I can't) then you should reopen > the bug and set the Version from 17 -> Rawhide. He might not have the sufficient rights. Doing that now, per comment 56.
This bug plagues me every time a kernel update is installed. After I clean my underpants, I recall that grubby is Fedora's own Chicken Little, always complaining the sky is falling. In my case, the error is not as fatal as grubby asserts; the update proceeds normally, and I always seem to be able to (at least) boot the newer kernel afterward. (A lot of other things typically break, but I've not been able to trace them back to grubby not finding its precious template.) If the bug cannot be found, can we at least change the error message to something a little less ominous?
I don't see this bug since F16 more or less . you should have upgrade system since ages . we should have only /boot/grub2 and remove /boot/grub directory and all in it .
Bad news Chief: I saw the bug this morning while doing a fedup from 19 to 20. So, the bug's still lurking out there. If /boot/grub/ shouldn't be there, then I recommend you remove it as part of the upgrade process. I do confirm the directory /boot/grub-wasn't-removed bug has afflicted the machine in question, I'll try your workaround to see if I can save on laundry during future upgrades.
I can guarantee that what you see now is not "this bug". But there might be some other bug that cause the same error message. Most likely something is wrong on your system and grubby cannot do what it is told to do. Probably because you have both /etc/grub2.cfg and /etc/grub2-efi.cfg, one of them is used and works without problems, the other one is unused and bad.
(In reply to Jim Wilson from comment #61) > If /boot/grub/ shouldn't be > there, then I recommend you remove it as part of the upgrade process. yeah perhaps if you clean /boot/grub/ you fix the bug yourself , but upgrade from grub to grub2 was 3 or 4 releases ago (more or less). it is other bug "grub2 should make sure that /boot/grub/ doesn't not exist", nevertheless rpm shouldn't remove files arbitrarily ...
Mads, I find /etc/grub2.cfg and /etc/grub.conf. The latter a broken symlink to /boot/grub/grub.conf, probably removed at the behest of Senor Basto. Makes sense to remove the broken symlink, too. I won't know if the bug has been supressed until the next kernel upgrade, but the workaround sounds reasonable, and doesn't seem to break anything else in the meantime. Sergio, Removing files manually is, at best, a workaround, not a fix. I think I mentioned the grubby problem has been bothering me for quite some time. Searching Bugzilla led me to this open bug, and I felt obligated to report it. I don't know grubby from a hole in the ground, but grubby was complaining, not grub2. I'm not suggesting rpm remove the offending file(s), but I think there must be some way mechanism to remove them if they break subsequent updates. I vehemently deny copying them into /boot by hand or somehow restoring them from an outdated backup. They somehow didn't get removed when they should have been, and that is the bug I'm reporting. I'll now remain silent unless I see grubby pitch another fit when the next kernel update floats in.
Bug 730357 is three bugs combined. Two are in software. First, the diagnostic is so poor that the underlying bug cannot be identified, except by recreating the original system (hardware and software) and proceeding from there; that poverty is itself a bug, and warrants keeping this report open and active until it's fixed. Second, there is whatever the original bug were, which may be genuinely fixed, or may be confined to no longer supported software. Third, there is a meatware bug, in that 730357 has not been addressed in a timely manner. This bug spans many reports, and may not be practicably fixable, given the nature of the development process. But it's a big, fat, ugly bug.
If the system isn't using GRUB, it's safe to remove the /etc/grub.conf. You can also just ignore the error. I ran into this issue when I was setting up a Centos 6.x server on a VPS. I followed the instructions from http://www.itekhost.net/grubby-fatal-error/ and the error message was gone. This problem can still be reproduced on Fedora 17/18/19 as well as Centos 5/6 as of today.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.