Bug 569664 (missing-vbox)

See

http://lists.fedoraproject.org/pipermail/test/2010-March/088899.html

> Yes, it is. Adam and I tracked this one down last week; we don't have
> the vboxvideo driver in Fedora, but we did have the autodetect code in
> the X server which tries to use it when it detects a VirtualBox
> 'graphics adapter'. And for some reason, X wasn't falling back to vesa
> when it noticed vboxvideo wasn't present, it just fell over. So we
> changed the autodetect code to go straight to vesa, for now.

*** Bug 567893 has been marked as a duplicate of this bug. ***

*** Bug 540785 has been marked as a duplicate of this bug. ***

*** Bug 568441 has been marked as a duplicate of this bug. ***

Fedora 13 Alpha has still the problem.

Actually, F13 Alpha == RC4.  Changing the Summary.

Aside from not being able to install using X, F13a also does not install X at all.  And it is not installed so as to be able to bring up eth0 (using bridged interface, with dhcp server in nearby typical Linksys device) -- eth0 does not come up on its own at all, and "ifup eth0" results in nothing but eth0 being "UP" without becoming configured with an address.

In this configuration with VirtualBox, Anaconda installs only 187 packages and do not install X.

Using an internet box it is possible to enable networking after installation to install additionnal package from repo.

To enable networking using internet box at address 192.168.1.1 

1/ ifconfig eth0 up 192.168.1.xxx
2/ route add default gw 192.168.1.1
3/ edit /etc/resolv.conf and add a line with just "nameserver 192.168.1.1"

After that, it is possible to use yum to update the systen and install new packages.

(In reply to comment #8)
> Aside from not being able to install using X, F13a also does not install X at
> all.  And it is not installed so as to be able to bring up eth0 (using bridged
> interface, with dhcp server in nearby typical Linksys device) -- eth0 does not
> come up on its own at all, and "ifup eth0" results in nothing but eth0 being
> "UP" without becoming configured with an address.    

Aren't you able to install vboxvideo driver from rpmfusion repo? What's broken on it? Of course, it is a bug of our Xserver, that it pretends it can use vbox driver when it cannot, but it should work even with the third party driver.

I'm a little confused, I got a needinfo message, but you're responding to comment #8 which is not from me, and which is unrelated to the original bug (X not working DURING install).  Do you need info from me?

never mind, and i'm sorry i commented at all.  i thought it might be useful or interesting to know that, having first failed to install /using/ X, F13a didn't even get around to installing /anything/ related to X.  there is not one package in this new F13a whose name includes the string "xorg".  it doesn't matter if i am "able to install vboxvideo driver from rpmfusion repo" or anywhere else, if the substrate on which such extras would live is absent.

ergo, just forget it.  nothing to see here, citizen, move along, move along.

I just did a new install from scratch in a VirtualBox virtual machine.

At start of installation, Anaconda says 187 packages will be installed.

At the end of installation, only groups "Mail server" and "Network server" are installed but group "Base" and other usual groups are not installed.

So independently of problem with X, there is  an other problem in Anaconda installation process in a virtual machine.

If I enable network (see my previous message bellow) I am able to install group Base and other groups from repos.

When X fails to start, this forces a standard text-based install, which installs a fixed small number of packages.  If X had started, there would have been a standard GUI install which would have installed a much larger set of packages by default, and allowed for package customization.  So the only problem here is the failure of X to start during the install - the behavior of the text-based installer itself is normal.  (The text-based installer used to allow package customization as well, but somewhere around F10 or F11 it was dumbed way down to what you've just experienced.)

So after manual installation of all necessary groups, I run VBoxLinuxAdditions-amd64.run.

During VirtualBox build process I get following message :

Installing the Window System drivers
Warning: unsupported pre-release version of X.Org Server installed. Not installing the X.Org drivers.

and of course I cannnot start X.

VirtualBox version is Oracle VM VirtualBox 3.1.4 (not OSE form Fedora repo).

You can create an xorg.conf file specifying the vesa driver by installing system-config-display and then running (as root) "system-config-display --noui".  Then X should work.  The problem with the guest additions will eventually get fixed with an updated version of VirtualBox.

I created /etc/X11/xorg.conf with system-config-display and I am now running Fedora 13 alpha in a virtaul machine under VirtualBox 3.1.4.

(In reply to comment #15)
> VirtualBox version is Oracle VM VirtualBox 3.1.4 (not OSE form Fedora repo).    

That's I believe your problem. Try it with rpmfusion VB. If it doesn't work, file a bug at bugzilla.rpmfusion.org.

I have the same issues with Sun's version, which should be the most up-to-date.

rpmfusion just packages the OSE version from Oracle (formerly Sun) and  bug should be open at http://www.virtualbox.org/wiki/Bugtracker

I just opened ticket http://www.virtualbox.org/ticket/6370

For what it's worth, still broken in Beta TC0.  See

http://lists.fedoraproject.org/pipermail/test/2010-March/088878.html

which says it should be fixed in xorg-x11-server 1.7.99.901-10.20100223, but Beta TC0 only has 1.7.99.901-8.20100223.

I confirm comment #22 that 13-Beta.TC0 does not solve the problem yet.

Just checked and F13 Branched still has the older version of xorg-x11-server (1.7.99.901-8.20100223), but Rawhide has a newer version (1.7.99.902-2.20100319).  So it ought to be possible to do a network graphical install of Rawhide in VirtualBox, though I haven't tried it.

Using

http://serverbeach1.fedoraproject.org/pub/alt/stage/Fedora-rawhide-x86_64-netinst.iso

I got the initial graphical (stage2) install screen to appear using VirtualBox, although the VM immediately froze at that point.  So this particular bug appears fixed in Rawhide.  Anyone know when an updated xorg-x11-server will get into F13?  Koji shows a number of newer versions already built:

http://koji.fedoraproject.org/koji/packageinfo?packageID=63

From my point of view the file Fedora-rawhide-x86_64-netinst.iso is dated 24-Nov-2009, so seems to be way obsolete. But this could be caused by broken mirror set of servers (you may see up-to-date image from another server than me).

No, I think you're right.  I didn't notice the 2009-11-24 date before and just assumed it would be recent.  Sorry.

Beta.TC1 only has xorg-x11-server 1.7.99.901-8.20100223, and GUI install still fails with VirtualBox (tested with i386 DVD ISO).  However, 1.7.99.902-2.20100319 was just pushed to F13 today, so TC2 should be fixed.

I can verify it does work!  I need to keep adding font packages until the "Welcome" run screen would show something other than squares.

I added three groups of fonts, this was the third group so it is one of these.

yum install xorg-x11-fonts-ISO8859-1-100dpi.noarch xorg-x11-fonts-Type1.noarch xorg-x11-fonts-ISO8859-1-75dpi.noarch xorg-x11-fonts-ISO8859-9-75dpi.noarch xorg-x11-fonts-misc.noarch

13-Beta.TC1 still has the problem.

Fixed in 13-Beta.RC1 (tested i386 DVD).  Graphical installer starts normally, didn't attempt to complete install.

Thank you for letting us know.

I confirm this problem is fixed. I did a full Beta RC1 x64 installation in graphic mode in VirtualBox 3.1.6 with no problem.