Bug#787233: xserver-xorg-video-nouveau: (EE) [drm] KMS not enabled
On 2015-05-30 22:00 +0200, Kingsley G. Morse Jr. wrote:
> On 05/30/15 09:58, Sven Joachim wrote:
>
>> That could have been because your installed nvidia packages blacklisted
>> the nouveau kernel module. Running "update-alternatives --config glx"
>> and selecting the mesa alternative should change that, but you may have
>> to manually "modprobe nouveau" (or reboot, as you did).
>
> Yes, I seem to recall also wondering if the
> nouveau kernel module had been blacklisted, and
> checking two ways.
>
> If I recall correctly,
>
> one way was the lsmod command, and
>
> both tests indicated it was loaded.
If you want me to investigate this issue, please boot into the old 3.0
kernel and send the complete dmesg output, plus the Xorg.0.log file.
Otherwise there is not much we can do.
>> Another possibility is that newer udev versions might be incompatible
>> with your old 3.0 kernel, causing modprobe to fail loading the nouveau
>> module.
>
> However, I think I may be aware of some evidence
> related to your second theory: incompatible udev
> and kernel versions.
>
> Soon after trying to upgrade the Linux kernel from
> 3.0 to 4.0, my computer hung after booting with
>
> /scripts/init-top/udev: line 14: can't create /sys/kernel/uevent_helper: Permission denied
> Gave up waiting for root device. Common problems:
> - Boot args (cat /proc/cmdline)
> - Check rootdelay= (did the system wait long enough?)
> - Check root= (did the system wait for the right device?)
> - Missing modules (cat /proc/modules: ls/dev)
> ALERT! /dev/disk/by-uuid/a9792df8-2513-4185-bb81-589f5f9d508d does not exist.
> Dropping to a shell!
>
> modprobe: module ehci-orion not found in modules.dep
>
> BusyBox v1.22.1 [...]
> Enter 'help' for a list of built-in commands.
>
> (initramfs)
>
> This happened with the following versions
>
> udev: 204-5
> initramfs-tools: 0.114
> sysv-rc: 2.88dsf-43
> linux-image-4.0.0-1-686-pae: 4.0.2-1
Both udev and initramfs-tools were random snapshots from September 2013,
totally unsupported today.
>> Did you just upgrade to udev 220?
>
> An
>
> $ aptitude full-upgrade
>
> to version 215-18 of udev and 4.0 of the kernel
> seems to have fixed it.
>
> So, that's what I think I know.
>
>
> On a related note, my testing suggests that
> version 215-18 of udev needs version 4.0 of the
> kernel to work.
That's certainly not the case, since tens of thousands people use that
udev version with the kernels 3.16 and 3.2 from Jessie and Wheezy,
respectively. In my experience, udev 215 even works with kernel 2.6.32,
although such a combination is unsupported - as is the 3.0 kernel which
you had used before.
> I can imagine that adding a dependency header
> indicating this might also be helpful.
>
> If you happen to have any insights into whether
> this would be a good bug to report or not, please
> enlighten me.
Won't work: userspace programs cannot depend on a particular kernel
version, for instance because you can install as many kernels as you
wish and boot one that is too old anyway.
Cheers,
Sven
Reply to: