Bug 1402990

Summary: setting grub2 default kernel not compatible with GRUB_DISABLE_SUBMENU=true option from /etc/default/grub
Product: Red Hat Enterprise Linux 7 Reporter: jas
Component: grub2Assignee: Peter Jones <pjones>
Status: CLOSED WONTFIX QA Contact: Release Test Team <release-test-team>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.2   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-01-15 07:29:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description jas 2016-12-08 20:20:58 UTC 
Description of problem:

I have several kernels installed on a student lab workstation.  I want students to only be able to access the kernel that I have configured as default.  However, I should be able to access the other kernels with an admin password.   From time to time, the last installed kernel is not the one I want them to access.  I use the option GRUB_DISABLE_SUBMENU=true from /etc/default/grub to make this happen.  I then configure the default boot kernel with either grubby --set-kernel (preferred since I specify only the path to the kernel) or grub2-set-default (totally unintuitive since I have to use the menu name that 10_linux generated).  When I boot the system, the main menu includes one kernel labelled "CentOS Linux" but without the version number. This kernel **should** be the default kernel that I've set, but it is not.  I'm pretty sure this is because the kernel is labelled "CentOS Linux" by grub, and not by it's longer name: 
CentOS Linux (3.10.0-327.36.2.el7.x86_64) 7 (Core)
.. so it doesn't match the saved_entry name in grubenv.

I'd really rather avoid having to custom build the whole menu by myself when there's an option built in to do exactly what I want.
Comment 3 RHEL Program Management 2021-01-15 07:29:07 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.