So the solution of not having any RAID installed by default on the live-desktop worked.

https://michael.orlitzky.com/articles/fix_busted_acls_faster_with_libadacl.xhtml

@fsmithred - I tested the live desktop iso devuan_excalibur_6.0-noraid-2025-08-29_1719_amd64_desktop-live.iso, and I confirmed that it did NOT auto start my test RAID arrays, which is good. I also confirmed that I can install the mdadm.deb in the root directory and do some RAID stuff.

The next test is the REAL test: run the desktop live on the 2 PCs that I reported in the first comment and make sure there are no other hidden surprises. Of course, I'll have to first run backups on those two PCs, which means digging out some extra HDDs, USB to SATA dock, etc. from my closet of tech stuff. So it might take a few days before I have more test results.

* Test notes

* Checking the iso's /live/initrd.img
  - file: devuan_excalibur_6.0-noraid-2025-08-29_1719_amd64_desktop-live.iso
  - Steps: Mount the iso, copy live/initrd.img to a temp directory.
  - cmd: unmkinitramfs initrd.img <output directory>
  - Weird. Extracting the initrd.img produces 3 directories: early, early2, main. Since it works, this could be just the way the live desktop init ram disk is organized.
  - Inside main, the contents look like the usual init ram disk.
  - find . | grep mdadm : No files found. Nothing related to mdadm is inside this ramdisk.
  - find . | grep rules.d : None of the rules files in udev/rules.d have any relation to md or raid.

Conclusion so far: If the init ram disk is has no knowledge of RAID, it shouldn't auto start any of my test RAID arrays.

* Checking the live desktop
  - cat /proc/mdstat  : file not found
  - sudo which mdadm  : file not found
  - lsmod | grep raid : No raid0, raid1, etc. modules.
  - lsmod | grep md   : No md_mod module.

Conclusion so far: Now that's what I call a solution. As predicted, since the init ram disk is totally clueless about RAID, it didn't (or couldn't) auto start any of the RAID arrays.

* Live desktop: installing mdadm.deb located on the root directory
  - install cmd: sudo dpkg -i /mdadm_4.4-11devuan3_amd64.deb
    - The install worked. There were some info messages about "live system is running on read-only media", and an error with grub-probe, but I'll see how far I can get.
  - Checking lsmod, md_mod is now loaded, but none of the raid modules are loaded.
  - cat /proc/mdstat: File exists. No RAID personalities listed. No arrays started.
  - sudo mdadm --examine --scan
    - Correctly discovered two RAID arrays, /dev/md/11, dev/md/22.
      - I don't know what the extra / means between the "md" and the number, but I'll keep going.
  - sudo mdadm --assemble /dev/md77 --uuid=<RAID UUID>
    - Array started on the intentionally weird md number, md77.
    - Array is confirmed in /proc/mdstat.
    - /proc/mdstat also shows the "raid1" personality.
    - lsmod now shows that the raid1 module is loaded. I guess the raid modules get loaded when they're needed.
      - This is convenient. The user doesn't have to manually load specific RAID modules in order to start their RAID arrays.
  - sudo mdadm --stop /dev/md77
    - Unsurprisingly, this also works.

  + Retest with no network connection (unplug from the PC).
    - Results: all same

  + Retest with no internet connection (plug PC into LAN, but unplug router's WAN).
    - Results: all same

Conclusion: Confirmed that the user can install mdadm locally and do RAID stuff, and there's no dependency on an Internet connection or any LAN connection.

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.

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.

hopefully a fix can be found

* What it takes to unload the md_mod module

Running "sudo modprobe -r md_mod" returns the error: "modprobe: FATAL: Module md_mod is in use.". But it doesn't tell you who's using it.

Running "sudo rmmod md_mod" returns the error: "rmmod: ERROR: Module md_mod is in use by: raid1 raid10 raid0 raid456".

So the solution is:

- Stop all RAID arrays so that the raid modules can be unloaded:
  - sudo mdadm --stop /dev/mdx /dev/mdy, etc

- Remove the 4 raid modules, then md_mod.
  - sudo rmmod raid1 raid10 raid0 raid456 md_mod

* What if you blacklisted the raid modules

I modified /etc/modprobe.d/mdadm.conf and added these lines, then rebuilt the init ram disk, then rebooted.

blacklist raid1
blacklist raid10
blacklist raid0
blacklist raid456
blacklist md_mod

The result was that the RAID arrays block devices were STILL created, but are inactive. /proc/mdstat also shows no raid "personalities" available.

$ ls -l /dev/md*
brw-rw---- 1 root disk 9, 127 Aug 28 21:45 /dev/md127
brw-rw---- 1 root disk 9,  22 Aug 28 21:45 /dev/md22

$ cat /proc/mdstat 
Personalities : 
md22 : inactive sda1[1] sdc1[0]
      200705 blocks super 1.2
       
md127 : inactive sda2[1] sdc2[0]
      197953 blocks super 1.2
       
unused devices: <none>

Looking at the loaded modules "sudo lsmod | egrep 'raid|md' | sort", the md_mod is STILL loaded, but none of the raid modules were loaded. As mentioned by g4sra, blacklisting doesn't prevent other ways of loading the md_mod.

Ans: Yep, I also have that file on my excalibur PC, and I also see it in the init ram disk.

I ran a quick test to see if I can see what effects "start_ro" has. "start_ro" has an effect on the RAID arrays I defined in /etc/mdadm/mdadm.conf, but it has no effect on the auto-started arrays at md127, md126. The setting will set whether or not the explicitly defined arrays are started with "auto-read-only" or not. For auto-started arrays at md127, the array is always started with "auto-read-only". I didn't dig any further to see what "auto-read-only" means, but the setting DOES show an effect.

When the "start_ro=1" line is defined (md22 is the raid number I explicitly defined in mdadm.conf):

$ cat /proc/mdstat 
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4] [raid10] 
md127 : active (auto-read-only) raid1 sdc2[1] sdb2[0]
      98944 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md22 : active (auto-read-only) raid1 sdc1[1] sdb1[0]
      100352 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

unused devices: <none>

When the "start_ro=1" line is commented out:

$ cat /proc/mdstat
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4] [raid10] 
md22 : active raid1 sda1[1] sdc1[0]
      100352 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md127 : active (auto-read-only) raid1 sda2[1] sdc2[0]
      98944 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

unused devices: <none>

Next, I'll play around with blacklisting the md module. If I find out something new that hasn't already been mentioned, I'll post my test results.

NB, and knobbling the UDEV rules as well...

- I mounted the file "devuan_excalibur_6.0-preview-2025-08-25_0923_amd64_desktop-live.iso" to the local file system, copied ./live/initrd.img to a temp directory and extracted it using the same 3* cpio + zstdcat|cpio, and examined ./etc/mdadm/mdadm.conf. The contents look like a default file. No "AUTO -all" or dummy "ARRAY <ignore>" lines.

I think you nailed it. The build script copies the kernel and initramfs to the /live directory from the chroot system that's being built. I think it's doing it too early, so it's not getting the final changes. I have to look at the code to confirm this (and correct it).

FWIW - unmkinitramfs will unpack the initrd easily with just one command.

First some quick replies to your comments:

- You said the 0923 iso "somehow got the default /etc/default/mdadm with START_DAEMON=true".
  - Ans: I didn't see that on the 0923 iso. It was START_DAEMON=false, the same as the "2025-08-13" that I tested a few days ago.

- You also asked if I could "still use the mdadm command without the service running?"
  - Ans: Yes, I was able to run the mdadm command in the 0923 iso. These two examples worked:
    - sudo mdadm --examine --scan
    - sudo mdadm --stop /dev/md127

* Test results for 0923 and 1056 were the same

  - /proc/mdstat showed that the RAID arrays auto started at md127, md126.
  - /etc/default/mdadm has START_DAEMON=false
  - Checking "ps -ef | grep mdadm", I didn't see any "mdadm --monitor". The mdadm monitoring/reporting daemon was NOT running.
  - Can I run the mdadm cmd? Yes, these cmds worked:
    - sudo mdadm --examine --scan
      - listed both of my test RAID arrays
    - sudo mdadm --stop /dev/md127

* Investigation

So why did the RAID arrays auto start? Here are my investigation notes. Note that I tested using legacy boot.

- /etc/mdadm/mdadm.conf does contain the lines "AUTO -all" and the dummy line "ARRAY <ignore>" with UUID of all zeroes. This looks OK.

- I extracted the contents of /boot/initrd.img.-6.12.38+deb13-amd64. This init ram disk in the live desktop apparently has 4 total archives concatenated together, with the last one being compressed.

(cpio -id ; cpio -id ; cpio -id ; zstdcat | cpio -id) < /boot/initrd.img-6.12.38+deb13-amd64

   And the contents of ./etc/mdadm/mdadm.conf contains the two lines "AUTO -all" and "ARRAY <ignore>". So this looks OK.
   
   And yet, the live-desktop STILL auto started my test RAID arrays???

- Checking the output of dmesg for clues, the second line shows the "Command line" args. And one of the lines show initrd=/live/initrd.img.

  Aha, /live looks like something on the .iso image.

- I mounted the file "devuan_excalibur_6.0-preview-2025-08-25_0923_amd64_desktop-live.iso" to the local file system, copied ./live/initrd.img to a temp directory and extracted it using the same 3* cpio + zstdcat|cpio, and examined ./etc/mdadm/mdadm.conf. The contents look like a default file. No "AUTO -all" or dummy "ARRAY <ignore>" lines.

- Conclusion: This would explain why the RAID arrays got autostarted. The live-desktop loaded THIS init ram disk that's located on the .iso.

- More info: The legacy boot menu comes from the iso image file "./isolinux/isolinux.cfg", which adds the "initrd" and other args to the boot cmd line.

label toram
    menu label devuan-live (amd64) (load to RAM)
    linux /live/vmlinuz
    append initrd=/live/initrd.img boot=live username=devuan toram  nottyautologin

* Test and investigation (UEFI live desktop)
- The test results and investigation results were the same, except that dmesg does NOT contain an "initrd" arg, so there's no clue about what init ram disk was loaded.

- Mounting the .iso again and checking "./boot/grub/grub.cfg", the menu entry contains a separate initrd line, which refers to the same "/live/initrd.img".

menuentry "devuan-live (load to RAM)" {
    set gfxpayload=keep
    linux   /live/vmlinuz boot=live username=devuan toram nottyautologin 
    initrd  /live/initrd.img
}

So both the UEFI and legacy boot must be loading the same init ram disk on the .iso file, which doesn't contain the two lines "AUTO -all" and "ARRAY <ignore>".

Re script:/etc/modprobe.d/mdadm.conf mine comes from the installed package:

ii  mdadm          4.2-5        amd64        Tool to administer Linux MD arrays (software RAID)

With the execute mode removed from script:/usr/share/initramfs-tools/hooks/mdadm mdadm is not invoked (not installed) in the initramfs.
That in conjunction with sysvinit 'mdadm' service being disabled md_mod is not automatically loaded at boot.

NB: If dm_raid has loaded that would use md_mod.

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.