Slackware64 13.1 Nvidia framebuffer woes - blank screen after lilo
preamble
Just upgraded my system from 13.0 to 13.1 Most things went pretty smoothly, but I tried 'startx' before the post-upgrade/config reboot and the system hung - "time to upgrade my video drivers", I thought. Upgraded to Nvidia 195.36.15*. X works perfectly, and a modprobe shows the 'nvidia' module loaded. So far so good. the problem itself However, when I try to use any vesa modes in lilo, I get a blank screen after the BIOS check and the system hangs - even toggling numlock on or off won't work... So I can only boot up in text mode. This makes me unhappy, partially because I like penguins, but also because it is an absolute insult to my new (old) monitor. I thought this could be to do with the nouveau conflicts reported by -current users some days ago, but the respective blacklist file is present so I'm stuck as to what to do... *I've tried 195.36.15, 195.36.24 and the latest 2xx beta drivers. All exhibit the same behaviour. EDIT - forgot to post my video card specs. It's an 8500gt w/ 256mb, 128-bit DDR3. |
I had some weirdness with my Nvidia gt220 and the huge kernel, but I don't recall at this point what they were. Something about rivafb if I remember correctly. A generic kernel (with initrd of course) ended the wierdness.
|
Ah, initrd... I've never (knowingly) used one before, since slack 11.0... I've always read about it in the docs but never seemed to need it?
Do I need one? I'm using the stock generic kernel. |
Ah - I'm an idiot..
Turns out I was using huge after all. Updated the symlink to generic (vmlinuz) and now I can get a VESA console :) However, I get kernel panic shortly after that.. guess I need an initrd? EDIT: I've noticed there are no smp kernels anymore.. I'd assume the the generic kernel is smp on slack64? |
Quote:
Quote:
|
There is a script, /usr/share/mkinitrd/mkinitrd_command_generator.sh that has never failed to generate the correct initrd for me. I personally just do
Code:
echo `sh /usr/share/mkinitrd/mkinitrd_command_generator.sh` |
Quote:
EDIT: Well, it failed for me ;] Fails to mount the root partition on boot (/dev/sda2). I think it's to do with my RAID controller, will try adding the respective module to the generated command... |
This is annoying... Still doesn't work.
Here is the command that mkinitrd_command_generator.sh gave me: Code:
mkinitrd -c -k 2.6.33.4 -f ext4 -r /dev/sda2 -m usbhid:ehci-hcd:jbd2:mbcache:ext4 -o /boot/initrd.gz However, boot halts with this: Code:
mount: mounting /dev/sda2 on /mnt failed: Invalid argument My RAID controller is the Intel equivalent of an LSI SCSI320-2e. I tried adding the 'megaraid' driver to the mkinitrd command so it reads Code:
mkinitrd -c -k 2.6.33.4 -f ext4 -r /dev/sda2 -m usbhid:megaraid:ehci-hcd:jbd2:mbcache:ext4 -o /boot/initrd.gz |
Did you go look in /boot/initrd-tree/lib/modules/2.6.33.4/kernel/ directory tree to see if your modules were actually placed in there? When you cat /boot/initrd-tree/rootdev, does it have the correct value? Does that device exist in /boot/initrd-tree/dev?
(BTW, the default for mkinitrd's "-o" option is /boot/initrd.gz) |
nvidia proprietary drivers never played well with framebuffer console for me...
|
Quote:
I'm thinking now that it's not really to do with the RAID controller - wouldn't mount complain about not being able to find the device in that case? Instead it says 'invalid argument'... Bit of a head-scratcher, this... |
Well, almost solved now!
It turns out the correct driver was 'megaraid_mm', not 'megaraid'. even with adding this to my initrd, though, I had the same problem. It turns out that the generic kernel + initrd recognizes drives in a different order to the huge kernel! Here was my drive setup under 13.0 - sda1 - swap on megaraid sda2 - / on megaraid sdb1 - home on megaraid hda1/2 - windows on ide under 13.1 huge, that changed to - sda1 - swap on megaraid sda2 - / on megaraid sdb1 - home on megaraid sdc1/2 - windows on ide but under 13.1 generic, that becomes - sda1/2 - windows on ide and tohers numbered accordingly So I disabled the IDE drive in BIOS and the system booted all the way to login! So, is there any way to force the IDE drive to be mounted as sdc instead of sda, even though IDE is compiled in and RAID is a module? |
The problem was solved by ripping out the Windows HDD. Typical =D
Thanks for all your help guys, I'm marking this solved. |
Quote:
could be useful to others (me too)... can you boot with vesa on, startx, and then, exiting x, go back to a fully working fb console? |
Quote:
To be honest it has always 'just worked' for me. It was 13.1 that broke it. I did encounter some weirdness when trying to figure it out. Here's what made it finally work -
And I am using Nvidia's 195.36.15 drivers, they seem to work best for me on this kernel. |
All times are GMT -5. The time now is 12:29 AM. |