Cannot install Fedora 10 or Fedora 11 (x86-64 version) -> Fedora bug

[TragicWarrior]

Both Fedora 10 and Fedora 11 hang while trying to install the selinux-policy-targeted* RPM package.

Here's how I reproduce the problem:

1. Download F10 or F11 64-bit ISO DVD
2. Create new Machine for Fedora 64-bit Linux (memory 512, disk 6 GB)
3. Attempt to install OS with only a ext3 / partition.
4. Observe virtual machine stalls when this package is being installed.

Note: This does not happen when installing Fedora 5, 12, or 13.

[Frank Mehnert]

Please attach a VBox.log file of such a failing VM session.

[Michael Thayer]

Are you sure that it is the virtual machine which is stalling and not the guest system running inside it? I am just wondering whether a bare metal installation of Fedora 10 or 11 would not show the same thing.

[TragicWarrior]

The "bare metal" installs work fine. I will collect a VBox.log file for this today.

[TragicWarrior]

Retested with VirtualBox 4.0 and problem still exists.

[Michael Thayer]

I can confirm this, though I don't immediately see what is causing it.

[Michael Thayer]

I tried a few things to try to see what was happening here. One of them was to set up an sshd server on the VM (dropbear) and run top with interval 0 in a login session from the host, to try to see what was happening at the moment of the freeze. Interestingly though the freeze chenged slightly - on other occasions I got a corrupted screen, this time I saw an assertion on the lines of

rpmio.c:... Assertion `fd && fd->magic == 0x04463138' failed

and messages showing that the installer had given up and shut down the installation system. I might be drawing the wrong conclusions, but it looks to me like this might be a bug in which the installer makes some assumption that doesn't apply to a virtual system (perhaps related to the speed of disk access).

I will close this ticket. If you do still think that this is something else and that it is something that VirtualBox is doing wrong you might try to find out more about what is actually happening so that we know what to look at. (To save you time, I also redirected kernel output to a serial port in case there was a kernel panic, but didn't see one.)