Bug 968267 - no fedup boot entry due to grubby 'unable to find a suitable template' error
no fedup boot entry due to grubby 'unable to find a suitable template' error
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: grubby (Show other bugs)
18
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-29 06:48 EDT by Honza Horak
Modified: 2014-02-05 16:35 EST (History)
9 users (show)

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


Attachments (Terms of Use)
dmesg output after rebooting (370.07 KB, text/plain)
2013-05-29 06:51 EDT, Honza Horak
no flags Details
fedup.log (9.30 MB, text/x-log)
2013-05-29 14:48 EDT, smanocch
no flags Details
grub.cfg file before running grub2-mkconfig (9.16 KB, text/plain)
2013-05-31 15:43 EDT, Honza Horak
no flags Details

  None (edit)
Description Honza Horak 2013-05-29 06:48:30 EDT
Description of problem:
I'm trying to upgrade F18 -> F19 using fedup and Fedora Beta iso image. Preparation seems to be ok, no error spotted in the log. After rebooting and choosing fedup in grub, correct images is loaded and it seems fine, but it won't start to update packages and just boot into graphical.target (login is displayed and F18 is without changes).

I suspect that it can be caused by problems in getting to system-upgrade.target, since I don't see any system-upgrade.target or system-update.target.

This sounds suspicious in dmesg output:
[   14.973470] systemd[1]: Activating default unit: default.target
[   14.973479] systemd[1]: Trying to enqueue job graphical.target/start/isolate

Version-Release number of selected component (if applicable):
fedup-0.7.3-4.fc18.noarch
systemd-201-2.fc18.7.x86_64


How reproducible:
every-time

Steps to Reproduce:
1. fedup --iso /fedora-19-beta.iso
2. reboot

Actual results:
Normal login screen is displayed, no packages updated after rebooting.

Expected results:
Packages updated after rebooting.
Comment 1 Honza Horak 2013-05-29 06:51:54 EDT
Created attachment 754294 [details]
dmesg output after rebooting
Comment 2 Honza Horak 2013-05-29 07:56:07 EDT
It is also suspicious that I see /system-upgrade symlink, but systemd-system-update-generator.1 speaks about /system-update symlink.
Comment 3 smanocch 2013-05-29 10:34:53 EDT
Same issue for me :-(
Comment 4 Will Woods 2013-05-29 13:19:24 EDT
(In reply to Honza Horak from comment #2)
> It is also suspicious that I see /system-upgrade symlink, but
> systemd-system-update-generator.1 speaks about /system-update symlink.

Upgrades and updates are different. systemd-system-update-generator is for updates, not upgrades. It's not relevant. More info here:
  http://freedesktop.org/wiki/Software/systemd/SystemUpdates/


Anyway: according to dmesg, your kernel command line is: 

BOOT_IMAGE=/vmlinuz-fedup root=/dev/mapper/vg_main-third_root ro log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg rhgb

Where's "systemd.unit=system-upgrade.target"? That's (currently) how we start the upgrade.

Does your grub.cfg/grub2.cfg have "systemd.unit=system-upgrade.target" in it?

Can you attach your fedup.log?
Comment 5 smanocch 2013-05-29 14:36:33 EDT
Hi, 
During the first reboot, when rpm transaction begin I saw a message about a readonly file system but is too fast to read since machine reboots.
Hopefully that this could help.
Comment 6 smanocch 2013-05-29 14:48:30 EDT
Created attachment 754513 [details]
fedup.log
Comment 7 smanocch 2013-05-30 13:22:42 EDT
Another detail: Expect that /boot partition, I've all partitions crypted with luks, in fact during system update boot it asks me password and goes on correctly.
Comment 8 Honza Horak 2013-05-31 01:49:46 EDT
(In reply to Will Woods from comment #4)
> (In reply to Honza Horak from comment #2)
> > It is also suspicious that I see /system-upgrade symlink, but
> > systemd-system-update-generator.1 speaks about /system-update symlink.
> 
> Upgrades and updates are different. systemd-system-update-generator is for
> updates, not upgrades. It's not relevant. More info here:
>   http://freedesktop.org/wiki/Software/systemd/SystemUpdates/
> 
> 
> Anyway: according to dmesg, your kernel command line is: 
> 
> BOOT_IMAGE=/vmlinuz-fedup root=/dev/mapper/vg_main-third_root ro
> log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg rhgb
> 
> Where's "systemd.unit=system-upgrade.target"? That's (currently) how we
> start the upgrade.
> 
> Does your grub.cfg/grub2.cfg have "systemd.unit=system-upgrade.target" in it?

It didn't, but I've found a reason and a work-around. The problem was that there was actually not even fedup entry in grub.cfg (I'm using grub2), so fedup didn't have a place to add system-upgrade.target. Actually, I have the same problem with new kernel - the grub2 menu is not recreated after installing a new kernel and I have to do i t manually.

So in case of fedup I fist re-created the grub2 menu (grub2-mkconfig -o /etc/grub2.cfg) and then run fedup egain and after it grub2.cfg includes even "systemd.unit=system-upgrade.target".

I'll proceed with upgrading later and see how it'll work, but a current question is -- who should actually upgrade grub2 menu after installing either vmlinuz-fedup image or new kernel? I don't see any grub2-mkconfig call in fedup code for example.
Comment 9 Will Woods 2013-05-31 11:48:26 EDT
fedup calls `new-kernel-pkg`:

  https://github.com/wgwoods/fedup/blob/0.7.3/fedup/boot.py#L31

which (as you might guess) is the same thing that happens when you install a new kernel package. `new-kernel-pkg` figures out which bootloader you're using, and calls `grubby` as appropriate to update the bootloader config.

But if grubby doesn't understand your bootloader config, new-kernel-pkg *silently fails*. Which is what happened to you, I'm guessing.

Do you happen to have a copy of the grub2.cfg from *before* you re-ran grub2-mkconfig?
Comment 10 Honza Horak 2013-05-31 15:43:58 EDT
Created attachment 755353 [details]
grub.cfg file before running grub2-mkconfig

(In reply to Will Woods from comment #9)
> Do you happen to have a copy of the grub2.cfg from *before* you re-ran
> grub2-mkconfig?

I believe the attached is what you asked.
Comment 11 Bertrand Juglas 2013-07-04 09:17:16 EDT
Hello,
I had also the problem of the /boot/grub2/grub.cfg file not updated by fedup :(
I've ran manually :
grub2-mkconfig -o /boot/grub2/grub.cfg
as explained on http://fedoraproject.org/wiki/GRUB_2
and everytime I run fedup there is no modification to the /boot/grub2/grub.cfg file
So now I'm trying to run manually new-kernel-pkg to see if it prints some error.
I've run grub2-mkconfig first because when I've installed the update of the kernel it didn't update the grub menu too :(
Comment 12 Bertrand Juglas 2013-07-04 09:41:03 EDT
when I run this command :
new-kernel-pkg -v --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
it prints this error :
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

So it confirms grubby is unable to find a suitable place in the file generated by grub2-mkconfig
Comment 13 Bertrand Juglas 2013-07-04 10:18:37 EDT
But when I run this command:
grubby --initrd=/boot/initramfs-fedup.img --title="System upgrade" --args="root=UUID=2604dc79-1112-4f84-b172-20abb9eaaa80 ro rootflags=subvol=root upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup enforcing=0" --add-kernel=/boot/vmlinuz-fedup --grub2

I don't have errors and it adds well this to /boot/grub2/grub.cfg :
menuentry 'System upgrade' --class gnu-linux --class gnu --class os {
 	linux /boot/vmlinuz-fedup root=UUID=2604dc79-1112-4f84-b172-20abb9eaaa80 ro rootflags=subvol=root upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup enforcing=0
 	initrd /boot/initramfs-fedup.img
}

So it seems to be bug in new-kernel-pkg and not in grubby itself. I suppose new-kernel-pkg calls grubby for GRUB1 and not for GRUB2.
Comment 14 Bertrand Juglas 2013-07-04 10:44:35 EDT
I've added these lines just after the menuentry line because without them it can't find the files :(
        insmod part_msdos
        insmod btrfs
        set root='hd0,msdos5'
Sorry for spamming this bug report :P
Comment 15 markusN 2013-08-04 12:33:10 EDT
(In reply to Honza Horak from comment #8)
> (In reply to Will Woods from comment #4)
> > Does your grub.cfg/grub2.cfg have "systemd.unit=system-upgrade.target" in it?
> 
> It didn't, but I've found a reason and a work-around. The problem was that
> there was actually not even fedup entry in grub.cfg (I'm using grub2), so
> fedup didn't have a place to add system-upgrade.target.

Potentially same problem as in bug 991822 (?)

> Actually, I have the
> same problem with new kernel - the grub2 menu is not recreated after
> installing a new kernel and I have to do i t manually.

Me, too (in F18).
Comment 16 Will Woods 2013-10-09 15:26:40 EDT
So the problem here is that grubby (for whatever reason) doesn't understand your existing grub2.cfg.

Reassigning to grubby.

If you're having this problem, please attach your grub2.cfg to help debug this problem. Thanks.
Comment 17 Fedora End Of Life 2013-12-21 08:46:25 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. 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 '18'.

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 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 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 18'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 18 Fedora End Of Life 2014-02-05 16:35:05 EST
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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.