Mounting md raid fails after snapshot 20260217

Hi,

After updating yesterday my TW system with zypper dup --no-allow-vendor-change and reboot, the booting process stops after halting a start job for a /dev/disk/by-uuid filesystem, which according to fstab is the home partition.
It leaves me in emergency mode.
All files systems except /home are mounted (nvme parititions, with btrfs).

On home normally a raid6 set /dev/md127 is mounted, consisting of 5 disks, /dev/sda through /dev/sde, all formatted with xfs.

mdadm -E reports all these disks to be clean, part of a raid6 system, checksums correct, as are it’s device roles.

journalctl gives nothing that seems to be problematic.
Neither seems dmesg: it ends reporting ‘Attached SCSI disk’ for all 5 disks.

But mdadm --detail /dev/md127 gives “cannot open /dev/md127: No such file or directory.”

What can I do to get my system safely up and running again?
Any help much appreciated!

@jehojakim Hi, so you weren’t using dmraid here?

Else perhaps https://forums.opensuse.org/t/solved-opensuse-tumbleweed-boot-failure-after-zypper-dup-nvme-raid-0-timeout/191533

@malcomlewis: No, I’ve always used mdadm. If I read the dmraid manpage online correctly, it does not have a raid6-option? Anyway, in my case the raid system is created with mdadm, so I´d think it would be wise to stick with that.

Following the link you gave, I can’t find the dracut error: rd.md=0: removing MD RAID activation the poster mentions, but maybe I don’t know where to look for it. I’ve so far inspected journalctl, dmesg and /var/log/boot.log

I do find (in dmesg) the avc: denied { getattr } errors he mentions; the devices they refer to are in all 5 messages /dev/nvme0n1p3; the fact that there are 5 such messages conincede with the fact that there are 5 disks in my raid setup. But they aro not nvme disks (partitions), but SATA disks.

mdadm.conf reads “Device containers partitions”. According th the man page of mdadm.conf, mdadm then “reads /proc/partitions and include all devices and partitions found therein.”

/proc/partitions contains not only the 5 sd[a-e] disks, but also the nvme partitions, but I would think that would not pose a problem?

@jehojakim OK, so could be SELinux related, you can make permissive and see if that changes the situation.
See https://en.opensuse.org/Portal:SELinux and https://en.opensuse.org/Portal:SELinux/Troubleshooting

From dmesg these 5 lines :

[ 8.397493] [ T193] audit: type=1400 audit(1771512352.436:7): avc: denied { getattr } for pid=1061 comm=“sh” path=“/usr/bin/kmod” dev=“nvme0n1p3” ino=1021921 scontext=system_u:system_r:mdadm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:kmod_exec_t:s0 tclass=file permissive=0

[ 8.397501] [ T193] audit: type=1400 audit(1771512352.436:8): avc: denied { getattr } for pid=1061 comm=“sh” path=“/usr/bin/kmod” dev=“nvme0n1p3” ino=1021921 scontext=system_u:system_r:mdadm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:kmod_exec_t:s0 tclass=file permissive=0

[ 8.402394] [ T193] audit: type=1400 audit(1771512352.441:9): avc: denied { getattr } for pid=1063 comm=“sh” path=“/usr/bin/kmod” dev=“nvme0n1p3” ino=1021921 scontext=system_u:system_r:mdadm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:kmod_exec_t:s0 tclass=file permissive=0

[ 8.402403] [ T193] audit: type=1400 audit(1771512352.441:10): avc: denied { getattr } for pid=1063 comm=“sh” path=“/usr/bin/kmod” dev=“nvme0n1p3” ino=1021921 scontext=system_u:system_r:mdadm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:kmod_exec_t:s0 tclass=file permissive=0

[ 8.428525] [ T193] audit: type=1400 audit(1771512352.467:11): avc: denied { getattr } for pid=1070 comm=“sh” path=“/usr/bin/kmod” dev=“nvme0n1p3” ino=1021921 scontext=system_u:system_r:mdadm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:kmod_exec_t:s0 tclass=file permissive=0

As said, the dev =¨nvme0n1p3" part, combined with r:mdadm seems strange to me, since the mvme partitions are not art of the raid6 device I use.

The results of

ausearch -ts boot
gives:

time->Thu Feb 19 15:47:21 2026
type=DAEMON_START msg=audit(1771512441.837:8778): op=start ver=4.0.2 format=raw kernel=6.18.9-1-default auid=4294967295 pid=1256 uid=0 ses=4294967295 subj=system_u:system_r:auditd_t:s0 res=success

time->Thu Feb 19 15:47:21 2026
type=SERVICE_START msg=audit(1771512441.843:18): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=‘unit=rpc-statd comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’

time->Thu Feb 19 15:47:21 2026
type=CONFIG_CHANGE msg=audit(1771512441.910:19): auid=4294967295 ses=4294967295 subj=system_u:system_r:unconfined_service_t:s0 op=remove_rule key=(null) list=1 res=1

time->Thu Feb 19 15:47:21 2026
type=CONFIG_CHANGE msg=audit(1771512441.910:20): auid=4294967295 ses=4294967295 subj=system_u:system_r:unconfined_service_t:s0 op=add_rule key=(null) list=1 res=1

time->Thu Feb 19 15:47:21 2026
type=SERVICE_START msg=audit(1771512441.912:21): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=‘unit=auditd comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’

don’t seem to indicate trouble. And if I add -m avc to the command, I get

I issued a
setenforce 0
but that apparently does not survive a reboot, and I’m unsure if the problem lies there?

I issued

@jehojakim Hi, can you upgrade to the latest snapshot and the 6.19.2 kernel?

In the links I provided you can add https://en.opensuse.org/Portal:SELinux/Setup look at #6

Ca n I upgrade without the home partition mounted?

And concerning the last link you gave, the commands suggested on #6 are enough for now?

@jehojakim So the RAID6 is just $HOME and not mounted at present?

Indeed, the raid6 should be mounted on /home, and isn’t now.

So switch to a tty (ctl+alt+F1) login as root user, kill off graphics with systemctl isolate multi-user.target then run mount -a does it mount now?

I don’t know if cause of your problem is the same as mine, but I also can’t boot Tumbleweed when using RAID (happened with February ISOs, January ISOs worked fine) - [SOLVED] openSUSE Tumbleweed boot failure after zypper dup: NVMe RAID 0 timeout - #16 by toxpal

1 Like

As mentionend in my opening post, I’m left in emergency mode, so no graphics environment to kill off.
Mount -a reports
mount: /home: cannot find UUID=86<…>
the UUID being the UUID for /home in /etc/fstab.

My problem is somewhat different I think, I don’t find the ‘truncate’ issue in journalctl, nor other error messages regarding UUID’s.

Funny thing is also I don’t get a grub menu when rebooting, even after powering off/on the system. TW is started immediately.

@jehojakim Strange indeed, so at the prompt where it asks to login or ctrl+D to continue? If so, press ctrl+D and see how that goes.

I’ve done that, before posting here, but it just does not do anything, so after waiting half an hour I rebooted, same situation again, and after trying to look for a solution myself I posted here…

@jehojakim Hmm, ok, so even mdadm doesn’t see the array, the config in /etc/mdadm.conf is correct?

Does it produce output frommdadm -E /dev/md127

Does is show present in lsblk output?

@malcolmlewis:

mdadm.conf reads “Device containers partitions”. According th the man page of mdadm.conf, mdadm then “reads /proc/partitions and include all devices and partitions found therein.”

/proc/partitions contains not only the 5 sd[a-e] disks, but also the nvme partitions, but I would think that would not pose a problem?

mdadm -E /dev/md127 reports
Cannot open /dev/md127: no such file or directorry

md127 does not come in the output of lsblk.

@jehojakim and contains the ARRAY and ARRAY metadata?
/proc/partitions should only contain md126 when all is working AFAIK, well that’s all I see here, but this is M/B Hardware RAID Intel Raid ISM.

/proc/partitions does not contain md127, only the sd[-a-e] and nvme entries.

Going to bed now, it’s 00:45 here, so reactions may take a while…