You are right, rolfie. But have you tried that with RAID1 installations???
The little boot partition plus LVM2 on the second partition overcomes all these "limitations". It's still quite usual on enterprise-server hardware.

I don't know your hardware or motherboard.
My test machine can do both, old-style BIOS mode and UEFI mode. (My experiences with software RAID1 System-installations in UEFI-mode are quite bad)
However, I suggest that you stick to one scheme:
Either
-BIOS/MBR mode mainboard
-MBR / DOS disk labels
-Boot the stick with the USB NON_UEFI selection.
Or
-EFI/UEFI mainboard
-GPT disk labels
-Boot stick with the USB UEFI selection.

When booting, EFI mainboard firmware offers you the UEFI-USB-Boot option to load the USB stick. In that mode you do a EFI-mode Devuan install and the installer proposes GPT disk formatting. On MBR/BIOS hardware this would be in MBR mode with DOS labels on the disk. I wouldn't force to mix the modes, even though possible. I'm no specialist in UEFI tricks, but HoaS seems to know a lot more on that topic.
You may be able to mix up these elements, but the result could be "interesting".

In MBR mode you can go as instructed in my post. In EFI mode you must have 1 active, bootable EFI partition. you can set aside a second such partition on your second disk. After successful installation you can then dd the active EFI partition to the inactive second one. Maybe it works?

Colburn,
I have done some testing and research to your problems.
First of all it seems that your computer/server/mainboard has not been set up properly.
There are 2 ways to operate hardware and its OS to be installed: UEFI or classic MBR type. This affects the boot process and how the disks are used.

1. UEFI
=======
This is a very tricky new solution. EFI is a good solution to overcome limitations to the classic PC restrictions. It requires you to label and format disks in GPT manner.
Now U-EFI, provoked by big tech companies adds complexities to "increase" security against malware, but it's mainly used to lock out any software that is NOT "certified" by Microsoft.
To avoid that UEFI snag, you have to disable the "Secure Boot" option in the mainboard (or BIOS) setup.

To do that, I suggest to reset the mainboard to factory defaults and the selectively adjust the few settings you really need:
- disable secure boot
- keep the board in EFI mode
- check the boot-order (priority) for the system to boot from
- Install from a CD, DVD or USB-stick (select the UEFI-USB install media)
- Scrub your disks and fdisk them to GPT and so on (I suppose you let the Devuan installer do it, it does it well!)

2. MBR / BIOS mode
==================
Most enterprise level servers work in that mode. Ask an datacenter operator.
There are no worries about secure boot etc.

To do that, I suggest to reset the mainboard to factory defaults and the selectively adjust the few settings you really need:
- check the boot-order (priority) for the system to boot from
- Install from a CD, DVD or USB-stick (select the USB install media)
- Scrub your disks and fdisk them to MBR (DOS Label) and so on (I suppose you let the Devuan installer do it, it does it well!)

3. RAID
=======
If your motherboard or system includes a Hardware RAID controller, make sure you know it well and follow the manufacturers indications for the OS setup. I have worked quite a lot with such kind of hardware and it worked well (Dell PERC) Others are quite problematic, because usually they let you access RAID members from the OS, which is a very bad thing!
If in doubt, switch the controllers to simple SCSI or SATA controller through-mode and disable the RAID functions on that hardware.
Then install Devuan using the software RAID option. This works really well.

4. My experience with an UEFI board and SW-RAID
===============================================
My system worked well with one single disk, all in UEFI and GPT mode. That's why I added a disk and tried to set it up with the Devuan installer to assemble the RAID and partitions. I failed miserably.
I switched the system to BIOS/MBR mode, relabeled the disks to DOS Labels and set up the thing all using the Devuan Daedalus installer (Netinstall)
It worked really well, like a charm.

5. Example setup
================
- Reset the computer to factory defaults
- Set options sensibly as mentioned above
- Boot the Devuan Netinstall stick
- Choose the standard install method (just "Install")
- Give all answers accordingly to your needs
- Enter the Disk Partitioner:
--    Remove any residual config whatsoever There shall be no LVM volumes, no LV Groups, no RAID partitions, just nothing.
--    Create a 512MB primary partition, the first, on each disk and set the type to type fd (Linux RAID). (sda1 sdb1)
--    Create a very big primary or extended partition. the second, on each disk and set the type to fd (Linux RAID). (sda2 sdb2)
--    Go to the RAID submenu of the partitioner and create the the RAID volumes.
    (Assemble sda1 and sdb1 to md0, and sda2 and sdb2 to md1)
--    Now back in the main partition menu, define md0 as the /boot partition (ext3 or ext4)
--    Enter the LVM submenu (Logical Volume Manager)
    1. Declare md1 a LVM physical volume
    2. Create a Volume Group vg1 and add md1 as a member
    3. In that volumegroup create the volumes you need:
    -- 40 GB for root (ext4) (/)
    -- 40++ GB for home (ext4) (/home)
    -- ??GB for swap (swap) (size depends on you RAM in the system)
    -- ??GB for server-uses (ext4) (/srv)
--    Now back in the main partion menu, define the for logical volumes as shown above
    (I will show the filesystem layout at the end)
- Now continue your installation, tasksel does a wonderful job. (I chose Devuan Desktop, XFCE, web server, Console productivity and SSH server)
- !!! at the end, don't just hit continue! chose Back instead and start a shell in the install environment. There you type
    grub-install /dev/sda and grub-install /dev /sdb (That makes both disks bootable.
    Note: this is absolutely the one and only instance when you must access the RAID members of md0. It only copies one boot block to each disk.
- Here, you can reboot. It worked for me.
- Hint1: remove the anacron scheduler, it's of no use on a server and only causes problems at reboot
- Hint2: add your software as needed, web servers, ftp servers, database servers etc. They all should create and use subdirectories beneath /srv
- Hint3: LVM2 is an excellent way to handle disk space. It allows for snapshots even.
- Hint4: Backup to devices that are formatted (i.e. ext4) and mounted temporarily to /mnt. Never backup to device nodes like /dev/sdxyz. Tape drives did that.

I hope that helps.

A few notes:
Never, in the whole server's life, access RAID or LV members or elements of it. That is a sure way to hell. The only exception is the grub-install after kernel- or GRUB-updates.
RAIDed Volumes are accessed using /dev/md0 (for mounting, fsck etc) but don't touch /dev/md1 in our case.
Logical Volumes are accessed using /dev/mapper/VGx-lv-yyy (for mounting, fsck etc)
All filesystem activities as also backups etc have to access the corresponding mountpoints.

Now the configuration on my test server:
***********************************************************
linuxadmin@devuan:~$ df -h
Filesystem                Size  Used Avail Use% Mounted on
udev                      7.8G     0  7.8G   0% /dev
tmpfs                     1.6G  1.1M  1.6G   1% /run
/dev/mapper/VG0-lv--root   38G  3.8G   32G  11% /
tmpfs                     5.0M  8.0K  5.0M   1% /run/lock
tmpfs                     3.1G     0  3.1G   0% /dev/shm
/dev/md0                  446M   52M  369M  13% /boot
/dev/mapper/VG0-lv--home   47G  1.8M   45G   1% /home
/dev/mapper/VG0-lv--srv   339G   28K  322G   1% /srv
cgroup_root                10M     0   10M   0% /sys/fs/cgroup
tmpfs                     1.6G   12K  1.6G   1% /run/user/1000
tmpfs                     1.6G  4.0K  1.6G   1% /run/user/109
***********************************************************
linuxadmin@devuan:~$ lsblk -f
NAME               FSTYPE            FSVER    LABEL    UUID                                   FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                                         
├─sda1             linux_raid_member 1.2      devuan:0 d67d9792-6c1c-c10f-c183-ccdfd63fb72a                 
│ └─md0            ext3              1.0      BOOT     f16202ab-b30f-40df-95e5-9c18998b9b60    368.9M    12% /boot
└─sda2             linux_raid_member 1.2      devuan:1 f1e96c15-2935-8021-39ee-71cba1fab584                 
  └─md1            LVM2_member       LVM2 001          NEkYz6-31wg-ymNm-xR09-98J3-RavJ-0TZrZK               
    ├─VG0-lv--root                                                                              31.6G    10% /
    ├─VG0-lv--home                                                                              44.2G     0% /home
    ├─VG0-lv--swap                                                                                           [SWAP]
    └─VG0-lv--srv                                                                              321.5G     0% /srv
sdb                                                                                                         
├─sdb1             linux_raid_member 1.2      devuan:0 d67d9792-6c1c-c10f-c183-ccdfd63fb72a                 
│ └─md0            ext3              1.0      BOOT     f16202ab-b30f-40df-95e5-9c18998b9b60    368.9M    12% /boot
└─sdb2             linux_raid_member 1.2      devuan:1 f1e96c15-2935-8021-39ee-71cba1fab584                 
  └─md1            LVM2_member       LVM2 001          NEkYz6-31wg-ymNm-xR09-98J3-RavJ-0TZrZK               
    ├─VG0-lv--root                                                                              31.6G    10% /
    ├─VG0-lv--home                                                                              44.2G     0% /home
    ├─VG0-lv--swap                                                                                           [SWAP]
    └─VG0-lv--srv                                                                              321.5G     0% /srv

***********************************************************
linuxadmin@devuan:~$ cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md1 : active raid1 sda2[0] sdb2[1]
      468618240 blocks super 1.2 [2/2] [UU]
      bitmap: 1/4 pages [4KB], 65536KB chunk

md0 : active raid1 sda1[0] sdb1[1]
      497664 blocks super 1.2 [2/2] [UU]
     
unused devices: <none>
***********************************************************
linuxadmin@devuan:~$ lvshow
-bash: lvshow: command not found
linuxadmin@devuan:~$ man lvm
linuxadmin@devuan:~$ pvscan
-bash: pvscan: command not found
linuxadmin@devuan:~$ sudo pvscan
[sudo] password for linuxadmin:
  PV /dev/md1   VG VG0             lvm2 [<446.91 GiB / 0    free]
  Total: 1 [<446.91 GiB] / in use: 1 [<446.91 GiB] / in no VG: 0 [0   ]
linuxadmin@devuan:~$ sudo vgscan
  Found volume group "VG0" using metadata type lvm2
linuxadmin@devuan:~$ sudo lvscan
  ACTIVE            '/dev/VG0/lv-root' [38.14 GiB] inherit
  ACTIVE            '/dev/VG0/lv-home' [47.68 GiB] inherit
  ACTIVE            '/dev/VG0/lv-swap' [15.83 GiB] inherit
  ACTIVE            '/dev/VG0/lv-srv' [<345.25 GiB] inherit
linuxadmin@devuan:~$

Link to a excellent article that hints to the intricacies of UEFI-RAID-LVM

https://askubuntu.com/questions/1299978 … -uefi-bios
https://unix.stackexchange.com/question … oft-raid-1

I hope these (lengthy) instructions help.
If you need clarification, I will try to help. Good luck.

Beware of more evil to come:
https://www.theregister.com/2022/10/26/tightening_linux_boot_process_microsoft_poettering/

You know what this guy did to Linux and the free and open source world - pulseaudio and systemd greet you :-(

Now he is proposing even worse things: locking down hardware with TPM2 - Micro$oft must be happy to have him on board.
I am scared.

Easiest way:
just download https://files.devuan.org/devuan_chimaera/installer-iso/devuan_chimaera_4.0.0_amd64_desktop.iso
test its checksum and dd it to a USB-stick.
The USB stick doesn't have to be partitioned or formatted, just dd it to the device file /dev/sd? and not to /dev/sd?1 or so. (? = your drive. Find out with lsblk)
Then boot that USB drive and of you go...

(sudo dd if=devuan_chimaera_4.0.0_amd64_desktop.iso of=/dev/sdb bs=1M)

Sorry it didn't help.
I was referring to your post:

sudo mysql_secure_installation

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!

That looks pretty cool. I love it.
I should try openbox too, once I find the time and a not to busy computer.
Congrats!

Thank you, Head_on_a_Stick,
Great.
Any idea what the dock could be?

Have a nice weekend.

Hello,
you say nothing about your configuration: which desktop environment do you use?
There should be a "Display" configuration applet in you DE. open it, let it detect all displays and set each one up. Make sure to remove the option that mirrors display 1 and 2. It should be that...
Good luck.

I'm sorry to hear, Altoid.
As I wrote, dd writes from the beginning of the disk/partition. Even only a smaller iso-file dumped to it will overwrite the partition-boot-block and a lot of important filesystem information, like the superblock, some inode-tables, directories, datablocks etc.
Even if you are successful in creating a new partition table or taking the one from the end of the blockdevice (GPT), the overwritten information is gone.
When you create a new filesystem and install an OS or copy data to it, the data is mostly written to the beginning of the filesystem. So there are more likely data erased there when an accidental dd wreaks its havoc. You may be able to recover some files if they and the related inode-tables are in the non-overwritten area. But blocks my still be missing since the filesystem can reuse emptied blocks if their files were once deleted and the associated file was extended, before the accident happened.
The explanation may not please - life can be miserable.

Don't despair:
Use a shell (terminal) and type
sudo tasksel
Then give the right answers and it does the magic for you.
Happy new Year

Just a hint: be sure to type in the password correctly. That requires a correct keyboard setup!!
The WiFi PreShared Keys are, of course, case sensitive.
Good luck.