I think I figured out what's going on with the legacy boot's .bin files not running. Isolinux is a variation of the Syslinux boot loader, and it uses the ISO 9660 format for CD/DVD images.

Here's a description of the "kernel" keyword.

https://wiki.syslinux.org/wiki/index.ph … ERNEL_file

KERNEL file

Select the file SYSLINUX will boot. The "kernel" doesn't have to be a Linux kernel, it can be a boot sector or a COMBOOT file.

Chain loading requires the boot sector of the foreign operating system to be stored in a file in the root directory of the filesystem. Because neither Linux kernel boot sector images, nor COMBOOT files have reliable magic numbers, Syslinux will look at the file extension. The following extensions are recognized (case insensitive):

 none or other	Linux kernel image
 .0		PXE bootstrap program (NBP) [PXELINUX only]
 .bin		"CD boot sector" [ISOLINUX only]
 .bs		Boot sector [SYSLINUX only]
 .bss		Boot sector, DOS superblock will be patched in [SYSLINUX only]
 .c32		COM32 image (32-bit COMBOOT)
 .cbt		COMBOOT image (not runnable from DOS)
 .com		COMBOOT image (runnable from DOS)
 .img		Disk image [ISOLINUX only]

Apparently, the "kernel" keyword tries to detect the type of boot image based on the file name's extension. So isolinux must be trying to load the memtest .bin files as a "CD boot sector", instead of a "Linux kernel image".

Using the keyword "linux" forces isolinux to boot the file as a linux kernel image, regardless of the file extension.

If that's all correct, I'm now wondering: since the Excalibur's isolinux for legacy boot and grub for UEFI boot are capable of running the memtest .efi, is it really necessary to include the memtest .bin in the boot menus?

Here are my test results. In addition to the menu items, I also tested the other two ia32 memtest files included in the .iso. I found some unexpected issues, so I organized my notes into a Q/A format.

* Tested images
- devuan_excalibur_6.0-preview-2025-05-19_1437_amd64_desktop-live.iso
- devuan_excalibur_6.0-preview-2025-05-19_1919_amd64_minimal-live.iso

* Memtest file presence test
Q) Are the memtest files present in the .iso?
A) Yes, both .isos contain 4 memtest files:
  - /live/memtest86+ia32.bin
  - /live/memtest86+ia32.efi
  - /live/memtest86+x64.bin
  - /live/memtest86+x64.efi

* Menu item test
Q) Do both memtest menu items refer to the correct file name?
A)
  - desktop-live, legacy boot : Yes
  - desktop-live, UEFI boot   : Yes
  - minimal-live, legacy boot : Yes
  - minimal-live, UEFI boot   : NO!
    - error: file '/live/memtest-x64.bin' not found.
    - error: file '/live/memtest-x64.efi' not found.
    - Looks like the file name is missing the "86". This is confirmed by looking in the .iso's file: /boot/grub/grub.cfg
    - I can edit the menu item and add the "86", and memtest86-x64.bin and .efi are correctly launched.

* Memtest starts successfully test
Q) Does the memtest actually run in legacy boot and UEFI boot?
A)
  * Legacy boot, desktop-live and minimal-live
    - /live/memtest86+ia32.bin : The PC hangs.
    - /live/memtest86+ia32.efi : Memtest works.
    - /live/memtest86+x64.bin  : The PC hangs.
    - /live/memtest86+x64.efi  : Memtest works.

  * UEFI boot, desktop-live and minimal-live
    - /live/memtest86+ia32.bin : Memtest works.
    - /live/memtest86+ia32.efi : Memtest works.
    - /live/memtest86+x64.bin  : Memtest works.
    - /live/memtest86+x64.efi  : Memtest works.

Since the ia32 versions are not available from the menu, I edited the menu item and manually typed in the file name.

And I still have NO CLUE why in legacy boot mode, the .efi files WORK, but the .bin files HANG. Based on the file extension, I would have expected that to be reversed.

- PCs that I tested on:
  - A 2011 PC, so it's legacy boot only.
  - A 2019 PC, which has both boot options.
  - A 2022 mini PC, which is UEFI boot only.

The legacy and UEFI results are confirmed on multiple PCs.

* Bonus test: minimal-live's accessible beep
Q) I discovered that the minimal-live's menu's "access" and "access-toram" beeping is INTENTIONAL. It's described in the README_minimal-live.txt. Do both boot mode's menus trigger the accessible beep?
A)
  - minimal-live, legacy boot : Yes
  - minimal-live, UEFI boot   : NO!
    - In legacy boot's config file "isolinux/isolinux.cfg", both the "access" and "access-toram" menu labels have a 0x7 byte, the ASCII beep character.
    - But in the UEFI boot's config file "/boot/grub/grub.cfg", these menu items do NOT have the 0x7 byte. Maybe it was left out by mistake? Or maybe grub.cfg doesn't support the beep character?

* Other useful things that I learned from this test
  - At the boot menu, you can tell if the PC booted in legacy boot or UEFI boot by looking at the background.
    - In legacy boot, the desktop-live has a colorful blue background, and the minimal-live has a bright white background.
    - In UEFI boot, both have a plain black background. It looks like something you'd see in a console window.

  - The location of the boot menu config is:
    - Legacy boot: /isolinux/isolinux.cfg
    - UEFI boot: /boot/grub/grub.cfg

I ran into a problem with the memtest in "devuan_daedalus_5.0.0_amd64_minimal-live.iso". I also found some solutions.

* Laptops I was testing

- HP Elitebook 745 G3 (AMD PRO A10-8700B)
- HP MT45 Mobile Thin Client (Ryzen 3 Pro 3300U)

* Problem

When you try to run the memtest, you get this error:

error: version too old for 32-bit boot

* Best explanation I have so far

The Devuan Daedalus Minimal Live's default memtest doesn't seem to work in UEFI boot mode. The workaround is to launch one of the other memtest files, or use legacy boot.

* Solution 1 - try a different memtest file

The .iso image comes with two other memtest files "memtest86+x64.bin" and "memtest86+x64.efi". On my laptops, both of these worked. You'll have to edit the menu item to run these files.

- In the grub menu, move the cursor to Memory test.
- Press 'e' to edit the menu command.
- Change the file name from "/live/memtest" to one of these.

/live/memtest86+x64.bin
/live/memtest86+x64.efi

- Press F10 or CTRL+X to boot with the changes.

* Solution 2 - legacy boot

You'll have to check your PC/laptop's BIOS to see if it supports legacy boot mode.

I also discovered that although these two HP laptops do support legacy boot, they failed to show the USB drive as bootable in legacy mode. The solution was to use "fdisk" and turn ON the bootable flag for the EFI partition "partition 2". Then these laptops showed the USB drive as a boot option in legacy mode. Not sure if that's specific to these laptops or if that's normal for all PCs/laptops using UEFI and legacy boot.

* Short answer

The reason why "devuan_daedalus_5.0.0_i386_desktop-live.iso" can't run memtest is because the memtest app was not included in the .iso. As mentioned in this thread, that was probably a mistake.

The workaround is to download minimal-live/devuan_daedalus_5.0.0_i386_minimal-live.iso. That image does have memtest.

That doesn't mean that you have to install from the minimal-live. You can run the memtest from minimal-live, then run the desktop-live's installer.

* How to check the iso

Create a temp directory, then mount the iso to that directory.

mkdir /tmp/isofiles
sudo mount <filename>.iso /tmp/isofiles

Inside the "isofiles" directory, open the file "isolinux/isolinux.cfg" in a text editor. You should see a menu option like this:

label memtest
    menu label Memory test
    kernel /live/memtest

That means that the Memory test option will try to run "/live/memtest".

Now check the "live" directory and see if "memtest" is there.

To clean up, unmount and delete the temp directory.

sudo umount /tmp/isofiles
rmdir /tmp/isofiles

I finally have some free time to make some progress on this issue. Here's an update on what I've done and what I've learned about filing bugs. Perhaps someone in the future will find this info useful.

I looked at the current pluma source code, and the file that causes this GUI bug (pluma/pluma-encodings-combo-box.c) hasn't been changed in two years. Also, reading the code, the bug definitely still exists.

https://github.com/mate-desktop/pluma/

I created a github account and reported the issue and my proposed fix and its side effects. Ideally, I should create a pull request, but I don't know how. I'll have to try that the next time I have some free time.

https://github.com/mate-desktop/pluma/issues/703

I decided to file a bug in the Debian Bug Tracking system so that there's a record that this issue has already been posted. Devuan Daedalus has a tool "reportbug" used to report bugs to Devuan or Debian. First, I had to configure the reportbug tool so it knows what sender name and email address to use, and whether to use a GUI or a console text interface.

reportbug --configure

Then I ran the tool, which launched the bug reporting GUI.

reportbug $(which pluma)

Which posted the bug here:

https://bugs.debian.org/cgi-bin/bugrepo … ug=1089560

According to the Debian bug reporting instructions, I'm supposed to file the bug with Debian first instead of going straight to the Mate repository, since it's possible that a bug could be caused by changes made by the Debian package maintainers. Oops, too late now.

One thing I don't know is how this bug can be fixed in the current Devuan Daedalus distribution. Am I supposed to create a patch? Will the Debian maintainers create a patch? If I figure this out, I'll follow up with an update. That's all for today.

I also need an init script so that I can launch the x11vnc server without a user logging in. I broke up the task into two subtasks:

  - Figure out how to set up the init script, how it launches, what args it receives.
  - Write the logic for starting and shutting down the x11vnc server.

Today, I figured out some of the basics for writing an init script, starting it etc. Next time I have free time, I'll figure out how to start and stop the vnc server from the init script.

These steps were tested in Devuan Daedalus, with the MATE desktop environment.

* Create the script file

The init scripts are located in /etc/init.d. In this example, we'll create a script that will log all of the script args into a log file.

sudo pluma /etc/init.d/yourinitscript.sh

Put these contents in the file.

#!/bin/sh

#If you modify the INIT INFO section, update the rc.d links with these commands (as root):
#  update-rc.d yourinitscript.sh remove
#  update-rc.d yourinitscript.sh defaults
### BEGIN INIT INFO
# Provides: yourinitscript.sh
# Required-Start:
# Required-Stop:
# Default-Start: 1 2 3 4 5
# Default-Stop: 0 6
### END INIT INFO

#Write the current date/time, previous and current run levels, and the args passed into this script into the log file.
echo "`date` | runlevel `runlevel` | script args received: $*" >> /var/tmp/yourinitscript.log

Sysvinit uses the INIT INFO section to figure out the dependencies and what order each init script should be launched. These five appear to be the minimum required params that an init script needs to define.
  - Provides : I think sysvinit uses this to identify your script when it figures out the dependencies.
  - Required-Start: This defines what other init scripts must be run before telling yourinitscript.sh to start its service. In this example, we don't have any dependencies, so we leave it blank.
  - Required-Stop: Other init scripts that must be stopped before telling yourinitscript.sh to stop its service.
  - Default-Start: When sysvinit is running at these run levels, yourinitscript.sh will be started if it's not started.
  - Default-Stop: When sysvinit is running at these run levels, yourinitscript.sh will be stopped if it's started.

* Set up the symlinks

First, the script must be executable.

sudo chmod +x /etc/init.d/yourinitscript.sh

Next, we tell sysvinit to set up the symlinks that will run yourinitscript.sh whenever the services needs to be started or stopped.

sudo update-rc.d yourinitscript.sh remove
sudo update-rc.d yourinitscript.sh defaults

The symlinks are created in the subdirectores for each run level: /etc/rc0.d, /etc/rc1.d, /etc/rc2.d, etc.

I haven't figuured out why, but if you modify the script's INIT INFO section and then run "update-rc.d defaults", the command will give warnings. The workaround is to always "remove" any previously setups of yourinitscript.sh, then set up it with "defaults".

* Test the init script

To test that the script is working correctly, use the "service" command. You can pass in any args into your init script.

sudo service yourinitscript.sh aaa bbb ccc

Read the log file.

cat /var/tmp/yourinitscript.log

You should see this line in the log file.

Sun Jun 23 07:32:18 PM PDT 2024 | runlevel N 2 | script args received: aaa bbb ccc

Notice that the previous run level is "N", which means there's no previous run level. The current run level is "2", which is defined in /etc/inittab.

# The default runlevel.
id:2:initdefault:

Also notice that the script received the 3 dummy args "aaa", "bbb", and "ccc". This means that if necessary, your init script can receive all sorts of args. That is, it's not restricted to a specific set of keywords.

* Reboot the PC

Reboot the PC, then check the log file.

cat /var/tmp/yourinitscript.log

There should be two new lines.

Sun Jun 23 19:33:58 PDT 2024 | runlevel 2 6 | script args received: stop
Sun Jun 23 19:34:26 PDT 2024 | runlevel N 2 | script args received: start

Notice that on the first line, the previous run level is "2" and the current runlevel is "6". "6" is the runlevel that means the PC is rebooting.

Also notice that the script received the "stop" arg when the PC was shutting down for a reboot, and the "start" arg during the next boot. So your init script should at least handle these two args.

* Shutdown, then manually power up again

Shut down the PC. Then turn it back on.

cat /var/tmp/yourinitscript.log

There should be two new lines.

Sun Jun 23 19:45:27 PDT 2024 | runlevel 2 0 | script args received: stop
Sun Jun 23 19:46:04 PDT 2024 | runlevel N 2 | script args received: start

Notice that during the shutdown, the current runlevel is "0". "0" is the runlevel that means the PC is shutting down (halting).

* Uninstall

To uninstall the init script, first remove the symlinks.

sudo update-rc.d yourinitscript.sh remove

Optionally, delete the script. Make sure you have a backup copy of this script so you can install it again if needed!

sudo rm /etc/init.d/yourinitscript.sh

Hopefully, these steps are helpful to someone.

@zapper - more specifically, AMD's low end mobile 2018 processor.

I don't think the RK3588 would be twice as fast. More fun with passmark numbers

  i7-3520M | 2 cores / 4 threads | 2871 / 1743
  RK3588   | 4 cores + 4 cores   | 4515 / 1479

From these numbers, the RK3588 would be slightly slower in single threaded, but more total compute power if you can use all 8 cores.

I noticed that the RK3588 shows up in passmark's midrange CPU benchmarks . It's current total / single score is 4515 / 1479. So the 8 core RK3588 has roughly the same total performance as the AMD Piledriver FX-6350 6 core. The single threaded score is roughly the same as the AMD Phenom II 1100T. I don't know much about Intel model numbers, so I can't tell what Intel CPUs the RK3588 is roughly comparable to.

EDIT:
OK, I see now that the MNT Pocket Reform is an "open hardware" laptop. That explains why you were asking about mobile CPUs. Sorry, my answer may not have been helpful, since I was comparing to desktop CPUs that I knew of.

I have found that memtest in the live builds is a useful tool. For example, when someone gives me a PC to test and troubleshoot, I use the memtest to confirm that all memory sticks are working. Then I load the live desktop to check what hardware is installed on the PC. In a few cases, I have copied files from the PC's storage drives. So yes, memtest has been useful.

golinux - I don't think I'm doing any kind of redirecting for the way my devuan mirror is set up. I followed these apt-mirror instructions, and to expose the deb.devuan.org from my local mirror server to my devuan jessie PC, I think I just need to change my /var/www/merged symlink to point to my local mirror of the deb.devuan.org packages, as shown in these instructions.