efibootmgr -o xxxx,yyyy

Replace xxxx & yyyy with the boot numbers for Void & Devuan, respectively. Running efibootmgr with no arguments will list the current NVRAM boot entries and their order.

I take your point about using UUIDs when multiple drives are present.

The 177 line grub.cfg file created for Void has does not contain the strings "msdos" or "gpt", but I can see that msdos->gpt would be right;  I assume that files in /etc/grub.d/ are used by grub-mkconfig to create grub.cfg.  Unfortunately, I can't find out what Devuan would put here without actually letting the installer load the bootloader.  Lots of thinking needed.  Maybe a few experiments.

I am probably making too much of a meal of this and should just rsync backup everything to USB drive and let the Devuan installer run bootloader as its last step.

I don't use Void so I have no idea if they have an equivalent to De{vu,bi}an's kernel & initramfs symlinks in the root partition.

But you probably don't need the insmod stuff anyway. In my experience GRUB is pretty good at autoloading modules.

EDIT: looks like the Void grub package uses this script in /etc/kernel.d/ so you could replace that with your own script to change the kernel & initramfs image names to match the new, updated versions. I presume a .post suffix for the script would cause it to be applied after any kernel upgrade.

And if you have more than one hard disk, you're better off using UUIDs instead of /dev/sda2, in case the drives don't always come up in the same order.

Really? Not 'hd0,gpt2'? You have msdos partition table with uefi instead of gpt?

@fsmithred:  it sounds like the Devuan installer does the right thing.  To be safe, I will use rsync on both partitions and "sgdisk --backup" to save the partition table.

@rolfie:  I didn't understand your reply [my fault].

@head_on_a_stick?  your solution implies that, as long as I don't allow the Devuan installer to install the GRUB bootloader, then I can create my own complete menuentry script for Devuan and append it to the end of the Void grub.cfg file [running grub_install from Void].  That sort of implies that I can replace the Void supplied monster grub.cfg with a simpler:

  menuentry 'Void 5.9.16  runit restart [sda2]' {
     insmod gzio
     insmod part_msdos
     insmod ext2
     set root='hd0,msdos2'
     linux /boot/vmlinuz-5.9.16_1 root=/dev/sda2 rootfstype=ext2 quiet ro nosmt
     initrd /boot/initramfs-5.9.16_1.img
  }

which makes no reference to UEFI!  Or am I missing something?

With the downside that you have to modify this with every new kernel manually, there will be no automatic configuration possible.

The OP can add a custom menuentry in Void for Devuan that boots from the /vmlinuz & /initrd.img symlinks in the Devuan root partition that always point to the latest version:

menuentry 'Devuan' {
   search.fs_uuid $uuid
   linux /vmlinuz ro quiet root=UUID=$uuid
   initrd /initrd.img
}

Replace $uuid with the actual (filesystem) UUID of the Devuan root partition and put that stanza at the end of the file at /etc/grub.d/40_custom in Void then run this command in Void:

# grub-mkconfig -o /boot/grub/grub.cfg

Apart from that: use manual partitioning, make sure you hit p3 for Chimaera. Note: I have made the experience that with the first boot past the install the efivars are not mounted. I am adding that to the fstab. There are threads about that here in the forum.

If you have further questions, please ask.

rolfie

With uefi, each system that installs a bootloader will create a directory on the efi partition without removing any previous directoryies. If you install the Devuan bootloader and then want to go back to letting Void boot the computer, you can remove the Devuan entry with efibootmgr. It will be removed from the list of bootable devices that efibootmgr shows you, but the directory will still be there. You would have to do something extraordinary to screw it up permanently.

I now want to install Devuan 4.0 on partition 3, but I am  wary of messing up.  Does the netinstall.iso installer work as I would expect:  detects the Void system in partition 2, and constructs a combined grub.conf with Void and Devuan choices?

When I say "wary" I mean terrified, as I wasted 2 days trying and failing to convert the system from UEFI to MBR.

All my previous computers over 2.5 decades have been MBR-based, so this is all very new to me.

Thanks.