From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Description of problem: The /etc/rc.d/rc.sysinit script fails rather badly if the /dev/null file has become corrupted. rc.sysinit fails right at the top when it tried to mount /proc. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.rm /dev/null 2.touch /dev/null 3.reboot Actual Results: The system fails to boot. You get very weird error messages that don't lead to easy problem resolution... at least not for me... The error messages read: mounting proc: file system dup2:bad file descripter Configuring kernel parameters: dup2:bad file descripter Setting Clock: dup2:bad file descripter Ect... The script ends up dropping you into the maintenance shell after it fails to fsck the file system. I initially thought I had a corrupt file system because of the error messages. I found some references through Google about people rebuilding their system because of this problem. Expected Results: The system should *always* boot. Additional info: Patch to rc.sysinit <<<< start patch >>>> 50a51,60 > # Test for a valid /dev/null, remake the file if it's been corrupted. > if [ ! -c /dev/null ]; then > echo "The /dev/null file has been corrupted... Fixing..." > mount -n -o remount rw / > rm -f /dev/null > mknod /dev/null c 1 3 > chmod 0666 /dev/null > umount / > fi > <<<< end patch >>>> The patched rc.sysinit will test the /dev/null file and replace it with a new charactor special device when required. This patch assumes that /dev resides under the root filesystem. It will not cause any (more) problems if /dev/null gets corrupted and the /dev dir resides in another partition. You *might* want to put this patch into the shutdown script instead of rc.sysinit. It might be cleaner...
I am having exactly the same failure on an Compaq iPAQ Celeron 800 and an Compaq Prolian ML370 Server. Thank you for the tipp :) Christian
Yes, I am having similar issues as well, does anyone have a solution to why /dev/null is corrupting or just this workaround?
It's just a workaround for an annoying little bug with a really screwy failure mode. In my case, shell scripts running as root caused the corruption. I had written a script to check the process table and start (or restart) a large number of *really* junky vendor programs. The STDOUT and STDERROR for the programs were redirected to /dev/null. I suspect the vendors programs behaved badly and somehow overwrote /dev/null through the shell redirect. I was seeing /dev/null changed to a normal file instead of a special file. I only had the problem occur a few times. I also had a script running from cron, which checked /dev/null every hour, fixed it as necessary, and emailed me an alert. I was never able to figure out the actual mechanism causing the problem. The issue went away when I forced the vendor to rewrite their programs to use a common user account instead of root. Steve Daggett
Closing bugs on older, no longer supported, releases. Apologies for any lack of response. This should be fixed in current releases with the move to udev, with /dev being recreated on each boot.