Bug 51516 - install fails
install fails
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.3
i386 Linux
high Severity high
: ---
: ---
Assigned To: Matt Wilson
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-11 10:59 EDT by Chris Ricker
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-08-15 15:18:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Ricker 2001-08-11 10:59:05 EDT
I have a test box that I tried to install beta3 on.  I told the installer
(GUI) to wipe the whole thing and set up two ext3 filesystems:

/boot (hda1 25 megs)
swap  (hda2 256 megs)
/     (hda3 rest)

(it picked the partition numbers and primary versus logical, I didn't).  It
mkfs'ed /tmp/hda1 only.

Install proceeded as far as the transfer image stage, when it reported

"An error occured transferring the install image to yoru hard drive.  You
are probably out of disk space."

No error messages appear on any of the VCs, and the filesystems appear to
have been created.  Initially, none of the filesystems were mounted by the
installer.

When I hit okay, and tried again, /boot (/tmp/hda1) got mounted as
/mnt/sysimage and so the same error occurred.

What the installer should do is mount /tmp/hda3 as /mnt/sysimage and
/tmp/hda1 as /mnt/sysimage/boot.  When I try doing that manually, /tmp/hda3
won't mount.

If I then manually mke2fs -j /tmp/hda3, it will mount.

If I then tell the installer to proceed, it re-mkfs'es /tmp/hda1 only, and
then mounts it on /mnt/sysimage on top of /tmp/hda3.

Something is seriously borked here.  The installer is apparently confusing
/ and /boot?
Comment 1 Matt Wilson 2001-08-11 14:20:07 EDT
I wonder why the installer failed to transfer the stage2 image the first time.
Comment 2 Chris Ricker 2001-08-11 14:23:51 EDT
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....
Comment 3 Matt Wilson 2001-08-11 14:35:50 EDT
can you reproduce readily?  In text mode too?
Comment 4 Chris Ricker 2001-08-11 14:49:32 EDT
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.
Comment 5 Glen Foster 2001-08-13 15:10:15 EDT
This defect is considered SHOULD-FIX for Fairfax.
Comment 6 Matt Wilson 2001-08-15 13:13:06 EDT
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)"?
Comment 7 Chris Ricker 2001-08-15 13:15:27 EDT
Nope
Comment 8 Matt Wilson 2001-08-15 15:18:38 EDT
I can't reproduce this failure.
Comment 9 Matt Wilson 2001-08-17 15:45:35 EDT
I wish I could reproduce this, but since the test case is gone it's going to be
impossible to fix.
Comment 10 Chris Ricker 2001-08-17 15:53:17 EDT
The initial filesystem layout, before I booted the installer, was something like
Comment 11 Chris Ricker 2001-08-17 15:53:58 EDT
<sorry about that, this mozilla build is borked>
Comment 12 Chris Ricker 2001-08-17 15:56:53 EDT
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?

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