Bug 64963 - xfs died when disk was full at boot
Summary: xfs died when disk was full at boot
Status: CLOSED DUPLICATE of bug 57745
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 7.3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2002-05-15 03:56 UTC by teuben
Modified: 2007-04-18 16:42 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-05-18 02:23:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description teuben 2002-05-15 03:56:59 UTC
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
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:

Steps to Reproduce:
1.dd if=/dev/zero of=/tmp/bigzero (as non-root)

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

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.

Comment 1 Mike A. Harris 2002-05-18 02:12:27 UTC
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@xfree86.org and xpert@xfree86.org

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.

Comment 2 Mike A. Harris 2002-05-18 02:20:40 UTC
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)

Comment 3 Mike A. Harris 2002-05-21 16:51:08 UTC

*** This bug has been marked as a duplicate of 57745 ***

Note You need to log in before you can comment on or make changes to this bug.