This was using a USB with Rocky-9.7-aarch64-dvd.iso flashed onto it.
This was a new server and we wanted to test out a Linux distro, and used a drive we had lying around. Booting into the installer, after the GUI loaded and the language selection screen was visible it quickly popped up with “An unknown error has occurred”, and persisted after a few reboots. The “More info…” section had thousands of lines listed, but notably mentioned a failure to build an MD device. Selecting the “Debug” option just hangs indefinitely.
Turns out that drive was once part of an MD RAID. I figured this shouldn’t be too much of an issue since the installer also comes with a Troubleshooting section, but both the plain-text mode and the rescue option simply hang indefinitely after being selected with a blank screen.
I eventually got around this by flashing Archboot onto another USB, deleted the partition from the drive, and then booting back into the Rocky Linux installer it was able to successfully install onto the drive.
Ideally, the installer should either have an option to skip trying to assemble MD devices (since the intent was to reformat the drive using the installer to put Rocky Linux on it instead), or the troubleshooting tools should at the very least not try to do this so that it can actually be used to recover a system the installer is failing to run on.
In case the hardware is relevant to this, it is a GIGABYTE
R163-P30-AAG1 with an AmpereOne 128-Core A128-34X.
Should be possible by editing the grub menu before booting, and just adding to the end of the kernel line:
raid=noautodetect
at least that’s what google searches suggest doing which is a generic way of doing it for various Linux distributions. Since otherwise, mdadm by default will attempt to re-assemble. Since Rocky aims to be 100% compatible with RHEL then it would require RHEL making such changes as Rocky doesn’t plan to diverge from RHEL for compatibility reasons.
But, the grub entry changes for booting would or should solve the problem anyway. Or by doing what you did and deleting all the partitions on the disk first. Unfortunately it’s not possible to cater for every single situation since there are other issues that can occur with installations and disks where some solutions have also suggested using tools like wipefs.
This is before a bootloader is installed, so grub is not on the system yet. Or is the installer itself using grub and there’s some way to edit the install entry?
When you boot from the ISO, you get a grub menu. This is what I am referring to. Since Rocky isn’t installed, then obviously I’m not referring to the installed bootloader because it doesn’t exist yet. I could have probably clarified it better by putting:
So it is, just tried booting into the ISO again. You learn something new every day. The raid=noautodetect works for this, so I’ll call this resolved. Thanks!
Booted an X86_64 VM. Added multiple disks. Tested both RAID 1 and RAID 5 with mdadm. Then booted the VM with only one of the mdadm disks. Tested with Rocky 9.7 and CentOS Stream 9 latest. In every case, no crash. However, the mdadm disk would not show up until I did a mdadm –zero-superblock. Then it would show up.
I’ll have to do more testing on aarch64 to see if there’s an issue upstream or not.
Also, I have no idea if there might be an issue with a MDADM drive created under x86_64 and then trying to load that on aarch64. Would that cause another issue?
