Description of problem: My kickstart script is creating mirror on 2 disks of same size, like this: clearpart --all --initlabel part raid.01 --size=4096 --ondisk=vda part raid.02 --size=4096 --ondisk=vdb raid / --level=1 --device=md0 --fstype=ext3 raid.01 raid.02 part raid.11 --size=1 --grow --ondisk=vda part raid.12 --size=1 --grow --ondisk=vdb raid pv.01 --level=1 --device=md1 raid.11 raid.12 volgroup vg1 pv.01 logvol swap --vgname=vg1 --size=1024 --name=swap --fstype=ext3 I need one static size partition for / (root of system) and to add leaving free space to LVM PV. With Fedora 13, this worked well, but in Fedora 14 this configuration is forbidden. Version-Release number of selected component (if applicable): Fedora 14 How reproducible: always Steps to Reproduce: 1. use kickstart script above Actual results: --grow is not supported for RAID partitions Expected results: no error and working RAID Additional info: There is no need to have same size partition for RAID1 with metadata 1.1, where metadata are at start of disk. This is an typical configuration with redundancy and I have no idea, how to get partition sizes, which can be used in kickstart script to fill whole free space. part programs uses blocks/sectors and kickstart needs kB/MB, so this --grow option was my only chance to use whole disk. Some more information is found in closed bug: #577432. which introduced this problem.
Here's how to get the sizes of your devices in MB from %pre for use in kickstart: let vda_size=$(cat /sys/class/block/vda/size)/2048 or let vdb_size=$(grep vdb$ /proc/partitions | awk '{print $3}')/1024
We would also really like to see '--grow' available on raid volumes, even if it is with a caveat that it will not work properly at times. I understand that we can use script based logic to do the same thing in the pre section, then echo out a disk partition table based on that. It feels like more of a hack though than using --grow and accepting that it may break if disks are not identical.
I'd like to see '--grow' simply grow to the maximum size of the smallest drive member for example (something I assume to be a rare error case anyway).
Honestly I have no idea how I'm supposed to make a software RAID that fills the rest of a disk now unless I know in advance how many allocatable blocks are available. It used to be really trivial with --grow, now it seems to be rather difficult.
So from IRC discussions I gather that --grow simply isn't coming back for RAID devices. I'm afraid I can't fathom how going from "fails to work for some" to "fails to work for all" improves the situation, but after a few hours of hacking and waiting for my server to boot I managed to get a system of disk configuration in %pre working. I am happy to share with anyone who would like it, though I think it would be better if something that's not a hack (as mine surely is) went into the documentation.
Just discovered this and am very disappointed. This allowed me to have a very simple config (separate boot partition then lvm on raid for the rest) that applied in a large number of cases and worked perfectly fine. Huge step backwards.
We really need a straight forward automated way to continue to kickstart our servers. This either needs to be re-implemented or re-jigged. For now, I'm not using Fedora anymore because of this issue. Because of this issue, I've begun migration to Scientific Linux 6. Once the downstream hits this issue and SL as consequence: I'll (unfortunately) have to look at other distros all together. Very disappointed. Dan
I know it's a pain that the --grow functionality went away, but unless you simply refuse to look at the existing solutions there's no reason to say that you simply can't do that anymore. Since switching to a %pre script to generate the partitions, my functionality has increased since I can now auto-scale swap with RAM and could do other things like mismatched disk sizes. It sucks that I had to blow half a day figuring out something that the anaconda folks claimed was trivial, but maybe I'm just dumb. Anyway, you don't have to. But if you find it easier to switch distros than look a couple of comments up, then maybe that's the better option for you.
In Fedora 16 (and currently in rawhide) you can specify growable members, but only for RAID0 member partitions. Other raid levels will still not be supported. As Jason points out, you can do all of this in %pre if you're willing to figure it out.
I'll admit that I saw the %pre comments and in the past have quickly looked into using that, but I never did figure out how to do it. It would be nice, since the grow option was removed for raid1, to have an example of how to do it in %pre without having to spend the half a day, or more since this would need to be tested numerous times. I have to admit, I'm not interested in a distro switch (been using redhat since 4.2), but SL is an easy path. Thanks. Dan
*** Bug 747127 has been marked as a duplicate of this bug. ***
Sorry guys but "won't fix" for removing the grow option on raid1 devices is a very poor solution. If you plan to set up various clients with different functions and hard disks different in size the --grow option is needed. Let me explain why: we download the partition table during execution of the %pre section. The partition table is passed to anaconda during kickstart using the command line and downloaded from the install server with wget. The partition tables uses the --grow option on raid1 devices to be suitable for different hard disks. To deal with the disk size in the pre section is not a solution. I think the easiest way is to no longer use Fedora and switch to another dristro for our clients. Btw. I didn't find anything about the reasons for no longer supporting --grow. If it is as easy as described above there's no reason I can imagine why to remove the --grow option for raid1 partitions.
Implementing growing of raid partitions such that an arbitrary number of partitions always grow at the same rate and end up the same size is quite difficult. There are just more important things that we need to work on. If you are not satisfied with the fedora installer you have three options: 1) contribute by adding the functionality you want added 2) find a way to endure by using %pre or other methods 3) switch distros There's not much else to say.
I had no problems at all with that functionality of growing raid1 partitions in Fedora 13. I think the user himself is responsible to take care about the size of disks used. Normally two identical disks are used for this. And as far as I know a raid1 of two partitions different in size will end up with the smaller size of the both partitions. Or, if you want to make it really safe, the installer can abort if partitions used for raid1 are not equal in size. So I do not see any reason to remove --grow for raid1 partitions. What are the difficulties you mention above? Perhaps problems which might occur should be mentioned in the documentation to make users able to decide themselves about using --grow on raid1 partitions. But removing --grow is in my opinion to act as a guardian for users. Sorry, but I think a user dealing with unattended installs is knowledgeable enough to deal with problems resulting from --grow. Did you think about users when removing the --grow for raid1 partitions? Thought about large client roll out which may need the --grow feature? David, you suggest to contribute a functionality which was removed. Why not merge this functionality back into the current code? Should not be too difficult to do this by comparing the sources from the repository. And I think you're very familiar with the source code of the installer. Find a solution in the %pre section? Will not work in my scenario. Played arround with the %pre section but there's no satisfying solution. Well your "won't fix" will end up in a "won't use Fedora any longer".
For what it is worth, on the EL side of things (confirmed in RHEL and Centos) as of 6.3 the support is back in. it wasn't working quite right (see bug 683420) in 6.0, but in 6.3 looks good again. and yes you can do a lot of work in %pre, we do single vs dual drive and for el5 VM disk alignment. but it was nice for the installer to handle the disk size calculation.