Bug 7631
| Summary: | Install or upgrade leaves root ext2 partition trashed | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | redhat-bugzilla |
| Component: | installer | Assignee: | Brock Organ <borgan> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.2 | CC: | msf |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2000-07-13 20:44:29 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
redhat-bugzilla
1999-12-06 15:56:03 UTC
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 space.) 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) 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 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. Going to close this because it seems to not be a problem any longer but please feel free to reopen if it resurfaces. *** Bug 77436 has been marked as a duplicate of this bug. *** |