Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 150670 - Automatic partitioning option does not create separate /home
Summary: Automatic partitioning option does not create separate /home
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
: 155865 170482 (view as bug list)
Depends On:
Blocks: FC6Target AnacondaStorage
TreeView+ depends on / blocked
Reported: 2005-03-09 15:03 UTC by Stuart Ellis
Modified: 2009-11-17 12:25 UTC (History)
18 users (show)

Fixed In Version: anaconda-13.8-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-11-04 15:31:47 UTC

Attachments (Terms of Use)

Description Stuart Ellis 2005-03-09 15:03:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0

Description of problem:
If a user selects the option to automatically partition their /home directory will  be on the same partition as the OS.  This causes advanced users to routinely go through the manual partitioning process, and inconveniences new users who often do not realise at the time of installation that they should keep /home separate.

FWIW, issue raised on fedora-docs-list in context of providing correct advice on partitioning in the Isntallation Guide:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run anaconda.
2. Select automatic partitioning.
3. Complete installation.

Actual Results:  Completed installation has /home on the / partition.

Expected Results:  /home should be on a separate partition on the LVM group.

Additional info:

Comment 1 Peter Jones 2005-03-10 18:20:18 UTC
The "need" to have /home on its own partition is your preference, not a hard and
fast rule.

Comment 2 Karsten Wade 2005-03-10 23:52:02 UTC
Normally, we can consider the default anaconda preferences to represent Fedora
best practices.  In this case, most Linux practioners recommend a separate /home
for ease of upgrade, etc.

The problem is having to do destructive partitioning later after one learns of
the preference of /home as a partition.

It would be nice if the default offered a choice that will help end-users make
system changes later without having to deal with a complete reformat.  This has
the benefit of defaulting to the preferred behavior for most Linux enthusiasts.

Those who want their /home in the same partition as / can always change it back
that way.

This is a suggestion from the documenters, who are always putting in a Tip that
you might want /home as a separate partition ... and we thought, hey, maybe that
could be the default!

Thanks again for considering this.

FWIW, the "need" to have /home in the same partition as / as also a preference,
and not a hard and fast rule.  We're just recommending that one preference makes
a better default than the other.

Comment 3 Jeremy Katz 2005-03-14 18:09:09 UTC
I've thought about making it the default in the past, but one thing that makes
it a little tricky is how do you split the space between / and /home?

Comment 4 Tommy Reynolds 2005-03-14 19:11:43 UTC
Mark both as "grow" so they 50/50 split.  If the package selections don't fit,
the BACK button should allow users to change "/" to the known fixed size
announced by the installer if it fails.

At least this will prevent noob's from omitting the "/home" partition and then
having to scrape/re-partition in a few months when the next update comes out.  I
wouldn't mind a small bit of iteration here.

Comment 5 Jeremy Katz 2005-03-14 19:26:50 UTC
50/50 ends up being reasonable in cases where you have a "sane" sized disk, but
for something like a 250 GB disk (which isn't uncommon at this point) it ends up
being a little silly.  Although I guess something like 50/50 with a cap of 20 GB
on / might be reasonable.  Leaves lots of room for OS growth, etc.  

And, worst case, we're using LVM so we should be able to take advantage of it.

Comment 6 Karsten Wade 2005-03-16 00:14:18 UTC
That seems like a reasonable limit.

Having a default that grows /home as a partition with the remainder of a large
disk is (IMHO) a reasonable default.  For the majority of users, their largest
files will be media files in their ~/.  Anyone having special needs will best
understand what they need to change the default to.

Comment 7 Andrius Benokraitis 2005-03-16 00:32:28 UTC
I'm documenting quotas for RHEL4U1 in the SAG, and it seems like the entire "/"
file system must now be "enabled" in /etc/fstab in order quotas to work
(usrquota,grpquota) for /home. 

For /home to be included in the quota, and since /home doesn't have its own
logical volume associated, wouldn't this stifle admins a bit? Wouldn't this in
fact create a "global" quota limit, which includs /home and other directories
(/var)? May not be a real-world example, but would there be any potential limits
with quotas the way it is now (having no /home logical volume)?

Are there instances where admins need quotas on some piece of "/" and not on
others? Not sure, just thinking out loud here... That and I must either show my
examples setting usrquota,grpquota on the entire file system, or use a best
practice by inserting a note stating that I have a /home partition that was not
on by default during install. I'm leaning towards the former, as default
installs are used as a standard.

Comment 8 Jeremy Katz 2005-04-27 19:38:36 UTC
*** Bug 155865 has been marked as a duplicate of this bug. ***

Comment 9 Jeremy Katz 2005-04-27 19:40:10 UTC
Reopening and targeting FC5 since it's a little late for this in FC4

Comment 10 Rahul Sundaram 2005-06-27 12:44:57 UTC

Would be a good idea to have this RFE as a FC5 blocker. Having a seperate /home
by default is a very nice enhancement

Comment 11 Nerijus Baliūnas 2005-07-05 21:19:41 UTC
Please use 50/50 for disks up to 20 GB. For bigger disks 10 GB for / is enough,
rest should be /home.

Comment 12 Andrius Benokraitis 2005-07-05 21:33:02 UTC
What if use of a Web server is required? Wouldn't '/var' be part of that tiny
root 10GB partition? This is reminding me more and more like the needed defaults
that were created back in RHL7.2...

Comment 13 Nerijus Baliūnas 2005-07-05 21:57:30 UTC
Of course, algorithm may not be so simple, for example, after 30 GB it may be
40/60, after 40 GB - 30/70 and so on. But please don't give 125 GB for / when
the disk is 250 GB.

Comment 14 bob mckay 2005-10-14 11:59:34 UTC
I'm coming late to this debate, I hope not too late. The underlying assumption is that the whole disk 
should be used. With static partitions, this makes sense. WIth logical volumes, it's not so obvious. If the 
whole disk is used, a new user is essentially stuck forever with whatever paritioning scheme is chosen - 
shrinking a logical partition is not for the fainthearted with the tools currently available. On the other 
hand, expanding a logical volume is a breeze with the logical volume management tool. Or to put it 
another way, if the whole disk is used, the new user is immediately prevented from using the power of 
LVM (I've just spent close to a week figuring out _how_ to shrink that default logical partition, and I'm 
coming from a relatively long unix background).

Can I suggest an alternative. Something like 50/50 up to  20G, use 10G for / beyond that, and limit /
home to 20G. Let the user know that they have unallocated free space, and tell them where to look (ie 
logical volume manager) when they know how they want to use it. If they are running apache or 
something else that requires a bigger / filesystem, that's much harder anyway than expanding the / 
volume, you can assume they'll figure it out. 

Comment 15 Jeremy Katz 2005-10-15 15:09:00 UTC
*** Bug 170482 has been marked as a duplicate of this bug. ***

Comment 16 Alex Butcher 2006-01-27 15:52:07 UTC
A snapshot from a fairly well-used FC3 single-user 'desktop' installation:

$ df -h | grep -v scratch | grep -v burn | grep -v ' /2' | grep -v spare | grep
-v dos | grep -v shm
Filesystem            Size  Used Avail Use% Mounted on
/dev/hde2             2.0G  1.1G  806M  59% /
                      4.9G  3.6G  1.1G  77% /home
                      2.1G  1.6G  367M  82% /opt
                     1008M   50M  908M   6% /tmp
                       12G  5.8G  5.2G  53% /usr
                       16G  6.1G  8.9G  41% /usr/local
                      9.9G  6.6G  2.8G  71% /usr/src
                      3.0G  824M  2.0G  29% /var
                     1008M  306M  652M  32% /var/lib
                     1008M  670M  288M  70% /var/spool

Regarding the 'grep -v''ing:

/scratch is where I put miscellaneous downloads. This could as easily be /home.
/scratch is the largest single filesystem on this machine at 60G.

/burn and /burn2 are 9GB ext2 partitions for burning DVDs from. I've had
problems burning from resized ext3 on LVM on md RAID before, so I did this
pre-emptively. This is hopefully unnecessary on modern kernels/cdrtools.

/2 is a spare root on the second disc, manually copied before I do something

/spare is a another spare root, for the next time I upgrade the OS. If I install
with / as this partition, I can potentially dual boot and/or mount my old system
whilst merging changes.

/dos? are various legacy DOS partitions.

I'm still not using maildirs, so mail is in mbox files under /var/spool/mail.

I keep /var/lib as a seperate partition, for the sake of the rpm database.

Otherwise, hopefully all other decisions are easily understandable.

50/50 for / upto 10G should be fairly workable.

Comment 17 Stephen John Smoogen 2006-03-03 21:14:26 UTC
Hmmm it would seem to me that using the maxsize parameter in the logic would be
the best. Lets say:

Autopartitioning logic:

/boot --size=100
/  --size=400 --grow --maxsize=20048
/home --size=100 --grow

# and for us US Govt weanies

/tmp --size=100 --grow --maxsize=2048
/var/tmp --size=100 --grow --maxsize=2048

Comment 18 Keith G 2006-03-13 18:10:55 UTC
I'm a fairly new linux user and I've ended up installing /home on the same
partition as / , and trying to figure out how to best repartition. I use a FAT32
logical partition for data storage on the end of my linux partitions, so I don't
see that I need an extremely large /home, infact im more concerned with running
out of installation space on / .  My current setup is:

* 11GB  Primary FAT32 - Horrible ugly pathetic WinXP :(
* 100MB Logical /boot
* 40GB  Logical /
*  1GB  Logical swap 
* 68GB  Logical FAT32

How best should I repartition / to make /home ?  Also I'm going to be installing
 FC4 on another machine with 20GB to split between / and /home. That one
probably won't get much stored in /home at all, so how best should I split it?


Comment 19 Jon Masters 2006-04-18 11:46:40 UTC
FWIW, I don't think it's a good idea to have /home on a different volume by
default unless we provide an "easy" way for users to perform LVM/fs resizing
through a graphical tool (am I missing one?). I /used/ to religiously keep /home
and / separate. Now I just don't care - I can always create a new volume and
juggle things around later if I really care, but I usually don't.

Is the upgrades problem really such that this is necessary - can't we just say
"back it up" and/or provide some tips as in the past? Advanced users probably
know about volume resizing/creation of new volumes.

Comment 20 Tommy Reynolds 2006-04-18 13:07:26 UTC
Advanced users already know everything, so they don't matter ;-)

The upgrade problem is very real to new users, expecially for Fedora: then
tend to accept defaults for things they don't understand and partition layout
a prime example.  Then, six months later, when FC{n+1} appears, they must
either add a new drive, try to save and scrape, or, with a separate /home
partition _absolutely_ _nothing_.

The idea here is to lower the best-practices bar to newbies.

Comment 21 bob mckay 2006-04-30 08:23:37 UTC
The problem seems to be partially fixed in FC5, in that the lvm gui now provides the option of reducing 
volume size. However it still leaves a problem for novices, who may not understand that they will need to 
boot from a separate system in order to be able to umount and resize the system.

Comment 22 Karsten Wade 2006-04-30 14:37:13 UTC
These are orthogonal discussions.  The LVM situation with resizing partitions
and having /home as a separate partition by default are not really related.  I
understand the relationship and how certain LVM features help with one of the
use cases that supports a default /home.

I don't want us to lose site of the simplicity of just choosing ANY disk
percentage scheme and assigning a lot of it to /home.  This is a case where
anything is better than nothing.

This feature would be a fine one with FC 6, but it would be even more wonderful
if it could (have) made it into RHEL 5.  Seven years of supported RHEL 5 users
might have liked this as a default.

Is there any technical hurdle we cannot accomplish here?

Or is it that the Anaconda maintainer(s) just disagree with the concept entirely?

Not that I want to make a big research project out of this, but from the stories
I get from #fedora and fedora-list helpers, this is a no-brainer needed feature.

Comment 23 bob mckay 2006-04-30 16:15:09 UTC
I agree with Karsten's point about orthogonality, a point I originally made when 170482 was marked as 
a duplicate of this bug. Perhaps I should have been clearer in my preceding message, that the new 
ability to shrink logical volumes in the LVM gui has greatly ameliorated the problems associated with 
using the whole disk space by default.

However on the issue of separate /home, the new ability of the gui actually reinforces the need to 
separate /home from the system. The system still can't be resized without booting from a separate 
system, whereas /home is now easy to resize - up or down - if it's in a separate logical volume.  

It has also made the issue of choosing the initial sizing easier - there's now no problem with using a 
simple scheme such as 50/50 up to 20G, then 10G for system and the rest for /home beyond that 
(using the previous argument, that if a user needs more than 10G for system, they're not a newby, and 
can be relied on to know how to resize system). 

Comment 24 Robert Soliday 2006-07-05 19:15:18 UTC
This may be too simplistic but why not look at the reason people reformat with
an upgrade? They want to get rid of all the stuff under / while keeping the
stuff under /home. So why not offer an option to delete everything but /home
and/or other user specified directories and to not reformat the existing
partition. This way we could keep /home on the same partition as /.

Comment 25 Rahul Sundaram 2006-07-05 19:20:06 UTC
(In reply to comment #24)
> This may be too simplistic but why not look at the reason people reformat with
> an upgrade? They want to get rid of all the stuff under / while keeping the
> stuff under /home. So why not offer an option to delete everything but /home
> and/or other user specified directories and to not reformat the existing
> partition. This way we could keep /home on the same partition as /.

Thats already under consideration -

Comment 26 Red Hat Bugzilla 2007-02-05 19:32:39 UTC
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.

Comment 27 Patrick C. F. Ernzer 2007-06-16 12:56:43 UTC
Just my 0.02 EUR

I fully agree with Karsten, on automatic partitioning we want to help the
average user (who just clicks through the installer) and we want to reflect best

Suggest the following;
swap recommended
/boot 100M-200M
/ 1G - 20G
/home the rest

This takes into consideration;
  - you are pretty hard pressed to be able to even find a new HD that is less
than 60G
  - this is for Joe Average who just clicks through the defaults
  - we ship resize2fs, so if Joe Average does become a power user, he can shrink
his /home

Comment 28 Paul W. Frields 2007-08-29 12:25:39 UTC
The latest Installation Guide (F7) discusses partitioning in a way useful to
more new users, but it's unfortunate that we still haven't resolved a good way
to handle this in the installer.

What about this idea:
1. Iff the whole storage area is >(some lower bound, say 4GB?), and the user
chooses automatic partitioning, create a minimal sized /home of ~50-100 MB, and
touch a marker such as /home/.autopart.
2. If firstboot detects /home/.autopart, it runs a module that gives appropriate
guidance to the user and allows them to resize /home and / with a simple slider.

Comment 29 Lubomir Kundrak 2008-01-14 08:55:55 UTC
I'm not going to believe this is really still being discussed. In most cases it
brings more problems than it can solve. Ranging from waste of space to inability
to upgrade due to lack of space on / even though there would be enough space on
/home. This really makes no sense to makes that a default, since "one big /"
approach is far most fault prone and guarantees most fair use of space in most

Custom partitioning can still be used, many people do that, including me, are
happy with that. I am as satisfied with the current default partitioning as I
can ever be. My two cents on "don't break things that work perfectly" side.

Comment 30 Karsten Wade 2008-01-16 06:51:16 UTC
(In reply to comment #29)
> I'm not going to believe this is really still being discussed. 

Hee hee, I agree, but from the opposite side.  Just as you are certain you are
right, I am certain that technical issues aside, it makes more sense to have a
/home partition by default from the installer.

> In most cases it
> brings more problems than it can solve. 

Please back up your assertion with facts.

The problems of not having a /home are clear -- new users suffer, people helping
them suffer.  We've talked for years directly to these suffering newbies, and
Fedora helpers continue to report that this is a common sufferance.

> Ranging from waste of space to inability
> to upgrade due to lack of space on / even though there would be enough space on
> /home. 

Ten years ago, it was far more common for other parts of / to be more full than
/home, so the argument about waste of space made sense.  However, the growth of
non-program file sizes and the ability to move them around has lead to a growth
in /home.

You are correct that there is a technical issue here that is hard to resolve,
which is how to provide a useful ratio or algorithm to calculate how to slice up
a disk.  I personally think the "minimum of X GiB to /, rest to /home" could
work for the vast, vast majority of cases.  In my experience, 8 to 12 GiB for /
is more than enough.

If we were to actually commit to fixing this problem in the installer instead of
leaving it to documentation and the time of newbie helpers, we might find a way
to figure out what that ratio should be.  For example, if Smolt gathered disk
growth rates over time by top-level / directories.

> This really makes no sense to makes that a default, since "one big /"
> approach is far most fault prone and guarantees most fair use of space in most
> cases.

Until it comes time to upgrade or try out a new distro.  Or to encrypt one's
personal data.  Then it's a mad scramble to find a way to double-backup all your
data so you can erase your primary data source and start over.

Remember, defaults are for the newbies, not the experienced user.  We need to
provide defaults that represent the best practice we can afford to hard code. 
As you say next, you yourself change the default.

> Custom partitioning can still be used, many people do that, including me, are
> happy with that. I am as satisfied with the current default partitioning as I
> can ever be. 

How would having /home be a default partition affect you negatively?

I'm guessing that you don't spend much time helping newbies in #fedora or
fedora-list?  Neither do I, but I do talk often with those wonderful and helpful
Fedorans who do, and so far the universal desire is to see /home as a default

> My two cents on "don't break things that work perfectly" side.


If they worked perfectly, this bug wouldn't have been filed, nor would such
reasoned arguments have been made.

So far, the arguments against the /home partition come to these:

1. "It's too hard to figure out the ratio, so why try?"
2. "It's not really needed because I don't need it."

Presuming there is a way to reasonably resolve 1. (mathematically, Smolt
results, survey, etc.), how is anyone hurt /home as a default partition?

So far, AIUI the evidence from the Fedora helper community is clear.  If you
have counter evidence, let's see it.

Comment 31 Patrick C. F. Ernzer 2008-01-16 11:21:08 UTC
+1 to Comment #30

one small addition, bug owner to please keep in mind what the minimum size of
storage is one can buy today (well over 16GB), there is absolutely no need to
assign all space in the volume group. It is actually beneficial to keep some
Free PEs and allow the user to grow partitions (as per comment #28)

And I think we can determine pretty well what the worst case size for / is, take
the size we need on / for a 'all packages' install (meaning package size +
whatever size we may need on top of that for temporary files), multiply by 2 to
cover the worst case where user installs Fedora and on the first yum update
every single package would need updating. Add 10% on a better safe than sorry
note. Add another 250MB to the resulting size for config files and round up to
the next Gigabyte for good measure.

Comment 32 Axel Thimm 2008-01-16 12:10:57 UTC
+1 to Comment #30 from me, too.

And adding to the pile of pros and cons: An old con to overpartitioning is that
one loses slack space due to the fragmentation of free space. But we're rather
close to making that a non-issue if we have a fully working extN-resize. So this
would be an incentive to get the online resizing of ext2/3/4 completed (if it
isn't in rawhide, I haven't checked lately).

And another pro to having separate /home: I love wiping out my old Fedora
install and make a reinstall w/o having to backup my data. I have inherited a
couple of FC2->F7 systems and the issues that accumulate with each upgrade (as
well as old and unused packages) are quite disturbing at the end. Instead an
installer method of scratch-all-then-have-a-new-install-but-don't-touch-home is
simple and clean.

On comment #31: Leaving some free PEs around is not a good idea - the standard
user will forget about it the next day and will wonder that some months later he
needs a new disk, while perhaps half of it is just not-allocated :)

P.S. When we get zfs then free space is automatically redistributed. ;)

Comment 33 2008-03-28 15:30:05 UTC
+1 to Comment #30 for me, too.

From the DISA STIG for UNIX:
The /home, /export/home, and /var filesystems will have their own partitions. 
If not properly partitioned, in the event that one of these partitions becomes
full, the risk of the root partition becoming 100% full will occur, which may
cause system and application issues.

The DISA STIG for UNIX can be found at

Comment 34 Bug Zapper 2008-05-14 01:59:15 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:

Comment 35 Bug Zapper 2008-11-26 01:47:32 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:

Comment 36 Subhendu Ghosh 2009-06-18 22:21:04 UTC
Partition defaults:

swap -
/boot --size=200
/  --size=4000 --grow --maxsize=20000
/var --size=4000  --grow --maxsize=10000
/home --size=1000 --grow

Swap - account for how memory algorithms work today and the typical amount of RAM.

A larger /boot partition to allow for dual boot or a large set of installed kernels

/ -   decent size to allow almost a full install on the minimum size. Upper limit allows inclusion of /usr/local and /opt based software

/var  - minimum size if good for most logs, virt images could go into filesystem or sub-mount and new partitions could be added later

/home - where 90% of the user data lies and should not be touched during any upgrade

Comment 38 Chris Lumens 2009-11-04 15:31:47 UTC
This will be fixed in anaconda builds for F13, though not for F12.  The algorithm for deciding sizes here is really simple and might require some minor tweaking in the future, but I'm pleased with it for now.  Basically if you have a VG <= 50 GB, you'll get /, swap, and /boot.  If you have a VG > 50 GB, / will get capped at 50 GB and /home will fill out the rest.  The growing algorithm has been undergoing some work lately that should make sure none of the LVs have too ridiculous of a size, and the 50 GB minimum for having a /home makes sure that devices with smaller disks won't end up with an unusable split.

In the worst case, this is just a suggestion and you are free to change it yourself with the partitioning UI.

Comment 39 Patrick C. F. Ernzer 2009-11-04 16:45:05 UTC

sounds reasonable to me. Once that is in we'll finally have a reasonable setup for users who just accept all defaults. Thanks for making this happen.

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