@fsmithred - Off topic: Are you still the maintainer of the package "clearlooks-phenix-lightpurpy-theme"? I filed a bug on Sep 9, and the last email I got was "Your message to Devuan-bugs awaits moderator approval".

  Excalibur + MATE Desktop: clearlooks-phenix-lightpurpy-theme doesn't work

The fix should be pretty easy: fix the theme's installed directory's capitalizaton. I'd like to verify the fix and have 1 fewer bug before Excalibur's release.

@fsmithred - I confirmed that the live desktop rc2 is using slim. And I do not see the "Untitled window" when the live desktop auto logs in. I also did a 2-monitor test, and slim's background DOES tile onto the 2nd monitor.

The problem is that both of these behaviors are not possible with the source code downloaded from "apt source --compile slim". I did that from the live desktop (see my test notes), and confirmed that the source code IS creating the child window "Untitled window" and the background should NOT tile onto the 2nd monitor.

The only conclusion I can think of is that you're building slim for the live desktop from a different source code than what's available from "apt source". Perhaps your versiom of slim code INCLUDES the code change that comments out creating the child window?

Other than that, there were no surprises in my rc2 live desktop tests.

* Test Notes

- Confirm that slim is the display manager.
  + Ans: Yes. "ps -ef | grep slim" shows "/usr/bin/slim -d".
- Screen resolution OK?
  + Ans: Yes. xrandr shows 1920x1080 on FX-8120's monitor, 1600x900 on A6-3620's monitor.
    - I was testing both PCs at the same time. Each PC has its own monitor. These resolutions are the correct max resolution for the connected monitor.
- Check that slim.conf has auto login enabled.
  + Ans: Yes, "cat /etc/slim.conf" shows:
    default_user devuan
    auto_login   yes
- Check if slim + auto login showed the "Untitled window".
  + Ans: slim + auto login did NOT show an "Untitled window".
    ? How is this possible? Does this build contain the code change that disabled slim from creating the child window that causes the "Untitled window"? Or is this using an older version of slim?
      - Version of slim: "apt show slim" shows version is "1.4.1-devuan1+excalibur1".
      - Also, "slim -v" shows 1.4.1.
        - This seems like the current version. Daedalus slim was 1.4.0.
- I downloaded the source code using "apt source --compile slim". This includes enabling deb-src, installing dpkg-dev. I didn't install all of the dependencies required to compile, just enough to get the source code patched and the compiling started.
  - Taking a look at panel.cpp, at the bottom, slim's code IS creating the child window. Why don't I see it in the live desktop auto login??? Is the source code from apt source NOT correct for the slim binary in the live desktop???
  - I can't compile and test slim like I did yesterday, because it requires a reboot to run the compiled slim binary, which will wipe out the live desktop environment. This is as far as I can go.
- Logging out, then logging back in as devuan/devuan, any problems?
  + Ans: No problems seen.
- Quick check: Confirm that RAID is NOT installed on the live desktop.
  + Ans: Confirmed. "cat /proc/mdstat" shows "No such file or directory".
- Quick check: There's an mdadm.deb in the root / directory.
  + Ans: Confirmed. mdadm_4.4-11devuan3_amd64.deb is there.
- Dual monitor test: Reboot to a fresh live desktop, then log out to observe the slim login GUI and background.
  ? Ans: The background tiles to the 2nd monitor, even though the source code says the child window IS being created with the dimensions of the 1st monitor, which should keep the background ONLY on the 1st monitor. There's definitely a source code to binary mismatch (or some voodoo magic) going on with the live desktop slim.
- Memtest: still runs?
  + Ans: Both menu options worked in UEFI and legacy boot.

I did some tests between Dadealus's slim and Excalibur's slim. I don't have an explanation for why the code was changed, but I have a guess. I also don't have a good proposal for a solution, because I don't understand enough about the login error handling and XWindows to figure out where to move the code. Not in one afternoon, anyway.

* Daedalus slim
When Daedalus slim shows the login screen, if there are 2 monitors, the login screen is shown on one monitor, and the other monitor shows the background. In the case of Devuan, the background is a small solid blue 50x31 image, which slim tiles horizontally and vertically. So slim shows a solid blue background, which looks OK on the 2nd monitor.

But if you have a unique background image, that unique image gets tiled over to the 2nd monitor. Now the user sees two monitors with this unique background, but only one of them contains the login screen. So this is my guess as to the original reason why the code was changed - to not show anything on the 2nd monitor, which does not contain any login GUI, to avoid confusing the user.

When slim starts, it requests for a Display, a Screen, and a Root window. I don't understand these XWindows concepts, but my debugging shows that the width and height is the sum of both monitors side by side, such as 3840x1080.

* Excalibur slim
In Excalibur slim, the implemented solution was to create a child window that's the width/height of just the primary monitor. All of the login window's GUI/background/etc will be placed inside this child window. As a result, nothing is shown on the 2nd monitor.

When you log in manually, Excalibur slim destroys the child window that it created, so you don't see this child window.

But when you autologin, the code jumps straight to the user/password login logic, and never destroys this child window, resulting in this "Untitled window" that's the size of the primary monitor. That's because the code never NEEDED to clean up any child windows before. The previous Root window was owned by the X server.

So it sounds easy to say "just destroy the child window before doing the auto login", but I don't know what happens if the auto login fails and slim has to show the login GUI. Will the code recreate a new child window for the login GUI? If yes, someone will have to move the code logic so this child window gets recreated when it's needed. This means refactoring the code and retesting the different code paths, including error handling code paths.

The reason why commenting out the code block seems to work is that both the child window and the Root window refer to the same Root window. So the behavior ends up being the same as Daedalus slim - there's no untitled window, but the background tiles to the 2nd monitor. And the slim code is smart enough to recognize that the child window refers to the same Root window, so it does NOT try to destroy the Root window that it didn't create.

That's all the time I have for this problem. It'll be up to the Debian maintainers who should know this code better than I can - at least in 1 afternoon's debugging - to figure out a good solution.

One thing that makes me uneasy about the fix, the guy wrote:

That always makes me nervous about whether the code change is really a fix, or whether it breaks something else. We'll see.

about your being burned out. And yes, I did see something about "death metal" in the Excalibur directory, which is why I thought Excalibur would have a new icon file name. It's also why I spent this evening testing the other 3 distros - ascii, beowolf, chimaera - so I can complete the list of icon files in my original post and make sure the list is accurate.

Sure, and thanks for listening to my request, AND for fixing the memtest.

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