The small linux problem thread

KeyPress event, serial 40, synthetic NO, window 0x7000001,
    root 0x1ed, subw 0x0, time 8036965, (-399,213), root:(1872,832),
    state 0x10, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x7000001,
    root 0x1ed, subw 0x0, time 8037072, (-399,213), root:(1872,832),
    state 0x10, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False
KeyPress event, serial 40, synthetic NO, window 0x7000001,
    root 0x1ed, subw 0x0, time 8603183, (-968,234), root:(1303,853),
    state 0x10, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 41, synthetic NO, window 0x7000001,
    root 0x1ed, subw 0x0, time 8603342, (-968,234), root:(1303,853),
    state 0x10, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

is what I get when pressing f8 without and with fn.

KeyPress event, serial 40, synthetic NO, window 0x7000001,
    root 0x1ed, subw 0x0, time 8808518, (-225,1014), root:(226,1900),
    state 0x10, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x7000001,
    root 0x1ed, subw 0x0, time 8808654, (-225,1014), root:(226,1900),
    state 0x10, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False
KeyPress event, serial 40, synthetic NO, window 0x7000001,
    root 0x1ed, subw 0x0, time 8867263, (-179,39), root:(272,925),
    state 0x10, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x7000001,
    root 0x1ed, subw 0x0, time 8867375, (-179,39), root:(272,925),
    state 0x10, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

f11/playplause on another keyboard with and without fn.

Not sure what to make of the numbers and there’s no listed function lock key in the manufacturers site.

If you do apt get upgrade, this should not break your system, it will not remove anything, it will only upgrade existing packages and install any new dependencies. Once you get through that, you can do the atp full-upgrade to get to the current version of your release. This is destructive and this is where you may have some conflicts like what you are describing.

Are you mixing and matching repositories or are you only using the default Debian repositories? Are you mixing Debian versions? I think I am the resident Debian shill here and I run unstable/SID as my daily, I rarely have breakage issues until a major release is imminent and they shift the repos over by one.

As far as roll back, there is a way but you need to be on XFS or BTRFS to utilize it I think. Otherwise you need to dump your currently installed package list to a file to use for play back if you want to force roll back packages.

Otherwise, you will have to install each upgradable package in groups of main + dependencies.

1 Like

yep it shouldnt but i does on debian… quite regularly. :frowning:
last time for me was the nvidia non-free gpu drivers… when they went from 490? to 520
the non-free was loading the the 490? driver but trying to install cuda for 520.

i thought i broke something so spend half a day trying to fix it only to download a fresh image and have the same thing happen again.
3 days later i found a solution… and a day after nvida sorted it there end.

then last month debian got a big update and guess what… more shit broke.
something to do with php8.1 so again i just re-imaged.

as for pepsi… your best bet is a new image if stuff is breaking.
especially if its full version updates you need.
and debian stable?.. not if your doing nightly build updates or even weekly ones.

1 Like

I guess you mileage may vary but, Debian is my daily for a reason. I have been running SID since ~2007 with limited issues minus what was mentioned above. I tend to run all AMD systems though as I have been burned by nVidia too many times in the early 2000s. I don’t run stable on my devices though. I use testing as a bare minimum on my SBCs or ArchLinuxARM if they are supported.

2 Likes

I have main, contrib and non-free repos enabled but that is it. No sid or testing. I don’t install .deb packages outside these and use Flatpaks and AppImages for everything else. But as HEXIT points out some package updates do weird things even in Debian.

It is not like Debian doesn’t know this happens because they have a wiki page about rolling back updates at https://wiki.debian.org/RollbackUpdate except apt-get it not playing along to follow their guide - see further below.

Changing the file system now is not preferred as my root partition is already set up as ext4. I will park this for when I do a full release upgrade. I suppose btrfs + a utility like timeshift will give the equivalent to Windows System Restore?

Currently, I do periodic manual partition image back ups to my NAS using Clonezilla before I make major changes and that is how I recovered when I initially upgraded all the packages and things broke. But this is cumbersome to do every time I want to update a package. Can timeshift be used with rsync to a Samba share on the network? Can rsync do a full backup on a live file system? This is why I have opted for Clonezilla.

Back to the alternative, I have created a log of current and to be upgraded version list of packages using the utility apt-show-versions. To test the water as an example I upgraded unzip utility from version 6.0-26 to 6.0-26+deb11u1. Then I tied to roll back to the previous version manually using sudo apt-get install unzip=6.0-26 and got the following error:

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Version '6.0-26' for 'unzip' was not found

Not sure why. It looks like apt-get no longer offers the previous version?? This means I need to keep a local copy of the .deb package and force a downgrade using dpkg. I am loathed to do this because it doesn’t keep track of dependencies. Anyway, the question is where do I get the existing version .deb package? From the installation media I used?

I am also a Debian shill because I have a soft spot for it having used it over many years on and off plus on Raspberry Pis but this whole situation of unreliable package updates makes me feel like I am in Arch land. Once I isolate the offending package/s I will share more details of it and also make a bug report.

I suggest you look into btrfs.

1 Like

Strange, xev is seeing no difference at all.

Quick search says this may be KDE doing weird things:

Or changing the settings in the BIOS may help:

apt-cache policy <package name>

should give you a list of your installed version and any available previous versions in the repo’s

then

sudo apt-get install <package name>=<version>
2 Likes

You’ll find the available packages/versions here: http://ftp.debian.org/debian/pool/main/u/unzip/

If you’re trying to get a really old version of something, you may need to modify your /etc/apt/sources.list and perhaps add a line pointing to http://archive.debian.org/debian/.

But HEXiT’s advice may be what you really need…

2 Likes

I suggest you try something that can read the /dev/input/event’ -type devices, xev events might be filtered beforehand. Also, sometimes special keys show up on separate devices. That should also be independent of the desktop environment.

The main and unstable Debian archives don’t have the version of unzip 6.0-26 which is bizarre. It seems I have to get the .deb file from snapshots.debian.org and install with dpkg

1 Like

well at least you know why it wont install :wink:

2 Likes

Turns out timeshift works with rsync too. I was able to update the packages in small batches and narrow down the offending package then roll back and freeze those. Turns out it is a bug in GTK that affects cups printer discovery in system print dialogue box.

2 Likes

I am… slightly confused. I can’t push or pull to/from GitHub anymore and I don’t know why.

z% git push github --tags
Enter passphrase for key '/home/tarulia/.ssh/github_private': 
[email protected]: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

???

Naturally my first idea was well maybe GitHub removed my key for some reason. But no, it’s there. It’s been in use since 2015 with no issues. For the last 2 years even. Not sure when it started since I haven’t used it much the last couple months.

Their help page doesn’t seem to help me here…

The only thing they list that I could try was this:

z% ssh -vT [email protected]
OpenSSH_8.8p1, OpenSSL 3.0.5 5 Jul 2022
...
cebug1: Trying private key: /home/tarulia/.ssh/github_private
Enter passphrase for key '/home/tarulia/.ssh/github_private': 
debug1: load_identity_file: Skipping key /home/tarulia/.ssh/github_private: Invalid key length
debug1: No more authentication methods to try.
[email protected]: Permission denied (publickey).

Uuuh OK? Anyone know if they changed anything regarding minimum requirements? If so they aren’t listed in the help pages…

This might be related, but I think this would be algo error, not key length. I guess I would check to see what your key length is and what algorithms it uses. 1024 bits is generally deprecated… how old are your keys?


Note: GitHub improved security by dropping older, insecure key types on March 15, 2022.

As of that date, DSA keys (ssh-dss) are no longer supported. You cannot add new DSA keys to your personal account on GitHub.com.

RSA keys (ssh-rsa) with a valid_after before November 2, 2021 may continue to use any signature algorithm. RSA keys generated after that date must use a SHA-2 signature algorithm. Some older clients may need to be upgraded in order to use SHA-2 signatures.

How would I check that? :sweat_smile:

Well as mentioned it’s on the account since 2015 but I believe I created it before then already, so not entirely sure.

ssh-keygen -l -f ~/.ssh/github_private

This is very similar to a problem I was dealing with weeks ago. Trying to SSH into an old piece of network gear was quitting immedately with “Bad server host key: Invalid key length”

The crypto-policies package on at least RHEL9 and Fedora were recently updated to set RequiredRSASize 2048 in /etc/crypto-policies/back-ends/openssh.config even in LEGACY mode which I use. ssh on my own PC was seeing the server used a 1024-bit RSA key and would refuse to continue connecting.

I didn’t find a better fix than modifying that line in the file myself, and setting the file immutable so future crypto-policies updates don’t/can’t change it without my allowing it (and having the opportunity to immedately change it back before an ssh process breaks).

1 Like

Thank you, however, I’m getting this:

z% ssh-keygen -l -f ~/.ssh/github_private
/home/tarulia/.ssh/github_private is not a key file.
z% file ~/.ssh/github_private             
/home/tarulia/.ssh/github_private: PEM RSA private key

what D:

My mistake… Try pointing ssh-keygen to the public side of the key. Your non-standard naming scheme must be preventing it from guessing the file name for that one.

And for the next question, ssh-keygen -y will generate the public key from an unencrypted private key, if you don’t have that handy.

1 Like

Thank you that worked

z% ssh-keygen -l -f ~/.ssh/github_public
1024 SHA256:cavzFgUdePDx17bL/BG8aRZmV5v6THVlJ8mZHYv+yg4 no comment (RSA)

This is freshly generated as per above.

I guess that matches with what you said earlier


I’m guessing I can’t just keep the private key and just generate a newer longer public key? Probably need an entirely new pair?