Unable to configure LVM+RAID in Anaconda for Fedora 44

Ask Fedora
, , ,
1

Hi all,

I’m trying to configure a brand new computer but am unable to force it to my specification. The installation medium is a USB key of the Everything netinstall variant.

The motherboard seems to be faulty because I can’t use harware RAID (as soon as I build arrays in BIOS, arrays are badly reported in Anaconda; when I touch RAID for SSDs, I am doomed to reflash BIOS !!!). Consequently I’ll go through software RAID.

This seems to works for physical partitions, such as ESP or /boot.

But I want isolate parts of the filesystem in separate partitions for /home, databases and photo archives. Since the size for them may vary widely with activity, I’d like to create these partitions under LVM to be able to cope with bad volume estimates. These partitions are mainly long-term storage and are therefore on SATA disks if this is relevant.

Note that this how my present computer (with a different brand of motherboard) was configured many releases ago. So it only updated with system upgrades.

I can create an LVM pv on the new PC with Anaconda but nothing more can be done. No partition can be created on the pv.

I checked that the lvm tool is 2.03.38, the same as the one on my running machine. But no way.

As a work around, I installed a minimal GUI system on one ot the disks and used KDE Partition Manager to manipulate the drives. I can do everything.

However, when I boot back in Anaconda, metadata (?) is not correctly interpretred and Anaconda does not recognise the LVM pv and even less the partition in it.

I tried to configure the partitions in CLI mode (in Ctrl+F2 screen) but this is not passed back to Anaconda when I return to Ctrl+F6.

How can I proceed?

Eventually, I can set aside the SATAs, install a minimal F44. Then in this OS, how can I add the new LVMs and partition while removing what could have been stored in /home? How can I set RAID1 mode? In console?

2

I use bare partitions (not raid nor lvm) for /boot and /boot/efi
I then use LVM for / and /home.
The VG containing the root LV is not on raid (the entire OS is on an nvme SSD), but /home is an LV on a separate VG on a software raid5 array created on 3 SATA drives.

All my file systems except /boot/efi are ext4.

As I understand it from several reports here, using raid in any form for /boot and /boot/efi seldom is successful since that would require the raid drivers to be active before the system boots (which cannot happen). Similarly, using LVM for those 2 file systems is not appropriate for the same reason.

3

Not exactly. My present computer has BIOS RAID enabled; therefore the RAID array is seen as a single disk at boot time and this is no problem.

Regarding my new computer, BIOS RAID is broken, particularly with SSDs (corrupts the BIOS when enabled forcing to reflash – never seen that before!). Consequently, I opted for software RAID. And it goes fine. I suppose that the boot sequence sees two independent disks (RAID1) and starts on one of them. As long as there are no writes, integrity is not impacted. When fstab is read in, the global architecture settles down to what is configured.

As is, this part works fine on the new computer.

To sum up, /boot (ext4) and /boot/efi (vfat) are “bare” partitions mirrored through RAID1.

This is exactly what I’d like to implement (as I did on my current PC).

It looks like F44 Anaconda can no longer create partitions in an LVM VG (RAID or not RAID). I made sure by creating an ordinary LVM VG (not RAIDed). The VG is available in Anaconda but when you select it the + button remains disabled, just the same as the menu command. Double-clicking on the VG only shows properties.

I am considering a workaround:

  • install a “minimal” OS with a real “bare” / partition
  • under this “minimal” OS, configure a RAID1 partition for an LVM VG with command lines
  • allocate a /home LV partition (command lines)
  • modify fstab to point /home onto this LV
  • finish installation with dnf (in fact launch a script for that, retrieved from my current computer on the LAN)

Due to past storage failures, I consider RAID1 mandatory (it saved my day several times). However, I am not sure about the build order in software RAID context (there is no question when hardware RAID works).

I think I must first create RAID partitions containong an LVM VG. If I work the other way round, i.e. create two LVM partitions, then allocate LVs associated with RAID1, I bump into a big problem: when I need to grow the VG, I must grow separately the two instances (and in the same way) before I grow the RAID1 LV. This is error-prone and probably defeats the looked-for reliability.

The easy way would be to RAIDify the whole disks. This is what is done with hardware RAID. But when mdadm launches a resync, it scans the whole disks, even unallocated areas. This means a 3-hour slow down period on my present computer when probably only 1/4 of it would be strictly necessary. Disks are twice as large on the new computer. Software RAID would be helpful in covering only the allocated areas (partitions instead of disks).

The main problem is Anaconda. Do you think my workaround is viable?

4

I have never used raid1, but it should be no different than any software raid. (I use both raid5 and raid6 on different systems.) The differences: Raid5 can suffer one device failure without data loss (3 or more devices), Raid6 can suffer up to 2 devices failing at the same time without data loss (4 or more devices).

For software raid with LVM:

  1. Create the raid array. The raid array can be created using the entire physical device or using partitions of the same size on the same or different devices.
  2. Create the VG using the raid array as the PV
  3. Create the LVs within that VG and format them for the file system to be used.
  4. mount the file system as needed.

This should work this way whether using software raid or hardware (bios) raid.

Note that you probably cannot use both types of raid at the same time. It likely will torpedo your system.

In the past, fedora was unable to even see the devices when the bios mode for sata was set to raid. This has mostly been solved, but still may be an issue for many with an older bios and/or hardware.

I have not tested raid within anaconda and the newer browser based anaconda does not yet have all the features fully refined (and some not yet included) that were available in the older anaconda.

My plans with raid are simple. My personal data is on a raid array so if there is a device failure no data is lost and replacing a drive in the array is simple.

The OS, which can easily be installed new or restored from a backup, is not on raid. I keep a current mirror backup of the OS on a spare device so it can be swapped in if needed with minimal down time. The mirror device is updated every time I install a new app so it remains current.

This makes the system very stable and easily maintained without messing with raid for the OS itself.

You essentially could do the same. 2 drives, not in hardware raid.
Create identical partitions for /boot/efi and /boot on each drive but only use those partitions on one drive for the installation. Create an mdadm raid1 array using partitions in the remaining space on the two drives.
Then using LVM create the VG and suitable LVs for / and /home.

Do all the above with something like gparted or similar from the install media.

Finally, actually do the installation and with the devices and partitions (including LVs) already defined use anaconda storage editor to select the partitions to be used for the installation. The raid array and LVM will not be an issue for installation since it was already defined before the installation started.

Note that this leaves 2 partitions on one device that are not used – those equivalent to /boot and /boot/efi. These can be used to do the backups of those 2 partitions and able to be activated if the other device fails. BUT to avoid conflicts during boot these must not have the same UUIDs as the similar partitions on the device being used for booting.

5

This is exactly how I proceed. Unfortunately, F44 Anaconda does not allow step 3 (everything grayed out or disabled).

I tried this in a console window (Ctrl+F2) but Anaconda GUI (Ctrl+F6) does not rescan the disks and does not see the changes.

I also installed a “standard” OS on the SSD to configure my SATA with the advanced tools available once OS is up and running. But when I return to Anaconda, in the hope of using disk config as it is, Anaconda does not see the LVs. I suspect it can’t understand the metadata (version issue?)

What Im going to do next: install F44 on the SSDs without LVM (and without SATAs); run the OS partition manager and configure the HDDs; modify fstab to include the SATAs with their LVs; reboot.

6

instead of using Ctrl+F2 to get the console, use a terminal window within the live media. The graphical environment is where anaconda resides and not within the system console area reached with Ctrl+F2.

You can open a terminal window, use su to get to the root access, then install gparted using dnf. The partitions you create using gparted, the raid array created by mdadm, and LVs created after that should be seen by the anaconda installer since mdadm and the lvm drivers are already activated in that environment before launching the installer.