Hmm... looks like grub can use any of these files:
/boot/grub/menu.lst
/boot/grub/grub.conf
/boot/grub/grub.cfg
/boot/grub2/grub.cfg

in /usr/lib/linux-boot-probes/mounted/40grub2, function parse_grub_menu() :

if [ -z "$title" ]; then
	ignore_item=1
elif echo "$title" | grep -q '(on /dev/[^)]*)$'; then
	log "Skipping entry '$title':"
	log "appears to be an automatic reference taken from another menu.lst"
	ignore_item=1
fi

That's why it skipped the entry - it matched the string.  For your particular case, the easiest fix would probably be to patch 40grub2, but that wouldn't help others who encounter the same problem.  Does arch use the same version of grub2?

Hopefully this is the problem:

In /etc/default/grub, find the line

#GRUB_DISABLE_OS_PROBER="false"

and remove the # symbol:

GRUB_DISABLE_OS_PROBER="false"

It's worded kind-of awkwardly, but that will make grub not disable the os-prober, that is, it will enable the os-prober.
After saving the file, re-run update-grub

There are a few ways to do this.  Replace command_user="radio" with command_user="$USER" is one way (probably the way that makes the most sense).  Another option is command_user="$(whoami)".  If you want a non-sensical solution, use command_user="$(env | grep ^USER= | cut -c 6-)" (but that is a very strange way to get the USER).

(from reading back in my irc logs) Something similar was tried for a short time.  Unfortunately, the first "D" in DDoS (Distributed) meant that approach was not very effective.  After successfully slowing down the bots for a few days via IP-address blocking, they adapted to use a unique IP address for each request. Before anubis was added to the site, the web interface was pretty much unusable most of the time.

If that's all that is done, just use a user-agent that displays the actual o/s family (i.e. Linux).  There are several "valid" (default for a browser) user-agents that could be rotated through, without needing to report Windows as the o/s.  I know it's not a perfect solution for privacy, but the user-agent string matching the operating system probably isn't a huge deal.  I wonder what happens if your user-string says "MyBrowser 1.2.3.4" - will anubis block access entirely?

I know it's not an "official source" like you asked for, but I do have a copy of the file I think you're looking for

-rw-r--r-- 1 tempo tempo 4045406208 Oct 20  2023 devuan_daedalus_5.0.0_amd64_desktop.iso
-rw-r--r-- 1 tempo tempo       4711 Sep  1  2023 README.txt
-rw-r--r-- 1 tempo tempo       1453 Sep  1  2023 SHA256SUMS.txt
-rw-r--r-- 1 tempo tempo        833 Sep  1  2023 SHA256SUMS.txt.asc

I could upload it somewhere if you really need it - or it might still be available via bittorrent (?)

In another post you mentioned that "Daedalus 5.0.0 desktop DVD and Daedalus 5.0.0 live usb for UEFI works well."  Does this mean you have the Daedalus 5.0.0 desktop DVD?  You should be able to make an iso image from the dvd, if that's what you need.

Next step, rewrite the scraper in C
:-)

I have a RPi3b+ running devuan.  (actually, 2- one of them I manage remotely but can gain physical access to it if needed).  Like you, I believe I started with ascii on it, some image obtained from https://arm-files.devuan.org/ written directly to SD card (since then, I've moved to external USB storage).  Never tried an installer (don't think it was around then for arm).
Is there any particular reason for staying on ascii?  I've upgraded mine, one to chimaera the other to daedalus.  The first upgrade I think I had to resize the boot partition because the original one was too small.  If you're setting it up new and don't have anything important already set up that you need to keep, it's probably easiest to download a more current image and dd it to your RPi media.

dDepending on your needs, Genymotion (https://www.genymotion.com/product-desktop/download/) may work.  I used it in the past, seems like it's gotten a bit worse in later versions though from my perspective.  It's something you could try, but it seems a bit hit-and-miss as far as app compatibility is concerned.  It gives the option of using VirtualBox or QEMU for hypervisor.

I just noticed this problem yesterday on a VPS that I use.  But it does not affect a different one.  Both on the same kernel, 6.1.0-37 (amd64).  May have something to do with the hosts.  Thanks for tracking it down and finding a solution!

Not sure why backports kernel wouldn't work in your case.  But to remain on a specific kernel version you could try this,
create a file in /etc/apt/preferences.d  - you could call it pin-kernel  or something
The contents would be:

Package: linux-image-amd64
Pin: version 6.1.137-1
Pin-Priority: 1001

  You didn't mention architecture, so I'm assuming amd64.  After creating that file, run `apt update`.   I haven't actually used this with a kernel so not 100% sure on it.  Keep an eye out for later kernel updates, once there's one past 6.1.0-37, you may want to try it out.  To do so, remove the pin-kernel file and run `apt update` again.  (or apt-get, or whatever you use to upgrade).

You were on the wrong archive page.  Try this one https://web.archive.org/web/20250209214 … mail/cups/