Description of problem: On a kdump boot on ia64 we see the following error: Creating initial device nodes mknod: /tmp/initrd.Ye4781/dev/efirtc: No such file or directory This is caused by the bit of code in mkdumprd that creates the "init" for the initrd image. I am attaching a patch which resolves this issue. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 298952 [details] patch to create /dev/efirtc in the right place
easy, obvious fix, with no need for extra testing, requesting exception for 5.2.
cleared exceptio, moving to 5.3, since deadline passeed
Release note material: """ On IA64 systems, there exists a bug in which, during the boot up of the kdump kernel, this error will scroll accross the screen: mknod: /tmp/initrd.<numbers>/dev/efirtc: No such file or directory This error is the result of a malformed request to create the efirtc device node in the wrong path. However, the device node in question is also created statically in the initramfs when the kdump service is started. As such this secondary, run time creation is redundant, and the resultant failure is harmelss. This cosmetic error will be corrected in our next release """
adding to RHEL5.2 release notes updates: <quote> (ia64) When the kdump kernel is booted, the following error will appear in the boot log: mknod: /tmp/initrd.[numbers]/dev/efirtc: No such file or directory This error results from a malformed request to create the efirtc in an incorrect path. However, the device path in question is also created statically in the initramfs when the kdump service is started. As such, the run-time creation of the device node is redundant, harmless, and should not affect the performance of kdump. </quote> please advise if any further revisions are required. thanks!
This RFE has been reviewed during the RHEL RFE review with Red Hat product management. This request has been *tentatively* approved for inclusion in the next update. This decision is not final and still pends further technical review and scoping by Red Hat development engineering.
fixed properly in -22.el5
Tracking this bug for the Red Hat Enterprise Linux 5.3 Release Notes. This Release Note is currently located in the Known Issues section.
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team.
I'm sorry, I don't know how I missed that. There are several devices that get overwritten in this way. and the fix is obvious. I'm respinning now.
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-0105.html