Bug 64963

Summary:	xfs died when disk was full at boot
Product:	[Retired] Red Hat Linux	Reporter:	teuben
Component:	XFree86	Assignee:	Mike A. Harris <mharris>
Status:	CLOSED DUPLICATE	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.3
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-05-18 02:23:08 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 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
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.

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 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.

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 ***