Bug 730357 - grubby fatal error: unable to find a suitable template
grubby fatal error: unable to find a suitable template
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: grubby (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
: Reopened
: 748952 751268 809346 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-12 11:17 EDT by Mads Kiilerich
Modified: 2016-03-17 10:42 EDT (History)
38 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 04:48:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
grub.cfg before update (2.19 KB, text/plain)
2012-08-18 14:14 EDT, Jim Haynes
no flags Details
grub.cfg after update (2.77 KB, text/plain)
2012-08-18 14:15 EDT, Jim Haynes
no flags Details

  None (edit)
Description Mads Kiilerich 2011-08-12 11:17:19 EDT
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
Comment 1 Brian Lane 2011-09-06 12:27:46 EDT
*** Bug 735785 has been marked as a duplicate of this bug. ***
Comment 2 Mads Kiilerich 2011-09-06 18:21:40 EDT
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.
Comment 3 Kamil Páral 2011-09-07 05:06:54 EDT
Marking this bug as Beta blocker from the same reason as in bug 735785.
Comment 4 Mads Kiilerich 2011-09-07 05:48:39 EDT
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.
Comment 5 Kamil Páral 2011-09-07 12:01:47 EDT
Reopening bug 735785, clearing blocker field.
Comment 6 Mads Kiilerich 2011-09-13 10:33:36 EDT
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.
Comment 7 Alexander Todorov 2011-10-06 05:59:08 EDT
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.
Comment 8 Alexander Todorov 2011-10-06 05:59:22 EDT
grubby-8.1-1.fc16.x86_64
Comment 9 Sergio Monteiro Basto 2011-11-10 23:11:42 EST
grub2-mkconfig -o /boot/grub2/grub.cfg

is the solution ?
Comment 10 Mads Kiilerich 2011-11-11 06:04:26 EST
(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.
Comment 11 Sergio Monteiro Basto 2011-11-16 20:07:13 EST
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"
Comment 12 Mads Kiilerich 2011-11-25 10:24:13 EST
*** Bug 748952 has been marked as a duplicate of this bug. ***
Comment 13 Mads Kiilerich 2011-11-25 10:24:45 EST
*** Bug 751268 has been marked as a duplicate of this bug. ***
Comment 14 Sergio Monteiro Basto 2011-11-25 19:20:07 EST
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"
Comment 15 Mads Kiilerich 2011-11-25 21:27:35 EST
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.
Comment 16 Richard W.M. Jones 2011-12-06 08:38:08 EST
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.
Comment 17 Mads Kiilerich 2011-12-06 08:55:04 EST
(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 .
Comment 18 Sergio Monteiro Basto 2011-12-06 10:44:26 EST
(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
Comment 19 Sjoerd Mullender 2011-12-06 14:05:40 EST
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.
Comment 20 Julian Sikorski 2011-12-11 05:18:54 EST
I can confirm comment #19 - renaming /boot/grub and /etc/grub.conf made the error go away.
Comment 21 jethawk 2011-12-12 23:14:42 EST
(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
Comment 22 Julian Sikorski 2011-12-13 08:50:42 EST
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.
Comment 23 Mads Kiilerich 2011-12-13 14:36:39 EST
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 .
Comment 24 jethawk 2011-12-13 23:24:14 EST
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.
Comment 25 Mads Kiilerich 2011-12-14 12:51:22 EST
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/.
Comment 26 Sergio Monteiro Basto 2011-12-15 20:17:51 EST
(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 ?
Comment 27 Mads Kiilerich 2011-12-16 09:40:33 EST
(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.
Comment 28 Frank Murphy 2011-12-22 03:53:43 EST
(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
Comment 29 Thomas Meyer 2012-01-16 13:20:00 EST
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.
Comment 30 Floris 2012-02-04 13:39:38 EST
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?
Comment 31 Floris 2012-02-04 14:23:57 EST
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)
Comment 32 Tobias Mueller 2012-02-13 15:32:47 EST
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.
Comment 33 Michal Hlavinka 2012-02-21 13:10:58 EST
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?
Comment 34 Mads Kiilerich 2012-02-21 13:33:40 EST
(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.
Comment 35 Brian Lane 2012-04-03 12:00:21 EDT
*** Bug 809346 has been marked as a duplicate of this bug. ***
Comment 36 John Mellor 2012-06-10 21:43:20 EDT
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.
Comment 37 Sergio Monteiro Basto 2012-06-10 22:08:11 EDT
(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.
Comment 38 John Mellor 2012-06-10 22:24:40 EDT
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
Comment 39 Sergio Monteiro Basto 2012-06-11 05:43:00 EDT
(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 ...
Comment 40 Mads Kiilerich 2012-06-11 06:08:13 EDT
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.
Comment 41 Mads Kiilerich 2012-07-30 11:59:34 EDT
*** Bug 833011 has been marked as a duplicate of this bug. ***
Comment 42 Jim Haynes 2012-08-18 14:14:53 EDT
Created attachment 605360 [details]
grub.cfg before update
Comment 43 Jim Haynes 2012-08-18 14:15:58 EDT
Created attachment 605361 [details]
grub.cfg after update
Comment 44 Amazed 2012-08-26 01:54:14 EDT
This appears to be bug #124246.
Comment 45 Mads Kiilerich 2012-08-26 10:51:59 EDT
(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.
Comment 46 Mads Kiilerich 2012-08-26 10:52:35 EDT
(In reply to comment #44)
> This appears to be bug #124246.

Same symptom, different root cause.
Comment 47 Peter Lemenkov 2012-10-18 02:37:55 EDT
I've got the same on my Fedora 18 (Mac Mini, UEFI, so no grub2 at all - only grub2-efi).
Comment 48 Jan Vlug 2012-12-14 05:22:41 EST
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.
Comment 49 Mads Kiilerich 2012-12-14 05:42:34 EST
(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.
Comment 50 Jim Haynes 2013-01-23 13:21:12 EST
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.
Comment 51 Mads Kiilerich 2013-01-23 13:26:41 EST
(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.
Comment 52 Jim Haynes 2013-01-23 14:25:20 EST
(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.
Comment 53 Mads Kiilerich 2013-01-23 14:44:16 EST
(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.
Comment 54 Fedora End Of Life 2013-07-03 22:35:51 EDT
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.
Comment 55 Fedora End Of Life 2013-08-01 04:48:25 EDT
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.
Comment 56 dgod.osa 2013-08-01 05:16:31 EDT
still can be reproduced in rawhide.
Comment 57 Richard W.M. Jones 2013-08-01 05:19:16 EDT
(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.
Comment 58 Kamil Páral 2013-08-01 05:57:11 EDT
(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.
Comment 59 Jim Wilson 2014-01-09 12:22:11 EST
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?
Comment 60 Sergio Monteiro Basto 2014-01-09 12:43:45 EST
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 .
Comment 61 Jim Wilson 2014-01-09 13:09:09 EST
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.
Comment 62 Mads Kiilerich 2014-01-09 14:57:21 EST
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.
Comment 63 Sergio Monteiro Basto 2014-01-09 15:20:28 EST
(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 ...
Comment 64 Jim Wilson 2014-01-09 15:37:13 EST
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.
Comment 65 Daniel Kian Mc Kiernan 2014-01-11 03:29:06 EST
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.
Comment 66 John Paulson 2014-08-25 01:10:37 EDT
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.
Comment 67 Jan Kurik 2015-07-15 11:14:36 EDT
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

Note You need to log in before you can comment on or make changes to this bug.