Red Hat Bugzilla – Bug 7631
Install or upgrade leaves root ext2 partition trashed
Last modified: 2008-05-01 11:37:53 EDT
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.)
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.
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.
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!)
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.
Have you tried release 6.2?? Would like to know whether you are still having
issues with the 34G drive.
Please verfiy against latest release.
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.
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.
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.
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.
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)
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
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
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.
Going to close this because it seems to not be a problem any longer but please
feel free to reopen if it
*** Bug 77436 has been marked as a duplicate of this bug. ***