The handling of efivarfs is different in chimaera and daedalus. I can only refer to sysvinit; other init choices may result in the same or different handling.

On daedalus, the fstab entry that is identified by the mount point /sys/firmware/efi/efivars is used 3 times by the initialisation scripting:

• Firstly as an explicit "mount" by mountkernfs.sh with the name "none" but using the options of the fstab entry for /sys/firmware/efi/efivars if any,

• Secondly as a "remount", also via mountkernfs.sh and in the name "none", but invoked by checkroot.sh, and

• Thirdly as a "mount -a" by mountall.sh which uses all the elements of fstab, esp its name efivarfs.

It's the first use that establishes the mount unless fstab says remount, since that requires a pre-existing mount.

In that third use, "mount" is unhappy auto-mounting over a mount point with content. The actual mount command used is:

mount -t efivarfs -oro efivarfs /sys/firmware/efi/efivars

The previous mount stays unaffected.

However, a later remount command may refer to the mountpoint via the name in fstab even though that's not the name of the mount of that mountpoint. Thus, if you are so inclined, you might add several fstab lines like

writable /sys/firmware/efi/efivars efivarfs remount,rw,noauto 0 0
readonly /sys/firmware/efi/efivars efivarfs remount,ro,noauto 0 0
thursday /sys/firmware/efi/efivars efivarfs remount,rw,noauto 0 0

and with that enjoy your personal command language dealing with the /sys/firmware/efi/efivars mountpoint. E.g.

# mount writable ; grep efivars /proc/mounts
# mount readonly ; grep efivars /proc/mounts

Note that the name of the mount stays the same.

Afaik, chimaera is different in not mounting efivarfs by mountkernfs.sh and therefore some of this entertainment is not immediately available.

The first editing could have worked, but the kernel to load need to be gunzip-ed first; make it a vmlinx instead of vmlinz.

I.e., gunzip the kernel and edit config.txt.

afaik nfs doesn't support xattrs.

Maybe duplicity would work for you instead?

It's vaguely interesting that you want to whine so incessantly about what you have and haven't installed.
Please go on.

So why not look for programs where they are rather than looking at some arbitrary place and then complaining when they aren't there?

I'm not sure which instructions you are trying to follow there, but that step doesn't seem right.

As far as I know, the partitioning tool used in the installer will expect that you first set up raid member partitions, thereafter you set up the raid device itself, and thereafter you partition and format that as if a single device.

1) "Normally" a migration is done with the running OS, and in that case it's really a VT console level activity.

Last time I looked into it, the Debian system seemed to have some new layers of confusion with a series of (Windows-ish) steps to  go through to reach a VT console level. That might be different now. The important bit is of course that the migration script needs to not be terminated prematurely when the init transition occurs, and therefore the shell that runs it must not be under any "session process control".

In your case, you could instead hook up drive B as the disk for a qemu virtual machine, and then migrate within that while idling in front of the browser on the "main" OS, drive A. The only particular quirk with that would be how to make drive B bootable by qemu (perhaps using extlinux)

In all cases you'll need a final grub setup after the migration; i.e. running update-grub with OS A to let it (re-)discover the drive B OS.

Though, I think I would call that a 201 activity as it does require sllghtly more than notional knowledge about running a qemu virtual machine, and about equipping it with an extlinux boot. It might not be your ideal solution but that's the way I can think of to let you view the instructions while following them. Printed on paper might be a better option.

2) You will need to re-update grub with OS A. Possibly already at the first of the two migration reboots.

3) The pinning will be preserved and shouldn't cause any issue ... unless, well, unless something.

4) And it shouldn't be an issue with keeping the old Tk either.

Why not pick one of the installer ISOs instead?
They have desktop, server or netinstall in their names.
https://www.devuan.org/get-devuan

Is anyone (still) getting those warnings from

wget --no-check-certificate https://www.devuan.org/get-devuan

The certificate was updated 2 weeks ago, and is valid some 8 or so weeks more. So there shouldn't be or have been any warnings.

No, nothing special or strange.

You post the link for the paste here, and then anyone can follow it  while it's valid.

Note that the certificate was Issued On Friday, October 21, 2022 at 10:55:06 AM and it Expires On Thursday, January 19, 2023 at 10:55:05 AM, so something strange is happening here.

Please do the following to download the certificate complained about

echo -n | openssl s_client -connect www.devuan.org:443 -servername www.devuan.org \
    | openssl x509 > /tmp/wwwdevuanorg.cert

and then upload that to pastebin.debian.org for us to review.

maybe you can teach your browser something by adding  .html to the end instead of /