Bug 426992
Summary: | kernel-debug and kernel packages use the same label in zipl.conf | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Qian Cai <qcai> |
Component: | mkinitrd | Assignee: | Peter Jones <pjones> |
Status: | CLOSED ERRATA | QA Contact: | Alexander Todorov <atodorov> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 5.1.z | CC: | anton, atodorov, borgan, ddumas, dhoward, dzickus, jjarvis, pknirsch, syeghiay, tao |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | s390x | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-01-20 22:12:14 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Qian Cai
2007-12-29 15:44:28 UTC
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. Thank you, Gonzalo Muelas. 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? Thanks! (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. Thanks, Read ya, Phil Should be fixed in mkinitrd-6.1.19.6-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. http://rhn.redhat.com/errata/RHBA-2009-0237.html |