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 
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? 
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?
Okay, Iām feeling a little dumb here.
I had an unclean reboot of Ubuntu 22.04. I read that I should hit my SSD with fsck, but to make sure it isnāt mounted. I rebooted with a live CD, dropped to a terminal, and ran fsck /dev/nvme0n1p1 (which is my root drive) and it said it canāt run because it isnāt mounted. I mounted it (cautiously) and reran fsck which then warned me it would screw the partition up. So then I unmounted it again and re-ran fsck, which again refused to run because it wasnāt mounted. What am I missing here?
I just tested this on my /boot partition (bravo, not romeo) and it seemed to work as expected. I was only able to fsck when it wasnāt mounted. I wonder if the filesystem is corrupted and it is reported bad information. Also, what filesystem do you have on your root drive?
# fsck -fv /dev/nvme0n1p2
fsck from util-linux 2.36.1
e2fsck 1.46.5 (30-Dec-2021)
/dev/nvme0n1p2 is mounted.
e2fsck: Cannot continue, aborting.
# umount -l /boot/
# fsck -fv /dev/nvme0n1p2
fsck from util-linux 2.36.1
e2fsck 1.46.5 (30-Dec-2021)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
349 inodes used (1.07%, out of 32768)
3 non-contiguous files (0.9%)
1 non-contiguous directory (0.3%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 341
65278 blocks used (49.80%, out of 131072)
0 bad blocks
1 large file
333 regular files
7 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
------------
340 files
# mount /boot/
1 Like
Iām using ext4. It was weird. When it was mounted, fsck said donāt do that. So I unmounted it, and then fsck said mount it. LOL!
1 Like
EXT4 does support online fsck now. It has been there for about 10 years. I would still recommend doing it offline, just add the force flag maybe?
Also, if you modify the FSTAB entry to do a scan of the drive, your init should force the scan due to dirty shutdown.
1 Like
Thank you! I think I got it, now! 
Turned on my living room PC with 20.04 (desktop) and it hits the boot screen okay then it just goes to black with a flashing cursor ā¦