Dave, as has been pointed out in support case 00383321 ... this would require reverting functionality that was added in RHEL6 or adding in functionality to make this functionality "optional".  I think the latter here is the best solution going forward, so I'm going to adjust this BZ as such.  

Thanks
Jeremy West
Red Hat Support Supervisor

Dave,

I've discussed this with the engineering teams, and while we definitely want to help this this resolved for you ... this change in functionality will need to be targeted for 6.2, due to a large volume of work that's already planned for the 6.1 release.  

If you have any questions/concerns, please address those in the customer support case as bugzilla is not a support tool.

Thanks!
Jeremy West

Well, you don't need to come up with separate manual partitioning for every machine.  Since you want to use autopart, you know you want the same partitioning on every system and just want the sizes to be different for different disks.  kickstart knows how to do that:

part /boot --fstype=ext4 --size=512
part pv.1 --size=10000 --grow
volgroup vg00 pv.1
logvol swap --vgname=vg00 --recommended --name=swap --fstype=swap
logvol / --vgname=vg00 --size=5000 --grow --fstype=ext4

You can play with the sizes to achieve the best fit, but there shouldn't be much extra work required.  You certainly shouldn't need to tweak it on a system-by-system basis.

For my initial request I'd have been happy with an additional flag to add to autopart or something rather than requiring something to activate the new behavior.

But comment 4 also gives what's probably a suitable workaround.  The main concern we had was with the boot device name, which isn't always the same on each machine, and is automatically determined by autopart.  For whatever reason I had it in my head that the --ondisk parameter to 'part' was required, but that appears not to be the case, and is certainly sufficient.

The config offered in comment 4 doesn't actually work, but it's really close. :)
The --name param for logvol appears to be required (the installer complains about running in command line mode without all options supplied without it).  So for the record, here's a working config:

part /boot --fstype=ext4 --size=512
part pv.1 --size=10000 --grow
volgroup vg00 pv.1
logvol swap --vgname=vg00 --recommended --name=swap --fstype=swap
logvol / --vgname=vg00 --size=5000 --grow --name=root --fstype=ext4

Attempted to resolve this WORKSFORME as I added that last comment, and it didn't take.  Perhaps that's restricted here and someone with more authority needs to do it.

I can close it as WORKSFORME if you're not interested in pursuing some additional change for 6.2, like "autopart --nohome" or something.  I'm not guaranteeing we'd do that, and we can always reopen a closed bug.  Just something to consider.

I imagine it'd still be useful to someone.  I'm no longer blocked on it getting implemented though.

If we get more reports of this, we can always reopen.

The workarounds provided in this bug report do not completely work around the issue.

autopart names volume groups after the hostname.  I have not found a reliable method to replicate this functionality when manually specifying a partition layout.

It would be helpful to have an 'autopart --nohome' option, as mentioned earlier.  This would provide the ability to use the default partition layout without tying up a bunch of disk space in /home.

Re-opening this, because we - oVirt/RHEV - also have this requirement.

In our case, we don't have users on the system, and need to assign all the available space to the / partition, especially because large /var/tmp is needed in some flows.

In RHEL 7 you can use something like:

reqpart --add-boot
part swap --recommended
part / --fstype xfs --size 1000 --grow

I should have elaborated, we are using autopart --type=thinp.
Transforming this into lines is more complex.

I request this RFE to prevent users from having to care about these details.

autopart --type=thinp --nohome

is easier than a couple of lv lines.

You know, if we added an interface to blivet's device factory to kickstart you could do something like:

reqpart --add-boot
logvol swap --recommended --factory
logvol / --factory --thin # no size means grow as large as possible

And that would do all the building block work for you. It won't happen for 7.3, but I wonder if it might be worthwhile.

What would the semantics of --factory be?

In general it looks good - because it seems to be an interface between autopart and doing the complete manual work.

The factory in blivet allows you to specify the leaf device (the one containing the filesystem or swap) without having to specify the building blocks. Normally in kickstart if you specify a logvol without first specifying the pvs and vg you get an error. The --factory option would signal anaconda to use the device factory instead of failing. By default, all factory lvs would go into the same vg, which would only be as large as it has to be to contain those lvs. It would limit the configuration options for the volgroup as well. To expose the full range of the devicefactory[1] it would probably be necessary to add a new kickstart command rather than an option. I am less confident in that idea than I am in simply adding the basics to the existing part, logvol, raid commands via a --factory option.

Does that answer your question?


[1] * alternative container (eg: vg) size policies: as large as possible, fixed
    * container (eg: vg) raid, which is done by creating and using an md pv
    * others exist, but you get the idea

I understand the broader concept, and this sounds pretty powerful.

+1 for this feature. I'm dissapointing with autopart for a long time. When, for example, there is no way to manually setup partitions on server, except auto/kickstart installation. And I got 800Gb /home partition on server :D

The --nohome option for the autopart command will be implemented. If you are interested in --factory, please open a new bug.

Just ran into this bug/feature. /home with 927GB :)

Big +1 for the extra switches.

The fix is available in a pull request: https://github.com/rhinstaller/anaconda/pull/986

Pull request was merged just 4 hours ago :)

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2293