This happened on two machines using legacy grub, bit not on a machine using grub2.

On a fourth machine with x86_64 arch and grub legacy the correct default was set.

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.

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.

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.

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)?

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*}
 fi}\
-%{expand:\
-/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --install %{KVERREL}%{?-v:.
-}\
 %{nil}


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.

Adding Kay too.  Maybe he has an idea.  I'm told this also messed up ARM somehow.

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.

This might fix it:
  http://koji.fedoraproject.org/koji/buildinfo?buildID=421077

It looks like things are working as expected again.
Thanks.

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.

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.

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

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.

This is still happening with systemd-204-4.fc20.i686.

Hmm, so /bin/kernel-install would have to distinguish between "--package kernel" and "--package kernel-PAE" or any other kernel variant.

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.)
Thanks.