Bug 51516
| Summary: | install fails | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Chris Ricker <chris.ricker> |
| Component: | anaconda | Assignee: | Matt Wilson <msw> |
| Status: | CLOSED WORKSFORME | QA Contact: | Brock Organ <borgan> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 7.3 | ||
| 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: | 2001-08-15 19:18:42 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
Chris Ricker
2001-08-11 14:59:05 UTC
I wonder why the installer failed to transfer the stage2 image the first time. I think it failed the first time because it was creating /dev and such inside of /boot (25 meg slice) that mistakenly got mounted as /. I think the real question is why it failed to mkfs the real "/" slice, since all the other breakage stemmed from that.... can you reproduce readily? In text mode too? It's no longer reproducible, because I mkfs'ed (ext3) the / partition by hand. When I did that, the same install session would still fail but rebooting and then starting the install over worked. Just guessing, but I think the problem may have been caused by the initial partition table being extremely complex. That machine's a total test bed, so it had darn near every conceivable PC operating system on it.... You may have to close this as a heisenbug, but there's something fragile in the logic anaconda uses to determine which partitions to mkfs and such. This defect is considered SHOULD-FIX for Fairfax. during your partitioning run, did you ever have an allocation fail? That is, when adding partitions did the message, "Could not allocate requested partitions: (some reason)"? Nope I can't reproduce this failure. I wish I could reproduce this, but since the test case is gone it's going to be impossible to fix. The initial filesystem layout, before I booted the installer, was something like <sorry about that, this mozilla build is borked> Damn, you can't hit return in the text box in this mozilla build, or it submits the page, so just deal with the really long lines.... At any rate, hda1 was NTFS, hda2 was Solaris/x86's weird partition containing UFS slices, and then logical partitions were ext2, ext3, reiser, FreeBSD partition containing UFS slices, and then a BeFS. I don't know that that had any thing to do with it, but perhaps all the complex partitioning confused it? |