Bug 663099 - [RFE] kickstart's autopart should not automatically create /home in an enterprise environment
Summary: [RFE] kickstart's autopart should not automatically create /home in an enterp...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.2
Hardware: Unspecified
OS: Unspecified
Target Milestone: alpha
: 7.3
Assignee: Vendula Poncova
QA Contact: Release Test Team
Filip Hanzelka
Depends On:
Blocks: Red Hat1395321 1428455
TreeView+ depends on / blocked
Reported: 2010-12-14 17:22 UTC by Dave Miller
Modified: 2018-11-14 16:20 UTC (History)
17 users (show)

Fixed In Version: anaconda-
Doc Type: Enhancement
Doc Text:
"autopart --nohome" in a kickstart file disables the creation of `/home/` in automatic partitioning This update adds the "--nohome" option to the "autopart" command in a kickstart file to disable automatic creation of the `/home/` partition. This enhancement avoids the need to perform manual partitioning if the `/home/` partition is to be averted. As a result of the update, the `/home` partition is not created if partitioning is done automatically.
Clone Of:
: 1428455 (view as bug list)
Last Closed: 2017-08-01 08:50:51 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2293 0 normal SHIPPED_LIVE anaconda bug fix and enhancement update 2017-08-01 12:39:44 UTC

Description Dave Miller 2010-12-14 17:22:30 UTC
Description of problem:
Bug 150670 introduced a "feature" to autocreate a separate /home partition if the disk is over a certain size when using the "autopart" option in kickstart, but provided no capability to opt out of this configuration without doing a complete manual partitioning.

This is less than optimal in an enterprise environment where the majority of the servers will never have anything in the /home tree because they are web, application, or database servers and not desktops or shell servers.

We have a variety of hardware configurations and making separate kickstarts with manual partitioning information for every possible drive configuration we might have is not optimal.  We need a way to get the old behavior back or this puts a serious dent in the idea of using RHEL6 instead of RHEL5 on new machines. (And we have requirements from our web development teams for software which is hard to obtain for RHEL5, so other distributions aren't out of the question if we can't get RHEL6 to work)

Additional info:
We are an enterprise customer, we have a support ticket on file for this issue (case 00383321).

Comment 2 Jeremy West 2010-12-14 17:37:38 UTC
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.  

Jeremy West
Red Hat Support Supervisor

Comment 3 Jeremy West 2010-12-14 17:50:29 UTC

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.

Jeremy West

Comment 4 Chris Lumens 2010-12-14 18:12:30 UTC
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.

Comment 5 Dave Miller 2010-12-14 20:13:09 UTC
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.

Comment 6 Dave Miller 2010-12-15 06:12:40 UTC
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

Comment 7 Dave Miller 2010-12-15 06:14:12 UTC
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.

Comment 8 Chris Lumens 2010-12-15 15:03:35 UTC
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.

Comment 9 Dave Miller 2010-12-15 17:32:13 UTC
I imagine it'd still be useful to someone.  I'm no longer blocked on it getting implemented though.

Comment 10 Chris Lumens 2010-12-15 18:15:48 UTC
If we get more reports of this, we can always reopen.

Comment 11 adam.dorsey 2014-07-17 18:05:16 UTC
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.

Comment 12 Fabian Deutsch 2016-05-18 18:52:36 UTC
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.

Comment 13 David Shea 2016-05-18 19:01:42 UTC
In RHEL 7 you can use something like:

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

Comment 14 Fabian Deutsch 2016-05-18 19:13:18 UTC
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.

Comment 15 David Lehman 2016-05-18 19:34:04 UTC
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.

Comment 16 Fabian Deutsch 2016-05-18 19:38:22 UTC
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.

Comment 17 David Lehman 2016-05-18 20:04:13 UTC
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

Comment 18 Fabian Deutsch 2016-05-19 12:32:35 UTC
I understand the broader concept, and this sounds pretty powerful.

Comment 20 Vit Ry 2017-01-30 22:58:56 UTC
+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

Comment 21 Vendula Poncova 2017-02-16 10:26:52 UTC
The --nohome option for the autopart command will be implemented. If you are interested in --factory, please open a new bug.

Comment 22 Gorkhaan 2017-02-20 16:44:37 UTC
Just ran into this bug/feature. /home with 927GB :)

Big +1 for the extra switches.

Comment 24 Vendula Poncova 2017-03-08 12:27:23 UTC
The fix is available in a pull request: https://github.com/rhinstaller/anaconda/pull/986

Comment 26 Eduardo Baitello 2017-03-16 18:01:17 UTC
Pull request was merged just 4 hours ago :)

Comment 32 errata-xmlrpc 2017-08-01 08:50:51 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.