From Bugzilla Helper: User-Agent: Mozilla/5.7 [en] (Win98; U) Description of problem: i had a full root (/), which i didn't know about. Rebooted the system. started X. Didn't run. Neither as root... Saw / was full, cleaned up the disk, but again, startx didn;'t work. Did indeed tell me something useful that font on unix/:7100 could not be initialized. Indeed, xfs was not running. I restarted it. Then X ran fine again. xfs had apparently died because of a full disk, but the boot.log file told me xfs (and for that matter all init.d things) had started fine. That's ok, that is what i expected, since root can always use above the 100% of the disk space, since it can write into the extra free blocks (i did confirm my disks had plenty of those, this was an 8GB disk and i had not changed the default allocation after the install a few days ago). I still don't understand how xfs claimed it started, but yet, didn't run, and caused X not to start. I imagine for a non-expert this is a pretty hard one to figure out. In general a full / (or unwriteable /tmp) often causes a lot of weird error messages in linux. This is not redhat specific. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.dd if=/dev/zero of=/tmp/bigzero (as non-root) 2.reboot 3.startx Actual Results: i actually did try this sequence. And dd is nicely able to produce files > 2GB, which most other programs (e.g. sum) cannot process. Additional info: I also believe that the screen output , as the system boots, with the nice green "OK" in the right column, should NOT be overwritten by the first console "login:" prompt. In e.g. slackware this doesn't happen. It prevents the user from seeing what the last end of the boot log (/var/log/boot.log and /var/log/dmesg are not the same as what is on the screen after all), and in particular any failing modules may have been missed this way. It would be wonderful if this could be fixed at the same time.
This problem has been reported many times to us, however it isn't a Red Hat specific problem really. It is something that I think should be addressed by XFree86.org upstream in their own codebase, and picked up by us in a future release. Please report this issue to XFree86.org via xfree86 and xpert It's something I can consider looking into, however it is fairly low priority, so it stands a much higher chance of getting fixed, if reported to the XFree86 team and fixed there.
Oh, by the way... I agree with your idea of not overwriting the [OK] status, etc.. and I configure my inittab to not clear the screen by adding --noclear to mingetty on tty1. So, I would love the distro to support this by default personally. I've asked internally if we can do that however, and was told a flat out "no way", so unless 1000's of users petition us and make us out to be evil on slashdot for not doing this, it probably wont change. ;o) Lemme know the petition URL if you find one/start one. ;o)
*** This bug has been marked as a duplicate of 57745 ***