Bug 826537 - Pre-upgraded system never install fc17 kernel in grub2
Pre-upgraded system never install fc17 kernel in grub2
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: grubby (Show other bugs)
17
Unspecified Unspecified
urgent Severity urgent
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
: 817289 826529 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-30 08:59 EDT by Kamil Páral
Modified: 2012-08-20 01:19 EDT (History)
24 users (show)

See Also:
Fixed In Version: grubby-8.12-1.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-04 14:37:31 EDT
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)
grub.cfg in the upgraded system (2.62 KB, text/plain)
2012-05-30 09:01 EDT, Kamil Páral
no flags Details
anaconda.log (8.72 KB, text/plain)
2012-05-30 09:01 EDT, Kamil Páral
no flags Details
program.log (51.72 KB, text/plain)
2012-05-30 09:01 EDT, Kamil Páral
no flags Details
storage.log (83.55 KB, text/plain)
2012-05-30 09:01 EDT, Kamil Páral
no flags Details
syslog (62.96 KB, text/plain)
2012-05-30 09:01 EDT, Kamil Páral
no flags Details
yum.log (3.03 KB, text/plain)
2012-05-30 09:02 EDT, Kamil Páral
no flags Details
preupgrade errors (13.56 KB, image/png)
2012-05-30 10:50 EDT, Kamil Páral
no flags Details
kickstart generated by preupgrade (262 bytes, text/plain)
2012-05-30 10:51 EDT, Kamil Páral
no flags Details
original grub.cfg before running preupgrade (2.65 KB, text/plain)
2012-05-30 10:52 EDT, Kamil Páral
no flags Details
modified grub.cfg after preupgrade finished but before reboot (2.96 KB, text/plain)
2012-05-30 10:53 EDT, Kamil Páral
no flags Details

  None (edit)
Description Kamil Páral 2012-05-30 08:59:39 EDT
Description of problem:
This is a follow-up of bug 820351. We thought the bug wouldn't hit us once we open up Fedora 17 updates repo. But it is still broken. See bug 820351 comment 21.

To reproduce, I did f16 minimal install and used preupgrade-cli. Afterwards I have two kernels installed
kernel-PAE-3.3.7-1.fc16.i686
kernel-PAE-3.3.7-1.fc17.i686
but grub.cfg only contains fc16 version.

See attached logs from the upgrade process.

Version-Release number of selected component (if applicable):
F17 Final
preupgrade 1.1.10-1.fc16

How reproducible:
always

Steps to Reproduce:
1. install F16, fully update
2. preupgrade to F17
3. see only fc16 kernels listed in grub
Comment 1 Kamil Páral 2012-05-30 09:01:29 EDT
Created attachment 587722 [details]
grub.cfg in the upgraded system
Comment 2 Kamil Páral 2012-05-30 09:01:34 EDT
Created attachment 587723 [details]
anaconda.log
Comment 3 Kamil Páral 2012-05-30 09:01:38 EDT
Created attachment 587724 [details]
program.log
Comment 4 Kamil Páral 2012-05-30 09:01:42 EDT
Created attachment 587725 [details]
storage.log
Comment 5 Kamil Páral 2012-05-30 09:01:54 EDT
Created attachment 587726 [details]
syslog
Comment 6 Kamil Páral 2012-05-30 09:02:00 EDT
Created attachment 587727 [details]
yum.log
Comment 7 Kamil Páral 2012-05-30 09:21:32 EDT
To illustrate the main problem - it is not easy to fix it. "yum update" doesn't help until a newer kernel is released. You have to edit grub.cfg manually or run grub2-mkconfig or meddle with kernels (reinstall fc17 kernel). Layman users might have problems doing that. Also most people won't know what to do, because they don't read CommonBugs.
Comment 8 Mads Kiilerich 2012-05-30 09:30:35 EDT
That grub.cfg has not been generated by the f17 grub2. I don't see any invocations of grub2-install / grub2-mkconfig in the anaconda logs. Is the boot loader installation step always skipped with preupgrade or was that an explicit choice here?

In this case the problem must be caused by the grubby template error message - it was for once really fatal.

Is the f16 kernel fully installed and with both vmlinuz and initramfs in /boot?

Can you confirm that grub2-mkconfig will generate a working configuration?
Comment 9 Dan Scott 2012-05-30 09:47:38 EDT
(In reply to comment #8)
> That grub.cfg has not been generated by the f17 grub2. I don't see any
> invocations of grub2-install / grub2-mkconfig in the anaconda logs. Is the
> boot loader installation step always skipped with preupgrade or was that an
> explicit choice here?

In my case (comment #21 of bug 820351) I made no explicit choices for preupgrade; the result came from the default preupgrade process once F17 was made generally available yesterday.

> In this case the problem must be caused by the grubby template error message
> - it was for once really fatal.
> 
> Is the f16 kernel fully installed and with both vmlinuz and initramfs in
> /boot?

In my case, the F16 kernel was fully installed and had both vmlinux and initramfs. So did the F17 kernel.

> 
> Can you confirm that grub2-mkconfig will generate a working configuration?

Running grub2-mkconfig > /etc/grub2.cfg && grub2-install /dev/sda generates a working configuration (the results are much different than what had been living in /etc/grub2.cfg - now I understand what people are talking about with respect to the grub video modes), so for this naive user (heh) it seems like a decent workaround / manual fix for the bug.
Comment 10 Kamil Páral 2012-05-30 09:57:39 EDT
This problem does not happen when using netinst.iso to upgrade - a single fc17 kernel is installed and the old fc16 kernel is removed. So this issue is probably really caused by preupgrade in some way.
Comment 11 Kamil Páral 2012-05-30 10:50:09 EDT
Created attachment 587752 [details]
preupgrade errors

Preugprade-cli finishes with some weird errors.
Comment 12 Kamil Páral 2012-05-30 10:51:47 EDT
Created attachment 587760 [details]
kickstart generated by preupgrade
Comment 13 Kamil Páral 2012-05-30 10:52:17 EDT
Created attachment 587761 [details]
original grub.cfg before running preupgrade
Comment 14 Kamil Páral 2012-05-30 10:53:03 EDT
Created attachment 587762 [details]
modified grub.cfg after preupgrade finished but before reboot
Comment 15 Kamil Páral 2012-05-30 10:55:17 EDT
This is probably a duplicate of bug 820340, but there are more logs here.
Comment 16 Kamil Páral 2012-05-30 11:39:21 EDT
I have tested preupgrade-1.1.11-1. It fixes the errors printed out at the end of preupgrade process (attachment 587752 [details]). But it does not fix this issue. fc17 kernel is still installed but not present in grub.cfg.
Comment 17 Germano Massullo 2012-05-30 14:11:26 EDT
Could you please tell my how to get these logs? I have other computers that are running upgrades so I can reproduce the problem
Comment 18 Mads Kiilerich 2012-05-30 14:24:53 EDT
(In reply to comment #11)
> Created attachment 587752 [details]
> preupgrade errors
> 
> Preugprade-cli finishes with some weird errors.

That is bug 815473 and bug 826473 and bug 811964 - preupgrade isn't selected once in the bootloader as it should.
Comment 19 Germano Massullo 2012-05-30 14:26:52 EDT
I have a computer on which the anaconda (you mean preupgrade but is anaconda) is not avaible at all in grub
Comment 20 Mads Kiilerich 2012-05-30 14:54:41 EDT
*** Bug 826529 has been marked as a duplicate of this bug. ***
Comment 21 Chris Gilligan 2012-05-30 17:24:21 EDT
I concur, this bug occurred for me after preupgrade fc16/fc17beta and again at fc16/fc17gold.

Also concur grub2-mkconfig > /etc/grub2.cfg && grub2-install /dev/sda repairs this issue and creates proper grub.cfg loading fc17 kernel
Comment 22 Mads Kiilerich 2012-05-30 19:02:58 EDT
(In reply to comment #21)

(Please do the grub2 stuff correctly - and stop spreading the wrong way.
First install stuff mkconfig can pick up: grub2-install /dev/sda
Then create the config securely: grub2-mkconfig -o /boot/grub2/grub.cfg
)
Comment 23 Adam Williamson 2012-05-31 12:44:52 EDT
https://admin.fedoraproject.org/updates/grubby-8.12-1.fc17 is expected to fix this , I believe. If people can re-test it'd be good. Testing before the update hits stable is a bit tricky, though.
Comment 24 Garrett Mitchener 2012-05-31 21:34:35 EDT
I saw this too on two different machines and I think this is probably the correct bug to post a comment.  On one machine, the upgrade seemed to go well, but then the machine rebooted back into the F16 kernel as described here.  I had to manually run

grub2-install /dev/sda

followed by

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


I wasn't paying too much attention, but I believe all the files in /boot/grub2 before this were all from the F16 version of grub2.

On the other machine (upgraded the same way) I'm quite sure that the files in /boot/grub2 were from F16 after reboot.  To make matters worse, once I got to the command line, grub2-install was somehow not able to identify that the "target" should be i386-pc for this machine, and I had to dig through a lot of documentation to figure out that the command to fix it was

grub2-install --target=i386-pc /dev/sda

In short, I don't think grubby is necessarily the (only) culprit here.  I think grub2 and/or anaconda and/or preupgrade are also at fault for not installing the new bootloader files.

I have a third F16 machine that I'll be upgrading, probably in about a week.  I'd be willing to test a proposed fix on it then if you can tell me how.

Seriously: We've got to do better on upgrades, especially for something as critical and technical as the bootloader.  There's a new Fedora every six months or so.  Every time I've upgraded, no matter what method, something goes wrong with the bootloader, I get no error message, just a malfunctioning system.  And the fix is always to get to a command line and manually run the grub installation commands that ought to be done automatically.
Comment 25 Adam Williamson 2012-05-31 22:12:16 EDT
That doesn't sound like the same bug. Do you have the kickstart file from the preupgrade?
Comment 26 Garrett Mitchener 2012-05-31 23:27:56 EDT
(In reply to comment #25)

> That doesn't sound like the same bug. 

Okay, on reading this page over again, maybe my bug is different, but I think it's related.  Part of the original bug may have been fixed before I ran my upgrade.  I used the preupgrade graphical interface, didn't see any error messages then, and afterward grub2.cfg did have an entry for the upgrade, which ran more or less correctly, but it generated this error in /root/upgrade.log:

09:00:36 Upgrading grubby-8.11-1.fc17.i686
...
09:47:23 Upgrading kernel-PAE-3.3.7-1.fc17.i686
grubby fatal error: unable to find a suitable template
...
10:45:19 Upgrading grub2-2.0-0.25.beta4.fc17.i686
warning: /etc/default/grub created as /etc/default/grub.rpmnew
...

What I'm thinking here is that grub2 isn't getting installed properly somehow (maybe too late in the process), and grub2.cfg isn't getting rebuilt, so grubby fails during the install of the kernel package.  In my case, all of that went wrong during the actual upgrade.

Did all the malfunction in the original bug report happen while running preupgrade but before booting into the upgrade itself?  Comment #8 makes me think something also went wrong during the upgrade.

> Do you have the kickstart file from the preupgrade?

Where would I find it?
Comment 27 Adam Williamson 2012-06-01 00:11:55 EDT
Ooh. I just figured something out that I didn't realize before.

We're doing something different in preupgrade to what we're doing in DVD/netinst upgrades. DVD/netinst default bootloader handling on upgrade is still 'install new bootloader' (which has been default since F16); i.e. anaconda will entirely reinstall the bootloader on upgrade.

That's not actually the case for preupgrade from F16 to F17, though.

The code we put in preupgrade during F16 cycle to ensure it did a new bootloader install when upgrading from F15 to F16 was quite specific:

        # Fedora 16 switched to grub2
        if float(self.source_version) < 16.0 and float(self.target_version) >= 16.0:
            ks[3] += '  --location=mbr'
        else:
            ks[3] += '  --upgrade --location=none'

So - when you're upgrading from 16 to 17, you get the good old pre-F16 default behaviour back. You get "bootloader  --upgrade --location=none" . So in preupgrade, we're just telling anaconda to update the existing bootloader configuration, not to reinstall the bootloader.

That's obviously significant here. So the problems we're having are when the attempt to update the bootloader configuration fails.

I think Kamil and Garrett are actually both seeing a similar case where the bootloader config update is just failing, and I was wrong to say they're different bugs, but I'm not sure how to be sure...
Comment 28 Kamil Páral 2012-06-01 03:51:08 EDT
(In reply to comment #27)
>             ks[3] += '  --upgrade --location=none'
> 
> So - when you're upgrading from 16 to 17, you get the good old pre-F16
> default behaviour back. You get "bootloader  --upgrade --location=none" . So
> in preupgrade, we're just telling anaconda to update the existing bootloader
> configuration, not to reinstall the bootloader.

Great job. That's exactly what I see in my generated /boot/upgrade/ks.cfg.

So we need to fix:
1. kickstart generation in preupgrade
2. grub2.cfg generation by grubby
Comment 30 Mads Kiilerich 2012-06-01 05:48:37 EDT
(In reply to comment #28)
> 2. grub2.cfg generation by grubby

Just a clarification: grubby will never generate grub.cfg, neither directly nor by calling grub2-mkconfig. It is only anaconda that will generate grub.cfg by invoking grub2-mkconfig.

(The role of grubby in the brave new world with the over-engineered grub2 configuration scheme is a bit unclear. Perhaps grubby should do something different.)

Patching of grub.conf with new kernels while preupgrading should however work with https://admin.fedoraproject.org/updates/grubby-8.12-1.fc17 .
Comment 31 Kamil Páral 2012-06-01 07:30:21 EDT
*** Bug 820340 has been marked as a duplicate of this bug. ***
Comment 32 Adam Williamson 2012-06-01 11:20:09 EDT
Caterpillar: we'd really prefer not to, because they're different problems.
Comment 33 Kamil Páral 2012-06-01 11:43:54 EDT
IIUC we need a new preupgrade package that fixes kickstart generation, as stated in comment 27. And soon, before all our users decide to upgrade (and hit the issue).

Richard, can you provide one? Thanks.
Comment 34 Adam Williamson 2012-06-01 12:59:08 EDT
Kamil: I don't necessarily agree. It's at least not urgent. There's nothing intrinsically wrong with doing a config update instead of a reinstall (though obviously it's a bit odd for preupgrade and DVD to take different paths here). With grubby 8.12, it should actually work okay. It just explains why grubby is important and why we're hitting issues on preupgrade we're not hitting on DVD.

If grubby 8.12 does fix the bugs with actually correctly updating the grub config, then I'd say there's no urgent problem any more.

We might decide that we always want to reinstall grub2 on upgrade until its code and config format start stabilizing a bit more as a matter of policy, but that's not 'OMG needs to happen yesterday'.
Comment 35 Adam Williamson 2012-06-02 00:01:12 EDT
So I tested, and 8.12 seems to do the trick. If anyone else wants to try, the trick is to run the F16 part of preupgrade, then edit /boot/upgrade/ks.cfg (or /boot/update/ks.cfg, i forget which it is) and add a line:

repo --name=side --baseurl=http://www.happyassassin.net/extras/repo2/x86_64

then go ahead and reboot and do the preupgrade. That repo is on my personal server, it has grubby 8.12 in it. (I don't have an i686 version up, sorry). After the preupgrade completes, it should properly add the F17 kernel. I compared by doing it with two identical cloned VMs, making the edit in one case but not in the other. It worked with the updated grubby, it didn't work without.

The update needs one more karma point.
Comment 36 Germano Massullo 2012-06-02 05:02:07 EDT
(In reply to comment #35)
> So I tested, and 8.12 seems to do the trick. If anyone else wants to try,
> the trick is to run the F16 part of preupgrade, then edit
> /boot/upgrade/ks.cfg (or /boot/update/ks.cfg, i forget which it is) and add
> a line:
> 
> repo --name=side --baseurl=http://www.happyassassin.net/extras/repo2/x86_64
> 
> then go ahead and reboot and do the preupgrade. That repo is on my personal
> server, it has grubby 8.12 in it. (I don't have an i686 version up, sorry).
> After the preupgrade completes, it should properly add the F17 kernel. I
> compared by doing it with two identical cloned VMs, making the edit in one
> case but not in the other. It worked with the updated grubby, it didn't work
> without.
> 
> The update needs one more karma point.

My two virtualmachines are actually in trouble after a normal Fedora 16 update (lol, yes). As soon as possible I will fix them and test your patch.
Comment 37 Germano Massullo 2012-06-02 06:25:33 EDT
(In reply to comment #35)
> So I tested, and 8.12 seems to do the trick. If anyone else wants to try,
> the trick is to run the F16 part of preupgrade, then edit
> /boot/upgrade/ks.cfg (or /boot/update/ks.cfg, i forget which it is) and add
> a line:
> 
> repo --name=side --baseurl=http://www.happyassassin.net/extras/repo2/x86_64


Have I to add it at the bottom of file?
Comment 38 Germano Massullo 2012-06-02 08:45:49 EDT
(In reply to comment #35)
> So I tested, and 8.12 seems to do the trick. If anyone else wants to try,
> the trick is to run the F16 part of preupgrade, then edit
> /boot/upgrade/ks.cfg (or /boot/update/ks.cfg, i forget which it is) and add
> a line:
> 
> repo --name=side --baseurl=http://www.happyassassin.net/extras/repo2/x86_64
> 
> then go ahead and reboot and do the preupgrade. That repo is on my personal
> server, it has grubby 8.12 in it. (I don't have an i686 version up, sorry).
> After the preupgrade completes, it should properly add the F17 kernel. I
> compared by doing it with two identical cloned VMs, making the edit in one
> case but not in the other. It worked with the updated grubby, it didn't work
> without.
> 
> The update needs one more karma point.

On my Fedora 16 64bit LXDE VirtualBOX virtual machine I did:
- yum update
- reboot
- preupgrade
- putted on bottom of file /boot/upgrade/ks.cfg  repo --name=side --baseurl=http://www.happyassassin.net/extras/repo2/x86_64
- preupgrade again
- reboot and let start anaconda to do upgrades
- rebooted

The final result is that I still have Grub 2 with old Fedora 16 kernels. Maybe something went wrong, dunno, I cannot vote -1 since I don't know if I correctly followed the procedure
Comment 39 Mads Kiilerich 2012-06-02 09:01:45 EDT
(In reply to comment #38)
> - preupgrade
> - putted on bottom of file /boot/upgrade/ks.cfg  repo --name=side
> --baseurl=http://www.happyassassin.net/extras/repo2/x86_64
> - preupgrade again

I guess that step created a new ks without your changes. Running preupgrade once should be enough.
Comment 40 Germano Massullo 2012-06-02 11:09:46 EDT
I completely erased old virtual machine and installed a new Fedora 16 64bit LXDE virtual machine, then I did:
- yum update
- reboot
- preupgrade
- putted on bottom of file /boot/upgrade/ks.cfg  repo --name=side --baseurl=http://www.happyassassin.net/extras/repo2/x86_64
- reboot and let start anaconda to do upgrades
- rebooted
It works. I voted on https://admin.fedoraproject.org/updates/grubby-8.12-1.fc17 to increase Karma
Comment 41 Kaare Fiedler Christiansen 2012-06-03 02:45:47 EDT
*** Bug 817289 has been marked as a duplicate of this bug. ***
Comment 42 akvasu@gmail.com 2012-06-03 06:58:27 EDT
Hi 

I've done the yum update, and actually already did preupgrade 2 times - Initally I had to manually edit the Grub command to enter the temporary upgrade kernel path. After I did that I got some dracut error saying no image found. I checked this and then used grub2 options to reboot the machine and it completed the preupgrade perfectly as per the upgrade logs. However I don't find any kernet installed - 

[root@localhost ~]# cd /boot/
[root@localhost boot]# ls
config-3.3.2-1.fc16.x86_64         initrd-plymouth.img
config-3.3.6-3.fc16.x86_64         lost+found
config-3.3.7-1.fc16.x86_64         memtest86+-4.20
efi                                System.map-3.3.2-1.fc16.x86_64
elf-memtest86+-4.20                System.map-3.3.6-3.fc16.x86_64
grub                               System.map-3.3.7-1.fc16.x86_64
grub2                              upgrade
initramfs-3.3.2-1.fc16.x86_64.img  vmlinuz-3.3.2-1.fc16.x86_64
initramfs-3.3.6-3.fc16.x86_64.img  vmlinuz-3.3.6-3.fc16.x86_64
initramfs-3.3.7-1.fc16.x86_64.img  vmlinuz-3.3.7-1.fc16.x86_64
[root@localhost boot]# 

Is there a different path for Kernel Install? I couldn't find any 17 kernel installed. I am going to try that option provided above, but in your cases I think the kernel did get installed? 

Thanks
Anup
Comment 43 Mads Kiilerich 2012-06-03 07:09:46 EDT
(In reply to comment #42)

'rpm -q kernel' only shows f16 kernels, and 'yum update' will not install kernel-3.3.7-1.fc17.x86_64?

That sounds like a different issue. Better file a new issue with a full description and attach your logs there - and paste a link here.
Comment 44 akvasu@gmail.com 2012-06-03 07:59:51 EDT
Hi 

I had to boot into the 3.3.7-1.x86_64 kernel and yum update didnt find any updates. yum distro-sync actually pointed out the packeges that were at higher versions and tried to remove them. 

[root@localhost boot]# rpm -q kernel 
kernel-3.3.2-1.fc16.x86_64
kernel-3.3.6-3.fc16.x86_64
kernel-3.3.7-1.fc16.x86_64
[root@localhost boot]# 

There are no other kernels, the 500 mb /boot is only at 20% usage. 

What other info can I collect? I will fine a new bug. I do have a solid state HDD - I think in F15/F16 there had been issues with the solid state devices. 

Thanks
Anup
Comment 45 Mads Kiilerich 2012-06-03 08:05:45 EDT
(In reply to comment #44)

Please attach the anaconda logs there - and show the yum commands and their output.
Comment 46 Adam Williamson 2012-06-03 18:14:17 EDT
akvasu: do you have the 17 updates repo enabled?
Comment 47 Sergio Monteiro Basto 2012-06-03 18:20:05 EDT
cat  upgrade.log | grep -i grub -C2
21:20:04 Upgrading python-batchhttp-1.1-4.fc17.noarch
21:20:05 Upgrading python-transaction-1.1.1-4.fc17.noarch
21:20:06 Upgrading grubby-8.11-1.fc17.x86_64
21:20:06 Upgrading libmount-2.21.2-1.fc17.x86_64
21:20:09 Upgrading xfsprogs-3.1.8-1.fc17.x86_64
--
22:41:45 Upgrading wireless-tools-devel-29-7.1.fc17.x86_64
22:41:46 Upgrading hpijs-3.12.4-2.fc17.x86_64
22:41:48 Upgrading grub2-2.0-0.25.beta4.fc17.x86_64
warning: /etc/default/grub created as /etc/default/grub.rpmnew
22:41:52 Upgrading lighttpd-fastcgi-1.4.30-1.fc17.x86_64
22:41:53 Upgrading avahi-ui-tools-0.6.30-7.fc17.x86_64
--
23:45:15 Upgrading libgcc-4.7.0-5.fc17.i686
23:45:16 Upgrading kernel-3.3.7-1.fc17.x86_64
grubby fatal error: unable to find a suitable template
23:45:24 Upgrading libstdc++-4.7.0-5.fc17.i686
23:45:29 Upgrading zlib-1.2.5-6.fc17.i686
Comment 48 Mads Kiilerich 2012-06-03 18:31:34 EDT
(In reply to comment #46)
> akvasu: do you have the 17 updates repo enabled?

He apparently filed Bug 827876.

(In reply to comment #47)
> cat  upgrade.log | grep -i grub -C2

Sergio, why are pasting that and what do you want to say?
Comment 49 Sergio Monteiro Basto 2012-06-03 18:49:13 EDT
(In reply to comment #48)
> (In reply to comment #46)
> > akvasu: do you have the 17 updates repo enabled?
> 
> He apparently filed Bug 827876.
> 
> (In reply to comment #47)
> > cat  upgrade.log | grep -i grub -C2
> 
> Sergio, why are pasting that and what do you want to say?

Anaconda logs , isn't upgrade.log and upgrade.log.syslog on /root ? 

I find out on upgrade.log  why preupgrade never install F17 kernel , because gives the error "grubby fatal error: unable to find a suitable template"

and using grubby-8.11-1.fc17.x86_64
Comment 50 Mads Kiilerich 2012-06-03 19:07:38 EDT
(In reply to comment #49)
> I find out on upgrade.log  why preupgrade never install F17 kernel , because
> gives the error "grubby fatal error: unable to find a suitable template"

That message is usually not relevant. It usually come from grubby failing when trying to update an irrelevant and unused bootloader. It might however also be a real problem that is fixed by https://admin.fedoraproject.org/updates/grubby-8.12-1.fc17 .
Comment 51 Hin-Tak Leung 2012-06-03 21:10:39 EDT
(In reply to comment #50)
> (In reply to comment #49)
> > I find out on upgrade.log  why preupgrade never install F17 kernel , because
> > gives the error "grubby fatal error: unable to find a suitable template"
> 
> That message is usually not relevant. It usually come from grubby failing
> when trying to update an irrelevant and unused bootloader. It might however
> also be a real problem that is fixed by
> https://admin.fedoraproject.org/updates/grubby-8.12-1.fc17 .

Yes, that message has been there for months - I think it was a left-over from the grub 1 to grub 2 switch in f15->f16 - i.e. if one is too lazy to remove grub1 bits from /boot - I am just not motivated to touch /boot (even for "cleaning up") unless it is a clear problem.
Comment 52 akvasu@gmail.com 2012-06-03 21:55:52 EDT
Hi 

I don't have the f17 repo installed, however I am on a F16 boot. The thing is I did preupgrade and I expected it to install these repos, booting back into f16 i think it shouldn't indicate the F17 repos. I've done the manual update via yum a couple of times in earlier releases (f14-f15) - thats when I used to manually add the repo. 

I can try adding the F17 repo and then retrying the preupgrade, considering that it is has been able to install a few of the f17 apps, I thought it was able to get the repo info correctly. 

Looks like I am stuck on F16 for now.... the DVD download will take time and i'll have to hunt for a DVD to try the DVD upgrade route
Comment 53 Kamil Páral 2012-06-04 06:54:13 EDT
The grubby update fixed the issue (tested i686 minimal install and preupgrade-cli).
Comment 54 akvasu@gmail.com 2012-06-04 12:04:23 EDT
Hi 

Will this be added to mainstream? Or should I manually update grubby and then try preupgrade ?

Thanks
Anup
Comment 55 Kamil Páral 2012-06-04 12:25:48 EDT
Anup, fixed grubby is now in Fedora 17 stable updates, no manual steps should be necessary. Everything should work out-of-the-box.
Comment 56 Sergio Monteiro Basto 2012-06-04 12:41:36 EDT
hi, 
no update for F16 ? 
and preupgrade from F15 to F16 ? I will not hit the same problem ?
Comment 57 akvasu@gmail.com 2012-06-04 13:00:23 EDT
Hi 

I still dont get the new Kernel installed.... Looks like I am still hitting #820351 

Thanks
Anup
Comment 58 Adam Williamson 2012-06-04 14:22:02 EDT
akvasu: I meant did the updated system, after preupgrade had completed, have the f17 repos enabled.
Comment 59 Adam Williamson 2012-06-04 14:37:31 EDT
8.12 is pushed stable now, so let's close this.
Comment 60 Adam Williamson 2012-06-04 14:38:15 EDT
sergio: things work differently in an f15->f16 preupgrade, this bug would not happen.
Comment 61 Mads Kiilerich 2012-06-05 07:04:18 EDT
(In reply to comment #27)
> So - when you're upgrading from 16 to 17, you get the good old pre-F16
> default behaviour back. You get "bootloader  --upgrade --location=none" . So
> in preupgrade, we're just telling anaconda to update the existing bootloader
> configuration, not to reinstall the bootloader.

That is still an issue. Leaving the system in a working state where a grub2-mkconfig cause boot time error messages is not a good idea. That require that we in all future should say "whenever you run grub2-mkconfig you have to run grub2-install first". That issue in f16 preupgrade is now tracked in Bug 827987.
Comment 62 mlatelcom 2012-07-02 05:02:11 EDT
I ran preupgrade-cli and all packages where downloaded. after rebooting I got a grub entry to start the installation process but once it starts booting suddenly drops me to the dracut shell with the no /dev/root msg. Booted into another OS on the same machine(another HDD)to check the files and all the installation files are under /var/cache/yum/ directory but there is nothing in /boot directory.Some directories are empty too; so it looks like the installation process haven't start yet.
Comment 63 Adam Williamson 2012-07-03 15:20:43 EDT
If you get a 'no /dev/root' error at that point, then you're hitting some other problem from what's discussed in this bug report. That error message in itself isn't very useful - it just means that anaconda wasn't able to initialize for some reason, the reason could be one of many, and always produces the same ultimate /dev/root error. One known outstanding bug which can trigger that error is https://bugzilla.redhat.com/show_bug.cgi?id=813973 , if you have a small /boot partition. You could check and see if you're hitting that. If not, file a new report. thanks!

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