Re: Blank screen at boot with kernel 3.1
Le 25 janvier 2012 16:07, Sven Joachim <svenjoac@gmx.de> a écrit :
> On 2012-01-25 16:33 +0100, Rémi Moyen wrote:
>
>> Well, I'm guessing that at the early stage of the boot some very crude
>> driver is used and things fail when the kernel tries to load/use
>> something more complicated. Kernel 3.1 can display something but only
>> using the "big" characters at startup (something like 80x25, I would
>> guess).
>
> This is the standard text mode which you get when you don't load a
> framebuffer driver such as vesafb or nouveaufb (the latter is part of
> the nouveau.ko kernel module).
This is what I suspected, yes. Up to that point, I don't think
anything can really go wrong!
>> Kernel 2.6 switches to smaller characters very early in the
>> boot sequence and I am guessing that this is when attempting that that
>> the kernel 3.1 fails. But that's just a guess and doesn't really help
>> me...
>>
>> Also, I noticed that when I did a first install with graphical
>> environment, X was working with the 2.6 kernel (obviously not with the
>> 3.1...) and the xorg.0.log was saying something along the lines of
>> "searching a driver for your card, trying (in this order) nouveau, nv,
>> vesa" (not the exact messages, but that was the gist of it). Then
>> error messages about not being able to load nouveau (with the 2.6
>> kernel, again, so why was it not working there?),
>
> I assume because the card is not supported by the nouveau module
> in the Squeeze kernel. IIRC, you need Linux 2.6.38 at least.
Might be, yes. The kernel is 2.6.32, I think (at least, the
kernel-image package in stable is 2.6.32, so I think this is the one I
have). So that might explain why the nouveau driver is not properly
used with the stable kernel.
I am also guessing, based on this (why didn't I think about that
earlier?) that in the 3.1 kernel, my card is supposed to be supported
by nouveau, hence it tries to use it (and this causes all my problems)
whereas in 2.6.32 it doesn't even try to use nouveau and falls back to
vesafb or something like it, hence it still manages to display
something. Does this makes sense, or is this gibberish?
>> same errors for nv
>> (which was normal because at that point I had not installed the
>> xserver-xorg-video-nv package so I was not expecting X to be able to
>> use it)
>
> Would have been useless anyway, nv does not support your card.
OK. That would avoid me even trying it :-)
> You have to use either the NVidia blob or nouveau with a kernel >= 3.2
> and libgl1-mesa-dri package >= 7.11.1-1.
Hmm... Why do you say 3.2? Is there something specific that was added
in nouveau in 3.2? Support for my card, I guess? Where did you find
this information?
Kernel 3.2 seems to be still in unstable, I'd rather not install
something from there if I can avoid it. But that is worth trying, at
least!
Also, it should be working with the nvidia stuff, but apparently it
doesn't. I understand that to use the nvidia stuff I need to somehow
deactivate nouveau, but neither the blacklist in modprobe.d nor using
nomodelist in the boot options did the trick...
> If you want to make sure nouveau does not do anything harmful (or
> useful) ever, boot with the "nomodeset" kernel parameter.
I tried that, but it didn't change anything. OK, maybe I did it wrong?
Let me try to summarize what I've learned/guessed here:
* To blacklist nouveau, there needs to be a "blacklist nouveau" line
somewhere in a file in /etc/modprobe.d. The nvidia DKMS package does
this (or I did that manually), but apparently this is not enough. I've
yet to try running depmod -ae and regenerating the initrd afterwards,
could not doing it be a reason why nouveau is not properly
blacklisted?
* To completely disable nouveau, I should pass nomodeset to the
kernel. I tried doing this by modifying the GRUB_CMDLINE_LINUX_DEFAULT
(or GRUB_CMDLINE_LINUX) in /etc/default/grub and then running
update-grub, this does not seem to work (then rebooting). Is it the
right way to set this parameter?
Thanks for your help!
--
Rémi Moyen
Reply to: