Well, it looks like the system accepted the second report:
https://bugs.devuan.org/cgi/bugreport.cgi?bug=734

Thanks.

Thanks for the replies/help.  The full package list for testing shows 6.21.00-1.1, the same as I'm using on Chimaera.  Oddly, the full package list for Chimaera doesn't show either csh or tcsh.

What would be the method to request a fixed version or a patch fix be considered to include in the next release?  Would that have to go through Debian's wish-list request system?

Thanks for the extremely quick reply!  That appears to work for me, too.

Thank you for all the help.  After working through some odd issues (and a bug report about BIOS corrupting disk data), the machine just went into "production" use with a 5800 CPU, an ASUS Pro WS X570-ACE motherboard, a MSI Radeon RX 5500 XT GAMING X graphics card, Devuan Beowulf, the kernel from backports, AMD graphics and Realtek firmware from backports, some other packages from backports that apparently got pulled in as dependencies, and the Mesa and related libraries from MX AHS.  The MX AHS packages were mentioned in these linkded pages: https://dev1galaxy.org/viewtopic.php?id=3913 and http://forums.debian.net/viewtopic.php?f=16&t=146083  So far, everything appears to be working well.

Thanks for the great info about the meta package.  During installation, I just followed the default path.  Now that I know about the meta package structure, I'll make sure to install the meta package from backports.

That's a very good point.  Thank you for suggesting the 5.10 LTS branch from the beowulf-backports repository.  So far, today's current 5.10 kernel from beowulf-backports appears to be working well.  I partitioned the big HDDs and created the RAIDs.  The big RAID is doing its initial sync as I type (and for the next ~4+ hours).

I did a web search or two about how to add a backports repository.  One thing was not clear from the relevant web pages those searches found.  Does apt-get pick up updated kernel packages from backports automagically?  When I tried "apt-get -d -t beowulf-backports update", it wanted to update an enormous boatload of things, which I immediately rejected.  (Packages from the stable, non-backports repositories had already been fully updated.)

I found the reason for my case of not getting updates.  My /etc/apt/sources.list had originally only listed the cdrom (well, actually DVD to be more precise) as sources.  That's likely a side effect of not configuring the network in the installer.  When I noticed a Raspberry Pi 3 running Devuan Ascii was getting updates that my main X86 system was not getting, investigation yielded that the Raspberry Pi's /etc/apt/sources.list had separate lines for "ascii", "ascii-updates", and "ascii-security" (along with a commented-out line for "ascii-backports").  After changing my /etc/apt/sources.list to mimic the one on the Raspberry Pi, I had ~164MB of updates to download, including Firefox 60.6.1esr.

Thanks for the reply.  I read through both of those threads and the Debian bug report referenced in the latter thread.  Here's a little more detail on my situation:

I'm using only eth0 (well, and lo, of course), not wlan.

For essentially all practical purposes, I always have the network cable plugged in when I boot the Raspberry Pi.

I do not have Network Manager installed.

I boot to text console, not graphical login manager.

My directory /etc/network/interfaces.d is empty, and I have these four non-comment, non-empty lines in /etc/network/interfaces:

  auto lo
  iface lo inet loopback 
  auto eth0
  iface eth0 inet dhcp

Those four lines are identical to the corresponding lines in a 64-bit X86 machine that also runs Devuan Ascii.  The X86 machine does not have any delays.

Those four lines are also exactly how the datacenter network gurus where I work have always configured Debian-based systems for dynamic IP address on eth0.  Following the examples of said gurus, that's the way I have configured Debian-based systems I have worked with.  Except for cases whether the DHCP server (run by corporate IT) is slower than slow, I have not seen similar delays on those machines--only on the Raspberry Pi.

The X86 machine I mentioned and Raspberry Pi were tested with the same network cable, same port on the switch and router, etc.

When I boot the Raspberry Pi, the LEDs on the RJ45 jack behave curiously.  Initially, both are off.  Then, the yellow/amber LED on the right blinks on a couple of times and then goes back off--doing this once shortly before the DHCPDISCOVER line appears on the console and then again shortly after that line appears.  After the DHCPDISCOVER line appears on the console, and I think after the second round of yellow/amber blinks, the tree LED on the left comes on and stays on.

My hunch is there is something different about how the Raspberry Pi's NIC hardware, firmware, and/or drivers are initialized (relative to most X86 desktops and servers) that causes the initial dhclient process invoked by /etc/init.d/networking invoking "ifup -a" to fail/hang.

Is anyone acquainted well enough with the Raspberry Pi 3B+ NIC hardware/firmware/drivers to shed more light on why the Raspberry Pi shows the hang while the X86 machine does not?

I have a hypothesis that one possible workaround would be to remove the 'auto eth0' line from /etc/network/interfaces and add an "ifup eth0" or perhaps "ifup -a" command to /etc/rd.local.  Any second opinions on whether this would likely be reliable?