Bug 7631 - Install or upgrade leaves root ext2 partition trashed
Install or upgrade leaves root ext2 partition trashed
Product: Red Hat Linux
Classification: Retired
Component: installer (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Brock Organ
Depends On:
  Show dependency treegraph
Reported: 1999-12-06 10:56 EST by redhat-bugzilla
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-07-13 16:44:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description redhat-bugzilla 1999-12-06 10:56:03 EST
Twice, when installing 6.1 on a machine with a 34GB IBM Deskstar
(IBM-DPTA-373420), the root partition has been left dirty after the
install. Upon booting the first time after each install, I have to
manually run e2fsck, and each time it fills /lost+found.

e2fsck mentions this:
	Filesystem contains large files, but lacks LARGE_FILE flag in

In one case, I followed the regular installation procedure. At my second
attempt, I remounted / (/dev/hda3) and /boot (/dev/hda1) read-only before
allowing the normal reboot.

The drive is connected to the IDE controller on an Intel SE440-BX2

I've not run badblocks on the drive, and am attempting that now.
(It's going to take a while.)
Comment 1 redhat-bugzilla 1999-12-06 14:44:59 EST
I've done some more experimentation, and determined that the errors occur
when the filesystem is of a certain size. I've tested at 15GB, 25GB, and
at 33GB. The installation succeeds without trouble at 15GB and 25GB, but
consistently fails at 33GB.

I can't help but notice that all of the ext2 filesystem parameters when making
a 33GB partition are very close to Big Round Numbers, like 253 and 16384.

Badblocks found no trouble. dmesg has also reported no trouble from hda, or
from the ide controller.
Comment 2 redhat-bugzilla 1999-12-13 08:49:59 EST
My compromise has been to use less-than all of the space, settling on a 28g
root partition in this case. (I like having a large contiguous pool of

This may be an unrelated issue, but in regular use of that partition, I'm
getting ext2 fs errors on directories:

EXT2-fs error (device ide0(3,4)): ext2_readdir: bad entry in directory #3556554:
rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0

where 3556554 is an inode. I see the error on many ~50 directories (distinct
inodes, of course) that were created at about the same time using the standard
kernel included with RH6.1.
Comment 3 Jay Turner 2000-02-24 09:54:59 EST
Couple of things that I have noticed in digging up information about this
drive.  One is that there is a jumper setting which will clip the capacity of
the drive to just below 33G, so that might be one thing which is happening.  The
other thing is that the interface on this drive appears to be DMA66.  Are you
plugging this into a DMA66 controller?  There could be strange things happening
as a result of this.  We do not have a 34G IDE drive in the test lab, so I
really cannot comment on what is happening here.  I have not been able to
replicate this problem with any of the drives we have in the lab (of course,
none are > 18G!)
Comment 4 redhat-bugzilla 2000-02-24 11:40:59 EST
The SE440BX2 motherboard has only a UDMA/33 IDE interface, and this drive
is connected to that motherboard.

I presume that RH >=6.1 works fine on multi-drive disk arrays that are
larger than 34GB, so it would appear that it's either (a) a problem
that occurs somewhere in the hda block-device layer or below, or (b)
a problem that appears in every large block device, but for which
md provides a workaround.
Comment 5 Jay Turner 2000-04-21 10:52:59 EDT
Have you tried release 6.2??  Would like to know whether you are still having
issues with the 34G drive.
Comment 6 Michael Fulbright 2000-06-12 14:04:02 EDT
Please verfiy against latest release.
Comment 7 redhat-bugzilla 2000-06-12 15:04:02 EDT
I'm afraid I don't have a spare system to try this with, and I can't afford
the workstation downtime to test it. Sorry.

Comment 8 redhat-bugzilla 2000-06-22 13:30:22 EDT
Using the upgrade option on a Red Hat 6.2 installation CD, I changed
this system from 6.1 to 6.2. Again, the installer/upgrader did *not*
cleanly umount either of the two ext2 filesystems.

After running e2fsck -y manually, the lost+found directories for both
filesystems were full of trash -- lots of block and character special
(device) files, whole directories, &c. Remarkably, the system booted 
okay, and much of it still works.
Comment 9 redhat-bugzilla 2000-06-22 13:32:07 EDT
Note: I said that the system booted okay, but only after e2fsck whined and
moaned, and I had run e2fsck manually on each of the two filesystems.
Comment 10 redhat-bugzilla 2000-06-26 07:59:51 EDT
Note that bug 12836 seems to be another installer-induced problem,
although both of them could probably be caused by a failure to
umount the target root before rebooting.
Comment 11 redhat-bugzilla 2000-06-26 08:38:59 EDT
jturner mentioned the settings in the computer; I'm not really sure about
the DMA66 capabilities of this motherboard. For reference, the settings
in the BIOS are these:
	Primary IDE Master: IBM-DPTA-373420-(PM)
	Type: Auto
	Maximum Capacity: 34220 MB (auto detected)
	Multi-Sector Transfers: 16 Sectors (auto)
	LBA Mode Control: Enabled (auto)
	Transfer Mode: FPIO 4 / DMA 2 (auto)
	Ultra DMA: Mode 2 (auto)

The BIOS version is 4S3EB2X0.86A.0022.P15
It's a PIII/500, with 512KB cache, 256MB RAM
Comment 12 redhat-bugzilla 2000-06-27 17:20:59 EDT
I did another installation, using RH 6.2 and the latest installer
image from the updates site -- updated boot 20000407, for bug
fix advisory id RHBA-2000:015-01.

This time, I didn't make the smaller partition; instead, I just made
a swap partition (256MB), a /boot partition (50MB), and the rest 
was root.

And, in fact, this install worked okay; upon rebooting, / and /boot
were both clean.

My feeling is that this bug may still be there, but things have changed
enough so that I'm just not tickling it any more. None of the updates
listed for the two updated installer floppies seem to mention things
related to the problem I was seeing.
Comment 13 Michael Fulbright 2000-07-13 16:44:27 EDT
Going to close this because it seems to not be a problem any longer but please
feel free to reopen if it
Comment 14 Brent Fox 2002-11-07 10:51:45 EST
*** Bug 77436 has been marked as a duplicate of this bug. ***

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