I'd gone through the whole process of getting it serving Web pages - then powered off - then on (cold reboot) it displayed mostly-original default settings - but sometimes on a warm reboot it would find all of the newer files and settings.

If you observe some similar instability you may want to go into BIOS and toggle-off the hardware RAID and use only software RAID.

That was the advice given to me on this Forum.

Since Devuan is essentially Debian with a different init system, the same initrd workaround also works for Devuan.

md-dev
raid0

That looked like those should be important, since I have a RAID0 array.

I verified that the mdadm package was already installed

I ran
update-initramfs -u
as instructed in https://wiki.debian.org/SoftwareRAID.

I verified that the vmlunuz and initrd.img files got copied to the efi Devuan directory.

I used efibootmgr to create a new entry in the UEFI boot menu using this command:

efibootmgr --disk /dev/md126 --part 1 -c -L "Devuan (EFI stub)" -l /EFI/Devuan/vmlinuz -u 'root=UUID=6ae760b1-58a7-4b88-8373-5342d04deba2 ro rootfstype=jfs initrd=\EFI\Devuan\initrd.img mdadm=true'

I try to boot Devuan from the new "Devuan (EFI stub)" boot selection.  It acts like it almost boots.  It appears to load the kernel and the initramfs, lots of messages scroll by, and then it gets stuck the same as I originally posted, because it can't find the root partition.  I check /dev and the /proc/mdstat file and see that the RAID didn't get assembled and accessed.

I removed the "quiet" boot parameter so I could see more messages as it attempts to boot.  Here are the last screen full that I captured:

2.0068111 ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 2.008934] logitech-djreceiver 0003:046D:C52F.0002: hiddeue, hidraul: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000
2.0143951 ata3.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
2.0166101 ata3.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 2.0191041 ata3.00: ATAPI: TEAC DU-W524GSB, AT11, max UDMA/100
[ 2.022807] ata3.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
[ 2.0250031 ata3.00: ACPI cnd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
[ 2.0297501 ata3.00: configured for UDMA/100 [ 2.0338561 scsi 2:0:0:0: CD-ROM TEAC DU-W524GSB AT11 PQ: 0 ANSI: 5 [ 2.069880] logitech-djreceiver 0003:046D:C52F.0002: device of type eQUAD step 4 DJ (0x04) connected on slot 1
[ 2.071549] input: Logitech Wireless Mouse PID:4055 Mouse as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.1/0003:0463/input/inputs
[ 2.074472] input: Logitech Wireless Mouse PID:4055 Consumer Control as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6:16D:4055.0003/input/input6
2.0775111 hid-generic 0003:046D:4055.0003: input, hidraw2: USB HID v1.11 Mouse [Logitech Wireless Mouse PID:4055] on [ 2.1181581 input: Logitech Wireless Mouse as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.1/0003:046D:C52F.0002/0003 usb-0000:0
[ 2.1208831 logitech-hidpp-device 0003:046D:4055.0003: input, hidrau2: USB HID v1.11 Mouse [Logitech Wireless Mousel on usb-0000: [ 2.3826821 atab: SATA link down (SStatus 0 SControl 300)
[ 2.3939641 sd 0:0:0:0: [sdal 976773168 512-byte logical blocks: (500 GB/466 GiB) [ 2.3939691 sd 1:0:0:0: [sdbl 976773168 512-byte logical blocks: (500 GB/466 GiB)
[ 2.3957641 sd 0:0:0:0: [sdal Write Protect is off
[ 2.3974751 sd 1:0:0:0: [sdb] Write Protect is off [ 2.4000231 sd 0:0:0:0: [sdal Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 2.4000251 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 2.4252331 sr 2:0:0:0: [sr0] scsi3-mmc drive: 48x/48x writer dud-ram cd/ru xa/form2 cdda tray [ 2.427732] cdron: Uniform CD-ROM driver Revision: 3.20 [ 2.4443251 sd 1:0:0:0: [sdb] Attached SCSI disk
[ 2.4901401 sd 0:0:0:0: Attached scsi generic sge type 0
[ 2.4918771 sd 1:0:0:0: Attached scsi generic sg1 type 0 2.494487] sr 2:0:0:0: Attached scsi generic sg2 type 5
[ [ 2.4971051 sd 0:0:0:0: [sdal Attached SCSI di
Begin: Loading essential drivers... [ 2.8761861 raid6: sse2x4 gen() 15158 MB/s
[ 2.9441841 raid6: sse2x4 xor() 9417 MB/s
[ 3.0121841 raid6: sse2x2 gen) 17565 MB/s
[ 3.0801841 raid6: sse2x2 xor() 9643 MB/s [ 3.1481851 raid6: sse2x1 gen() 14536 MB/s
[ 3.2161841 raid6: sse2x1 xor() 8576 MB/s [ 3.2173181 raid6: using algorithm sse2x2 gen() 17565 MB/s
3.2184461 raid6: .... xor() 9643 MB/s, rau enabled
[ 3.2195701 raid6: using ssse3x2 recovery algorithm
[ 3.2217431 xor: automatically using best checksumming function
3.2236601 async_tx: api initialized (async) done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file systen... Begin: Running /scripts/local-top ... done.
Begin: Running/scripts/local-premount... Begin: Waiting for suspend/resume device... Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block done.
Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... Begin: Running into clearl Hal done.
aux
Begin: Running /scripts/local-block... done.
Begin: Running /scripts/local-block... done.
Begin: Running /scripts/local-block... done.
mdadm: error opening /dev/md?*: No such file or directory
Gave up waiting for suspend/resume device
Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  UUID=6ae760b1-58a7-4b88-8373-5342d04deba2 does not exist.  Dropping to a shell!

BusyBox v1.30.1 (Debian 1:1.30.1-6+b3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

I noticed the message about "Loading essential drivers... raid6 ..." and then more messages about raid6.  Why raid6.  I have raid0, or does raid6 encompass all forms?

Anyway, it looks like I am getting close to getting Devuan to boot, but I must be missing some essential kernel hook or initramfs module, or something?

Any suggestions?

I don't have any other disks in the system.  The UEFI efi partition is the first partition on the RAID0 array.  Those three OS's that I listed all have their initial boot code stored in their own subdirectories on the efi partition.  All three of those OS's boot right up.  The UEFI firmware obviously knows how to load and run those boot code modules, even when the efi partition is on a RAID.

I originally tried to install Debian on this machine following the instructions at the link in the Debian wiki that steve_v pointed to.  I got as far as step 9, which involves booting the the install disk in rescue mode and mounting the Debian partition in chroot mode.  When I do that, the install disk says that it can't find any partitions.  I put a query on the Debian forum but never got an answer.  So, I decided to try Devuan.  It seemed to go through the install phase all right but it won't boot.  That is how I ended up here.

To be sure about things, you might therefore want to have a separate /boot partition outside of the raided partitions.

FWIW, when setting up RAID systems I always keep /boot (and usually root as well) on a small RAID1.
A software RAID1 (mirror) is indistinguishable from a pair of identical partitions as far as the BIOS, bootloader and initrd is concerned, so even a rescue disk with no RAID support whatsoever can still get you into your boot/root FS.
One can even set up the two drives as alternate BIOS boot disks, so as to have bootloader redundancy as well.

As for the problem at hand, there seems to be some confusion as to whether this is a fakeraid or mdraid setup. If it's the former, you'll likely want to use dmraid and access your disks under /dev/mapper/. Mdadm has nothing to do with sata/fake/dmraid.
I have no experience with this personally, I've never used it, and I probably never will. The only time it has any benefit over software (md)RAID is when you're sharing an array with Winblows... And that's a dodgy proposition to begin with IMO.
There is a Debian wiki page on the matter though. Might be worth a read if you haven't already, looks like there are some traps regarding GRUB installation and UUIDs.

If this is actually an mdraid array, (much mention of mdadm in this thread)... I know Devuan can boot from RAID1 just fine, and I've set it up that way many times. I have no experience with RAID0 though, IMO an array that reduces reliability is an oxymoron, especially for the root filesystem.
One has followed the steps in the Debian wiki WRT to generating mdadm.conf and updating the initrd, no? IME that's all it should need.

Though this should be rather similar to using the rescue mode... did you select the "configure raid" option in the "select root filesystem" menu, and then use the md device?

I realized I tried a raid1; I should it with try raid0 instead.

EDIT: I started to wonder about which kind of raid system you are setting up.

Basically, if any of the bootstrap files end up straddling a division line between raid0 partitions there will be grief, because those are all loaded before any raid0 support is available, using disk block addressing.

To be sure about things, you might therefore want to have a separate /boot partition outside of the raided partitions.

I tried booting the install disk in Rescue mode but discovered that the
modprobe raid0
mdadm --assemble --scan
trick I posted earlier doesn't work when booted in that mode.  Apparently it's not loading the same kernel, or the same kernel options, as when booted in normal install mode.

This is turning out to be much more difficult than I anticipated.

However since the boot reaches the initramfs prompt, it indicates that grub is happy enough, and the the issues sits with the initramfs. Specifically that the block device '/dev/md0' doesn't get set up on boot.

The first of possibilities is that you have opted for "non-standard" hotplug handling.
Did you set up something else than eudev for that?

EDIT: You may refer to the scripts in /usr/share/initramfs-tools/ to figure out what is going wrong, though that might be difficult to do without getting it started. However, at the initramfs prompt, you can mount a disk read-only and then chroot into it.

mdadm: error opening /dev/md?*: No such file or directory
Gave up waiting for suspend/resume device
Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  UUID=6ae760b1-58a7-4b88-8373-5342d04deba2 does not exist.  Dropping to a shell!

BusyBox v1.30.1 (Debian 1:1.30.1-6+b3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

UUID=6ae760b1-58a7-4b88-8373-5342d04deba2 is the UUID of the partition where Devuan was installed, so that is correct.

I think the clue is probably this:

mdadm: error opening /dev/md?*: No such file or directory

It appears that some kernel component is not getting loaded which would allow the RAID array to be recognized.

Any suggestions?

It turns out that all I had to do was run the installer up to the point where it runs the partitioner, back up and drop to a command prompt, and type
modprobe raid0
mdadm --assemble --scan

Now when I go back into the partitioner it shows my RAID0 array and all the existing partitions.

I.e. do that on the installer command line to begin with.
And make sure to save the configuration file(s) somewhere.

EDIT: Actually, the installer includes some functions for setting up RAID. You will need to use "expert" mode, and then in particular select the "mdcfg" option as additional component. At the partitioning stage there will then be some RAID setup options. I'm not yet totally sure how these work though.

EDIT: I'll take it back: the RAID setting up is available also with "default" mode. But you need to use the Manual option for partitioning so that you first partition the physical devices, and then use the "Configure RAID" option before finishing the partitioner.

Note that grub will only install on the one disk, which should be one of the physical disks. You may later also run grub-install onto the other disk(s) to make them separately bootable.

I tried adding dmraid=true or mdadm=true to the boot parameters but neither one helped.

Windows 7 uses an Intel driver to access the RAID. Both Artix Linux and CentOS use mdadm.

I booted the CD in expert mode and did some exploring of the install environment from a command shell.  I tried executing
find / -name 'mdadm*'
and got this:
/cdrom/pool/DEBIAN/main/m/mdadm
/cdrom/pool/DEBIAN/main/m/mdadm/mdadm_4.1-11_amd64.deb
/cdrom/pool/DEBIAN/main/m/mdadm/mdadm-udeb_4.1-11_amd64.udeb
/tmp/mdadm.conf
/sbin/mdadm
/run/mdadm

So, mdadm is already on the CD.  The /tmp/mdadm.conf file caught me attention.  Its contents are:
ARRAY metadata=imsm UUID=f46ce314:c874c458:5630027e:d4375317
ARRAY /dev/md/WD1TBRAID0 container=f46ce314:c874c458:5630027e:d4375317 member=0 UUID=58b9905f:2a773399:518dbd70:7b52bdc0

Aha!  WD1TBRAID0 is the name of my RAID array, so Devuan is recognizing the RAID to a certain extent.  I just need to find some way to make it read the partition table (GPT) and find the existing partitions.

Is there some magic kernel boot parameter I can enter, or some hocus-pocus commands I can enter from a command shell to make it make use of mdadm, and whatever else might be required, to make Devuan understand and use my RAID array?

Any suggestions will be appreciated.

Charles Bailey