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.

1 members found this post helpful.

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?

Yeah. I'm not at my Slackware computer, but IIRC there are instructions in the /boot directory called readme.initrd (or something like that). Follow those and you're good to go.

Yes. The 64-bit kernels are smp.

1 members found this post helpful.

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 ### NOTE: Those are backticks. ###

1 members found this post helpful.

Yeah, found that after a quick google. Trying it out now. Thanks!

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:

It compiles the initrd without a hitch and Lilo installs with only the usual (incosequential) warnings.

However, boot halts with this:
Then some subsequent errors about the rootfs not being mounted and the system hangs.

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 but still no luck, same things happens..

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)

1 members found this post helpful.

nvidia proprietary drivers never played well with framebuffer console for me...

0 members found this post helpful.

Thanks for that, just checked. All seems to be in place.

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.

sorry, i am very curious how you solved this with proprietary drivers.

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?

yep...

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 -

• Make sure the rivafb, nv etc. drivers are not compiled into your kernel. Stock 13.1 generic kernel is fine.
• DO NOT add the ehci_hcd or usbhid modules to your initrd. They will result in the behaviour described in OP, for some reason which completely eludes me.

And I am using Nvidia's 195.36.15 drivers, they seem to work best for me on this kernel.