OK, so I decided to upgrade my video card in my Fedora 11 box. But when I fire it up, it won’t load X, or even boot. I look up what to do, and the instructions seem to say to install the latest Ndivia video drivers. So I put the old card back in and do so. Still no joy. So I put the old card back in, and this time it won’t even boot with the old card.
OK, so I have to somehow undo what I’ve done. But I can’t boot the machine.
Here is the problem. The machine pays no attention to keyboard commands during boot (e.g., I cannot get into the BIOS with DEL.) Which means that I can’t tell it to boot at a lower level to bypass X. In other words, I cannot boot.
Well, OK. So I burn a DVD of Fedora 13, and figure I’ll just rescue and upgrade at the same time.
But the Fedora DVD doesn’t recognize my keyboard either, until after it gets into the upgrade process, so I can’t just do a rescue. So I go ahead and upgrade. It says all the packages are installed, and reboot. I reboot, and it still can’t boot, because apparently the upgrade didn’t fix the video problem. And because I don’t have keyboard at boot, or even DVD initialization, I still can’t boot into terminal mode to fix the problem. I tried loading Knoppix, but I can’t figure out how to use it to see the Fedora drive. When I try to mount the drive, it says it doesn’t recognize the lpm2vp filesystem type.
Does anyone have any suggestions?
[Tuesday morning update]
OK, I’m updating from the machine using Knoppix, and I’ve mounted the drive. Now I just have to see if I can figure out what to do to fix it. Ideally, I’d uninstall the drivers that I installed, but I don’t have yum available in this mode, so I’m going to see if blacklisting Nouveau will fix it.
[Update a couple minutes later]
Dang. Nouveau is already blacklisted (it must have happened automagically when I installed the Nvidia drivers). Now I don’t know what to do to fix the problem.
[Update early afternoon]
OK, so I can boot into runlevel 3. I can’t bring up eth0 (it says that the device is not managed by NetworkManager — Google provides no clue as to what the problem could be), so I have no network connectivity with the box. When I telinit 5, it tells me that it’s disabled the nvidia drivers because it’s missing the nividia.ko for the new Fedora 13 kernel. The default driver in xorg.conf is vesa. As it continues to try to get to runlevel 5, it flashes a few times, but then quits. And the last line it displays is “Starting NMB services” which is says failed. It then just sits there until I ctrl-C out of the attempt, at which point I’m back to runlevel 3.
Any ideas?
[Update a few minutes later]
Well, the good news is that the machine is bootable, so in the last resort I can just back up /home and do a clean install.
[Update a few minutes later]
Hoorah! I stopped NetworkManager, and brought up eth0, and I now have an ssh connection to the machine from my laptop, so I have a place to back up. Though I’m starting to think that I should just go out and buy a new drive for a clean install, and then copy files over to it, and use the old drive for a mirror.
[Update a few minutes later]
OK, I removed akmod-nvidia, but I still get the same behavior when trying to telinit 5, and it still hangs at “Starting NMB services.”
[Update a while later]
Success! Almost. I reinstalled the nvidia drivers, following the instructions for Fedora 13, including editing grub.conf to blacklist nouveau. Then I shut down, put in the new video card, and rebooted. This time, when I telinited 5, it finally came up. The only problem now is that the screen isn’t displaying fully (that is, there is an inch of so of black on each side and a half inch top and bottom on my 22: LG monitor). Also, the highest resolution available from screen preferences is 1280 x 1024 (and I’m actually using 1280 x 720 to better match my screen ratio). I’m looking at the monitor manual to see if there’s anything I can do to enlarge the display, but I may also have to hack the X config file to get higher res. I assume that I can now reset the default to boot into level 5.
NMB, by the way, is Windows networking name services, and is part of the Windows-compatible-filesharing package Samba. (Sort of the Microsoft equivalent of DNS). Probably irrelevant to your other problems.
Clean install is not too bad an idea, really…
Even if you do not have yum working properly, you should be able to uninstall packages using rpm. yum is basically used for resolving package dependencies during install.
I believe it is ‘rpm -e $PACKAGE-NAME’ to uninstall a package.
You can list all currently installed packages with ‘rpm -qa’.
As for the X problems, you might try to get X to autodetect your graphics card and let it write a new /etc/X11/xorg.conf file:
system-config-display –noui
It X is failing to detect your graphics card, you can either specify a card specific driver, or the generic VESA driver (I advise the generic driver at this stage). It seems like X is not being able to detect a valid screen resolution with the VESA driver in your case. You can try editing your /etc/X11/xorg.conf, so it has a “Modes” line. Your configuration file should look like this:
Section “ServerLayout”
Identifier “single head configuration”
Screen 0 “Screen0” 0 0
InputDevice “Keyboard0” “CoreKeyboard”
EndSection
Section “InputDevice”
Identifier “Keyboard0”
Driver “kbd”
Option “XkbModel” “pc105”
Option “XkbLayout” “us”
EndSection
Section “Device”
Identifier “Videocard0”
Driver “vesa”
EndSection
Section “Screen”
Identifier “Screen0”
Device “Videocard0”
DefaultDepth 24
SubSection “Display”
Viewport 0 0
Depth 24
Modes “1024×768” “800×600” “640×480”
EndSubSection
EndSection
As a last resort I suppose you can backup your data and do a clean install. If you have done a lot of upgrades on the same disk over and over, this is probably advised.
To disble nmb you can probably do:
“service nmb stop” to disable it after booting.
“chkconfig –levels 2345 nmb off” to disable it at boot time.
The lack of nvidia.ko indicates that the driver installer most likely failed to compile a kernel module specific to the running kernel. It should have left a log file either in the directory you ran it from, /tmp, or /var/log detailing why it failed. I don’t remember which directory is correct off the top of my head.
If that monitor is a CRT, there are probably monitor-menu options to stretch/shrink/translate the screen; do that once and you’re good.
If it’s LCD, then you’re probably just in the wrong mode. Usually these days that gets autodetected, but not always.. worst case you have to figure out the best available resolution/scanrate and put it in xorg.conf.
It’s LCD. But I put the resolution into xorg.conf, and it still won’t show up as an option.
Hm, strange… the syntax there is a bit odd, you have to define the resolutions for both the display device and the driver (and can only use the intersection), maybe it’s not in one or the other?
Probably best to have a look at the xorg logs in /var/log again to see what’s going on.
Well, here’s an interesting bit from the log:
Here’s the current xorg.conf:
Oh, you’re still using the lowest-common-demoninator VESA driver, not the “nv” nvidia one. Not sure if that matters.
I would be tempted to delete (rather, rename out of the way as a test) the xorg.conf and see if it can just pick up everything automagically; that’s apparently supposed to work in this modern world.
Odd, though. Based on that xorg I would expect the only available modes to be 1600×900 and 1280×800, so clearly I don’t understand what’s going on.
Obviously, neither do I. You’re saying just blow away the configuration file and see what happens? Part of the problem, I think, is that the OS doesn’t recognize the monitor.
Yeah. (Well, I’d rename/move it so it can be recovered when this doesn’t work). As I understand it, these days that file is supposed to be unnecessary for typical configurations – it might be best to let the video driver work things out on its own, rather than giving it possibly incomplete instructions in a format we barely understand.
Do that in runlevel 3, and start X manually with “startx” so you don’t get stuck again…
Alternately, try switching out the vesa driver reference to the hardware specific one (nv?) – that may make a difference too.
Well, I tried letting it create its own configuration file. Here’s what resulted:
And I still can’t get anything higher than 1280 in width.
I also tried replacing “vesa” with “nvidia” and “nv.” The former just got changed back to “vesa” and the latter gave me a really funky looking screen (like one of those three-dimensional images that you have to look at just right to see the image).
Well, if you can get video using the generic VESA driver, the next step is getting an hardware accelerated driver working. VESA is never going to be high performing since it has no hardware acceleration.
IIRC you are using a NVIDIA card. Try installing the NVIDIA binary drivers and using their driver. If you cannot get a package from your vendor try downloading the Linux driver from http://www.nvidia.com. There are docs for that here:
http://us.download.nvidia.com/XFree86/Linux-x86_64/195.36.31/README/editxconfig.html
I thought that I had installed the Nvidia drivers.
OK, I tried letting nvidia-xconfig set up the file. When I tried to restart X, I got a segment fault in rc5/something-nvidia.
A segmentation fault simply means a program tried to access a memory zone outside its allocated memory space. The reasons could be many and varied. My guess is your NVIDIA driver binaries are not compatible with the other system libraries you have, or the NVIDIA DKMS Linux kernel translation layer was not properly recompiled. Try running X in verbose mode:
startx — -verbose 5 -logverbose 5
Then check the Xorg.0.log file.
Well, sounds like a problem with your nvidia drivers (vesa works, insofar as vesa ever does). I don’t suppose it got far enough to create a new logfile in /var/log with details of the problem?
Oh, and a tip I saw elsewhere, just in case; KVM monitor/keyboard switches sometimes interfere with monitor detection – if you’re using one try cutting it out to see if that helps with the resolution problem.
No KVM switch. I’ll try running things verbose and see what the log says.
OK, just for the record, here are the warnings that nvidia-xconfig generated:
And here is the file it generated:
OK, it’s telling me that the driver isn’t compatible with the latest version of the X server I have, so I’ll have to go to Nvidia’s site and see if there’s an update. Or else go to an earlier version of the X server. That doesn’t seem like a good idea.
OK, apparently I’m not the only one with this problem (it’s the same graphics processor as mine). And no posted solution. Maybe I should go to nouveau?
IIRC you said before the Nouveau driver did not work out for you. So it is either VESA or the NVIDIA binary drivers.
The Fedora people have a dislike of the NVIDIA binary drivers. There are only two ways of installing them on Fedora. Either you use an rpm package made by a 3rd party, or go to the NVIDIA site and download the appropriate package for you. Before installing a new driver version, you should uninstall any old NVIDIA binary drivers you have. This can be done like this:
# nvidia-installer –uninstall
There are instructions on how to install a 3rd party NVIDIA driver rpm package here:
http://www.mjmwired.net/resources/mjm-fedora-nvidia.html#nvidia_rpmfusion
Alternatively go to nvidia.com and download the Linux binary driver from there. You will need to have the kernel-devel package installed:
# yum install kernel-devel
Then you can install the drivers by running the file you downloaded from nvidia.com as root.
I’ve heard good things about the official Nvidia drivers; they’re apparently the best-performing available on Linux. It might be worth seeing if Nvidia has an update, or expects to soon.
That said, I think proprietary drivers in general are pretty prone to this sort of shambles – it’s a lot better for it all to be integrated into the same development stream so you don’t have this sort of issue. If noveau does all you need it’s definitely the path of least resistance – I dunno what’s required to switch back from the vendor ones, though.
Alternately, this thread makes it sound like you might be able to override that check. Not sure if that’s a good idea, but…
IIRC you said before the Nouveau driver did not work out for you.
No, I just said that in order to use the Nvidia drives I had to blacklist it. I’ve never actually tried it.
Actually, it turns out that Nvidia has a new driver (uploaded within the last week) for the GT220. So what do I do with it? It has the extension .run.
It’s probably a shell script with installer and embedded self-extracting software… ah, yes, on Nvidia site:
“Installation instructions: Once you have downloaded the driver, change to the directory containing the driver package and install the driver by running, as root, sh ./NVIDIA-Linux-x86-195.36.31-pkg1.run”
nvidia-installer –uninstall
No such program found.
Also, I found this warning:
How long does it take RPMfusion or someone else to package up a new driver? The latest packages I see there are May 18th.
Like I said, you can use a 3rd party rpm (like the ones provided by RPMfusion).
As for the packages at nvidia.com, yes, they may overwrite files from some other previously installed package. However if you do an uninstall of the NVIDIA binary drivers using “nvidia-install –uninstall” it should restore things to their previous state.
OK, now I’m screwed. I installed the Nvidia drivers, and it gives me a royally unreadable screen. And there’s no obvious way to uninstall. When I try ‘nvidia-install –uninstall it just says, “Huh”? Or to be more precise, “command not found.”
OK, it turns out that to uninstall, you rerun the same script with an –uninstall.
This page seems helpful. I’ll let you know how it goes.
I recognize that Linux has many wonderful features, but this thread underlines why I don’t use any of the major flavors.
For all the posturing, Windows is more than capable of handling swapping out a video card. If nothing else, the system will default to 640x480x256 until you debug things; 99% of the time this means updating to the most recent device driver.