You are not logged in.
Switching to the "/dev/md127" ARRAY name in /etc/mdadm.conf also fixed my RAID10 array.
Avatar by Ditey: https://twitter.com/phrobitey
Offline
Needs someone willing to test the changes in the kernel config and if that fails in the kernel itself with this release.
I built linux from source using those changes you mentioned (setting CONFIG_BLOCK_LEGACY_AUTOLOAD=Y and bumping the version), and installed it and it works now like it used to (after restoring /etc/mdadm to its previous state).
(no offense, i just didn't want to install a kernel from google drive XD)
Ok so that CONFIG_BLOCK_LEGACY_AUTOLOAD thing is considered deprecated; so what's the new way to get those nice names for your raid array? https://lkml.kernel.org/linux-block/bc9 … rnel.dk/T/
Last edited by scott_fakename (2022-05-30 06:06:20)
Offline
Exactly the same issue with RAID 0 too (FakeRAID on Intel 82801).
Offline
Same problem with `/home` on RAID 0.
Changing mdadm.conf to `/dev/md127` didn't work. I need to mount manually from emergency mode before continuing boot.
Update:
Running "mdadm --examine --scan" showed "/dev/md/0" even with "/dev/md127" in /etc/mdadm.conf and /etc/mdadm/mdadm.conf.
Finally I could make the volume mount automatically during boot with /dev/md/0 in mdadm.conf and in fstab (in stead of using the UUID).
Last edited by MorningWalk (2022-05-30 15:14:32)
Offline
I have confirmed that my 3 MDADM RAID1 arrays were fixed by switching to the /md/{number} rather than name:
DEVICE partitions
# 2022-05-30: switched these to the dev/numbers:
# got these from lsblk
# due to [url]https://bbs.archlinux.org/viewtopic.php?id=276716[/url]
#ARRAY /dev/md/sys metadata=1.2 name=BEAST2:sys UUID=048e293b:ffaed1bd:b4915c78:aa04669e
ARRAY /dev/md127 metadata=1.2 name=BEAST2:sys UUID=048e293b:ffaed1bd:b4915c78:aa04669e
#ARRAY /dev/md/extra metadata=1.2 name=BEAST2:extra UUID=72617117:d155d725:6607a4dc:7d00b3f0
ARRAY /dev/md126 metadata=1.2 name=BEAST2:extra UUID=72617117:d155d725:6607a4dc:7d00b3f0
#ARRAY /dev/md/media metadata=1.2 name=BEAST2:media UUID=3272395b:66dae6a9:9b8fc738:f74ae7f3
ARRAY /dev/md125 metadata=1.2 name=BEAST2:media UUID=3272395b:66dae6a9:9b8fc738:f74ae7f3
Last edited by tcarpent (2022-05-30 13:00:12)
Offline
I also confirm RAID 0 with vanilla 5.18 works, it just needs the following mdadm.conf:
DEVICE partitions
ARRAY /dev/md127 metadata=imsm UUID=1c886e3f:e79f9f7a:dc64f1d3:d784c0e6
ARRAY /dev/md125 container=/dev/md127 member=0 UUID=4ab7bf4a:07b92108:c14b394a:d02342cb
ARRAY /dev/md126 container=/dev/md127 member=1 UUID=498974e2:56ccfe58:b5a6bca6:cd76e4ac
Last edited by iq2luc (2022-05-30 13:10:13)
Offline
Ok so that CONFIG_BLOCK_LEGACY_AUTOLOAD thing is considered deprecated; so what's the new way to get those nice names for your raid array? https://lkml.kernel.org/linux-block/bc9 … rnel.dk/T/
I suspect it is the udev rules supplied by mdadm not working as expected without CONFIG_BLOCK_LEGACY_AUTOLOAD. Not sure how to contact the mdadm authors, the linux-raid mailing list perhaps.
Offline
I also confirm RAID 0 with vanilla 5.18 works, it just needs the following mdadm.conf:
DEVICE partitions
ARRAY /dev/md127 metadata=imsm UUID=1c886e3f:e79f9f7a:dc64f1d3:d784c0e6
ARRAY /dev/md125 container=/dev/md127 member=0 UUID=4ab7bf4a:07b92108:c14b394a:d02342cb
ARRAY /dev/md126 container=/dev/md127 member=1 UUID=498974e2:56ccfe58:b5a6bca6:cd76e4ac
I have one RAID0 with two nvme and lvm so the second array I have to change to /dev/nvme1 ? And what is with container? I have only the luks container so it’s without?
Offline
I have one RAID0 with two nvme and lvm so the second array I have to change to /dev/nvme1 ? And what is with container? I have only the luks container so it’s without?
https://github.com/archlinux/svntogit-p … 5ceec985de restores the old behavior in 5.18.1.arch1-1 now in testing.
Offline
Thanks for your effort. How long takes the testing?
Offline
Thanks for your effort. How long takes the testing?
Done. It only stayed in testing for a few hours given the known issues the previous release had.
Offline