Looks good to me :-)

There is no pinning for that package. If you run apt update followed by apt list --upgradable I think gnome-sudoku will still be marked for upgrade to the chimaera version.

The apt-mark hold suggestion doesn't work either in my testing but this does:

Package: gnome-sudoku
Pin: version 1:3.30.0-2
Pin-Priority: 501

^ Save that under /etc/apt/preferences.d/gnome-sudoku.pref, run apt update and check the Candidate line in the output of apt policy gnome-sudoku. It should prefer the old version with that setting.

The man page states that a pin value of 1001 would be needed because the beowulf version constitutes a downgrade but that doesn't seem to be the case in my tests with a Debian bullseye chroot. If your system behaves differently please report back, I would appreciate the feedback. TIA.

If you want to keep the package updated from beowulf then add these lines to /etc/apt/sources.list:

deb http://deb.devuan.org/merged beowulf main
deb http://deb.devuan.org/merged beowulf-updates main
deb http://deb.devuan.org/merged beowulf-security main

Then change the Pin: version line in /etc/apt/preferences.d/gnome-sudoku.pref to

Pin: release beowulf

And remember to run apt update afterwards.

Because it's very complicated to use (see apt_preferences(5) for the official documentation, the Debian wiki page is bollocks) and it's far too easy to break your system if you don't know what you're doing.

I've just got the Debian buster version of gnome-sudoku running from a chroot in my Alpine system with no issues but the chroot takes up almost a gigabyte of disk space, which is ridiculous.

For the mini.iso images just use

# cp mini.iso /dev/mmcblkX ; sync

Replace X with the correct identifier for the SD card. It should be copied to the entire card rather than a partition.

I think the armel versions need the various components copied to specific locations on the card using dd and the seek option but I've never actually tried it so I'll have to leave that to somebody who knows better.

Please stop posting vague, confusing descriptions. Instead post clear explanations of what you actually see.

Do not ask about XY problems. Instead simply state the actual issue, which in this case is that your AMD graphics are not working. UEFI has *nothing* to do with that and installing a non-UEFI system will not help. Please change the thread title to reflect this and help prevent further confusion and noise.

@fsmithred's suggestion to try a newer kernel might help. Brand new hardware might not be supported by chimaera's six month old kernel.

Unfortunately though the AMD graphics firmware hasn't been updated since 2021-08-18, even in ceres, so you might have to draw it directly from upstream:

apt install git
git clone https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
cp -r linux-firmware/amdgpu /lib/firmware

Required reading: https://forums.debian.net/viewtopic.php?f=16&t=104157

Yes, word splitting is needed to avoid passing the options as a single string.

A bug has been filed: https://bugs.debian.org/cgi-bin/bugrepo … bug=998650

No action yet though.

@Miyo: sorry but I'm not in the mood. You can stop baiting now.

Erm, I don't know. I have an X201 but I don't have any portable NVMe SSDs. Sorry.

SSD longevity is very good these days, they may even outlast spinning rust drives now.

My ThinkPad P14s Gen 2a NVMe drive has had ~6TB of writes and reports itself as 1% used in respect of total lifetime:

alpine:~$ doas nvme smart-log /dev/nvme0n1 | grep 'percentage\|write'
percentage_used				: 1%
host_write_commands			: 66812355
alpine:~$

See also https://techreport.com/review/27909/the … -all-dead/ ← and that's almost seven years old now so current drives should be even better.

There shouldn't be compatibility problems for any hard drives. The firmware exposes the same interface regardless of manufacturer AFAIK.

They just provide status messages for startup and rc-status.

The OP has clearly been modifying their system in various ways because I can't get the k3s service running under OpenRC without changing the source bashism to .. Since they can't be bothered telling us what they have done to either of their systems or even share more information about this k3s service I really can't be bothered digging deeper...

Since we're posting political stuff:

https://theanarchistlibrary.org/library … t-faq-full

All you lucky Devuan users can install a local copy under /usr/share/doc/anarchism/ with

# apt install anarchism

Related:

# apt install fortune-anarchism

Got it.

Create a file at /usr/local/bin/gdebi-gtk with this content:

#!/bin/sh
pkexec /usr/bin/gdebi-gtk "$@"

Then save the file and make it executable:

# chmod +x /usr/local/bin/gdebi-gtk

So now pkexec will ask for the password and authorise gdebi before it attempts to install the .deb.

It's a horrible hack and it shouldn't be needed. Perhaps consider opening a bug report about this.