Hide Forgot
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).
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