Debian Security does not have a release file

If you are updating from Debian Buster to Debian Bullseye, you may notice the message in the title when editing you sources.list file. This is because the repository has changed.

In buster it was:

deb http://security.debian.org/ buster/updates main contrib non-free

deb http://deb.debian.org/debian buster/security main

In bullseye it is

deb http://deb.debian.org/debian-security/ bullseye-security main 

or  

deb http://security.debian.org/debian-security bullseye-security main

depending on where you look. (Debian Security Information or Debian SourcesList.)

Simply replacing Buster with Bullseye gives the error in the title.

Edit: changed the Buster repository because I think I misremembered the address. I changed to one I blogged about before as working after a similar issue.

Debian seems to be trying to make the security repository address as confusing as possible, and succeeding.

Update icon in Firefox Mozilla build from Ubuntuzilla

In a previous post I wrote about how to get the latest version of Firefox in Debian using Ubuntuzilla. The only disadvantage with this method I have found is that the Firefox icon is seriously out of date. There is a bug report for this at Ubuntuzilla, but as it has been open for almost eight years, the chances of seeing it fixed are slim.

A user has posted a fix there.

Go to

/usr/share/pixmaps

in a terminal and do

# ln -sfn /opt/firefox/browser/chrome/icons/default/default128.png firefox-mozilla-build.png

This needs to be repeated after an update apparently.

New Firefox ESR is late in Debian

Firefox 78 ESR reached its end of life on 2 November - five weeks ago - but the new version, Firefox 91 ESR has not arrived in Debian Stable (or indeed testing, which I am using now). That means that a number of issues that are fixed in 91 ESR will not be fixed in Firefox 78 ESR, leaving users exposed to vulnerabilities until 91 ESR arrives.

Although none of these vulnerabilities has been exploited to expose users to attack, being weeks overdue for security updates is not a good place to be.

If this makes you nervous, I will detail how to update to the latest version below.

The story has gone round the internet with an added does of FUD. It is an example of how one web site runs a story they read on another web site which read the story on a blog somewhere and nobody bothers to fact check it.

The story first appeared on BaronHK's Rants, a blog by... somebody. techrights.org reprinted it, and then Phoronix and The Register covered it.

The story notes the open vulnerabilities (which is true), but the blog and the re-runs all claim that Debian won't be able to push Firefox 91 ESR to Stable because Stable isn't up to date enough. This claim comes from a bug report linked to in the blog where a post on 8 November says:

Firefox-ESR 91.3 doesn't use OpenGL GLX anymore. Instead it uses EGL by default. EGL requires at least mesa version 21.x. Debian stable (bullseye) ships with mesa version 20.3.5 For the nvidia users the following bug report might be important...

Nobody at Phoronix or The Register thought to check the progress of the bug report before running the story. If they had, they would have noticed that the bug was closed on 7 December and the problem was nothing to do with the above and was in fact in Cubed (an audio component, apparently).

So, baseless FUD from a random blog gets spread around the internet.

Debian of course has to make sure that the new Firefox ESR release doesn't have bugs. If you are nervous about using Firefox 78 ESR in Debian, here is one way to get the latest version (there are other ways).

Add the Ubuntuzilla repository and key to your Debian sources, update and install either the latest ESR, or the latest Mozilla build, Firefox 95, which is what I did (I am running Testing after all). 

Note that you will have to uninstall firefox-esr first (which will automatically install the Epiphany browser). You can then install from Ubuntuzilla. If you don't, you will get this error message:

dpkg-divert: error: 'diversion of /usr/bin/firefox to /usr/bin/firefox.ubuntu by
 firefox-mozilla-build' clashes with 'diversion of /usr/bin/firefox to /usr/bin/
firefox.real by firefox-esr'
dpkg: error processing archive /var/cache/apt/archives/firefox-mozilla-build_95.
0-0ubuntu1_amd64.deb (--unpack):
 new firefox-mozilla-build package pre-installation script subprocess returned e
rror exit status 2
dpkg-divert: error: mismatch on divert-to
  when removing 'diversion of /usr/bin/firefox to /usr/bin/firefox.ubuntu by fir
efox-mozilla-build'
  found 'diversion of /usr/bin/firefox to /usr/bin/firefox.real by firefox-esr'
dpkg: error while cleaning up:
 new firefox-mozilla-build package post-removal script subprocess returned error
 exit status 2
Errors were encountered while processing:
 /var/cache/apt/archives/firefox-mozilla-build_95.0-0ubuntu1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Installing anything from Ubuntu on Debian is normally a bad idea, as it can cause instabilities, but in this case it is fine, because the repository is just for the latest Firefox builds from Mozilla.

Update: some information from a Debian developer about the delay.

Work on this is nearing completion.

Please note that Mozilla is constantly updating to newer rustc and LLVM versions. That means that preparing a new major ESR release for Debian requires not just the packaging of the firefox-esr and thunderbird updates, but also some very complex toolchain components. Those components are usually already in unstable/testing, but for stable, oldstable, and LTS, the toolchain must be backported first.

lists.debian.org

Debian also supports additional hardware architectures and the toolchain components sometimes require specific work in order to support those additional architectures. In fact, that was the case with this current update that is underway. 

...

It is lamentable that it has taken this long, but that is not an indication of a lack of effort on the part of the people in Debian working on this.

lists.debian.org

From Piorunz at the mailing lists, here is an alternative method to update Firefox ESR, preserving the user profile until Firefox ESR is updated in Debian.

lists.debian,org

Piorunz also points out that Mesa is not the problem in a post on Phoronix:

Works perfectly fine with Debian Stable and Mesa 20.3.5, because Firefox 91 ESR detects Mesa version and adjust acelleration settings accordingly: 

Code: X11_EGL available by default

blocklisted by env: 

Blocklisted by gfxInfo

Phoronix

 

Fix - Mouse Scroll Wheel stops working

My mouse scroll wheel has been stopping working intermittently for a while. I decided to open it up to see if I could get it working again. I suspected that the mouse has an optical movement detection system for the scroll wheel (as for the mouse itself) because the wheel action is so light it can only be rotating on a shaft, and that dirt might be preventing the detector form working.

Removing the battery revealed a catch which when moved over with a screw driver allowed the top panel of the mouse (the flexible bifurcated ends of which flex to activate the mouse buttons) to be removed.

The scroll wheel (remarkably car wheel like) has spokes. I am guessing* that at the bottom a beam of IR light (because there is no visible light) passes through the spokes to a detector on the other side, and the interruption of the beam is used to detect motion of the mouse wheel.

The wheel was indeed quite dirty, and I noticed a foreign object, a thin strand of unidentifiable material at the side of the wheel which could indeed have blocked light from passing through the spokes of the wheel. An examination of the spokes with a magnifying glass showed they were dusty.

I gave the wheel a clean with a soft artist's paint brush, including the spokes, a wipe with an alcohol impregnated lens cloth and a blast with an air cleaner, through the spokes and underneath and to the sides.

The scroll wheel is now functioning normally.

So don't bin that mouse when the scroll wheel stops working - give it a clean!

* I was right: superuser.com, has the details, including how the detector knows which direction the wheel is turning.

 

Error updating Debian Testing

I got the following error messages while updating Debian Testing this morning:

E: initramfs-tools: installed initramfs-tools package post-installation script subprocess returned error exit status 1


gzip: stdout: No space left on device
E: mkinitramfs failure gzip 1
update-initramfs: failed for /boot/initrd.img-5.14.0-4-amd64 with 1.
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 initramfs-tools

Say What? This is a 500G HD and it's only 7% full!

Turns out /boot is on its own 500MB partition and its full.

I had too many old kernels installed, and the solution was to get rid of most of them (keeping one known good backup kernel).

I searched for "linux-image" in Synaptic, but this can be done from a command line too obviously.

When I had finished I ran

# update-initramfs -u

Which is the part of the update precess that had failed.

I will have to pay more attention to housekeeping from now on.

Systemd messages after suspend in Debian Testing -fixed

Update 19/12/21 Fixed - see below

I've been seeing some Systemd messages after this laptop comes out of suspend - but they only appear for a fraction of a second. I tried filming the screen as the laptop came out of suspend but only managed to get a blurry still by freezing the video.

How to read the error messages? I found I could read Systemd messages in real time, suspend and wake up the laptop and see the messages in the output. 

The command is

# journalctl -f

And the error messages were

Oct 24 19:21:38 Toshiba-laptop kernel: debugfs: File 'radeon_ring_gfx' in directory '0' already present! 

Oct 24 19:21:38 Toshiba-laptop kernel: debugfs: File 'radeon_ring_cp1' in directory '0' already present! 

Oct 24 19:21:38 Toshiba-laptop kernel: debugfs: File 'radeon_ring_cp2' in directory '0' already present! 

Oct 24 19:21:38 Toshiba-laptop kernel: debugfs: File 'radeon_ring_dma1' in directory '0' already present! 

Oct 24 19:21:38 Toshiba-laptop kernel: debugfs: File 'radeon_ring_dma2' in directory '0' already present! 

Seems to be a kernel bug (Arch Linux Forums).

Update - fix found

It seems the AMD driver packages in Debian contain both amdgpu and radeon drivers; the radeon driver is used by default on my hardware, but kernel modules for both amdgpu and radeon are loaded, and both try to create the same directory. 

The solution was to use the amdgpu driver as documented at the Debian Wiki. The amdgpu driver supports modern GPUs. Mine is older, and radeon is used by default because it's more stable, but it's also possible to use the amdgpu driver experimentally. For some reason, although both modules are still loaded, the error messages do not appear when using the amdgpu driver.

[More information on amdgpu on older chips in this article:

The Current State Of Older AMD Graphics Hardware On Linux: What Driver To Use And What To Expect (Linux Reviews)]

The following command got me the name of the GPU card:

# lspci -nnk | grep -i vga -A3 

00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon R2 Graphics] [1002:9853] 

Subsystem: Toshiba Corporation Mullins [Radeon R2 Graphics] [1179:f910] 

Kernel driver in use: amdgpu 

Kernel modules: radeon, amdgpu

(When I first ran the command, radeon was the driver in use.)

I found that Mullins belongs to the Sea Island family at the Gentoo Wiki.

To enable amdgpu on an older Sea Island card, I followed the advice at the Debian Wiki and edited etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash radeon.cik_support=0 amdgpu.cik_support=1"

Update grub afterwards with 

# update-grub2.

For my GPU, the E1-6010, amdgpu apparently breaks hibernate to disk, but it does fix the Systemd messages as posters have noted at the Arch Linux Forum thread linked to in the original post. It also enables Vulkan, a replacement for OpenGL rendering with better performance.

Although I no longer get the original errors messages, I noticed a new one:

 [6.710082] kfd kfd: amdgpu: MULLINS  not supported in kfd

As far as I can work out, this relates to use of the GPU to assist with mathematical computations by some applications, which doesn't affect me, so I'm calling this one fixed.

Gnome music is irredeemably ...

Update: I have discovered that music appears after a reboot. I haven't found a "search/refresh library" option in Gnome Music. Does it exist? IMHO it probably needs one.

5 years ago:

Gnome Music doesn't find any titles in my music collection - again...

 

Image source

Today:

Currently listening to:

From my music folder. On Gnome. Which I like.

Gotta agree with tiberiousr from reddit (link at top) on this one: "...shit".