Bug#803200:

[alberto fuentes]

Thanks for being so detailed!

On Thu, Dec 17, 2015 at 1:27 AM, Andreas Beckmann <anbe at debian.org> wrote:

> Take a look at
> https://wiki.debian.org/KernelModesetting
>
> and try booting with "nomodeset"
>
> and maybe try disabling any graphics stuff in /etc/default/grub
> (needs running 'update-grub' after editing)
>

I included nomodeset on /etc/default/grub and updated grub afterwards. I
dont think I have any special configuration there (it doesnt show up while
running debsumbs -ce nor any other file that seems that might affect). I
attach my grub file nonetheless

This didnt do anything


>
>
> -------------------------------
>
>
> You can try to forcibly move the nouveau module away:
>
> dpkg-divert --rename
> /lib/modules/4.3.0-1-amd64/kernel/drivers/gpu/drm/nouveau/nouveau.ko
>
> (that's the "friendly" way, it tells apt about the rename, and apt will
> respect
> it on kernel upgrades (as long as it stays in the same path, i.e. until
> you upgrade to
> 4.4 or an ABI bump for 3.3 happens (the ABI version is the '1' in
> '4.3.0-1-amd64'))
>
> To undo this later on use
>
> dpkg-divert --remove --rename
> /lib/modules/4.3.0-1-amd64/kernel/drivers/gpu/drm/nouveau/nouveau.ko
>
>
> Then rebuild the initramfs (update-initramfs -u) just in case ...
> any maybe while rebooting you find something that complains that it cannot
> load the nouveau module
> Thereafter (hopefully) the nvidia module should be loadable.
>

This finally did it!

sddm always starts with a weird resolution and i dont see the user or
password boxes, but i enter my password blindly, press enters and it logins
with my usual resolutions (this might have to do with the fact that xrandr
showed a ghost vga-1 along with my other two dvi-0 and vga-0)

# journalctl -b and searching for nouveau showed nothing, but in tty1
outside the logs and before the login prompt I can read the text attached
in nolog.output

How that text scape the logs is a good question. I dont have or never had
raids... not sure why is giving the other error

as useless as it might be I also attach modules-load.service.log and
divert.output showing the output of

$ sudo journalctl -b -u systemd-modules-load.service (before the diversion)

and

$ update-initramfs -u (after the diversion)




I have no idea what is triggering nouveau to load. I am the only one having
this issue or is it more general? because I dont think I have many special
configurations


Thanks for your time!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20151217/e63cec38/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: grub
Type: application/octet-stream
Size: 1187 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20151217/e63cec38/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nolog.output
Type: application/octet-stream
Size: 519 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20151217/e63cec38/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: divert.output
Type: application/octet-stream
Size: 415 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20151217/e63cec38/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: modules-load.service.log
Type: text/x-log
Size: 2250 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20151217/e63cec38/attachment.bin>