Bug 1367792

Are you sure this was done with grubby-8.28-18.el7.s390x , and that wasn't merely the version installed after the rpm update was finished?  To me this looks like something I'd expect -17.el7 to do, but -18.el7 should have fixed.

That is, if you upgrade grubby in its own transaction before updating anything else, does the error still occur?

Reproduced with grubby-8.28-18.el7.s390x (compose RHEL-7.3-20160901.1):

[root@rtt7 ~]# zipl
Using config file '/etc/zipl.conf'
Building bootmap in '/boot'
Building menu 'zipl-automatic-menu'
Adding #1: IPL section 'linux' (default)
Adding #2: IPL section 'linux-0-rescue-28b817321aa14230b612ddd82169abe9'
Preparing boot device: dasda (3627).
Done.
[root@rtt7 ~]# echo "MAKEDEBUG=yes" >> /etc/sysconfig/kernel
[root@rtt7 ~]# yum install ./kernel-3.10.0-501.el7.s390x.rpm
[root@rtt7 ~]# zipl
Using config file '/etc/zipl.conf'
Building bootmap in '/boot'
Building menu 'zipl-automatic-menu'
Adding #1: IPL section '3.10.0-501.el7.s390x'
Adding #2: IPL section '3.10.0-501.el7.s390x_with_debugging' (default)
Adding #3: IPL section 'linux'
Adding #4: IPL section 'linux-0-rescue-28b817321aa14230b612ddd82169abe9'
Preparing boot device: dasda (3627).
Done.
[root@rtt7 ~]# rpm -q grubby
grubby-8.28-18.el7.s390x
[root@rtt7 ~]#

A note - to reproduce it, it is necessary to add MAKEDEBUG=yes to /etc/sysconfig/kernel. This option is not there by default, so without this change this bug problem won't appear.

(In reply to Jan Stodola from comment #3)
> A note - to reproduce it, it is necessary to add MAKEDEBUG=yes to
> /etc/sysconfig/kernel. This option is not there by default, so without this
> change this bug problem won't appear.

Based on this information -- which indicates to me that default behavior works fine -- this is not a blocker, so I'm deferring this to 7.4 planning.

Clearing pjones' needinfo request as well since jstodola tested it with -18 version.

BTW, it's not only on s390x with zipl, but also on x86_64, see bug 1285601#c5.

I have this issue with x86_64 and grub2 since upgrade to RHEL 7.3.

The /boot/grub2/grub.cfg entries are now in correct order (first entry: normal boot, second entry: with debugging, RHEL 7.2 had this in reverse) but grub2-editenv list show saved_entry with `... with debugging`.

(In reply to Thomas Mueller from comment #6)
> I have this issue with x86_64 and grub2 since upgrade to RHEL 7.3.
> 
> The /boot/grub2/grub.cfg entries are now in correct order (first entry:
> normal boot, second entry: with debugging, RHEL 7.2 had this in reverse) but
> grub2-editenv list show saved_entry with `... with debugging`.

/etc/syconfig/kernel has MAKEDEBUG=yes altough i never added this. interestingly 

rm /etc/sysconfig/kernel
rpm --erase --nodeps grubby
yum install grubby

does not restore the file. It seems it is added somewhere while install?

The same happens on x86_64 with GRUB.

New kernels default to debug when MAKEDEBUG=yes which in turn got installed with some update but did not get reverted.

The workaround is to remove MAKEDEBUG=yes from /etc/sysconfig/kernel and set correct default manually. Next kernel update will not break it unless MAKEDEBUG=yes appears magically again.

Please fix new-kernel-pkg not to default to debug.

More info:
Documentation states:
'MAKEDEBUG specifies if new-kernel-pkg should create non-default "debug" entries for new kernels.'
So they should be non-default by design, not default. This is clearly a nasty bug.

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.