Hide Forgot
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?
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?