Bug 888863

Summary: No apparent way to put LVM on top of RAID in new custom storage UI
Product: [Fedora] Fedora Reporter: Matthew Miller <mattdm>
Component: anacondaAssignee: Brian Lane <bcl>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: dev, dopey, g.kaviyarasu, jcm, jonathan, kas, marc, mattdm, mihai, mishu, redhat-bugzilla, sbueno, vanmeeuwen+fedora
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: anaconda-19.22-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-07 19:06:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Matthew Miller 2012-12-19 16:47:22 UTC
I'm using the TC3 anaconda installer.

I want to make a mirrored /boot partition, and then a second mirrored partition with an LVM volume group on top of that (including / and /home partitions).

This seems relatively common and straightforward.

However, I can't figure out how to do it at all: there seems to be no option for LVM on top of RAID, as they're both presented at the same layer.

Comment 1 Brian Lane 2012-12-20 05:13:46 UTC
Currently the only way to do LVM on RAID is via kickstart. I've been trying to work on adding it, but there just isn't enough time.

Comment 2 Matthew Miller 2012-12-20 17:15:07 UTC
In that case, I'm going to move this to Rawhide so it's tracked for the next release. This is what I do all the time when _not_ using Kickstart, for what it's worth. When using kickstart, I'm usually either deploying an ephemeral (replaceable) system or one with enterprise RAID hardware. The software raid setup for desktop systems, when I use the anaconda gui.

Comment 3 Marc Doughty 2013-01-18 04:58:20 UTC
I can confirm this.

Actually, under Fedora 18 on raw disks, I can't even run the installer after I manually create an MD array in the console. Anaconda bombs-out.

If possible, there probably should be a button for 'advanced' configuration when multiple hard drives are detected that describes a few common multi-disk layouts:

/ on /dev/md0 (RAID-1)
   The entire system will be mirrored. Performance will be the same as a single drive system, and it will be able to operate with only one disk in the array running.


/boot on /dev/md0 (RAID-1), one big / on /dev/md1 (<choose RAID level: 10/5/1/0>)
    The /boot partition will be mirrored across all matching disks, and everything else will be on a raid <number> array. <explain characteristics of md1 array>


/boot on /dev/md0 (RAID-1), LVM on /dev/md1 (<choose RAID level 10/5/1/0>)
    You get the idea, but this one mentions how the individual partitions will be able to be grown in the future. This should also be the default.

RAID levels should default based on the available number of disks, possibly in a different screen that describes each one and calculates available layouts/space.

Comment 4 Matthew Miller 2013-01-21 18:29:40 UTC
My preference is for an Advanced mode which skips listing a bunch of possible end goals and turns the approach the other way around.

Right now, the UI is oriented at users who describe a high-level end state and the program figures out how to implement that. It might work to have that provide more options and show more information, but that makes it more confusing for non-experts while not necessarily making it easier for storage experts.

Instead, the advanced mode should work from the bottom up, disks to partitions to raid and lvm to filesystems on top. That way, people who know what they want and how to build it have a straightforward way to do so.

I know that's a more complicated approach, with effectively two separate code modules doing the same thing in different ways, but I think that this is an important enough area that it's worth it (for Fedora and for RHEL).

Comment 5 Fedora End Of Life 2013-04-03 13:48:57 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:

Comment 6 Andy Wang 2013-12-27 00:56:28 UTC
I saw that this was marked fixed in anaconda 19.22-1 but I don't see any obvious way to do this in Fedora 20 installer.  Am I missing something or is this still not implemented?

Comment 7 Jan "Yenya" Kasprzak 2014-01-02 15:57:32 UTC
Me too. The Fedora 20 anaconda storage configuration tool seems to start with the "mount point" abstraction, and only then it is possible to select the underlying storage type (LVM, RAID, partition, BTRFS), but I don't see any way how to make the "mount point" to be a LV with the underlying device being RAID-1.

Since it has been more than half a year since this bug has been "fixed" according to the above message, I am reopening this and changing the version to Fedora 20.

Comment 8 Brian Lane 2014-01-07 19:06:06 UTC

Step 4. Click Modify, select raid level.

Comment 9 Andy Wang 2014-01-07 21:23:52 UTC
Oh duh.  I totally missed that little nugget tucked away there. Thanks for pointing that out and sorry for the confusion :)

Comment 10 Jon Masters 2016-04-30 07:07:35 UTC
Please note that it took more than 3 hours of manually creating different partitioning schemes (which cause Anaconda to crash on load), rebuilding media, and poking around with source trying to make it do what I wanted on F23 before discovering this option. That means this option is not intuitive or easy to use. Ordinary users have no hope of ever figuring this out. It's a terrible shame because it does work, once you spend many hours trying to figure it out.

Comment 11 Jon Masters 2016-04-30 07:08:38 UTC
Setting needinfo because I'd like a second opinion on reopening this bug.

Comment 12 Brian Lane 2016-05-03 17:08:19 UTC
It doesn't need reopening.

It is documented here:

The documentation could probably benefit from having some typical storage scenarios as separate sections instead of having to wade through the current if-this-then-that style.

Comment 13 Matthew Miller 2017-11-29 15:49:59 UTC
This is easily addressed in a bottom-up way in the new Blivit-GUI option.