* Quick summary

@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.

Here's what I've learned tonight about blacklisting that's not been mentioned in other comments.

* 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.

OK, thanks for the reply. I have installed rsyslog manually on my Excalibur PC, and a quick check shows no obvious problems. I wanted to make sure it wasn't an oversight in the Excalibur installer.

I'll marked this as solved, since it's a known issue.

@fsmithred: Tonight, I tested your two images:
  - devuan_excalibur_6.0-preview-2025-08-25_0923_amd64_desktop-live.iso
  - devuan_excalibur_6.0-preview-2025-08-25_1056_amd64_desktop-live.iso

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>".

@fsmithred: I haven't tested your two isos yet. Instead, I satisified my curiosity by investigating exactly what this "START_DAEMON" settings does and how it affects mdadm.

The START_DAEMON option is used in the script /etc/init.d/mdadm to determine if it should start mdadm with --monitor. According to the man pages, the monitor mode periodically checks the arrays to check for status changes and reports these events by logging to the syslog, sending a mail alert, etc.

$ ps -ef | grep mdadm
root      1434     1  0 19:57 ?        00:00:00 /sbin/mdadm --monitor --pid-file /run/mdadm/monitor.pid --daemonise --scan --syslog

At first, I thought this option was harmless. Then I see this in the man pages:

MONITOR MODE
  <...>
  As well as reporting events, mdadm may move a spare drive from one array to another if they are in the same spare-group or domain and if the  destination  array  has  a
  failed drive but no spares.

That's definitely a NO for a live desktop.

Otherwise, in my tests, turning off the START_DAEMON didn't affect my mdadm cmd line commands.

* Other issues

While testing the START_DAEMON setting to see if "mdadm --monitor" really writes to the syslog, I couldn't find /var/log/syslog on my Excalibur PC! The package "rsyslog" wasn't installed. Is that an oversight in the Excalibur netinstall iso, or is rsyslog no longer installed by default? If not, what are the alternative log files?

On a side note, my tests show that mdadm --monitor DOES log to the syslog when it detects a failed drive or a drive added back to a degraded array. I used mdadm --fail, --remove, --add, and observed the syslog.

@g4sra - I tried the suggestion about "raid=noautodetect" as a kernel boot arg, but that didn't work. Based on my research, that's supposed to work only when the RAID code is compiled directly into the kernel, instead of being a separately loaded module.

After searching online and lots of testing of the init ram disk, including borking it a few times , I think I found the easiest solution.

* Solution

Add these two lines to /etc/mdadm/mdadm.conf:

#Disable all auto-assembly, so that only arrays explicitly listed in mdadm.conf or on the command line are assembled.
AUTO -all

#At least one ARRAY line is required for update-initramfs to copy this mdadm.conf into the init RAM disk. Otherwise,
#update-initramfs will ignore this file and auto generate its own mdadm.conf in the init RAM disk.
ARRAY <ignore> UUID=00000000:00000000:00000000:00000000

Then rebuild the init RAM disk:

sudo update-initramfs -u

* Explanation

The AUTO keyword is described in the mdadm.conf man pages as a way to allow or deny auto-assembling an array. The "all" keyword matches all metadata.

From my tests "AUTO -all" doesn't affect any ARRAY lines that you manually define in mdadm.conf. Also, your ARRAY lines can be placed before or after the "AUTO -all" line, and they'll still work.

The reason why "AUTO -all" isn't enough is because when you run "update-initramfs", the script for handling mdadm first checks if your mdadm.conf has any ARRAY lines defined. If not, the script will ignore your mdadm.conf file containing the "AUTO -all" and run its own script "mkconf" to auto generate an mdadm.conf containing any RAID arrays that it detects on the PC, even if they're not currently started, and even if you didn't want any of those arrays to be auto-started.

So we define a dummy ARRAY line to ensure that your mdadm.conf is copied into the init ramdisk.

See: /usr/share/initramfs-tools/hooks/mdadm, /usr/share/mdadm/mkconf

* How to check the mdadm.conf in the init ram disk

Create a temp dir to hold the files. Then extract the files from the init ram disk. Replace the file name with your initrd file.  The files are extracted into the current directory.

mkdir /tmp/testdir
cd /tmp/testdir

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

cat ./etc/mdadm/mdadm.conf

* Other info

I tracked down exactly what triggers the RAID arrays to get auto started during boot, even if the init ram disk's mdadm.conf contains no ARRAY definitions. It's this udev rule file:

/usr/lib/udev/rules.d/64-md-raid-assembly.rules

I don't know how to read udev rules, so I don't know what this file does, but I've confirmed that moving this file out of this directory, then rebuilding the init RAM disk will disable auto starting arrays on boot. Since there are other md related rules in here, I don't know what the side effects are of removing just this file.

I ran into the same "Use of uninitialized value" error in daedalus + apt-mirror. The problem is that although the apt-mirror script's parsing logic for the Packages file (found in the binary packages) has been updated so that the md5sum is an optional field, the parsing logic for the Sources file (found in the source code packages) has NOT been updated. So it assumes that every package must contain the "Files:" section containing md5sums.

This means that if you're not mirroring the source code (not using deb-src), you won't see this error.

The problem isn't specific to Devuan. I tested with a Debian repository and saw the same errors.

- Devuan test, mirror.list

deb-src http://deb.devuan.org/merged daedalus-security main

  This downloads the file from: http://deb.devuan.org/merged/dists/daed … Sources.gz

- Debian test, mirror.list

deb-src http://deb.debian.org/debian bookworm-updates main

  This downloads the file from: http://deb.debian.org/debian/dists/book … Sources.xz

If you look open the Sources file in each test, you'll see that neither of their package descriptions contain "Files:" (md5sums), nor "Checksums-Sha1", only "Checksums-Sha256". So the problem is definitely an out-of-date apt-mirror script.

* A Solution

The only solution I have is to update the apt-mirror script. And since I know enough Perl to be dangerous , I came up with a solution.

- Copy the apt-mirror script into another directory, such as /opt, which is usually empty. That way, if anything goes wrong, the original apt-mirror script is still available.

cp /usr/bin/apt-mirror /opt

- Open /opt/apt-mirror in a text editor. Look for the function process_index(), and the "else" block with the comment "Sources index", which should be at line 919.

- The entire "else" block's code must be replaced with this code, which will handle any combination of the presence/absence of the 3 section names:

        else
        {    # Sources index

            #The sections "Files:", "Checksums-Sha1:", and "Checksums-Sha256" contain 1 or more lines with 3
            #space-separated fields: md5/sha1/sha256 checksum, file size in bytes, file name
            #There's no guarantee that all 3 sections will be defined, or that they will have the same list of files.
            #Use a hash to keep track of the file names and their sizes. Then update the ALL and NEW files afterwards.
            my %package_files;
            my %sections = (
                "Files:"            => *FILES_MD5   ,
                "Checksums-Sha1:"   => *FILES_SHA1  ,
                "Checksums-Sha256:" => *FILES_SHA256,
            );

            foreach my $section_name (keys %sections)
            {
                if (!defined($lines{$section_name})) { next; }

                foreach ( split( /\n/, $lines{$section_name} ) )
                {
                    next if $_ eq '';
                    my @file = split;
                    die("apt-mirror: invalid Sources format") if @file != 3;
                    print { $sections{$section_name} } $file[0] . "  " . remove_double_slashes( $path . "/" . $lines{"Directory:"} . "/" . $file[2] ) . "\n";
                    $package_files{$file[2]} = $file[1];
                }
            }

            my $file_size_bytes;
            my $file_path;
            foreach my $file_name (keys %package_files)
            {
                $file_size_bytes = $package_files{$file_name};
                $file_path       = remove_double_slashes( $path . "/" . $lines{"Directory:"} . "/" . $file_name );
                
                $skipclean{ $file_path } = 1;
                print FILES_ALL $file_path . "\n";

                if ( need_update( $mirror . "/" . $lines{"Directory:"} . "/" . $file_name, $file_size_bytes ) )
                {
                    print FILES_NEW remove_double_slashes( $uri . "/" . $lines{"Directory:"} . "/" . $file_name ) . "\n";
                    add_url_to_download( $uri . "/" . $lines{"Directory:"} . "/" . $file_name, $file_size_bytes );
                }
            }
        }

- To run the updated apt-mirror:

/opt/apt-mirror <your apt-mirror config file>

- To run the originally installed apt-mirror script:

apt-mirror <your apt-mirror config file>

I don't know anything about the logging system. But your post reminded me of back in the early 2010s when SSDs were getting cheap enough for not-so-rich computer geeks to buy. I remember there were Linux tweaks for reducing unnecessary disk writes by specifying "relatime" or "noatime" or something like that to reduce or stop updating a file's "access time" every time it's read. Back then, those tweaks had to be done manually.

If I had to speculate about today, I would suspect you'd still have to do those tweaks manually. My reasoning is that whatever the logging system an app or Linux is using would have no idea what type of storage device the log files are being written to. It could be an HDD, SSD, a RAID array that's a MIX of HDD+SSD (weird, but possible), a RAM disk, even a network shared folder on another PC. Since there's no way to know (or at least, no EASY way to know), I conclude that it's up to the sys admin to make those disk optimization tweaks manually.

Of course, a real sys admin can tell us for sure.

Two thoughts, based on maintaining my own PCs at home over the years.

* Who's going to maintain the server if something goes wrong? Example: If the server gets fried by lightning, who knows how to rebuild the server and restore the data from a backup? Who will make the backups?

* I've learned the hard way that SSDs aren't great for long term data storage, especially with static data (files that don't change). Based on what I can figure out from research, the SSDs memory cells suffer from voltage drift over time. So it gets harder to read old data, because the SSD controller has to work harder to determine what a cell's voltage level is, which determines the data bit values. This leads to slower SSD read speeds. In theory, the drift can get so bad that the data bits would be misread, thus get corrupted.

So you might want to ask a sys admin how they manage and maintain servers with SSDs in a work environment, especially with servers storing lots of static data. Are there SSDs that will silently refresh these memory cells and keep the read speeds and the data bits from degrading? Or do they go through regular hardware refreshes, so they end up replacing their whole server every few years, including the SSDs?

I figured out how to get the memtest86+ia32.bin and memtest86+x64.bin files to boot in legacy boot. Edit the menu item and insert the word ".linux" before the file name. This also works with the .efi files. In other words, all of these work in legacy boot:

.linux /live/memtest86+ia32.efi
.linux /live/memtest86+ia32.efi
.linux /live/memtest86+x64.bin
.linux /live/memtest86+x64.efi

This suggests that isolinux.cfg menu items should be using the keyword "linux" instead of "kernel". Current menu items:

label memtest-efi
    menu label Memory test (memtest86+x64.efi)
    kernel /live/memtest86+x64.efi

label memtest-bin
        menu label Memory test (memtest86+x64.bin)
        kernel /live/memtest86+x64.bin

I couldn't find any explanation what "kernel" does. I took a guess that if the "linux" keyword works at loading /live/vmlinuz (a compressed kernel), and "memtest86+x64.bin" is a bzimage (also a compressed file), then perhaps the "linux" keyword would work, and it did on my legacy-boot only PC.

Perhaps the .bin file was created for users using an older version of isolinux that does not know how to boot an efi file.