I see a mini.iso in the netboot directory here: https://pkgmaster.devuan.org/devuan/dis … nt/images/

And I checked one of our forked packages (util-linux) and there's one for riscv64 that's the same version as excalibur amd64.
https://pkgmaster.devuan.org/devuan/poo … til-linux/

So it looks like it's possible. The mini.iso is the same as what debian calls (or called?) business card iso. It's like the netinstall but doesn't have firmware in the iso. If you try it, please report back and let us know if it worked. Thanks.

Nice find. I'll add it to the excludes file. You should probably keep the newest one, but the rest can be deleted.

I've got over 200 of them and I hardly ever reboot. The file name is your dbus machine-id which changes on every reboot in devuan unless you edit /etc/default/dbus or run a script that changes it for you. (I have one)

OK, I just ran my script and changed /var/lib/dbus/machine-id. The file in ~/.dbus/session-bus did not change, but when I switched to root in a terminal, the new id was in /root/.dbus/session-bus. I guess if I log out and in, then user will get the new number.

Maybe this needs another line or two. (Note: Most of this code was borrowed from a live-config script.)
EDIT: Note 2: no guarantee that it won't screw something up that needs a consistent machine-id. Also no guarantee that it will prevent your machine from being identified.

#!/bin/sh
# update-machineid
# Change /var/lib/dbus/machine-id manually.

MACHINEID=/var/lib/dbus/machine-id
UUIDGEN=/usr/bin/dbus-uuidgen
UUIDGEN_OPTS=--ensure

if [ "$(id -u)" -ne 0 ] ; then
        echo " You need to be root."
        exit 1
fi

if [ -f "${MACHINEID}" ] && [ -x "$UUIDGEN" ] ; then
	OLD_ID=$(cat $MACHINEID)
	rm -f "${MACHINEID}"
    $UUIDGEN $UUIDGEN_OPTS
	NEW_ID=$(cat $MACHINEID)
	notify-send -t 5000 "Changed dbus machine-id
 old: $OLD_ID
new: $NEW_ID" 
fi

exit 0

What kind of shares are they? NFS, Samba, local partitions or something else?

What's in /etc/fstab?

Also please post the output of blkid and maybe lsblk. Maybe other stuff, too after we narrow it down.

Your description of the debian installer's network setup is what I see when I use the devuan installer on a laptop. I don't know how you got to the screen you described. I do know that near the beginning of the devuan install there's a screen that asks you to supply firmware on a separate usb stick, and in most cases you should ignore that and continue. But that comes before the screen that lets you choose the interface to set up.

I don't see scripts on that page, just deb packages. And they aren't the same ones that are in debian/devuan. The versions of guile don't match the current versions in bookworm/daedalus. You're probably better off installing the packages from the repo.

I'm curious to see what glxgears tells you. Added xlibre to a refracta-excalibur (xfce)  VM and tested in qemu and hardware against the same system with xorg.

In qemu...

xlibre:  18FPS
xorg:  800FPS

live-usb on hardware (Thinkpad T450s)...

xlibre: 60FPS
xorg:   60FPS

I don't know enough to make any intelligent comments about that. I do notice that xlibre is slow in qemu.

I think I found a simple solution. This iso does not have mdadm installed or have the config files for it. It does have the mdadm package sitting in the root of the filesystem, and it can easily be installed with sudo dpkg -i /mdadm*.deb. You don't need a network connection for this to work.
https://files.devuan.org/devuan_excalib … p-live.iso

Tested in vbox with a RAID1 with two virtual hard disks. I booted the iso with the drives attached, installed mdadm and was able to run mdadm commands. There was no active array until I assembled /dev/md0. Please confirm.

Yeah, I ran into that "module is in use" warning. I managed to screw up my builds yesterday so that the desktop wouldn't start, and I finally found my error this morning. Right now I'm leaning toward removing all the mdadm stuff from the live and letting people rely on the rescue functions in the netinstall iso. I think I'll make a no-raid iso for the main site and any other test isos can be uploaded to a different location.

I'm assuming that the netinstall gives you more control over assembling raid arrays, but I've only used it a couple of times and never looked into the code.

I'm still a little frazzled from yesterday. New iso(s) coming later today (probably).

Thanks for persevering.

I tried adding "blacklist md_mod" to /etc/modprobe.d/mdadm.conf and rebuilding the initramfs. Did it with and without commenting out the existing line (...ro=1) and it didn't help. All the raid modules are still being loaded.

Also noted that 'modprobe -r md_mod' fails with message that md_mod is in use. There's no raid on my test box, so I don't know who is using it. (mdadm is not running)

Another option I thought of would be to build the iso without mdadm installed but with the deb package in the iso in case someone needed it. I think that could work, but I'm not sure.

One other thought came up after booting an older kernel whose initrd was made before installing mdadm. That would be to have two initrds in the iso, one of them made without mdadm installed and one with. That's more complicated to automate.

lsmod | grep raid    or    lsmod | grep md to see what modules are loaded.

I did that and decided that md_mod was probably the one to blacklist. When I went to /etc/modprobe.d to create a file, I saw that mdadm.conf was already there.  Does anyone else have this file?

# mdadm module configuration file
# set start_ro=1 to make newly assembled arrays read-only initially,
# to prevent metadata writes.  This is needed in order to allow
# resume-from-disk to work - new boot should not perform writes
# because it will be done behind the back of the system being
# resumed.  See http://bugs.debian.org/415441 for details.

options md_mod start_ro=1

This one has START_DAEMON=false in /etc/default/mdadm:
https://files.devuan.org/devuan_excalib … p-live.iso

Installing cryptsetup-modified-functions might do the same thing as your edited version. I didn't need this in daedalus, but the author of the patch (devujan) did need it. I don't know if he still needs it in excalibur or if it needs to be changed.
https://dev1galaxy.org/viewtopic.php?pid=41064#p41064
https://git.devuan.org/devuan/cryptsetu … -functions