I switched to a new nvidia gpu and new larger monitor... The exact same
problems.
I still dont know if this is a general problem or just is part of my
configuration. I installed latest short lived branch driver from nvidia
(NVIDIA-Linux-x86_64-358.16.run) and it worked right away.
I will stick wi
On Thu, Dec 17, 2015 at 1:58 PM, Andreas Beckmann wrote:
> update-initramfs -u?
>
Yup, I had run it... Just to be sure, I runned it again and rebooted... but
still the same output on tty1
I think the output is okay, but I attach it just in case. The tty1 output
is the same as before
$ dpkg-dive
On 2015-12-17 13:43, alberto fuentes wrote:
> This makes me think I didnt remove the diversion properly, although
> dpkg-divert --list |grep nou returns nothing and your command said
> diversion removed correctly previosly
update-initramfs -u?
Andreas
On Thu, Dec 17, 2015 at 12:34 PM, Andreas Beckmann wrote:
> since it has a typo ... so perhaps try again after removing the diversion
>
Opss.. I did check that the line was added to grub by pressing e during
grub selection, but I didnt notice the typo!!
>
> You should also try the
> GRUB_
On 2015-12-17 12:15, alberto fuentes wrote:
> Thanks for being so detailed!
>
> On Thu, Dec 17, 2015 at 1:27 AM, Andreas Beckmann wrote:
>
>> Take a look at
>> https://wiki.debian.org/KernelModesetting
>>
>> and try booting with "nomodeset"
>>
>> and maybe try disabling any graphics stuff in /et
Thanks for being so detailed!
On Thu, Dec 17, 2015 at 1:27 AM, Andreas Beckmann 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 editin
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)
---
You can try to forcibly move the nouveau module away:
dpkg-div
More info on this bug...
reading about blacklisting on
https://wiki.archlinux.org/index.php/Kernel_modules#Blacklisting
blacklist nouveau seems to be a soft kind of blacklisting, thats it, if
something depends on it, it will load it anyway
There is no mkinitcpio binary in debian, but the soluti
On Wed, Dec 16, 2015 at 1:03 PM, Andreas Beckmann wrote:
> OK, this is the real problem (nouveau being loaded despite of the
> blacklisting), but I have no idea how to debug it :-(
>
I thought maybe it was loaded as a fallback or something
I have no idea how to debug this either, but i'll try t
On 2015-12-16 12:43, alberto fuentes wrote:
>> Yup, I rebooted after every install line.
> I just checked again. blacklist nouveau exists but the module is loaded
> anyway. After rebooting and failing to start i login in tty1 and doing
> lsmod |grep nou the module is loaded.
OK, this is the real
On Tue, Dec 15, 2015 at 5:51 PM, Andreas Beckmann wrote:
> Did you reboot after this step? If nouveau is loaded, the nvidia module
> cannot be loaded, too, obviously.
>
Yup, I rebooted after every install line.
Also, in the past I had to remove xorg.conf file to be able to get back to
nouveau,
On 2015-12-15 16:59, alberto fuentes wrote:
> new kernels, new versions of the package... This is a follow up mail.
> Mostly the same experience :)
>
> From testing running on nouveau, I installed :
>
> # apt-get install linux-image-amd64 linux-headers-amd64 nvidia-driver -t sid
>
> it fails to
On Tue, 2015-10-27 at 22:39 +0100, Alberto Fuentes wrote:
> Dear Maintainer,
>
>* What led up to the situation?
>
> I upgraded from 348 (or so) to latest 352 in experimental. The new nvidia-
> driver in experimental segfaults to me (I have being trying to upgrade for a
> month now (after you
13 matches
Mail list logo
