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: https://www.redhat.com/archives/fedora-docs-list/2005-March/msg00012.html Version-Release number of selected component (if applicable): How reproducible: Always 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:
The "need" to have /home on its own partition is your preference, not a hard and fast rule.
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.
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?
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.
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.
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.
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.
*** Bug 155865 has been marked as a duplicate of this bug. ***
Reopening and targeting FC5 since it's a little late for this in FC4
Would be a good idea to have this RFE as a FC5 blocker. Having a seperate /home by default is a very nice enhancement
Please use 50/50 for disks up to 20 GB. For bigger disks 10 GB for / is enough, rest should be /home.
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...
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.
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.
*** Bug 170482 has been marked as a duplicate of this bug. ***
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% / /dev/mapper/200GVolGroup01-home 4.9G 3.6G 1.1G 77% /home /dev/mapper/200GVolGroup01-opt 2.1G 1.6G 367M 82% /opt /dev/mapper/200GVolGroup00-tmp 1008M 50M 908M 6% /tmp /dev/mapper/200GVolGroup01-usr 12G 5.8G 5.2G 53% /usr /dev/mapper/200GVolGroup01-usrlocal 16G 6.1G 8.9G 41% /usr/local /dev/mapper/200GVolGroup00-usrsrc 9.9G 6.6G 2.8G 71% /usr/src /dev/mapper/200GVolGroup00-var 3.0G 824M 2.0G 29% /var /dev/mapper/200GVolGroup01-varlib 1008M 306M 652M 32% /var/lib /dev/mapper/200GVolGroup01-varspool 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 stupid/dangerous. /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.
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
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? Cheers, Keith.
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.
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.
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.
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.
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).
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 /.
(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 - http://fedoraproject.org/wiki/AnacondaWorkItems#upgrade
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
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 practices. 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
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.
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 cases. 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.
(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 partition. > My two cents on "don't break things that work perfectly" side. -1 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.
+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.
+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. ;)
+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 http://iase.disa.mil/stigs/stig/unix-stig-v5r1.pdf.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Partition defaults: swap - http://kbase.redhat.com/faq/docs/DOC-15252 /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
Please see https://www.redhat.com/archives/anaconda-devel-list/2009-October/msg00517.html.
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.
Chris, 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.