Bug 902498 - fedup does not create entry in grub.cfg
fedup does not create entry in grub.cfg
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: grubby (Show other bugs)
19
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-21 14:22 EST by Torsten Rohlfing
Modified: 2015-02-18 08:49 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-18 08:49:05 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
fedup log file (3.64 MB, text/x-log)
2013-01-21 14:22 EST, Torsten Rohlfing
no flags Details
The /boot/grub2/grub.cfg file - unchanged by fedup (4.32 KB, text/plain)
2013-01-21 14:23 EST, Torsten Rohlfing
no flags Details
Another fedup log file from running "fedup-cli" rather than "fedup" (1.82 MB, text/x-log)
2013-01-24 15:42 EST, Torsten Rohlfing
no flags Details
grub.cfg after (5.10 KB, application/octet-stream)
2013-02-16 14:55 EST, Sammy
no flags Details
Existing f19 grub.cfg that grubby balks on (2.07 KB, text/plain)
2014-02-24 17:38 EST, Philip Prindeville
no flags Details

  None (edit)
Description Torsten Rohlfing 2013-01-21 14:22:28 EST
Created attachment 684577 [details]
fedup log file

Description of problem:

Running fedup to prepare for F17->F18 upgrade completes without errors or warnings, but no upgrade entry is created in /boot/grub2/grub.cfg (file is not modified according to timestamp).


Version-Release number of selected component (if applicable):

fedup-0.7.2-1.fc17.noarch

(also using grub2-2.0-0.39.fc17.x86_64)


How reproducible:

Alyways


Steps to Reproduce:
1. fedup --network 18
2. check /boot/grub2/grub.cfg for upgrade boot entry
3. check timestamp of /boot/grub2/grub.cfg
  
Actual results:

No upgrade boot entry in grub.cfg. File not changed.


Expected results:

Expect to find an "Upgrade to F18" entry in the boot menu.


Additional info:

Not sure this is related, but it makes the affected machine a bit special.

This system has been upgraded all the way back since FC3 (in single-version increments.) Anyway, the original boot partition was 100MB, which is now officially no longer enough to upgrade (Thanks to whoever came up with that number as the default boot partition size!).

To address the issue, I created a new /boot directory in the root file system, copied the contents of the original boot partition there, and re-ran "grub2-install". Then I removed the original boot partition from /etc/fstab.

The new /boot directory has gone through one kernel upgrade and several reboots without a problem, so it is fully functional. 

Also, I checked the original (still existing) /boot partition, just in case fedup for some reason is trying to create a boot entry in the grub.cfg file there, but there is no change to any files on that partition either.

So I don't think this is related to the problem, but thought I'd better mention it.
Comment 1 Torsten Rohlfing 2013-01-21 14:23:52 EST
Created attachment 684578 [details]
The /boot/grub2/grub.cfg file - unchanged by fedup

This is the grub.cfg file, both before and after running fedup (no change is made by running fedup).
Comment 2 Sammy 2013-01-22 09:06:50 EST
I am also having the same problem on multiple machines. New kernels sometimes have no entry in the grub.cfg file (and sometimes do!). This totally messed
me up on the laptop as I removed the old kernel and was left with an empty
grub.cfg file.......not fun.
Comment 3 Torsten Rohlfing 2013-01-22 23:54:13 EST
Sammy -

I don't think this is the same problem.

All my kernel updates have always resulted in proper entries added to the grub.cfg. My problem is very specific to fedup.

(In reply to comment #2)
> I am also having the same problem on multiple machines. New kernels
> sometimes have no entry in the grub.cfg file (and sometimes do!). This
> totally messed
> me up on the laptop as I removed the old kernel and was left with an empty
> grub.cfg file.......not fun.
Comment 4 Mark Harfouche 2013-01-24 15:22:14 EST
Did you properly start the upgrade?

Start the upgrade prep by executing following command
sudo fedup-cli --network 18 --debuglog fedupdebug.log
Once the preparations have completed, check the fedupdebug.log file if any errors show up in the output from fedup-

as explained in http://fedoraproject.org/wiki/FedUp
Comment 5 Torsten Rohlfing 2013-01-24 15:41:43 EST
That's exactly what I did - I only used "fedup" instead of "fedup-cli" and added "--debug" and "--verbose" to the command.

To be sure, I just repeated with your exact command line, and the result is exactly the same: no entry in grub.cfg, no error in the fedup log file.

Will attached the log file once again, just in case.

(In reply to comment #4)
> Did you properly start the upgrade?
> 
> Start the upgrade prep by executing following command
> sudo fedup-cli --network 18 --debuglog fedupdebug.log
> Once the preparations have completed, check the fedupdebug.log file if any
> errors show up in the output from fedup-
> 
> as explained in http://fedoraproject.org/wiki/FedUp
Comment 6 Torsten Rohlfing 2013-01-24 15:42:33 EST
Created attachment 686981 [details]
Another fedup log file from running "fedup-cli" rather than "fedup"
Comment 7 Will Woods 2013-01-24 17:11:00 EST
fedup adds the boot entry by running:

  new-kernel-pkg --initrdfile /boot/initramfs-fedup.img \
                 --banner 'System Upgrade' \
                 --kernel-args 'upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup enforcing=0' \
                 --make-default \
                 --install fedup

(possibly adding "selinux=0" to kernel-args instead, if SELinux is disabled)

What happens if you run that command by hand?
Comment 8 Torsten Rohlfing 2013-01-24 17:17:48 EST
I get

  grubby fatal error: unable to find a suitable template

which I suppose would explain why no entry is created.

(In reply to comment #7)
> fedup adds the boot entry by running:
> 
>   new-kernel-pkg --initrdfile /boot/initramfs-fedup.img \
>                  --banner 'System Upgrade' \
>                  --kernel-args 'upgrade systemd.unit=system-upgrade.target
> plymouth.splash=fedup enforcing=0' \
>                  --make-default \
>                  --install fedup
> 
> (possibly adding "selinux=0" to kernel-args instead, if SELinux is disabled)
> 
> What happens if you run that command by hand?
Comment 9 Will Woods 2013-01-25 14:29:08 EST
This is a grubby bug, then.

Can you please attach your /etc/grub2.cfg (or /boot/grub2/grub.cfg - they should be the same file)?
Comment 10 Torsten Rohlfing 2013-01-25 14:31:19 EST
That file is already attached to the bug.

(In reply to comment #9)
> This is a grubby bug, then.
> 
> Can you please attach your /etc/grub2.cfg (or /boot/grub2/grub.cfg - they
> should be the same file)?
Comment 11 Torsten Rohlfing 2013-02-04 12:43:58 EST
Latest on this matter - did some digging in the Fedora forums and found suggestions to run

grub2-mkconfig -o /boot/grub2/grub.cfg

in case of grubby errors. Did this, and now the upgrade kernel is there.

Also, after running the above, I can now run the new-kernel-pkg command suggested by Will without getting an error.
Comment 12 Sammy 2013-02-16 08:57:09 EST
This is happening all the time...very annoying, kernel installed no entry in /boot/grub2/grub.cfg
I ran the command by hand:

# /sbin/new-kernel-pkg -v --package kernel-3.7.8-202.fc18.x86_64.rpm --install 3.7.8-202.fc18.x86_64
initrdfile is /boot/initrd-3.7.8-202.fc18.x86_64.img
/etc/grub.conf does not exist, not running grubby for grub 0.97
adding 3.7.8-202.fc18.x86_64 to /boot/grub2/grub.cfg
grubby fatal error: unable to find a suitable template
/etc/grub2-efi.cfg does not exist, not running grubby for grub 2 with UEFI
/etc/lilo.conf does not exist, not running grubby
/etc/extlinux.conf does not exist, not running grubby for extlinux

If I run grub2-mkconfig it correctly creates the grub.cfg....
Comment 13 Will Woods 2013-02-16 14:36:49 EST
Was /boot mounted at the time? Are all the kernels listed in grub.cfg present and readable?

What does grub.cfg look like after it's "fixed" by running grub2-mkconfig?

Can someone attach a bad config and the resulting fixed config?
Comment 14 Sammy 2013-02-16 14:54:26 EST
Yes,  /boot is always mounted isn't it?
This is a clean DVD install of Fedora 18.

I am attaching grub.cfg after running grub2-mkconfig
I don't have the older one but it looks just the same.
Using this attached grub.cfg when I try to install the next
kernel it will still give me the same error. And not I still
get the error in Comment 12.

also, /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Fedora"
GRUB_DEFAULT=saved
GRUB_CMDLINE_LINUX="rd.md=0 rd.dm=0 rd.luks=0 vconsole.keymap=us rd.lvm.lv=fedora_dhcp-129-59-117-21/root rd.lvm.lv=fedora_dhcp-129-59-117-21/swap rhgb quiet LANG=en_US.UTF-8 selinux=0 nouveau.modeset=0 rd.driver.blacklist=nouveau" 
GRUB_DISABLE_RECOVERY="true"
GRUB_THEME="/boot/grub2/themes/system/theme.txt"
Comment 15 Sammy 2013-02-16 14:55:44 EST
Created attachment 698275 [details]
grub.cfg after
Comment 16 Sammy 2013-02-18 19:31:17 EST
OK. Here is what found on multiple systems:
The problem seems to have to do with /etc/mtab contents. Not clear what.
But if I do 'cat /proc/mounts > /etc/mtab' then the kernel updates work
just fine, namely the template is found. Tried on three different systems,
two desktops and a laptop.
FYI
Comment 17 Roland Roberts 2013-05-24 00:25:05 EDT
Comment 9 was the key in my case; at some point, /etc/grub2.cfg stopped being a link to /boot/grub2/grub.cfg. The side effect was that grubby kept updating /etc/grub2.cfg but that doesn't help during boot.

Oh, and the problem with "grubby fatal error: unable to find a suitable template" is discussed in Bug 730357, in my case having left-over /etc/grub.cfg and /boot/grub/grub.cfg files.
Comment 18 rimbotede 2013-06-04 15:31:52 EDT
(In reply to Sammy from comment #16)
> OK. Here is what found on multiple systems:
> The problem seems to have to do with /etc/mtab contents. Not clear what.
> But if I do 'cat /proc/mounts > /etc/mtab' then the kernel updates work
> just fine, namely the template is found. Tried on three different systems,
> two desktops and a laptop.
> FYI

I get the following error:
# cat /proc/mounts > /etc/mtab
cat: /proc/mounts: input file is output file
Comment 19 Jean-Jacques Sarton 2013-07-03 06:24:57 EDT
I have attempted to upgrade to f19 with fedup --network 19. After rebooting there what no upgrade and the inspection of the system show that the last kernel (vmlinuz-3.9.6-200.fc18.x86_64) is also not present within grub2, the system load always the previous kernel (vmlinuz-3.9.5-201.fc18.x86_64).
According to this the problem seem not to be within fedup.
Comment 20 rimbotede 2013-07-03 14:04:14 EDT
(In reply to Jean-Jacques Sarton from comment #19)
> I have attempted to upgrade to f19 with fedup --network 19. After rebooting
> there what no upgrade and the inspection of the system show that the last
> kernel (vmlinuz-3.9.6-200.fc18.x86_64) is also not present within grub2, the
> system load always the previous kernel (vmlinuz-3.9.5-201.fc18.x86_64).
> According to this the problem seem not to be within fedup.
Same here. It appears all of the problems I have recently with boot/kernel configuration have all common cause, unknown
https://ask.fedoraproject.org/question/27266/how-to-change-grub-2-boot-order/
https://ask.fedoraproject.org/question/27478/kernel-wont-update-how-to-fix-it/
Comment 21 Fedora End Of Life 2013-07-03 22:40:41 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 22 Domenico Ferrari 2013-07-04 02:48:44 EDT
I'm usign Fedora 18.
With fedup to F19 I have the same problem.
The entry is present in /etc/grub2.cfg

I resolved with
cp /etc/grub2.cfg /boot/grub2/grub.cfg
rm /etc/grub2.cfg
ln -s /boot/grub2/grub.cfg /etc/grub2.cfg
Comment 23 Jean-Jacques Sarton 2013-07-04 04:33:10 EDT
On my system /etc/grub2.cfg what already a link to /boot/grub2/grub.cfg.
I had resolved the problem while inserting the entry for the latest F18 kernel, rebooting and runnning 'fedup --network 19 -d -v'. The log has shown that a few packages what installed and then the entry for the system upgrade what present within grub.cfg
Comment 24 Randy 2013-07-21 02:30:37 EDT
Tried going from fc18 to 19 today.  Used 'fedup-cli --network 19'

Downloaded a boat-load of files, then just hung.  Restarted, looked at /var/log/fedup.log ... it ended with "RpmDBError: Package tuple (bla-bla) could not be found .."

Ran 'yum clean all', then 'yum -y update', worked fine.

Then ran 'fedup-cli --network 19' again, and it said I was up to date.

BUT - grub still doesn't have the fc19 offering.

Ran 'grub2-mkconfig' ... no difference in grub.cfg

also:
( /etc/grub2.cfg -> /boot/grub2/grub.cfg )
Comment 25 Jean-Jacques Sarton 2013-07-21 05:35:52 EDT
(In reply to Randy from comment #24)
> Tried going from fc18 to 19 today.  Used 'fedup-cli --network 19'
> 
> Downloaded a boat-load of files, then just hung.  Restarted, looked at
> /var/log/fedup.log ... it ended with "RpmDBError: Package tuple (bla-bla)
> could not be found .."
> 
> Ran 'yum clean all', then 'yum -y update', worked fine.
> 
> Then ran 'fedup-cli --network 19' again, and it said I was up to date.
> 
> BUT - grub still doesn't have the fc19 offering.
> 
> Ran 'grub2-mkconfig' ... no difference in grub.cfg
> 
> also:
> ( /etc/grub2.cfg -> /boot/grub2/grub.cfg )

For me the way what to manually edit grub.cfg (entry for last F18 kernel), rebooting and then to call fedup --network 19.
May be that the problem you have is similar. While executing the last fedup command some more packages what downloaded.
Comment 26 Fedora End Of Life 2013-08-01 05:07:20 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 27 Philip Prindeville 2014-02-24 17:36:06 EST
I'm reproducing this on f19.

I'll attach my grub.cfg file...
Comment 28 Philip Prindeville 2014-02-24 17:38:35 EST
Created attachment 867165 [details]
Existing f19 grub.cfg that grubby balks on

I get:

grubby fatal error: unable to find a suitable template

when I try:

new-kernel-pkg --initrdfile /boot/initramfs-fedup.img \
                 --banner 'System Upgrade' \
                 --kernel-args 'upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup enforcing=0' \
                 --make-default \
                 --install fedup
Comment 29 Philip Prindeville 2014-02-24 18:35:37 EST
If I run this with -v, I get:

initrdfile is /boot/initramfs-fedup.img
found /boot/initramfs-fedup.img and using it with grubby
/etc/grub.conf does not exist, not running grubby for grub 0.97
adding fedup to /boot/grub2/grub.cfg
grubby fatal error: unable to find a suitable template
/etc/grub2-efi.cfg does not exist, not running grubby for grub 2 with UEFI
/etc/lilo.conf does not exist, not running grubby
/etc/extlinux.conf does not exist, not running grubby for extlinux

still not sure what causes the fatal error, however.
Comment 30 vdm 2014-03-10 15:36:09 EDT
Seems that I've caught same problem on upgrading F19 to F20.
Used `grub2-mkconfig -o /boot/grub2/grub.cfg` and call to `new-kernel-pkg` to fix this.
Comment 31 Fedora End Of Life 2015-01-09 17:03:20 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

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 19 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.
Comment 32 Fedora End Of Life 2015-02-18 08:49:05 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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.

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