Florian Echtler's questions

Recently upgraded to Ubuntu 22.04, and had some issues activating my eduroam WiFi connection. Specifically, I got the following message in syslog:

Mai 04 11:42:11 sliver wpa_supplicant[687]: TLS: Certificate verification failed, error 68 (CA signature digest algorithm too weak) depth 0 for '/C=DK/ST=Denmark/O=Aalborg Universitet/OU=IT Services/CN=wifi.aau.dk'

Right now, I can only activate the eduroam connection when I do not use a certificate. Looking at it with openssl x509 ..., it seems the certificate is still using SHA-1.

Is this an issue to be fixed by the cert issuer (i.e. my university's IT ppl), or is it an issue with the update to 22.04?

Recently upgraded to Ubuntu 22.04, and it seems like the power-saving feature does not actually turn off the screen(s) after X minutes, but just blanks them. When I manually run xset dpms force off, they do properly turn off and go to sleep, but this and related solutions (e.g. https://askubuntu.com/a/1004163/29252) do feel rather kludgy.

Any suggestions for how to fix this "properly"?

I usually have German and English keyboard layouts on Ubuntu 20.04, but I recently started writing in Danish as well, and I can write most special letters (e.g. "æ" via AltGr-a, "ø" via AltGr-o etc.). However, I can't figure out how to get an "å". I guess it should be °a, but the ° isn't a dead key (unlike e.g. ^, ´ etc.). Any ideas how to fix this?

I'm using a Dell XPS 13 laptop with a noname USB-C dock for an external HDMI screen. Nearly 100% stock Ubuntu 20.04 with Xorg, Gnome-Shell, and kernel 5.8. Everything works fine, unless I want the screens to turn off, e.g. simply for powersaving when idle. What happens is that everything briefly goes black for a few seconds, then flickers a couple of times and turns back on. I can also manually trigger this bug by e.g. running xset dpms force off or by disabling the external output with xrandr --output DP-1 --off.

AFAICT the problem is that the external monitor correctly going into powersave triggers a hotplug event, which causes gnome-shell to reconfigure all the screens, and in the process wakes them up again.

I've captured the output from journalctl -f for one off-flicker-on sequence below - suggestions welcome, any ideas on how to make gnome-shell ignore these screen hotplug events?

Mai 01 21:30:34 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Allocate new frame buffer 1920x1200 stride
Mai 01 21:30:35 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): EDID vendor "DEL", prod id 41155
Mai 01 21:30:35 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Using hsync ranges from config file
Mai 01 21:30:35 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Using vrefresh ranges from config file
Mai 01 21:30:35 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Printing DDC gathered Modelines:
Mai 01 21:30:35 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Modeline "2560x1440"x0.0  241.50  2560 2608 2640 2720  1440 1443 1448 1481 +hsync -vsync (88.8 kHz eP)
Mai 01 21:30:35 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Modeline "1920x1080"x0.0  148.50  1920 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
[...]
Mai 01 21:30:35 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
Mai 01 21:30:35 sliver gnome-shell[2150]: meta_display_get_monitor_in_fullscreen: assertion 'monitor >= 0 && monitor < n_logical_monitors' failed
Mai 01 21:30:35 sliver gnome-shell[2150]: meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned int) number < g_list_length (manager->logical_monitors)' failed
Mai 01 21:30:35 sliver gnome-shell[2150]: meta_workspace_get_work_area_for_monitor: assertion 'logical_monitor != NULL' failed
Mai 01 21:30:43 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): EDID vendor "SHP", prod id 5324
Mai 01 21:30:43 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Printing DDC gathered Modelines:
Mai 01 21:30:43 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Modeline "3840x2400"x0.0  592.50  3840 3888 3920 4000  2400 2403 2409 2469 -hsync -vsync (148.1 kHz eP)
Mai 01 21:30:43 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Modeline "3840x2400"x0.0  474.00  3840 3888 3920 4000  2400 2403 2409 2469 -hsync -vsync (118.5 kHz e)
Mai 01 21:30:43 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): EDID vendor "SHP", prod id 5324
Mai 01 21:30:43 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Printing DDC gathered Modelines:
Mai 01 21:30:43 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Modeline "3840x2400"x0.0  592.50  3840 3888 3920 4000  2400 2403 2409 2469 -hsync -vsync (148.1 kHz eP)
Mai 01 21:30:43 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Modeline "3840x2400"x0.0  474.00  3840 3888 3920 4000  2400 2403 2409 2469 -hsync -vsync (118.5 kHz e)
Mai 01 21:30:46 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): EDID vendor "SHP", prod id 5324
Mai 01 21:30:46 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Printing DDC gathered Modelines:
Mai 01 21:30:46 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Modeline "3840x2400"x0.0  592.50  3840 3888 3920 4000  2400 2403 2409 2469 -hsync -vsync (148.1 kHz eP)
Mai 01 21:30:46 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Modeline "3840x2400"x0.0  474.00  3840 3888 3920 4000  2400 2403 2409 2469 -hsync -vsync (118.5 kHz e)
Mai 01 21:30:46 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Allocate new frame buffer 2560x2640 stride
Mai 01 21:30:46 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): EDID vendor "SHP", prod id 5324
Mai 01 21:30:46 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Printing DDC gathered Modelines:
Mai 01 21:30:46 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Modeline "3840x2400"x0.0  592.50  3840 3888 3920 4000  2400 2403 2409 2469 -hsync -vsync (148.1 kHz eP)
Mai 01 21:30:46 sliver /usr/lib/gdm3/gdm-x-session[2008]: (II) modeset(0): Modeline "3840x2400"x0.0  474.00  3840 3888 3920 4000  2400 2403 2409 2469 -hsync -vsync (118.5 kHz e)

On my Dell XPS 13 with Ubuntu 20.04, using the default Gnome shell, I've set the "Blank screen" timeout to 5 minutes. However, the screen does not blank completely, but still shows a black image with the mouse cursor visible.

When I run xset dpms force off in the shell, the displays turn off properly and go to powersave mode. After the blank screen timeout kicks in, the displays actually turn back on again to show the black image with cursor. Any ideas how to enable proper powersaving here?

P.S. I already checked Blank screen not properly blank and this seems to be different, as xset doesn't work in that case.

I'm using network-manager-openvpn to connect to my university VPN. The VPN works when I just run openconnect -u username vpn.host.edu from the commandline (although it spews a lot of ip route error messages).

However, when starting the VPN through the NetworkManager GUI, the resulting routing table is messed up:

$ ip route
default via 192.168.178.1 dev enxXXXXXXXXXXXX
default dev vpn0 proto static scope link metric 50 
default via 192.168.178.1 dev enxXXXXXXXXXXXX proto dhcp metric 20100 
[...]

The first entry causes all traffic to still be routed through the local gateway. Consequently, e.g. name resolution with the VPN DNS servers fails and the VPN is unusable. When I remove the first routing table entry with ip route del default via 192.168.178.1 dev enxXXXXXXXXXXXX, then everything starts working as intended.

All network settings for the VPN connection are set to "Automatic", so why is the VPN entry not the first default route?

P.S. I know that there are workarounds described in Network Manager does not set IP4.GATEWAY for OpenVPN connection and Network Manager does not set IP4.GATEWAY for OpenVPN connection - but I would like to fix this without having to run a shell command everytime.

My systemd journal is being spammed with messages from gnome-keyring-daemon, 3-4 log entries per second:

Nov 14 10:55:40 flunder gnome-keyring-daemon[16099]: asked to register item /org/freedesktop/secrets/collection/login/287, but it's already registered
Nov 14 10:55:40 flunder gnome-keyring-daemon[16099]: asked to register item /org/freedesktop/secrets/collection/login/288, but it's already registered

Killing gnome-keyring-daemon didn't help, nor did restarting the machine.

This is quite annoying and wasteful, and I have no idea what it's trying to tell me or how to remove that duplicate login item. Any suggestions?

UPDATE: this is actually caused by the Nextcloud desktop client. The duplicate entries are the Nextcloud passwords, and when I stop the client, the spam also stops.

I often use Bluetooth to quickly send a file from my phone to my laptop. On Ubuntu 22.04 with the default Gnome Shell, this means I first have to open the Settings -> Bluetooth dialog and leave it open before I can receive files. Is there any way to enable this feature permanently?

(I'm aware the current behaviour is for security reasons, but I know which devices I've paired with my laptop, so I'd be OK with auto-reception.)

EDIT: I know this can be worked around by using blueman, but that brings its own set of issues, so I'd rather use the standard gnome-shell tools.

On my 18.04 machine with stock kernel 4.15, I'm using a run-of-the-mill CSR Bluetooth dongle. Problem now is that the machine will not suspend properly when that dongle is plugged in - it will go to sleep for something between 5 and 10 seconds, but then resume on its own, even if no Bluetooth devices are currently connected or even powered on. When I unplug the dongle before suspend, it stays suspended as it should.

I could just turn off USB wakeup entirely, but I was hoping there's a more nuanced solution that just prevents wakeup via the Bluetooth dongle...

lsusb, usb-devices, hcitool output for dongle:

Bus 001 Device 007: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#=  7 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0a12 ProdID=0001 Rev=88.91
S:  Product=CSR8510 A10
C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

hci0:   Type: Primary  Bus: USB
    BD Address: xx:xx:xx:xx:xx:xx  ACL MTU: 310:10  SCO MTU: 64:8
    UP RUNNING PSCAN 
    RX bytes:124465 acl:0 sco:0 events:3928 errors:0
    TX bytes:3182 acl:0 sco:0 commands:51 errors:0
    Features: 0xff 0xff 0x8f 0xfe 0xdb 0xff 0x5b 0x87
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
    Link policy: RSWITCH HOLD SNIFF PARK 
    Link mode: SLAVE ACCEPT 
    Name: 'monolith'
    Class: 0x0c0104
    Service Classes: Rendering, Capturing
    Device Class: Computer, Desktop workstation
    HCI Version: 4.0 (0x6)  Revision: 0x22bb
    LMP Version: 4.0 (0x6)  Subversion: 0x22bb
    Manufacturer: Cambridge Silicon Radio (10)

I have a slightly messed-up 64GB USB drive formatted with FAT32, and would like to fix it on Ubuntu 18.04.

First attempt:

$ sudo fsck.vfat /dev/sdc1 
fsck.fat 4.1 (2017-01-24)
FATs differ but appear to be intact. Use which FAT ?
1) Use first FAT
2) Use second FAT
? 1
Reclaimed 4221 unused clusters (138313728 bytes).
Free cluster summary wrong (1484695 vs. really 1488915)
1) Correct
2) Don't correct
? 1
Perform changes ? (y/n) y
/dev/sdc1: 20 files, 402763/1891678 clusters
$

However, when I re-mount the drive afterwards, the corrupt files show up again and resist any attempt to delete them. I can re-run the command as often as I want, with exactly the same result.

Second attempt, based on How to repair a corrupted FAT32 file system:

$ sudo fsck.vfat -w -r -v -l -a -t /dev/sdc1 
fsck.fat 4.1 (2017-01-24)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "THREES  "
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
     32768 bytes per cluster
        32 reserved sectors
First FAT starts at byte 16384 (sector 32)
         2 FATs, 32 bit entries
   7567872 bytes per FAT (= 14781 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 15152128 (sector 29594)
   1891678 data clusters (61986504704 bytes)
63 sectors/track, 32 heads
        63 hidden sectors
 121097025 sectors total
FATs differ but appear to be intact. Using first FAT.
Checking file /
[...]
Checking for bad clusters.
Reclaiming unconnected clusters.
Reclaimed 4221 unused clusters (138313728 bytes) in 1 chain.
Checking free cluster summary.
Free cluster summary wrong (1484695 vs. really 1484694)
  Auto-correcting.
Performing changes.
/dev/sdc1: 21 files, 406984/1891678 clusters

Same result: fsck finds errors, acts like it fixes them, but the filesystem appears to be entirely unchanged afterwards and all the corrupt files are still there.

Filesystem has been unmounted before fsck, of course. What am I missing?

I've been experimenting with dual-boot between Linux and Android on an x86 device which came with Android + Windows preinstalled (Chuwi Hi10 Pro).

I soon found out that simply booting Ubuntu (either from a live USB stick or from the on-device install) will kill the Android installation (hangs at boot), to the point that only a factory restore will help.

The reason seems to be that Ubuntu automounts every ext4 filesystem it can find, including the Android partitions (system/data/cache/config). I've fixed this by adding the following to /etc/fstab:

# do _not_ automount the Android partitions
UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b  /none ext4 ro,noauto 0 0
UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b1 /none ext4 ro,noauto 0 0
UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b2 /none ext4 ro,noauto 0 0
UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b3 /none ext4 ro,noauto 0 0

I'm now wondering about two things:

1. What is it that Ubuntu can possibly do to the ext4 partitions that will later cause Android to hang on boot?

2. Could this be related to the fact that apparently all Android partitions share the same UUID?

EDIT: as suggested by mook765, here's the output of lsblk -f:

NAME         FSTYPE LABEL     UUID                                 MOUNTPOINT
mmcblk0                                                            
├─mmcblk0p1  vfat   ANDROIDIA 1389-AFF9                            /boot/efi
├─mmcblk0p2                                                        
├─mmcblk0p3                                                        
├─mmcblk0p4                                                        
├─mmcblk0p5                                                        
├─mmcblk0p6                                                        
├─mmcblk0p7  ext4             57f8f4bc-abf4-655f-bf67-946fc0f9f25b 
├─mmcblk0p8  ext4             57f8f4bc-abf4-655f-bf67-946fc0f9f25b 
├─mmcblk0p9  ext4             57f8f4bc-abf4-655f-bf67-946fc0f9f25b 
├─mmcblk0p10                                                       
├─mmcblk0p11 ext4             57f8f4bc-abf4-655f-bf67-946fc0f9f25b 
├─mmcblk0p12 vfat             8A7A-6F97                            
└─mmcblk0p13 ext4             9dadc784-4ed1-4e54-adec-8227b73a0777 /
mmcblk0boot0                                                       
mmcblk0boot1                                                       

I've successfully been using bumblebee with optirun/primusrun on my Optimus laptop for quite some time now. However, since yesterday, both programs suddenly hang without actually launching anything for about a minute. I did install some regular distribution updates, but none of them appeared to be X related at all. After hanging for a while, both programs exit with an error message:

optirun: [ERROR]Cannot access secondary GPU - error: X unresponsive after 10 seconds - aborting

primus: fatal: Bumblebee daemon reported: error: X unresponsive after 10 seconds - aborting

However, the secondary X server with nvidia driver actually does start up, and when I run, e.g.

DISPLAY=:8 xterm

the xterm window shows up on the external monitor connected to the Nvidia card, so it appears to be a communication problem within bumblebee. Running bumblebeed and optirun with --debug doesn't produce any useful information, both programs just hang for about a minute and then exit.

Any ideas how to fix this?

I have a Dell Latitude E6430 laptop, running Ubuntu 14.04, connected to a 27" Apple Cinema LED Display (which works fine). By tweaking the appledisplay kernel module a little bit, I can even get proper entries for the backlight in /sys/class/backlight and change the brightness using echo XXX > /sys/class/backlight/appledisplay/brightness.

As icing on the cake, I'd now like to have the brightness keys on the laptop (which do work for the laptop screen) also control the big display's brightness. Unfortunately, this doesn't work - I was assuming that as soon as a new backlight device is available, it's also connected to the brightness keys.

Any hints?

I have a Huawei E3531 3G dongle (which works fine on Ubuntu 14.04, right out of the box). However, it registers as an USB-Ethernet adapter and I can't view any signal strength or other connection information except by visiting the dongle's internal webpage at 192.168.8.1. Can this dongle also be used as a ttyUSBx modem device so it works properly with network-manager?

Thanks! Florian

As soon as I go online via my portable 3G hotspot, all running programs happily start pulling updates (e.g. Gwibber, Thunderbird, Update Manager...) and eat into my traffic quota. Is there a way to activate a network connection, but only tell specific programs about it (e.g. Firefox, if I just want to quickly look something up)? Note that I'm not looking for bandwidth limiting, I just want to prevent the automatic "ooh, I'm online, let's get some data" behavior.

EDIT: I have already received two useful answers, however, I'd still like to add some clarification: what does NetworkManager do to tell running programs they're now online? I assume it's some sort of DBus message. Can I prevent that from being sent?

I'm wondering where exactly Seahorse is storing the keyring data?

Most available information points to ~/.gnome2/keyrings/, however, this directory contains only two very small files (login.keyring, 105 bytes and user.keystore, 207 bytes) which are definitely not large enough to contain the over 20 keys stored in my login keyring. I'd like to include the actual keyring data in my backup, so where is it?