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

I don't know how to avoid that popup without making the .desktop file executable. I could mark it executable during the build, but I don't recall ever having to do that before. I never start it from the desktop icon, so I don't know when it started doing that.

And no, the one on the desktop is in /home/devuan/Desktop. The one in /usr/share/applications/ shows up in the apps menu. (another way to start it.)

In the running live system, open a terminal and run:

sudo refractainstaller-yad

The live-isos have wireless firmware installed. This one is new:
https://files.devuan.org/devuan_excalib … p-live.iso

sha256sum:
667f3e82469a36aa95bcbe11db67fbd96ea59ec41c66f96407d1334033db2658  devuan_excalibur_6.0-preview-2025-08-13_0014_amd64_desktop-live.iso

Almost forgot to mention:
That early screen that asks you to insert a usb with firmware can often be ignored, and the firmware package will be installed later in the installation process (unless you select expert install and tell it not to install the firmware).

I don't see 'bpo' in the kernel version. It looks like it's the excalibur kernel. Please post your /etc/apt/sources.list and any other sources apt is using.

I just booted excalibur with that kernel and firmware-iwlwifi is working correctly. (version 20250410-2)

That's a strange request. Is there some specific package version you need that's in the iso? I don't recall what the problem was, but the 5.0.0 iso was replaced shortly after release. Most of the software on the 5.0.1 iso would be the same versions as on 5.0.0. And lilttle of it will be the same after you do your first apt update && apt upgrade or if you choose a mirror during installation.

@Devarch: I've been using it in excalibur. What problem are you having? (maybe it should be in another thread).

Yes refractainstaller can do encrypted installs. You can have encrypted root and /home partitions, with or without a separate /boot partition. (without it gives you full disk encryption). No LVM or RAID (unless you do some of that manually)

Odie,

There are some errors in your documentation for refractasnapshot.

refractainstaller and refractcasnapshot packages are in the devuan repository. If you're running devuan, you can just 'apt install refractasnsapshot-gui refractainstaller-gui' and you will get all the the base and gui packages with all their dependencies.

You don't need to use sudo to run the scripts. You can just run them as root. And you don't need to add your user to the sudo group to be able to use sudo when you boot into the live-CD/DVD/USB. That's gets done automatically by live-config.

Refractainstaller does not depend on grub-efi-amd64. Older versions did require some grub package, but not necessarily the efi version. Installing grub-efi-amd64 as you suggest could cause problems for the user on a non-uefi system.

You don't need to edit grub.cfg.template and changing the name or putting your edits in grub.cfg will result in those edits not being used.

If you want to use a different kernel than the latest installed kernel, you can set it in one place, in the config file. If you edit the menu to use the specific kernel version, you will need to edit it every time the kernel gets updated and you are making multiple edits instead of just one.

There's no need to set geany as the "other editor" when geany is already the default editor.

You don't need to make a backup copy of snapshot_exclude.list because there's ALREADY a backup copy.

You don't need to delete the work_dir or the extracted dir after a run. They get deleted unless you edit the config file to keep them.

I'm only up to page 12 of 34. I don't have time to go through it all, and I probably missed something in that first 12 pages. Please study the existing documentation that comes with the packages. Maybe you could put a note at the top of your document saying that it's not official, it's not endorsed by the maintainer of the refracta tools and anyone should use that doc at their own risk.