+++ This bug was initially created as a clone of Bug #2385871 +++

1. Please describe the problem:

In systemd test suites, we create a MD device, stop it, then restart it.
Creating and stopping MD device seems to work, but cannot restart since kernel-6.17.0-rc0.
====
+ mdadm --create /dev/md/mdmirror --name mdmirror --uuid aaaaaaaa:bbbbbbbb:cccccccc:00000001 /dev/disk/by-id/scsi-0systemd_foobar_deadbeefmdadm0 /dev/disk/by-id/scsi-0systemd_foobar_deadbeefmdadm1 -v -f --level=1 --raid-devices=2
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
mdadm: size set to 64512K
Continue creating array? mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md/mdmirror started.

+ mdadm -v --stop /dev/md/mdmirror
mdadm: stopped /dev/md/mdmirror

+ mdadm --assemble /dev/md/mdmirror --name mdmirror -v
mdadm: looking for devices for /dev/md/mdmirror
mdadm: no recogniseable superblock on /dev/sdd
mdadm: no recogniseable superblock on /dev/sde
mdadm: no recogniseable superblock on /dev/sdc
mdadm: No super block found on /dev/vda3 (Expected magic a92b4efc, got 00000040)
mdadm: no RAID superblock on /dev/vda3
mdadm: No super block found on /dev/vda2 (Expected magic a92b4efc, got 00000401)
mdadm: no RAID superblock on /dev/vda2
mdadm: No super block found on /dev/vda1 (Expected magic a92b4efc, got 41615252)
mdadm: no RAID superblock on /dev/vda1
mdadm: No super block found on /dev/vda (Expected magic a92b4efc, got 00000000)
mdadm: no RAID superblock on /dev/vda
mdadm: /dev/sdb is identified as a member of /dev/md/mdmirror, slot 1.
mdadm: /dev/sda is identified as a member of /dev/md/mdmirror, slot 0.
mdadm: Unable to initialize sysfs
===

2. What is the Version-Release number of the kernel:

6.17.0-0.rc0.250730g4b290aae788e.3.fc43

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

Yes, it worked fine, until yesterday, with 6.16.0-65.fc43.

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

Yes, the issue is reproducible. See above.

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:

Yes.

6. Are you running any modules that not shipped with directly Fedora's kernel?:

No.

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

Will do.

Reproducible: Always

--- Additional comment from Yu Watanabe on 2025-07-31 21:22:30 UTC ---

With the following command,

journalctl --file TEST-64-UDEV-STORAGE-mdadm_basic-1.journal --no-hostname -o short-monotonic

--- Additional comment from Mikuláš Patočka on 2025-08-06 20:54:19 UTC ---

I bisected it, it's caused by the commit 9e59d609763f70a992a8f3808dabcce60f14eb5c

--- Additional comment from XiaoNi on 2025-08-07 00:07:27 UTC ---

Hi all

https://github.com/md-raid-utilities/mdadm/pull/182 fixes this problem. I'll backport this ASAP.

Thanks
Xiao

--- Additional comment from XiaoNi on 2025-08-07 12:33:56 UTC ---

Hi all

upstream mdadm will do a new release soon (maybe next week). fedora rawhide will upgrade to the new release.

--- Additional comment from Luca Boccassi on 2025-08-07 12:38:08 UTC ---

Thank you for looking into this.

1) Would it be possible to backport the necessary patches to the current rawhide version of mdadm and upload that now? This functionality is broken right now, and that impacts our tests and infrastructure that runs on rawhide (e.g.: https://github.com/systemd/systemd/actions/runs/16790786639/job/47551848819), so unblocking that sooner rather than waiting for an upstream release would be very appreciated

2) As mentioned in the mail thread, isn't the rule that the kernel is not supposed to break existing userspace programs? Is there any way to fix the kernel change so that backward compatibility with existing setups is maintained?

Thanks

--- Additional comment from Richard W.M. Jones on 2025-08-13 15:38:56 UTC ---

I'm also seeing this, which breaks libguestfs in F43.  Can we backport the fix asap please?

--- Additional comment from XiaoNi on 2025-08-13 16:35:39 UTC ---

hello all

I'll backport mdadm to latest upstream this week.

--- Additional comment from Justin M. Forbes on 2025-08-13 17:22:30 UTC ---

It would also be nice to get this backported to stable Fedora 42 at least sometime before October, as we are likely to backport 6.17 kernels to F42 in early October.

--- Additional comment from XiaoNi on 2025-08-14 01:25:48 UTC ---

Hi Justin

Thanks for the information. I'll do this today