Red Hat Bugzilla – Bug 426992
kernel-debug and kernel packages use the same label in zipl.conf
Last modified: 2011-01-24 17:27:22 EST
Description of problem:
Because of 15 bytes limit with labels in zipl, after installed kernel-debug
package, it has the same label as normal kernel package. The following error
message occurs in postinstall script,
/sbin/new-kernel-pkg --package kernel-debug --mkinitrd --depmod --install
2.6.18-53.1.4.el5debug || exit $?
Error: Config file '/etc/zipl.conf': Line 8: section name '2.6.18-53.1.4.e'
Version-Release number of selected component (if applicable):
kernel & kernel-debug: 2.6.18-53.1.4.el5
Steps to Reproduce:
Install kernel-2.6.18-53.1.4, and then kernel-debug. Both of them have the same
can you truncate the name by removing "."?
Sure, I can. However, the point is that customers will be confused by this error
message, and if he/she has not fixed this error by hand, he/she is likely to
boot to a wrong kernel instead of kernel-debug. In addition, I have not found
any mention of the solution to this problem in neither RHEL5.1 official
documents nor Kbase so far.
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Hello Red Hat,
as discuss on the Monday call with Brock and John, this issue could have impact
on customers using RHN to update their kernel to avoid security risks, if the
kernels differ in the 16th char and the rest are the same.
We suggest to consider it again for RHEL 5.3 and discussion in Wednesday call.
Btw. I don't think that the problem is "zipl", because after manually making the
label longer, and running "zipl" again it works.
I think the post-scripts from the rpm package kernel* call /sbin/new-kernel-pkg
and this script calls grubby, which is a binary where probably (since it is a
binary I was not sure how is coded) the labels are striped down to 15 chars.
Could you check how grubby is implemented and if there is such statement to
strip down the labels to 15chars?
(In reply to comment #6)
> Btw. I don't think that the problem is "zipl", because after manually making the
> label longer, and running "zipl" again it works.
> I think the post-scripts from the rpm package kernel* call /sbin/new-kernel-pkg
> and this script calls grubby, which is a binary where probably (since it is a
> binary I was not sure how is coded) the labels are striped down to 15 chars.
> Could you check how grubby is implemented and if there is such statement to
> strip down the labels to 15chars?
We can certainly make the limit bigger in grubby if we can find out what a reasonable limit /is/ . Phil, how many characters will zipl actually accept for a boot entry label?
There is currently no limitation for the length of boot entry labels, so it can be extended to any length we seem fit. Personally i don't think we should ever see any boot label being larger than 256 bytes, so that would be a good upper limit.
Read ya, Phil
Should be fixed in mkinitrd-220.127.116.11-31 .
... Or at least it should be, if I can get the right acks on it.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.