Bug 1154430 - grub2 boots wrong kernel after grub2-mkconfig, grub2-editenv / grub2-set-default has wrong entry
Summary: grub2 boots wrong kernel after grub2-mkconfig, grub2-editenv / grub2-set-defa...
Keywords:
Status: CLOSED DUPLICATE of bug 1124074
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: grub2
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Peter Jones
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-19 16:35 UTC by Nicholas, Crawford
Modified: 2015-06-19 18:01 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-15 16:37:34 UTC
Target Upstream Version:


Attachments (Terms of Use)
Workaround patch (733 bytes, patch)
2014-12-08 23:57 UTC, Nathan G. Grennan
no flags Details | Diff

Description Nicholas, Crawford 2014-10-19 16:35:45 UTC
Description of problem:
On systems with patched kernels running grub2-mkconfig causes the system to boot the base kernel.  i.e. instead of 3.10.0-128.8.1.el7 it boots 3.10.0-128.el7.

Version-Release number of selected component (if applicable):
grub2-tools-2.02-0.2.10.el7

How reproducible:
100%

Steps to Reproduce:
1. RHEL 7 system patched with a non-base kernel (8.1.el7)
2. run grub2-mkconfig -o /boot/grub2/grub.cfg
3. as config is built look at order
4. reboot
5. watch base kernel boot

Actual results:
boots older base kernel, ignores grub2-editenv list/grub2-set-default.

Expected results:
boots patched kernel, or selected kernel in grub2-editenv list/grub2-set-default.

Additional info:
It appears that RHEL7 is using the wrong selector for setting the grub2-set-default.  It could potentially be "working as intended" and then this bug would be related to the %post script in kernel patches.  Though documentation all specifies menuentry as the selector.

[root@localhost ~]# grub2-editenv list
saved_entry=Red Hat Enterprise Linux Server (3.10.0-123.8.1.el7.x86_64) 7.0 (Maipo)
[root@localhost ~]# uname -r
3.10.0-123.el7.x86_64

The selection appears to be based on the text following $menuentry_id_option in grub.cfg, listed by the following.

[root@localhost ~]# grep "^menuentry" /boot/grub2/grub.cfg | cut -d "'" -f4
gnulinux-3.10.0-123.el7.x86_64-advanced-3de2aca4-9fdd-42fd-9480-420d59b19a76
gnulinux-3.10.0-123.8.1.el7.x86_64-advanced-3de2aca4-9fdd-42fd-9480-420d59b19a76
gnulinux-0-rescue-b4d7fa385e6d4bd08a804d2082ef14d4-advanced-3de2aca4-9fdd-42fd-9480-420d59b19a76

in this case I run the following to preserve the patched kernel to survive grub2-mkconfig

[root@localhost ~]# grub2-set-default gnulinux-3.10.0-123.8.1.el7.x86_64-advanced-3de2aca4-9fdd-42fd-9480-420d59b19a76
[root@localhost ~]# grub2-editenv list
saved_entry=gnulinux-3.10.0-123.8.1.el7.x86_64-advanced-3de2aca4-9fdd-42fd-9480-420d59b19a76
[root@localhost ~]# grub2-mkconfig -o /boot/grub2/grub.cfg 
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.10.0-123.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-123.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-123.8.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-123.8.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-b4d7fa385e6d4bd08a804d2082ef14d4
Found initrd image: /boot/initramfs-0-rescue-b4d7fa385e6d4bd08a804d2082ef14d4.img

now after a reboot I get the following.

[root@localhost ~]# grub2-editenv list
saved_entry=gnulinux-3.10.0-123.8.1.el7.x86_64-advanced-3de2aca4-9fdd-42fd-9480-420d59b19a76
[root@localhost ~]# uname -r
3.10.0-123.8.1.el7.x86_64

Comment 1 Nicholas, Crawford 2014-10-19 16:37:05 UTC
potentially related https://bugzilla.redhat.com/show_bug.cgi?id=1124074

Comment 3 Nathan G. Grennan 2014-12-08 23:57:36 UTC
Created attachment 966037 [details]
Workaround patch

The bug is either the sort command, or a misuse of the sort command in grub-mkconfig_lib. The issue revolves around .x86_64 being at the end of the strings.

Comment 4 Peter Jones 2014-12-15 16:37:34 UTC

*** This bug has been marked as a duplicate of bug 1124074 ***


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