No internet connection in Debian Testing install

I installed Debian Testing on a separate partition on this computer recently and found I had no internet connection. I could connect to my router but not to any web sites. I had used the Debian Testing installer which does not contain non-free firmware, and selected not to configure wifi during install, as my wifi won't work without iwlwifi. However, I'd installed the package manually after the installation completed.

To cut a long story short, after a day of looking into it, I found that my /etc/resolv.conf file was a broken sim link. resolv.conf is used by Systemd and Network Manager to resolve IP addresses - hence no internet connections. I fixed it by editing /etc/resolv.conf  and adding the location of my access point, the router:

# Generated by NetworkManager
nameserver 192.168.2.1

I can't remember whether my internet connection started working right away, or I restarted Network Manager or rebooted. 

The file is apparently reset/overwritten by systemd-resolved/Network manager with an address from the DNS server, which in my case is the ISP via the router: the file now contains an entry for OpenDNS, which I'm guessing the ISP uses.

Anyway, I assume the problem occurred because I didn't configure the wireless connection during the install, but it might be a bug in the Debian testing installer.

LinuxHint 

Edit: added another link I used.

Red Hat Customer Portal

Edit: Corrected LinuxHint link and adding a link to a bug report I found at the time but forgot to add to this post.

resolv.conf symlink is broken

Borked my swap file

I installed Debian Testing on this computer to play with, but allowed the installation to use the swap partition. When I booted into the main installation (Debian Bullseye Gnome), I found it did not have swap memory available, which is not good because with only 4GB of RAM, it needs swap memory if I have a browser and other applications open. (Unfortunately it has one card slot, so upgrading the memory would involve purchasing an expensive 8GB card, unlike my laptop which had a free slot so I could drop in am extra 4GB card for not too much money).

The solution was to get the main installation to share the swap partition by updating the UUID.

# blkid /dev/sda3

Got me the UUID given to the swap partition on this computer by the new install.

I then replaced the old, now non-working UUID with the working UUID from the command above.

# nano /etc/fstab

askubuntu

Apparently it's OK for the two installations to share the swap partition, as long as it is not used for hibernation, which it is not.

askubuntu again.

Suspend won't work when screen locked in XFCE

If you set the screen to lock after a certain period in XFCE, and the computer to suspend after a further period, you may encounter the above message when you come back to the computer: the screen has blanked but the computer hasn't suspended. The message is (for search engines):

Authentication is required to suspend the sytem. Action: org.freedesktop.login1.suspend. Vendor: The systemd Project.

The XFCE settings for this are:

Power Manager > System > System Power Saving > Suspend / When inactive for 30 minutes.

and

Power Manager > Display > Display Power Management > Blank after 15 minutes

and

Power Manager > Security > Light Locker > Automatically lock the session / When the screensaver is activated

This does not happen if the screen is set to blank but not lock, and to lock when the system suspends, with the settings:

Power Manager > Security > Light Locker > Automatically lock the session / Never

and

Power Manager > Security > Light Locker > Lock screen when system is going to sleep

A solution (if you would like to lock the screen when it blanks and have the system suspend at a later time) is

Add a file 

/etc/polkit-1/rules.d/85-suspend.rules

(NB this involves creating a directory and a file in it - read to the end if you need instructions for this.)

with: 

polkit.addRule(function(action, subject) { 

 if (action.id == "org.freedesktop.login1.suspend" && 

 subject.isInGroup("<your user name>")) { 

 return polkit.Result.YES; 

} 

}); 

And in Terminal, type: 

# chmod 755 /etc/polkit-1/rules.d 

# chmod 644 /etc/polkit-1/rules.d/85-suspend.rules 

Then reboot.

This is a slightly modified version of a solution posted by mja at askubuntu.com. Why? Because the solution there uses:

subject.isInGroup("users")) {

But the group "users" does not exist by default, and its use in not recommended according to the Arch Wiki. Using my user name (which is also a group by default) worked for me.

So if your user name is fred, use

subject.isInGroup("fred")) {

Note that mja also points out that the first solution on the Ask Ubuntu site involving the 

org.freedesktop.login1.policy

file is not recommended according to the Arch Wiki site because the file could be overwritten at a later date.

The Debian Wiki has a solution to the same problem which involves the rules file and the policy file, but does not mention the need to create the group users.

For me, using the rules file was enough to solve the issues.

The Debian Wiki does give instructions for creating the rules.d directory:

# mkdir /etc/polkit-1/rules.d

so check it out if the process is unclear.

(M)utter Madness - application is not responding

I am running Gnome on Debian Testing, and after a recent update to Gnome 42, I started getting the

Application is not responding

dialogue box every few seconds with any application that carries out any processing operations, forcing me to click the "Wait" button to continue. The main culprit was Synaptic, which has to update and check package lists to identify updates: a process which quite normally takes a few seconds. I was getting the "not responding message three times during this process.

I don't know what changed recently to cause this annoyance, but here is how to fix it.

Open dconf Editor and go to /org/gnome/mutter.

Look for check-alive-timeout and edit the period if necessary. Mine was set to 5000 which is 5 seconds in milliseconds. I changed to to 60000, which is 1 minute in milliseconds - a more reasonable period.

Update:

I did a bit more research and found that it may actually be the application at fault,and the issue may be limited to Wayland.

The check-alive feature is there for the user to be able to terminate frozen applications more easily. However, sometimes applications are implemented in a way where they fail to be reply to ping requests in a timely manner, resulting in that, to the compositor, they are indistinguishable from clients that have frozen indefinitely. 

When using an application that has these issues, the GUI showed in response to the failure to respond to ping requests can become annoying, as it disrupts the visual presentation of the application. 

To allow users to work-around these issues, add a setting allowing them to configure the timeout waited until an application is considered frozen, or disabling the check completely.

Gnome has added this setting, which is good.

 gitlab.nome.org

Wayland compositors can send a ping to apps that they are supposed to respond to with a pong. However, if an app caught itself in an infinite loop or other computation that takes a long time, it might not send that pong.

reddit.com

Requests provided by wl_shell_surface 

wl_shell_surface::pong - respond to a ping event 

serial 

uint - serial number of the ping event 

A client must respond to a ping event with a pong request or the client may be deemed unresponsive. 

wayland.freedesktop.org

Firefox on Wayland

I'm using the Firefox release version from Ubuntuzilla on Debian Testing running Gnome, which uses Wayland by default now, so I wondered, does Firefox use Wayland by default? The answer is no, but it is fairly easy to enable it and it seems to work well, with a claimed significant improvement in rendering performance.

To enable Wayland mode in Firefox, edit

/usr/share/applications/firefox-mozilla-build.desktop

to

Exec=env MOZ_ENABLE_WAYLAND=1 firefox %u

(This will also work with other builds of Firefox and executable paths. See StackExchange.)

To get the performance increase in rendering, set

gfx.webrender.compositor.force-enabled 

to true in about:config. (Arch Wiki)

There is a bug which results in the window icon and title not displaying.

To correct this I had to change the line

StartupWMClass=Firefox

in the desktop file above to

StartupWMClass=firefox

(StartupWMClass must match the executable name exactly.)

I found the solution in this bug report, of which the previous bug is a duplicate, although more descriptive of this issue.

XFCE Docklike Plugin on Debian Bullseye Live

Traditionally on XFCE you would have a menu button and window buttons in the panel. You could create a launcher for an application in the form of an icon, and have window buttons in the form of icons for running applications. With the obvious disadvantage that you would have two application icons on the panel, where really you only need one (taskbars can contain a pinned launcher which, when the application is running, can also be used to switch to the application).

There is now such a taskbar available for XFCE, called xfce-docklike-plugin. It's not in the Debian Bullseye repository, so it's necessary to download, build and install it.

Unless you cheat and use the MX Linux repository based on Debian Bullseye. MX Linux XFCE edition is using the plugin as it's default window switcher. The repository is here. Tested on Debian Live XFCE non-free. You will need to install

xfce-dev-tools

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.