nouveau.noaccel=1 kernel parameter needed with upgrade to Debian Bullseye

no-windose · 11-22-2021, 03:19 PM

My computer has an old nVidia MCP61 chipset which requires the Linux kernel parameter nouveau.noaccel=1 when using the open source nVidia nouveau driver together with the MATE graphic environment. However, when I had Debian Buster, I could do without this parameter if I switched to GNOME.

After upgrading to Debian Bullseye, I now have to use this parameter again, even with GNOME. Therefore, I can no longer have GPU acceleration with Debian.

Is this a regression with a recurring bug after Debian released Bullseye? Any solution to this problem?

mrmazda · 11-23-2021, 12:52 AM

Which display driver are you using? You might need to switch. See this driver primer.

I run the modesetting DIX display driver with TDE:

Code:

# cat /proc/cmdline
root=LABEL=debian11 mitigations=auto consoleblank=0 vga=791 video=1440x900@60 5
# inxi -CISy
System:
  Host: mcp61 Kernel: 5.10.0-9-amd64 x86_64 bits: 64 Desktop: Trinity R14.0.11
  Distro: Debian GNU/Linux 11 (bullseye)
CPU:
  Info: Dual Core model: AMD Athlon II X2 240 bits: 64 type: MCP cache:
  L2: 2 MiB
  Speed: 2813 MHz min/max: N/A Core speeds (MHz): 1: 2813 2: 2813
Info:
  Processes: 162 Uptime: 16m Memory: 1.81 GiB used: 396.2 MiB (21.3%)
  Shell: Bash inxi: 3.3.09
# inxi -Gayz
Graphics:
  Device-1: NVIDIA C61 [GeForce 6150SE nForce 430] vendor: Micro-Star MSI
  driver: nouveau v: kernel bus-ID: 00:0d.0 chip-ID: 10de:03d0 class-ID: 0300
  Display: x11 server: X.Org 1.20.11 driver: loaded: modesetting
  unloaded: fbdev,vesa alternate: nouveau,nv display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1920x1200 s-dpi: 108 s-size: 451x282mm (17.8x11.1")
  s-diag: 532mm (20.9")
  Monitor-1: VGA-1 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8")
  diag: 612mm (24.1")
  OpenGL: renderer: NV4C v: 2.1 Mesa 20.3.5 direct render: Yes
#

no-windose · 11-23-2021, 11:08 AM

Do you mean Trinity Desktop Environment mrmazda? How do you change modesetting from unloaded to loaded and why would it be necessary with Bullseye and not Buster?

Code:

$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.9.0-12-amd64 root=UUID=8531969f-2a54-46d3-b30f-eb5205078211 ro nouveau.noaccel=1 quiet
$ 
$
$ inxi -CISy
System:
  Host: desktop Kernel: 4.9.0-12-amd64 x86_64 bits: 64 Desktop: GNOME 3.38.6 
  Distro: Debian GNU/Linux 11 (bullseye) 
CPU:
  Info: Dual Core model: AMD Athlon II X2 240 bits: 64 type: MCP 
  L2 cache: 2 MiB 
  Speed: 2800 MHz min/max: 800/2800 MHz Core speeds (MHz): 1: 2800 2: 1600 
Info:
  Processes: 187 Uptime: 20h 02m Memory: 3.74 GiB used: 1.71 GiB (45.8%) 
  Shell: Bash inxi: 3.3.01 
$
$
$ inxi -Gayz
Graphics:
  Device-1: NVIDIA C61 [GeForce 6150SE nForce 430] vendor: Foxconn 
  driver: nouveau v: kernel bus ID: blahblah chip ID: blahblahblah class ID: blahblah
  Display: x11 server: X.Org 1.20.11 compositor: gnome-shell v: 3.38.6 driver: 
  loaded: nouveau unloaded: fbdev,modesetting,vesa alternate: nv 
  display ID: :0 screens: 1 
  Screen-1: 0 s-res: 1600x1200 s-dpi: 96 s-size: 423x317mm (16.7x12.5") 
  s-diag: 529mm (20.8") 
  Monitor-1: VGA-1 res: 1600x1200 hz: 60 dpi: 100 size: 408x306mm (16.1x12.0") 
  diag: 510mm (20.1") 
  OpenGL: renderer: llvmpipe (LLVM 11.0.1 128 bits) v: 4.5 Mesa 20.3.5 
  compat-v: 3.1 direct render: Yes

HappyTux · 11-23-2021, 11:25 AM

Quote:

Originally Posted by no-windose

Do you mean Trinity Desktop Environment? I tend to only use open source drivers.

Code:

$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.9.0-12-amd64 root=UUID=8531969f-2a54-46d3-b30f-eb5205078211 ro nouveau.noaccel=1 quiet
$ 
$
$ inxi -CISy
System:
  Host: desktop Kernel: 4.9.0-12-amd64 x86_64 bits: 64 Desktop: GNOME 3.38.6 
  Distro: Debian GNU/Linux 11 (bullseye) 
CPU:
  Info: Dual Core model: AMD Athlon II X2 240 bits: 64 type: MCP 
  L2 cache: 2 MiB 
  Speed: 2800 MHz min/max: 800/2800 MHz Core speeds (MHz): 1: 2800 2: 1600 
Info:
  Processes: 187 Uptime: 20h 02m Memory: 3.74 GiB used: 1.71 GiB (45.8%) 
  Shell: Bash inxi: 3.3.01 
$
$
$ inxi -Gayz
Graphics:
  Device-1: NVIDIA C61 [GeForce 6150SE nForce 430] vendor: Foxconn 
  driver: nouveau v: kernel bus ID: blahblah chip ID: blahblahblah class ID: blahblah
  Display: x11 server: X.Org 1.20.11 compositor: gnome-shell v: 3.38.6 driver: 
  loaded: nouveau unloaded: fbdev,modesetting,vesa alternate: nv 
  display ID: :0 screens: 1 
  Screen-1: 0 s-res: 1600x1200 s-dpi: 96 s-size: 423x317mm (16.7x12.5") 
  s-diag: 529mm (20.8") 
  Monitor-1: VGA-1 res: 1600x1200 hz: 60 dpi: 100 size: 408x306mm (16.1x12.0") 
  diag: 510mm (20.1") 
  OpenGL: renderer: llvmpipe (LLVM 11.0.1 128 bits) v: 4.5 Mesa 20.3.5 
  compat-v: 3.1 direct render: Yes

Why the 4.9 kernel? Is not from bullseye it has a 5.10 kernel. Until you run an actual proper bullseye system it is impossible to tell where the problem comes from. Old kernel with new packages or the new packages themselves.

Code:

root@bullseye-raspi:~# uname -a
Linux bullseye-raspi 5.10.0-9-arm64 #1 SMP Debian 5.10.70-1 (2021-09-30) aarch64 GNU/Linux
root@bullseye-raspi:~# cat /etc/debian_version 
11.1

I would think an entire version higher may have the possibility of a better driver for you. Also using the (code)(/code) before and after the text replacing the () with [] will give a scrolling text area for a posting of the terminal output to make the output take up less space on the posting of it. I have edited it in my response to show you this idea.

no-windose · 11-23-2021, 12:02 PM

Thanks HappyTux. I don't know why I have the wrong kernel. I do have Bullseye though:

Code:

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 11 (bullseye)
Release:	11
Codename:	bullseye

I did upgrade from Buster to Bullseye as follows:

Code:

# sed -i 's/buster/bullseye/g' /etc/apt/sources.list
# apt update
# apt upgrade
# apt full-upgrade

mrmazda · 11-23-2021, 12:41 PM

Quote:

Originally Posted by no-windose

Do you mean Trinity Desktop Environment mrmazda? How do you change modesetting from unloaded to loaded and why would it be necessary with Bullseye and not Buster?

Yes
Either specify modesetting via /etc/X11/xorg.con* (which you would probably need to create, as normally this is handled automagically), or remove package xserver-xorg-video-nouveau

Quote:

I don't know why I have the wrong kernel...

I did upgrade from Buster to Bullseye as follows:

Code:

# sed -i 's/buster/bullseye/g' /etc/apt/sources.list
# apt update
# apt upgrade
# apt full-upgrade

Try:

Code:

apt dist-upgrade

I don't think I've ever tried full-upgrade, which may be an Ubuntu variation. Also, sources.list needs an important modification for security, as spelled out in the release notes.

shruggy · 11-23-2021, 02:16 PM

Quote:

Originally Posted by mrmazda

I don't think I've ever tried full-upgrade, which may be an Ubuntu variation.

It's just the new name of dist-upgrade. Despite what was said in this old thread on Debian forums, APT developers later added full-upgrade as a synonym for dist-upgrade first to apt (when it was first introduced in 2014) and then even to apt-get (2015). And aptitude still recongizes dist-upgrade as a synonym for full-upgrade to this day.

They're currently documented thusly:

aptitude docs speak of full-upgrade, but mention dist-upgrade as a deprecated synonym.
apt docs only speak of full-upgrade, but undocumented dist-upgrade is accepted as well.
apt-get docs only speak of dist-upgrade, but undocumented full-upgrade is accepted as well.

HappyTux · 11-23-2021, 04:10 PM

Quote:

Originally Posted by no-windose

Thanks HappyTux. I don't know why I have the wrong kernel. I do have Bullseye though:

Code:

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 11 (bullseye)
Release:	11
Codename:	bullseye

I did upgrade from Buster to Bullseye as follows:

Code:

# sed -i 's/buster/bullseye/g' /etc/apt/sources.list
# apt update
# apt upgrade
# apt full-upgrade

That is not good you are missing out on the security updates the format changed and a simple substitution will not result in a correct line.

Code:

root@bullseye-raspi:~# cat /etc/apt/sources.list
# For Bullseye https://www.debian.org/releases/bullseye/arm64/release-notes/ch-upgrading.en.html
deb http://deb.debian.org/debian bullseye main contrib non-free
# deb-src https://deb.debian.org/debian/ bullseye main contrib non-free

# For Bullseye Security https://www.debian.org/releases/bullseye/arm64/release-notes/ch-information.en.html#security-archive
deb http://security.debian.org/debian-security bullseye-security main contrib non-free
# deb-src https://deb.debian.org/debian-security bullseye-security main contrib non-free

# Bullseye Updates https://wiki.debian.org/DebianBullseye#FAQ
deb https://deb.debian.org/debian bullseye-updates main contrib non-free
# deb-src https://deb.debian.org/debian bullseye-updates main contrib non-free

# The Backports are _not_ enabled by default.
# Enable them by uncommenting the following line:
# Bullseye Backports  https://backports.debian.org/
# deb http://deb.debian.org/debian bullseye-backports main contrib non-free
# deb-src https://deb.debian.org/debian/ bullseye-backports main contrib non-free

# Bullseye Proposed Updates https://wiki.debian.org/StableProposedUpdates
# deb https://deb.debian.org/debian/ bullseye-proposed-updates main contrib non-free 
# deb-src https://deb.debian.org/debian/ bullseye-proposed-updates main contrib non-free

My list with the URLs in the comments it is from my Pi4 but the same applies to any other arch. You may want to read them. Try the below.

Code:

root@bullseye-raspi:~# dpkg --get-selections | grep image
linux-image-5.10.0-8-arm64			install
linux-image-5.10.0-9-arm64			install
linux-image-arm64				install

Yours will likely have the amd64 for them but the one you want to check is the.

Code:

root@bullseye-raspi:~# apt-cache policy linux-image-arm64
linux-image-arm64:
  Installed: 5.10.70-1
  Candidate: 5.10.70-1
  Version table:
 *** 5.10.70-1 500
        500 http://deb.debian.org/debian bullseye/main arm64 Packages
        100 /var/lib/dpkg/status
     5.10.46-5 500
        500 http://security.debian.org/debian-security bullseye-security/main arm64 Packages

Changing the arm64 to amd64 to see what it says it will install, it should be the latest available like I have.

no-windose · 11-23-2021, 04:14 PM

mrmazda I want to keep the nouveau driver since I tend to prefer open-source drivers. In any case it worked well on Buster and I wonder why it shouldn't on Bullseye.

mrmazda · 11-23-2021, 05:31 PM

Quote:

Originally Posted by no-windose

I want to keep the nouveau driver since I tend to prefer open-source drivers.

Did you read the primer I linked to? Both modesetting DIX and nouveau DDX display drivers are open-source. The modesetting DIX is newer technology, is not reverse-engineered, and is the only one I use on all my NVidia hardware new enough for it to support.

Quote:

In any case it worked well on Buster and I wonder why it shouldn't on Bullseye.

Changes can occur because software both evolves and devolves. I'm sure few if any developers are able to bother testing with ancient 6150 IGPs, so regressions affecting them would only be caught by a select few people, such as yourself, ordinary users.

ondoho · 11-23-2021, 11:50 PM

I'd like to know more about this old kernel.
@no-windose, please show us:

Code:

dpkg-query -S vmlinuz

no-windose · 11-25-2021, 01:33 PM

HappyTux: I don't know why I am still booting on kernel 4.9 after upgrading to Bullseye.

Code:

# uname -r
4.9.0-12-amd64
#

If I try to install kernel 5.10, I get a message warning that I won't be able to boot if I do so:

Code:

# apt install linux-image-5.10.0-9-amd64
You are running a kernel (version 4.9.0-12-amd64) and attempting to remove the same version. This can make the system unbootable as it will remove /boot/vmlinuz-4.9.0-12-amd64 and all modules under the directory /lib/modules/4.9.0-12-amd64. This can only be fixed with a copy of the kernel image and the corresponding modules. It is highly recommended to abort the kernel removal unless you are prepared to fix the system after removal.
    Abort kernel removal?

Stranger still, it seems that kernel 5.10 is already installed:

Code:

# aptitude search linux-image | grep ^i
ip linux-image-4.9.0-12-amd64 - Linux 4.9 for 64-bit PCs
i  linux-image-5.10.0-9-amd64 - Linux 5.10 for 64-bit PCs (signed)
i  linux-image-amd64 - Linux for 64-bit PCs (meta-package)
#

Here is the output of dpkg get-selections and apt-cache policy:

Code:

# dpkg --get-selections | grep linux-image
linux-image-4.9.0-12-amd64			purge
linux-image-5.10.0-9-amd64			install
linux-image-amd64				install
# 
# apt-cache policy linux-image-amd64
linux-image-amd64:
  Installed: 5.10.70-1
  Candidate: 5.10.70-1
  Version table:
 *** 5.10.70-1 500
        500 http://ftp.de.debian.org/debian bullseye/main amd64 Packages
        100 /var/lib/dpkg/status
     5.10.46-5 500
        500 http://security.debian.org/debian-security bullseye-security/main amd64 Packages
#

If I run upgrade-grub, the file /boot/grub/grub.cfg is unchanged and only offers the option to boot on kernel 4.9.
Why can't I have kernel 5.10 and what should I do?

ondoho: Here is the output of dpkg-query -S vmlinuz:

Code:

# dpkg-query -S vmlinuz
linux-image-5.10.0-9-amd64: /boot/vmlinuz-5.10.0-9-amd64
linux-image-4.9.0-12-amd64: /boot/vmlinuz-4.9.0-12-amd64
#

HappyTux · 11-25-2021, 03:34 PM

That is strange you boot from an uninstalled kernel or I thought that is what the purge meant. Only thing to do is answer the question with a yes when it asks to remove the running kernel. Now I would have backed up my home directory to keep the setting in it for restoration. This if it fails to boot and a re-install is necessary, I would have fresh install media for the Debian 11 on hand to, as it will guarantee a proper install with the latest kernel used.

no-windose · 11-25-2021, 05:34 PM

Thanks HappyTux. This is strange indeed. Could this mean that I have been hacked? I have noticed for a while that apt update && apt upgrade doesn't and didn't install any upgrade at all, even before I moved from Buster to Bullseye. How could I find out if I have been hacked before re-installing and loosing all trace of such a possible hack?

HappyTux · 11-25-2021, 06:08 PM

Quote:

Originally Posted by no-windose

Thanks HappyTux. This is strange indeed. Could this mean that I have been hacked? I have noticed for a while that apt update && apt upgrade doesn't and didn't install any upgrade at all, even before I moved from Buster to Bullseye. How could I find out if I have been hacked before re-installing and loosing all trace of such a possible hack?

Nor would it those are stable releases. With them the only upgrades you will get is from the security repository or from places like the backports if enabled. Those are few and far between in my experience I keep expecting to see updates available when I do it but most days they are not there. A quick search gives me the file to look in to find out when.

Code:

root@bullseye-raspi:~# cat /var/log/apt/history.log

Start-Date: 2021-11-01  14:08:29
Commandline: apt upgrade
Upgrade: libavdevice58:arm64 (7:4.3.2-0+deb11u2, 7:4.3.3-0+deb11u1), ffmpeg:arm64 (7:4.3.2-0+deb11u2, 7:4.3.3-0+deb11u1), libpostproc55:arm64 (7:4.3.2-0+deb11u2, 7:4.3.3-0+deb11u1), libavcodec58:arm64 (7:4.3.2-0+deb11u2, 7:4.3.3-0+deb11u1), libavutil56:arm64 (7:4.3.2-0+deb11u2, 7:4.3.3-0+deb11u1), libswscale5:arm64 (7:4.3.2-0+deb11u2, 7:4.3.3-0+deb11u1), libswresample3:arm64 (7:4.3.2-0+deb11u2, 7:4.3.3-0+deb11u1), libavformat58:arm64 (7:4.3.2-0+deb11u2, 7:4.3.3-0+deb11u1), libavresample4:arm64 (7:4.3.2-0+deb11u2, 7:4.3.3-0+deb11u1), libavfilter7:arm64 (7:4.3.2-0+deb11u2, 7:4.3.3-0+deb11u1)
End-Date: 2021-11-01  14:08:33

Start-Date: 2021-11-10  01:38:39
Commandline: apt upgrade
Upgrade: python3-samba:arm64 (2:4.13.5+dfsg-2, 2:4.13.13+dfsg-1~deb11u2), libldb2:arm64 (2:2.2.0-3.1, 2:2.2.3-2~deb11u1), samba-vfs-modules:arm64 (2:4.13.5+dfsg-2, 2:4.13.13+dfsg-1~deb11u2), samba:arm64 (2:4.13.5+dfsg-2, 2:4.13.13+dfsg-1~deb11u2), libwbclient0:arm64 (2:4.13.5+dfsg-2, 2:4.13.13+dfsg-1~deb11u2), samba-dsdb-modules:arm64 (2:4.13.5+dfsg-2, 2:4.13.13+dfsg-1~deb11u2), samba-common-bin:arm64 (2:4.13.5+dfsg-2, 2:4.13.13+dfsg-1~deb11u2), python3-ldb:arm64 (2:2.2.0-3.1, 2:2.2.3-2~deb11u1), samba-libs:arm64 (2:4.13.5+dfsg-2, 2:4.13.13+dfsg-1~deb11u2), samba-common:arm64 (2:4.13.5+dfsg-2, 2:4.13.13+dfsg-1~deb11u2)
End-Date: 2021-11-10  01:39:07

Had some on the first and tenth of this month those were from the already mentioned security. It means by not following the procedure to do the upgrade it did not fully update all your packages like it should have, in short it is a mess best resolved by getting it properly done to get rid of any lingering problems it may cause in the future like it is doing now. I despise re-installs but some of the time they are necessary.

Code:

root@bullseye-raspi:~# apt-cache policy ffmpeg
ffmpeg:
  Installed: 7:4.3.3-0+deb11u1
  Candidate: 7:4.3.3-0+deb11u1
  Version table:
 *** 7:4.3.3-0+deb11u1 500
        500 http://security.debian.org/debian-security bullseye-security/main arm64 Packages
        100 /var/lib/dpkg/status
     7:4.3.2-0+deb11u2 500
        500 http://deb.debian.org/debian bullseye/main arm64 Packages
root@bullseye-raspi:~# apt-cache policy python3-samba
python3-samba:
  Installed: 2:4.13.13+dfsg-1~deb11u2
  Candidate: 2:4.13.13+dfsg-1~deb11u2
  Version table:
 *** 2:4.13.13+dfsg-1~deb11u2 500
        500 http://security.debian.org/debian-security bullseye-security/main arm64 Packages
        100 /var/lib/dpkg/status
     2:4.13.5+dfsg-2 500
        500 http://deb.debian.org/debian bullseye/main arm64 Packages

Edit: And by necessary I mean if it fails to boot after the kernel upgrade. If it continues working without problems after that is done then use it until problems attributable to the upgrade path are found, then the re-install is necessary.