Bug#802246: Can't modprobe -r nvidia, rmmod works

[Andreas Beckmann]

On 2015-10-19 00:24, Luca Boccassi wrote:
>> always run
>>   dpkg-reconfigure glx-alternative-nvidia
>> after
>>   update-alternatives --config glx

>> to activate and run the triggers
>>
>> (THIS NEEDS TO BE DOCUMENTED)

Maybe we should write script (update-glx) that is a wrapper around
update-alternatives nvidia/glx and triggers+runs the neccessary followup
actions. ENOTIME - suggestions + patches welcome.

> This works with 340.93-5. Also tested on the desktop for collateral
> and it seems fine.

Thanks.
Does CUDA/OpenCL work with Bumblebee at all? Does it work with this
configuration?

> Would this mean that a bumblebee user has to run this manually when
> the package is installed? Is there a way we can automate this and make
> the bumblebee package trigger it?

Right now, yes. Should I upload this now?

How can I detect that a system is to be run under bumblebee? I could
skip creation of the "regular" /usr/lib/nvidia alternative there. Or
lower its priority.
>From a live-system point of view having stuff installed does not mean
that it is being used (thats why we aim for co-installability of nvidia,
nvidia-legacy-*, fglrx, using the nvidia and glx alternatives for
switching). If the bumblebee packages can provide some kind of switch,
all that would be needed after toggling it is to run
dpkg-trigger register-glx-alternative-nvidia from their maintainer scripts.

>> since that will 'modprobe -r nvidia'/'modprobe nvidia' you may end up
>> with the wrong^Wproblematic permissions - are you in the video group?
> 
> The devices are created with 666:

I won't trust the output from ls since you recently reported that the
device node switched from root:root 0666 to root:video 0660 after gdm3
crashed (so probably the device node in the /dev tmpfs got updated after
being accessed). :-)


Andreas