I am trying to migrate a running system to F32. The current system is SLED 15 running /home with RAID1. I’ve downloaded a Live F32 ISO and burned it. When it examines the disks it acts like it doesn’t know about RAID. – I use Linux, but I’m not a LInux Admin type. I’m not good with the CLI, I’m just dangerous.
I have ordered an adapter card to put another SATA drive in and build there. But once I do, how difficult will F32 be in mounting an existing RAID1 set of partitions? Not my first time to battle this kind of thing, But I’d like to get back to a 2 SATA drive system rather than a 3 (we will not count my SSD I use for SWAP).
Any gotchas I need to know about?
BTW – I’ve been reading and looking at various items. But I’m not comfortable with what I’m seeing which is why I’m looking at the route I’m taking to get to F32.
One other thing, I have a VBox definition that I need to have working and I’m hoping that some updates take place (based on some VBox complaints I have read).
Are you talking about mdraid or “hardware” RAID? The latter doesn’t make any sense on modern systems and it is very vendor-dependent.
In the case of mdraid, I’m not sure if a live system starts automatically what’s needed to detect the arrays, I haven’t run a live installation in a while. Regardless, you should be able to use mdadm --detail --scan before you start the installer. With that, mdadm will look for array information in all of the partitions listed in /proc/partitions. If for whatever reason this doesn’t work, you can assemble your sets with something like mdadm --assemble /dev/md1 /dev/sda1 /dev/sdb1 (replace with what’s appropriate for your configuration).
At this point you can start the installer and you should be able to see your md devices in the disk selection dialog.
A long time ago, several months after I had set up a system, I realized that /etc/mdadm.conf was never created and as a result the mdmonitor service failed to start. My RAID10 arrays were happily running all this time. All it took was mdadm --detail --scan >> /etc/mdadm.conf followed by systemctl restart mdmonitor.service. Perhaps I had hit a glitch at the time (it could have been F14 or F17, I don’t remember) and this is no longer necessary.
Thank you for answering. And yes, I am using mdraid.
My concerns are really based on what I have been use to with OpenSuse and SLED when it comes to an installer system. The RedHat install system is sufficiently different… I’m thinking I will just backup /home to a USB drive and let the RedHat system do what it knows.
And I did rapidly read through the install material and did a few searches, so I knew it would do RAID 1. It is just that the installer system on the LIVE CD doesn’t tell me what I want once it tells me it sees the drives.
The Suse install examines the disks and tells you what partitions it sees. From there I can go into expert mode and tell it exactly what to use, how to format, etc.
Because of not being familiar with this system, I guess you could say I don’t trust it. But once I get the back up done, I can reformat/partition the disks however RedHat would do it and then if I have to go back to SLED, I can in about 2 hours (takes that long to update the repos, select and install all the software and the like).
Thank you for responding. Yes, I saw the doc on Anaconda. The answer I gave to alexpl covers a lot more detail. And I’m thinking perhaps I should get the F31 ISO and use it instead because of the issues I have read about with VBox and F32.
And I agree on the VBox item needing to be its own. I do software for mainframes and we run into similar issues there.
I answered these out of order because I somehow missed your response when I first got back in here.
I can sort of relate to that, I suffer from a general distrust towards graphical applications for “serious stuff”. When I want to set up a RAID array, I boot off a live medium, partition the first drive, clone its configuration with sfdisk (or sgdisk) to the others and finally create the actual arrays. Then I launch the installer. I’ve used this process on Gentoo, Fedora, Debian/Ubuntu and a bunch of other distros. RAID information is stored in each partition and as long as you are using linux, the flavor does not matter; mdadm is straightforward in its operation and everything works pretty much as expected.