I've tested the gparted-live-1.0.0-3 live image, which is being discussed in the forum post I've linked at message #8 in this thread.
The url for the actual live image is:
https://sourceforge.net/projects/gparte … o/download

I was able to boot it to desktop from an ntfs partition.

I looked into the initrd, /lib/live/boot directory and ran a diff command between beowulf's files at the same location in the initrd.
There are a number of differences, I'm not posting full diff because most of them don't seem related to ntfs.
However, here's the diff between the 9990-misc-helpers.sh file:

82c82
<   elif echo "${sysfs_path}" | grep -q '^/block/vd[a-z]$'
---
>   elif echo "${sysfs_path}" | grep -q '^/block/[hsv]d[a-z]$'
474a475,482 
>   # For ntfs, since user space program ntfs-3g will be used. Check ntfs-3g instead of kernel module.
>   if [ "${fstype}" = "ntfs" ]; then
>       if type ntfs-3g >/dev/null 2>&1; then
>           return 0
>       else
>           return 1
>       fi
>   fi
1222c1230
<       if [ "$(cat ${sysblock}/removable)" = "1" ]
---
>       if [ "$(cat ${sysblock}/removable 2>/dev/null)" = "1" ]
1270c1278
<       if [ "$(cat ${sysblock}/removable)" = "0" ]
---
>       if [ "$(cat ${sysblock}/removable 2>/dev/null)" = "0" ]

The second difference looks almost exactly like the post you linked to in message #9 of this thread.

Thanks for paying attention and replying, fsmithred. That's why I (and I'm sure many others) use devuan - because of the sensible attitude towards resolving actual issues.

However, in this case:
FALSE ALARM!
I've just tested the debian-live-10.7.0-mate-amd64.iso directrly from debian.

It behaves exactly the same. No ntfs.ko in initramfs. "Warning: unable to mount /dev/sda3" when trying to access iso on ntfs partition.

Therefore: it's a Debian change, and Devuan simply mirrored it, and there's no direct obligation for Devuan team to do anything about it since it isn't connected to *ystemd.

I can see the same results for ascii. I don't have a beowulf system right now near me.

If we were to try:
The simplest way to include ntfs.ko into the initramfs would probably be modifying "/etc/initramfs-tools/modules", but first making sure that the modules themselves are installed on the base system of course. I don't know why they aren't there on beowulf.

Can you tell me how big a partition I would need to install a minimal beowulf 3.1 system from the live image? If I have a partition big enough I can maybe try and find an easy solution.

In the meantime - this isn't a Devuan problem, so it's a non-blocking issue if you are planning to release 3.1.
As I described, the beowulf 3.0 problems with eudev are not present in 3.1, so progress has already been made.

Update:
Debian has dropped the support of ntfs.ko: (see: 29 June 2019: GParted Live 1.0.0-3 Stable Release)
https://gparted.org/news.php?item=224Release

And here people seem to be solving the same problem:
http://gparted-forum.surf4.info/viewtopic.php?pid=35358

Testing the amd64 live-iso.

Burned to physical dvd.

Udev seems fine, all modules loaded on first try (with or without "toram").
Network cards and sound working -  the system even detected which output I had plugged and set default output accordingly. This is even more than I expected - usually some tweaking is needed on my setup to select the correct output. Very good.
Switching betweet manual/dhcp, as well as lan/wi-fi using wicd - all ok.
Cryptsetup, lvm work ok.
Added backports (with contrib and non-free sections), built zfs-dkms modules, imported the pools - all ok.
Used "dkms mkbmdeb" to pack the zfs modules into a deb, rebooted and installed the deb to avoid recompile of zfs modules - all ok.

Module count, as indicated by "lsmod | wc -l" is the same w/ or wo/ "toram" parameter.

Problem:
Trying to load the iso from hd through grub entry failed:
"Warning: can not mount /dev/sda3".
That's an ntfs partition where I've placed the iso, and, as I suspected, the ntfs modules are missing from /live/boot.img.
Deliberate policy or accidental omission? I hope the latter.
I used to be able to boot debian/devuan/ubuntu and many others from ntfs partitions like this.
When placing the iso to an ext4 partition, the boot proceeds normally.

Minor issues:
1)Incosistent formatting wrt tabs/spaces in "/etc/init.d/eudev" between start) and other) sections. Has no run-time effect.
2)Usage of "start-stop-daemon" to start eudev is not neccessary. It doesn't do any damage in this configuration, but it's still not needed. Udev will be perfectly fine when started as "udevd --daemon" - the way it was in jessie/ascii, unless I am mistaken.
3)acpi-fakekeyd: not neccessary anymore since eudev startup seems to be in order. May be used as a fail-safe for live-cd, but maybe consider adding it to exclude list, if possible, for the actual refracta-install process. Some people have complained that system installed from live-image uses a bit more resources - it's not much, and does no harm, but acpi-fakekey may be one of the reasons.

Other than that, live-image seems very good.

Keep Devuan rock-solid.

Just tested the beowulf hd-media installer located at
https://pkgmaster.devuan.org/devuan/dis … /hd-media/

The gtk installer doesn't boot, enters in a loop throwing xserver errors.
Fixed by specifying 'vga=788' at  the boot command line.

When using expert install, both gtk and text installers will, after detecting the iso, say something like:
'FIXME' iso mounted. The iso 'devuan-beowulf-..blah...iso' mounted at /dev/sda1 (FIXME).

So that's 2 FIXME entries somewhere.

Tested with beowulf dvd install image.

Other than that both text and gtk installers seem to work fine.

I agree, that should be the top priority.
Especially since the beowulf packages have been ready for some time, and beowulf systems themselves seem to run fine.

Jessie is really getting a bit long in the tooth, time to migrate.

Also:
I checked the ascii 2.1 live dvd, which always worked ok for me. It starts eudev as udevd --daemon.

Last thing: please confirm that my fix works on your machine, not only on mine.

Try the following:

Edit /etc/init.d/eudev startup script.

In the start) section, comment out the start-stop-daemon command, along with the enclosing if statement and add
the following line below it: udevd -d.

It should look like this:

    # clean up parts of the database created by the initramfs udev
    udevadm info --cleanup-db
   
    # set the SELinux context for devices created in the initramfs
    [ -x /sbin/restorecon ] && /sbin/restorecon -R /dev
  
    log_daemon_msg "Starting $DESC" "$NAME"

#   Commented out code is below this line

#    if start-stop-daemon --start $NAME --user root --quiet \
#      --pidfile $PIDFILE --exec $DAEMON --background --make-pidfile; then
#      # prevent udevd to be killed by sendsigs (see #261 & DEBIAN #791944)
#      mkdir -p $OMITDIR/$NAME
#      ln -sf $PIDFILE $OMITDIR/$NAME
#<----->  log_end_msg $?
#    else
#<----->log_warning_msg $?
#<----->log_warning_msg "Waiting 15 seconds and trying to continue anyway"
#<----->sleep 15
#    fi

#   Commented out code is above this line

#   Inserted code is below this line
    udevd -d
#   Inserted code is above this line

    log_action_begin_msg "Synthesizing the initial hotplug events"
    if udevadm trigger --action=add; then
<------>log_action_end_msg $?
    else
<------>log_action_end_msg $?
    fi

I tried editing rc.local as well but it didn't work for me. Maybe I did something incorrectly.
After that I decided to do it "by the book" and create an actual "init script" for this.

I'm downloading it and will give it a spin.

I noticed that too.
The "restart" portion of the eudev init script doesn't simply execute "start" and "stop" portions. It behaves differently. It just calls start-stop-daemon 2 times.

The "start" portion of the eudev init script, on the other hand, does a lot of things. It performs mounts, remounts, makes nodes, etc, a lot of important work. It seems to me that something within that portion fails for the first time (on initial boot), but succeeds when we run it a bit later in the boot sequence.

Bad thing that there is not much logging going on.

I was going to suggest that if you were to make a refracta iso again, maybe you could edit /etc/udev/udev.conf and change the udev_log parameter so that we can get as much information as possible. Udev may have something interesting to say about all of this, we should listen.

For me this fixes everything, including the sound. All the way up to pc-speaker.
I am testing on the beowulf rc live-image

I think I've found the fix.
Eudev needs group "kvm" to be present.

Try booting the beowulf live image rc from dvd into runlevel 1, after that

service eudev stop
groupadd kvm
service eudev start

Seems to fix the issue with missing modules. You don't even need acpi-fakekey for the mouse after that.

Update: turns out the kvm group has no effect - but stopping and restarting do.

I stand corrected.

I do remember though that when getting the warning

cryptsetup: WARNING: The initramfs image may not contain cryptsetup binaries 
    nor crypto modules. If that's on purpose, you may want to uninstall the 
    'cryptsetup-initramfs' package in order to disable the cryptsetup initramfs 
    integration and avoid this warning.

I did get into trouble (unable to decrypt root filesystem) a few times because cryptsetup bins were not included. So I learned to pay attention to it if I need to decrypt something at the initramfs stage.

The preferrable way of including cryptsetup bins for me is adding 'initramfs' to options column of crypttab. Like this:

# <target name> <source device>         <key file>      <options>
target_device_name   UUID=<..uuid here..>   none  luks,initramfs

And you don't need to add CRYPTSETUP=y. This is for ascii and later.

I hope Lomax was able to boot successfully.

If your root is unencypted you may boot but will have to unlock crypt partitions manually.

If you've only encrypted home and swap then you don't need cryptsetup in the initramfs and can ignore the warning. The root will be mounted and after that the cryptsetup binaries are accessible to the system in order to unlock the rest of partitions.

If you've described the situation accurately, you'll probably be able to boot and login as root. After that you can unlock the rest and add the required lines to crypttab/fstab.

I myself don't often use optical images for installation in most cases.

My preferred method is to put isos on hard drive and create grub entries to boot into them. Writing the iso to a usb stick is as redundant as burning it to a dvd in most cases.

There are cases where it's not possible, or not convinient, to do it from hd and in those cases external media, dvd/usb, comes to the rescue.

My dvd drive is a very old ide drive. It's by no means "modern bd crap".
Jessie and ascii live/install images, burned to a dvd, always worked flawlessly for me. I also sometimes write an ubuntu lts version to a disc and it always worked without problem as well.

Also, fsmithred said that the problem appears on some usb configurations as well, it's not limited to optical media.