Description of problem: Downloaded Fedora-14-x86_64-netinst.iso from TC2 and tried a) Install new system b) Install with basic video driver. Both options result in a blank screen. Version-Release number of selected component (if applicable): anaconda 14.14 How reproducible: Every time Steps to Reproduce: 1. start Virtualbox with the netinst image attached 2. Notice that the installer hangs and displayes blank screen 3. Actual results: The installer hangs and displays blank screen. Expected results: The installer displays information on screen as to how to proceed. Additional info: Was tried on VirtualBox 3.2.6 on OS X 1.5.8 on a MacPro3,1
Created attachment 437187 [details] VirtualBox log I can confirm on Linux (VirtualBox 3.1.8).
I see this also with RC1 i386 (DVD, CD #1, or netinst) on VirtualBox 3.1.8. However, it's possible to do a graphical install (or at least start one) by using VNC. (Change the guest's Network Adapter from the default "NAT" to "Bridged Adapter", press [Tab] at the boot menu and add the "vnc" option, then use one of Fedora's VNC clients.)
Update: I successfully completed a default i386 DVD install using VNC, but graphical fails in the same way it does during install, so it's necessary to use runlevel 3 (which is the default after doing a VNC install). I used the useradd and passwd commands to create an ordinary user account, since the graphical firstboot couldn't run.
Should mention that RC1 x86_64 install won't work at all (on VirtualBox or otherwise) due to bug 621775.
RC2 x86_64 DVD install in VirtualBox guest works for me using VNC as described above.
Same blank screen problem with RC3.
Same blank screen problem with RC4.
Created attachment 438943 [details] Log of RC4 install attempt with VirtualBox 3.2.8 Here's my log from RC4 x86-64 with the same issue. Same results with default menu option or basic video driver option.
Updateing a freshly installed F-13 via preupgrade results in a blank screen during update and a hard lockup.
You can get around this by setting up the rpmfusion devel repo and installing VirtualBox-OSE-guest (I had to use --skip-broken to get it installed); after that I get a desktop instead of a black screen
*** Bug 626978 has been marked as a duplicate of this bug. ***
Once you've installed, run X and see if it fails. It should fail in the same way as at anaconda time. Grab the X log from a failure case and attach it here.
Created attachment 442191 [details] Xorg.0.log This is from a failed attempt to start X after installing Fedora 14 Alpha in VirtualBox 3.2.8 using VNC. No updates applied.
Adam: any particular reason your needinfo specifies the original reporter? Everyone here is having exactly the same problem (with the possible exception of comment 10). My attachment in comment 13 should suffice.
Same problem exists in Beta TC1.
Just a "me too" F14 Beta TC1 x86_64 and virtualbox 3.2.8 (on F13 x86_64 host).
(In reply to comment #14) > Adam: any particular reason your needinfo specifies the original reporter? > Everyone here is having exactly the same problem (with the possible exception > of comment 10). My attachment in comment 13 should suffice. This line [ 136.653] (EE) open /dev/fb0: No such file or directory makes me concerned. Why it isn't there? This seems to be different from the previous issues with VirtualBox. Andre, please, keep watch on this bug, as you seem to be know a designated reporter (and we cannot change the reporter post in bugzilla, so you have to keep watch on you emails from Bugzilla). Thank you
Also, Andre, would you be willing to try with images from http://alt.fedoraproject.org/pub/alt/stage/14-Beta.TC1/ ? Is the situation better?
(In reply to comment #17) > > This line > > [ 136.653] (EE) open /dev/fb0: No such file or directory > > makes me concerned. Why it isn't there? This seems to be different from the > previous issues with VirtualBox. I don't have a /dev/fb0 in my F13 VBox machine, which works great and has full 3D (compiz) support. I also don't have a /dev/fb0 on my bare metal F13 install. > > Andre, please, keep watch on this bug, as you seem to be know a designated > reporter (and we cannot change the reporter post in bugzilla, so you have to > keep watch on you emails from Bugzilla). I'm also affected by this and can provide any logs that are required. (In reply to comment #18) > > Also, Andre, would you be willing to try with images from > http://alt.fedoraproject.org/pub/alt/stage/14-Beta.TC1/ ? > > Is the situation better? He already replied saying that the Beta TC1 build failed, too. See comment 15.
(In reply to comment #18) > Also, Andre, would you be willing to try with images from > http://alt.fedoraproject.org/pub/alt/stage/14-Beta.TC1/ ? > > Is the situation better? Already tested - comment 15.
BTW, there was a VirtualBox ticket filed for this issue: http://www.virtualbox.org/ticket/7387 but it's been closed. They're convinced the problem is on the Fedora side.
(In reply to comment #20) > (In reply to comment #18) > > Also, Andre, would you be willing to try with images from > > http://alt.fedoraproject.org/pub/alt/stage/14-Beta.TC1/ ? > > > > Is the situation better? > > Already tested - comment 15. Whoops! Yes, I am sorry, I have overlooked this one.
Still broken in F14 Beta RC1.
Still broken in F14 Beta RC2.
Broken in the same way using the F14 RC2 live image Fedora-14-Beta-i686-Live.iso.
Still broken in F14 Beta RC3 x86_64 install DVD.
Still broken in F14 Beta x86_64 Live
(In reply to comment #28) > Still broken in F14 Beta x86_64 Live Support X.org 1.9.0 -> fixed post-3.2.8 http://www.virtualbox.org/ticket/7306
(In reply to comment #29) > Support X.org 1.9.0 -> fixed post-3.2.8 > > http://www.virtualbox.org/ticket/7306 I'm not sure its relevant as the fix to this problem - the fix in virtualbox was to make the guest additions compile and run under X.org 1.9.0, which means that if you managed to install the system using text mode, then you should be able to build guest additions that would allow X to run in F14 (maybe - I haven't tested it yet, and the VirtualBox bug talks about Ubuntu). The problem in Fedora is that the graphical installer crashes (the kernel, itself, VirtualBox?), so you won't get a chance to get to the new guest additions.
One of the VirtualBox maintainers claims to have pinpointed the cause of this problem, in the Xorg code. Can someone verify this so hopefully we can get a fix soon? http://www.virtualbox.org/ticket/7387#comment:19
That was me: Guys, the reason for this crash is this line: http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/vbe/vbe.c?h=server-1.9-branch#n589 Here the code tries to copy 206 bytes. In the other case (VESA 3.0 supported), only 188 + 66 - 50 = 204 bytes are copied. VirtualBox supports only VESA 2.0, therefore the crash. The memcpy function is compiled with fortify enabled. Please could you fix this code in Fedora 14 if upstream doesn't fix it in time?
Created an upstream bug, see here: https://bugs.freedesktop.org/show_bug.cgi?id=30585
xorg-x11-server-1.9.0-12.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/xorg-x11-server-1.9.0-12.fc14
xorg-x11-server-1.9.0-12.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update xorg-x11-server'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/xorg-x11-server-1.9.0-12.fc14
Still not correct because the upstream patch is wrong. The correct size to copy is 255 bytes not 256 (the structure has a size of 255 bytes)!
I tested both this and the corresponding Rawhide build in my KVM guests and they didn't fix bug 623956 which is supposed to have the same cause. I'll test in both KVM and VirtualBox when fixed builds are pushed.
(In reply to comment #36) > Still not correct because the upstream patch is wrong. The correct size to copy > is 255 bytes not 256 (the structure has a size of 255 bytes)! Moving back to ASSIGNED based on test feedback.
su -c 'yum --enablerepo=updates-testing update xorg-x11-server'. does not work for me..... #fedora-qa (today) <satellit_afk> soas-i386-20101004.16.iso su -c 'yum --enablerepo=updates-testing update xorg-x11-server' no package xorg-x11-server available? [Bug 621893] F14 Beta RC1 X fails on VirtualBox Comment #35 ----snip----- <jlaska> satellit_: there is no binary package called, xorg-x11-server, there is a xorg-x11-server.src.rpm which provides several xorg-x11-server-* packages (see http://koji.fedoraproject.org/koji/buildinfo?buildID=198809) <satellit_> jlaska: OK so comment #35 was in error. Tried this on booted live CD
Use xorg-x11-server-Xorg
xorg-x11-server-1.9.0-13.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/xorg-x11-server-1.9.0-13.fc14
The -13.fc14 packages now work fine here when running as VirtualBox guest.
(In reply to comment #42) > The -13.fc14 packages now work fine here when running as VirtualBox guest. Thanks for the feedback, moving to VERIFIED. Frank, if you haven't already done so, can you supply some karma in the bodhi update (https://admin.fedoraproject.org/updates/xorg-x11-server-1.9.0-13.fc14). Thanks!
Works for me with a F14 x86_64 VirtualBox guest. With KVM, the F14 build works, but I had trouble with the Rawhide build - see https://bugzilla.redhat.com/show_bug.cgi?id=623956#c26 I'm going to hold off testing this on a Rawhide VirtualBox guest until I find out why it doesn't work in KVM. I suspect that it's something other than the Xorg update. Frank: Your karma is ignored unless you create a Bodhi account (easy to do) and log in - an email address isn't enough.
xorg-x11-server-1.9.0-13.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update xorg-x11-server'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/xorg-x11-server-1.9.0-13.fc14
I created a Rawhide VirtualBox guest by cloning my F14 guest and then updating to Rawhide. With the Koji xorg-x11-server packages installed, X works. There are currently 10 packages skipped due to dependencies, including systemd. So it's reasonable to consider this fixed and write off the KVM problem as typical Rawhide breakage.
I straightened Rawhide out by using yum shell to remove upstart-sysvinit and install systemd-sysvinit, then changed the default runlevel to 5. X still works. So this seems to be completely fixed regarding VirtualBox. I still haven't figured out why my Rawhide KVM guest won't run X, but it's probably not related to the xorg-x11-server update.
xorg-x11-server-1.9.0-13.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
I can confirm as of F14 RC1 I can now install under VirtualBox 3.2.10 without issue.
*** Bug 646818 has been marked as a duplicate of this bug. ***
F14 RC1 netinst works fine for me also in VirtualBox.