Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 964023 - Wrong default kernel
Summary: Wrong default kernel
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-05-17 05:20 UTC by Bruno Wolff III
Modified: 2013-08-28 18:44 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-08-28 18:44:39 UTC
Type: Bug

Attachments (Terms of Use)

Description Bruno Wolff III 2013-05-17 05:20:00 UTC
Description of problem:
After upgrading to kernel-PAE-3.10.0-0.rc1.git5.2.fc20.i686 the grub (legacy) config was updated such that the previous kernel was still the default, despite /etc/sysconfig/kernel containing UPDATEDEFAULT=yes.

Things worked as expected until very recently. (My last reboot was a couple of days ago.)

Comment 1 Bruno Wolff III 2013-05-17 05:23:51 UTC
This happened on two machines using legacy grub, bit not on a machine using grub2.

Comment 2 Bruno Wolff III 2013-05-17 05:52:12 UTC
On a fourth machine with x86_64 arch and grub legacy the correct default was set.

Comment 3 Bruno Wolff III 2013-05-17 13:24:34 UTC
One other note, is that the grub 2 machine above is i686, but not PAE. So the two machines that had the problem were using PAE kernels, and the two that didn't weren't.

Comment 4 Josh Boyer 2013-05-17 14:48:20 UTC
We switched to calling kernel-install in the spec instead of new-kernel-pkg directly.  Perhaps there is something odd there.  I'll assign it to systemd for now.

Comment 5 Bruno Wolff III 2013-05-18 16:20:55 UTC
I see that kernel-install uses --package kernel as an argument to new-kernel-pkg, where as the old kernel-PAE scripts used to use --package kernel-PAE. Since the machines where I am seeing the problem are exactly the ones using PAE kernels, I suspect this is related.

I saw the same machines have and not have the problem when I updated to 3.10.0-0.rc1.git6.2.fc20.i686.PAE this morning.

Comment 6 Bruno Wolff III 2013-05-18 16:39:59 UTC
It looks like the --package parameter is only used to check if this type of kernel is the default as part of the decision of whether to make this the new default kernel. Maybe new-kernel-pkg could extract this information from the kernel version since the infomation is there. I am not sure this would work for smp kernels if those builds are still in any way supported.

I am not sure how kernel-install is expected to handle this kind of thing in other distros. If it isn't, then maybe this needs to be a bug against grubby (for a change to new-kernel-pkg)?

Comment 7 Josh Boyer 2013-05-20 13:08:51 UTC
This is possibly related to this hunk of the kernel.spec change:

@@ -2046,9 +2044,6 @@ if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&\
    [ -f /etc/sysconfig/kernel ]; then\
   /bin/sed -r -i -e 's/^DEFAULTKERNEL=%{-r*}$/DEFAULTKERNEL=kernel%{?-v:-%{-v*}
-/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --install %{KVERREL}%{?-v:.

where we removed a call to new-kernel-pkg with the variant.  I would guess something similar is still needed with kernel-install, but I'm not sure exactly what the invocation should be.

Comment 8 Josh Boyer 2013-05-21 23:12:19 UTC
Adding Kay too.  Maybe he has an idea.  I'm told this also messed up ARM somehow.

Comment 9 Brendan Conoboy 2013-05-21 23:22:27 UTC
This might be related to BZ 965897 in which /sbin/new-kernel-pkg is called with --install instead of --update as happened in 3.9 and earlier kernels.

Comment 10 Kay Sievers 2013-05-22 22:01:25 UTC
This might fix it:

Comment 11 Bruno Wolff III 2013-05-26 17:29:03 UTC
It looks like things are working as expected again.

Comment 12 Bruno Wolff III 2013-05-26 17:59:57 UTC
It turns out I didn't look close enough. I just looked at the default setting in my grub.conf file. But it turns out the new kernel entry didn't get added. I'll look around some more to see if I am seeing this in multiple places or if a reinstall of the latest kernel fixes things.

Comment 13 Bruno Wolff III 2013-05-26 18:20:57 UTC
The problem might be due to a bad kernel. That particular particular machine is using the rawhide nodebug kernels on f19 and I think there may be an issue with what is currently the latest nodebug kernel. My rawhide machine will be finished updating in a little bit and I can see if that one is working OK.

Comment 14 Bruno Wolff III 2013-05-26 18:51:27 UTC
This is the grubby command that gets run:
/sbin/grubby --grub -c /boot/grub/grub.conf --update-kernel=/boot/vmlinuz-3.10.0-0.rc2.git1.2.fc20.i686.PAE --initrd /boot/initramfs-3.10.0-0.rc2.git1.2.fc20.i686.PAE.img --args= LANG=en_US.UTF-8

Comment 15 Bruno Wolff III 2013-05-26 19:37:32 UTC
The fix for bug 965897 seems to have made things worse, so that this bug (PAE kernel default) is hidden and I can't tell whether or not it is fixed.

Comment 16 Bruno Wolff III 2013-05-31 18:46:08 UTC
This is still happening with systemd-204-4.fc20.i686.

Comment 17 Harald Hoyer 2013-06-03 15:48:57 UTC
Hmm, so /bin/kernel-install would have to distinguish between "--package kernel" and "--package kernel-PAE" or any other kernel variant.

Comment 18 Bruno Wolff III 2013-08-28 18:44:39 UTC
The default kernel is being set correctly in rawhide. Running rawhide-nodebug kernels in F19 still exhibits in the problem, but that's not a supported configuration. So I think it is safe to close this now. (I don't have any branched systems right now.)

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