Description of problem: Anaconda does not switch to graphical install. Hardware: MB: Asus M2N68-VM Graphic chipset: NVidea GeForce 7050/nForce 630a (onboard graphic card) Version-Release number of selected component (if applicable): Fedora Core 10 Testversion of 25th of september (DVD version) How reproducible: Always Steps to Reproduce: 1. Boot from Fedora 10 Install DVD 2. Wait till the first install prompts appear, the language selection and the partitioning dialog 3. => its all console based Actual results: Does not switch to graphical install Expected results: Should switch to graphical install Additional info: According to http://www.linux-tested.com/results/asus_m2n68-vm.html this hardware worked with FC 9.
Please attach /tmp/anaconda.log to this bug report, as well as /tmp/X.log if it exists.
To be sure I just tried the Fedora 9 CDs (x86_64) on this hardware and it switched to graphical install. So it should be a new problem introduced in Fedora 10. Don't know if thats good news :o( I also want to add, that the problem has nothing to do with the boot problems I reported in early october. They occured on a different platform (also x86_64 tough)
Still need the log files to know what's going on here.
Hi Chris, sorry, I read your reply according the log files just now. How can I save this file? are usb-devices already supported at that stage of install?
I have no idea how to get the file on usb. Please remember, that I am doing an install. Immagine someone sitting in front of a monitor with a notbook on his knees typeing down the messages from the monitor, than you get, what I did :) Here is the part of X.log which might be most interesting for you (II) FBDEV: driver for framebuffer: fbdev (II) VESA: driver for VESA chipsets: vesa (II) Primary Device is: PCI 00@00:12:0 (WW) NV: Ignoring unsupported device 0x10de053b (GeForce 7050 PV / nForce 630a) at 00@00:12:0 (WW) Falling back to old probe method for fbdev (II) Loading sub module "fbdevhw" (II) LoadModule: "fbdevhw" (II) Loading /usr/lib64/xorg/modules/linux//libfbdevhw.so (II) Module fbdevhw: vendor="X.Org Foundation" compiled for 1.5.0, module version = 0.0.2 ABI class: X.Org Video Driver, version 4.1 (EE) open /dev/fb0: No such device (WW) Falling back to old probe method for vesa (EE) No devices detected. Fatal server error: no screens found If you still need info from the anaconda.log, please let me know for what I have to look or how I can get the file on a usb stick.
Thanks for grabbing that piece of the X.log. Yes, it can be a little difficult to extract information from anaconda early on when things go wrong. If you can plug in a USB key, you should be able to mount/make filesystems/copy files all from tty2. We've got all the tools there for that. If you've got a network connection and another computer available, you can also scp the X.log to another machine. Since you were able to grab that piece of the config file, I'm guessing you know how to do those other tasks too. If not, I can provide more explicit instructions. I'm betting this is an X problem, by the way.
No I didn't find the device for the usb stick. I know that they are usually assigned to the devices beginning with sd, but I only found the device for my hard drive on sdb. I have one more thing. More a suggestion for future releases, maybe. I continued this morning with my FC9 installation. I recognized, that anaconda switched to graphical install (as i wrote in this request), but after the installation X didn't work anymore. It seems that the installer tries to get a better config for X as it uses for the install process, or does the install process not use X? If it uses X, why don't you install X with the same settings which are used for graphical install with anaconda and defer the tuning until the user managed to log in the first time? If that were possible you wouldn't run the risk, that a installation does not work after install. In my case I even had to mount the root partition using the rescue functionality of the install DVD to edit the inittab to start in runlevel 3. Otherwise I was not able to work at all. The System seemed to freeze during boot before the console was initilized (I tried [Ctrl]+[Alt]+[F1-6] without getting a login prompt). As I wrote, this was a problem with FC9, but if that is applicable, maybe you can consider this for future releases of fedora?! Should I file another request for that, or is it just nonsense?
anaconda uses the same X setup as the installed system will use - that is, the same binaries and the same (lack of a) config file. This should result in the same behavior in both situations. If X is not working post-install, perhaps we are not installing a library that is required. Assigning the initial problem to X since they might know what's going on in the snippet you attached.
Also, after installation, the X log (even for failing to run X) will be available in /var/log/anaconda.xlog However in this case it's pretty clear what's going on. The 7050 isn't actually supported by the nv driver, but we're not falling back to vesa correctly.
Hi Adam, are you really sure about that? I read a hardware test on www.linux-tested.com (you can find the link below) which stated that the display adapter of the motherboard I have (with 7050 chipset) was supported by fc9. Unfortunately the test article doesn't state which resolution they tested. So I searched the net because I wanted to get some more information and I found atricles which state, that people got x running on that card (e.g. worldforum.pardus-linux.nl). Is this wrong than or am I mixing up something here? What do you mean by it is not supported? does it just mean that in the fedora package it is not compiled in, or does it mean, that there is no driver at all? http://www.linux-tested.com/results/asus_m2n68-vm.html http://worldforum.pardus-linux.nl/index.php?topic=1686.0
*** Bug 468762 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Crosslinking to similar bugs: Bug#478527 Bug#471365 Bug#465634
*** This bug has been marked as a duplicate of bug 480541 ***