Bug 150670 is almost 4 years old. https://bugzilla.redhat.com/show_bug.cgi?id=150670
I'd like to see if we can get agreement on changing the default partitioning in anaconda to separate /home & "/".
I think this is vital, especially since live upgrades aren't "officially" supported, and many support docs recommend separating "/" & home, and doing a clean install when upgrading fedora versions.
Here is a roundup of relevant stuff from wiki, bugzilla, lists. =============================================================
https://www.redhat.com/archives/fedora-docs-list/2005-March/msg00012.html Mailing list discussion from fedora-docs list.
from http://docs.fedoraproject.org/install-guide/f10/en_US/sn-partitioning-advice... "If you expect that you or other users will store data on the system, create a separate partition for the /home directory within a volume group. With a separate /home partition, you may upgrade or reinstall Fedora without erasing user data files."
from http://docs.fedoraproject.org/install-guide/f10/en_US/sn-upgrade-tree.html "! Installations are Recommended. In general, the Fedora Project recommends that you keep user data on a separate /home partition and perform a fresh installation. For more information on partitions and how to set them up, refer to Chapter 12, Disk Partitioning."
from http://fedoraproject.org/wiki/DistributionUpgrades "Tips. * It's a good idea to have a backup of your system before performing an upgrade. If you have /home in a separate logical volume or partition, it makes backing up user data easier. This is a feature requested for the Fedora Installer. See Bug 150670 for more on this." * Doing a clean installation and then restoring user data from backups is known to work better."
from: http://fedoraproject.org/wiki/YumUpgradeFaq "Although upgrades with yum have been tested and work, live upgrades are not recommended by the Fedora Project. If you are not prepared to resolve issues on your own if things break, you should probably use the recommend installation methods instead. The recommended installation method is with a boot media with the Anaconda installer as detailed in the Installation Guide"
Proposals for /home, "/" split: ========================================
Here's a breakdown of proposals from bug report:
* smaller of 50/50 or 20Gb for "/". /home gets rest. from https://bugzilla.redhat.com/show_bug.cgi?id=150670#c17: "Autopartitioning logic: /boot --size=100 / --size=400 --grow --maxsize=20048 /home --size=100 --grow"
* smaller of 50/50 or 10Gb for "/". /home gets rest.
* don't separate /home from "/"
* don't allocate all disk space so can increase sizes later.
The 1st one seemed to get the most agreement.
Can we please decided once and for all on the best default partition scheme.
Thanks,
Lex.
PS - remember we're talking about the default, and us advanced users can always custom partition to our hearts content. Bug 150670 is almost 4 years old. https://bugzilla.redhat.com/show_bug.cgi?id=150670
I'd like to see if we can get agreement on changing the default partitioning in anaconda to separate /home & "/".
I think this is vital, especially since live upgrades aren't "officially" supported, and many support docs recommend separating "/" & home, and doing a clean install when upgrading fedora versions.
Here is a roundup of relevant stuff from wiki, bugzilla, lists. =============================================================
https://www.redhat.com/archives/fedora-docs-list/2005-March/msg00012.html Mailing list discussion from fedora-docs list.
from http://docs.fedoraproject.org/install-guide/f10/en_US/sn-partitioning-advice... "If you expect that you or other users will store data on the system, create a separate partition for the /home directory within a volume group. With a separate /home partition, you may upgrade or reinstall Fedora without erasing user data files."
from http://docs.fedoraproject.org/install-guide/f10/en_US/sn-upgrade-tree.html "! Installations are Recommended. In general, the Fedora Project recommends that you keep user data on a separate /home partition and perform a fresh installation. For more information on partitions and how to set them up, refer to Chapter 12, Disk Partitioning."
from http://fedoraproject.org/wiki/DistributionUpgrades "Tips. * It's a good idea to have a backup of your system before performing an upgrade. If you have /home in a separate logical volume or partition, it makes backing up user data easier. This is a feature requested for the Fedora Installer. See Bug 150670 for more on this." * Doing a clean installation and then restoring user data from backups is known to work better."
from: http://fedoraproject.org/wiki/YumUpgradeFaq "Although upgrades with yum have been tested and work, live upgrades are not recommended by the Fedora Project. If you are not prepared to resolve issues on your own if things break, you should probably use the recommend installation methods instead. The recommended installation method is with a boot media with the Anaconda installer as detailed in the Installation Guide"
Proposals for /home, "/" split: ========================================
Here's a breakdown of proposals from bug report:
* smaller of 50/50 or 20Gb for "/". /home gets rest. from https://bugzilla.redhat.com/show_bug.cgi?id=150670#c17: "Autopartitioning logic: /boot --size=100 / --size=400 --grow --maxsize=20048 /home --size=100 --grow"
* smaller of 50/50 or 10Gb for "/". /home gets rest.
* don't separate /home from "/"
* don't allocate all disk space so can increase sizes later.
The 1st one seemed to get the most agreement.
Can we please decided once and for all on the best default partition scheme.
Thanks,
Lex.
PS - remember we're talking about the default, and us advanced users can always custom partition to our hearts content. Bug 150670 is almost 4 years old. https://bugzilla.redhat.com/show_bug.cgi?id=150670
I'd like to see if we can get agreement on changing the default partitioning in anaconda to separate /home & "/".
I think this is vital, especially since live upgrades aren't "officially" supported, and many support docs recommend separating "/" & home, and doing a clean install when upgrading fedora versions.
Here is a roundup of relevant stuff from wiki, bugzilla, lists. =============================================================
https://www.redhat.com/archives/fedora-docs-list/2005-March/msg00012.html Mailing list discussion from fedora-docs list.
from http://docs.fedoraproject.org/install-guide/f10/en_US/sn-partitioning-advice... "If you expect that you or other users will store data on the system, create a separate partition for the /home directory within a volume group. With a separate /home partition, you may upgrade or reinstall Fedora without erasing user data files."
from http://docs.fedoraproject.org/install-guide/f10/en_US/sn-upgrade-tree.html "! Installations are Recommended. In general, the Fedora Project recommends that you keep user data on a separate /home partition and perform a fresh installation. For more information on partitions and how to set them up, refer to Chapter 12, Disk Partitioning."
from http://fedoraproject.org/wiki/DistributionUpgrades "Tips. * It's a good idea to have a backup of your system before performing an upgrade. If you have /home in a separate logical volume or partition, it makes backing up user data easier. This is a feature requested for the Fedora Installer. See Bug 150670 for more on this." * Doing a clean installation and then restoring user data from backups is known to work better."
from: http://fedoraproject.org/wiki/YumUpgradeFaq "Although upgrades with yum have been tested and work, live upgrades are not recommended by the Fedora Project. If you are not prepared to resolve issues on your own if things break, you should probably use the recommend installation methods instead. The recommended installation method is with a boot media with the Anaconda installer as detailed in the Installation Guide"
Proposals for /home, "/" split: ========================================
Here's a breakdown of proposals from bug report:
* smaller of 50/50 or 20Gb for "/". /home gets rest. from https://bugzilla.redhat.com/show_bug.cgi?id=150670#c17: "Autopartitioning logic: /boot --size=100 / --size=400 --grow --maxsize=20048 /home --size=100 --grow"
* smaller of 50/50 or 10Gb for "/". /home gets rest.
* don't separate /home from "/"
* don't allocate all disk space so can increase sizes later.
The 1st one seemed to get the most agreement.
Can we please decided once and for all on the best default partition scheme.
Thanks,
Lex.
PS - remember we're talking about the default, and us advanced users can always custom partition to our hearts content. Bug 150670 is almost 4 years old. https://bugzilla.redhat.com/show_bug.cgi?id=150670
I'd like to see if we can get agreement on changing the default partitioning in anaconda to separate /home & "/".
I think this is vital, especially since live upgrades aren't "officially" supported, and many support docs recommend separating "/" & home, and doing a clean install when upgrading fedora versions.
Here is a roundup of relevant stuff from wiki, bugzilla, lists. =============================================================
https://www.redhat.com/archives/fedora-docs-list/2005-March/msg00012.html Mailing list discussion from fedora-docs list.
from http://docs.fedoraproject.org/install-guide/f10/en_US/sn-partitioning-advice... "If you expect that you or other users will store data on the system, create a separate partition for the /home directory within a volume group. With a separate /home partition, you may upgrade or reinstall Fedora without erasing user data files."
from http://docs.fedoraproject.org/install-guide/f10/en_US/sn-upgrade-tree.html "! Installations are Recommended. In general, the Fedora Project recommends that you keep user data on a separate /home partition and perform a fresh installation. For more information on partitions and how to set them up, refer to Chapter 12, Disk Partitioning."
from http://fedoraproject.org/wiki/DistributionUpgrades "Tips. * It's a good idea to have a backup of your system before performing an upgrade. If you have /home in a separate logical volume or partition, it makes backing up user data easier. This is a feature requested for the Fedora Installer. See Bug 150670 for more on this." * Doing a clean installation and then restoring user data from backups is known to work better."
from: http://fedoraproject.org/wiki/YumUpgradeFaq "Although upgrades with yum have been tested and work, live upgrades are not recommended by the Fedora Project. If you are not prepared to resolve issues on your own if things break, you should probably use the recommend installation methods instead. The recommended installation method is with a boot media with the Anaconda installer as detailed in the Installation Guide"
Proposals for /home, "/" split: ========================================
Here's a breakdown of proposals from bug report:
* smaller of 50/50 or 20Gb for "/". /home gets rest. from https://bugzilla.redhat.com/show_bug.cgi?id=150670#c17: "Autopartitioning logic: /boot --size=100 / --size=400 --grow --maxsize=20048 /home --size=100 --grow"
* smaller of 50/50 or 10Gb for "/". /home gets rest.
* don't separate /home from "/"
* don't allocate all disk space so can increase sizes later.
The 1st one seemed to get the most agreement.
Can we please decided once and for all on the best default partition scheme.
Thanks,
Lex.
PS - remember we're talking about the default, and us advanced users can always custom partition to our hearts content.
On Wed, 2009-02-25 at 20:31 +1100, Lex Hider wrote:
Bug 150670 is almost 4 years old. https://bugzilla.redhat.com/show_bug.cgi?id=150670
I'd like to see if we can get agreement on changing the default partitioning in anaconda to separate /home & "/".
I think this is vital, especially since live upgrades aren't "officially" supported, and many support docs recommend separating "/" & home, and doing a clean install when upgrading fedora versions.
A huge +1. This is just a no-brainer for end-users, having a separate /home makes it massively easier to recover from all sorts of problems. I really don't see a downside. Except in the case where you're installing to a very small amount of space - there could be a simple heuristic which uses a single / partition when there's, say, 6GB or less space available.
On Wed, 2009-02-25 at 10:58 -0800, Adam Williamson wrote:
A huge +1. This is just a no-brainer for end-users, having a separate /home makes it massively easier to recover from all sorts of problems. I really don't see a downside. Except in the case where you're installing to a very small amount of space - there could be a simple heuristic which uses a single / partition when there's, say, 6GB or less space available.
The biggest problem has always been coming up with the right algorithm to decide how much / gets vs how much /home gets. Come up with a good one and throw it at the Anaconda folks to see what sticks.
On Wed, 2009-02-25 at 11:39 -0800, Jesse Keating wrote:
On Wed, 2009-02-25 at 10:58 -0800, Adam Williamson wrote:
A huge +1. This is just a no-brainer for end-users, having a separate /home makes it massively easier to recover from all sorts of problems. I really don't see a downside. Except in the case where you're installing to a very small amount of space - there could be a simple heuristic which uses a single / partition when there's, say, 6GB or less space available.
The biggest problem has always been coming up with the right algorithm to decide how much / gets vs how much /home gets. Come up with a good one and throw it at the Anaconda folks to see what sticks.
I'm far too lazy, I'll just steal Mandriva's. :P MDV does this by default, so it must have an algorithm. I dunno where it is (installer code is a big hairball), so I've just asked the author.
If I was doing it from scratch, though, I'd do it the way I do it manually - ask how much space everything else needs, and give /home the rest. Say, with less than 10GB of space don't split 'em, with less than 20GB give / 10GB and /home the rest, with less than 80GB give / 15GB and /home the rest, and over 80GB give / 20GB and /home the rest. Something like that, just a rough sketch. It only has to cover the most common use cases, because anyone doing stuff like running a server and needing lots of space in /var should really be doing their own partitioning in any case.
On Wed, 2009-02-25 at 11:59 -0800, Adam Williamson wrote:
I'm far too lazy, I'll just steal Mandriva's. :P MDV does this by default, so it must have an algorithm. I dunno where it is (installer code is a big hairball), so I've just asked the author.
If I was doing it from scratch, though, I'd do it the way I do it manually - ask how much space everything else needs, and give /home the rest. Say, with less than 10GB of space don't split 'em, with less than 20GB give / 10GB and /home the rest, with less than 80GB give / 15GB and /home the rest, and over 80GB give / 20GB and /home the rest. Something like that, just a rough sketch. It only has to cover the most common use cases, because anyone doing stuff like running a server and needing lots of space in /var should really be doing their own partitioning in any case.
I usually use 7GiB for / on stable, 7 GiB for / on rawhide, 2GiB for SWAP and the rest for /home. For the system these 7GiB are just enough (well, it's not enough for corner cases like when you install everything and a kitchen sink, but Desktop users usually don't need that much). I'd also say that for server stuff, people would usually create a separate /var partition, so I don't really think this is a huge issue. Just use 10GiB as a base and if you have big enough available space (say more than ~100GiB) you can start increasing until you reach some predefined maximum (I think ~30GiB would be sane). And when you have too little of space (say less than ~20 GiB), don't split by default.
In short, I'd prefer to have as little as is needed for system (+ some extra for future needs; i.e. for /) and as much as possible for data (i.e. for /home and /var if either is separate).
I think debian has this problem pretty much solved, is there any reason for not doing it the same way they do?
Martin
On Wed, Feb 25, 2009 at 22:04:03 +0100, Martin Sourada martin.sourada@gmail.com wrote:
Just use 10GiB as a base and if you have big enough available space (say more than ~100GiB) you can start increasing until you reach some predefined maximum (I think ~30GiB would be sane). And when you have too little of space (say less than ~20 GiB), don't split by default.
You might need to be smarter than that. I have a lot installed (including some rpmfusion stuff), but hardly everything and my / is close to 40 GB.
On Wed, 2009-02-25 at 15:25 -0600, Bruno Wolff III wrote:
On Wed, Feb 25, 2009 at 22:04:03 +0100, Martin Sourada martin.sourada@gmail.com wrote:
Just use 10GiB as a base and if you have big enough available space (say more than ~100GiB) you can start increasing until you reach some predefined maximum (I think ~30GiB would be sane). And when you have too little of space (say less than ~20 GiB), don't split by default.
You might need to be smarter than that. I have a lot installed (including some rpmfusion stuff), but hardly everything and my / is close to 40 GB.
That's really rather big. How'd you hit that? Are you sure you don't have some specific thing taking up a lot of space? What's du or baobab or something tell you?
On Wed, Feb 25, 2009 at 13:35:49 -0800, Adam Williamson awilliam@redhat.com wrote:
On Wed, 2009-02-25 at 15:25 -0600, Bruno Wolff III wrote:
You might need to be smarter than that. I have a lot installed (including some rpmfusion stuff), but hardly everything and my / is close to 40 GB.
That's really rather big. How'd you hit that? Are you sure you don't have some specific thing taking up a lot of space? What's du or baobab or something tell you?
I have all of the different language stuff installed which adds quite a bit. I don't actually use anything except English, but I like to check for conflicts, as occasionally there will be conflicts that only appear in a subpackage for a specific language.
On Wed, Feb 25, 2009 at 3:53 PM, Bruno Wolff III bruno@wolff.to wrote:
On Wed, Feb 25, 2009 at 13:35:49 -0800, Adam Williamson awilliam@redhat.com wrote:
On Wed, 2009-02-25 at 15:25 -0600, Bruno Wolff III wrote:
You might need to be smarter than that. I have a lot installed
(including
some rpmfusion stuff), but hardly everything and my / is close to 40
GB.
That's really rather big. How'd you hit that? Are you sure you don't have some specific thing taking up a lot of space? What's du or baobab or something tell you?
I have all of the different language stuff installed which adds quite a bit. I don't actually use anything except English, but I like to check for conflicts, as occasionally there will be conflicts that only appear in a subpackage for a specific language.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Most of my systems either have a 40GB or an 80GB hard disk. For the 40GB hard disk, I set it to 15GB for / and 23GB for /home with 2GB for swap. For the 80GB hard disk, I set it to 20GB or 40GB (depending on whether I expect games to be installed on it) for /, and 55GB or 35GB for /home and 5GB swap. The reason I have such a high swap is because the machines that I do have the higher hard disks, they run more intensive processes and I put it there for a precaution. My one machine that does have 160GB hard disk is set up like this: 50GB for /, 105GB for /home, and 5GB for swap. This machine runs video conversion and recording and all sorts of extra media center goodies, so that's why /home is so large.
ServeMobile (one of my laptops) has an 80GB hard disk, and has been running Fedora from 8 onward. When I switched to Fedora 9, I upped the swap space because of some slowdowns that I experienced because of swap maxing out. And in Fedora 10, it uses this configuration.
On Wednesday 25 February 2009 01:58:29 pm King InuYasha wrote:
When I switched to Fedora 9, I upped the swap space because of some slowdowns that I experienced because of swap maxing out. And in Fedora 10, it uses this configuration.
That doesn't make sense. If swap is maxed out, something gets OOM killed, not slowed down.
Regards,
On Wed, Feb 25, 2009 at 5:47 PM, Conrad Meyer konrad@tylerc.org wrote:
On Wednesday 25 February 2009 01:58:29 pm King InuYasha wrote:
When I switched to Fedora 9, I upped the swap space because of some slowdowns that I experienced because of swap maxing out. And in Fedora 10, it uses this configuration.
That doesn't make sense. If swap is maxed out, something gets OOM killed, not slowed down.
Regards,
Conrad Meyer konrad@tylerc.org
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
If stuff is getting killed, I either didn't notice it or whatever. All I really knew was that it slowing down and the GNOME dialog for not responding windows shows up and whatever. Either way, upping the swap space pretty much fixed it.
On Wed, February 25, 2009 4:47 pm, Conrad Meyer wrote:
On Wednesday 25 February 2009 01:58:29 pm King InuYasha wrote:
When I switched to Fedora 9, I upped the swap space because of some slowdowns that I experienced because of swap maxing out. And in Fedora 10, it uses this configuration.
That doesn't make sense. If swap is maxed out, something gets OOM killed, not slowed down.
I see a fairly reproducible issue with acroread run as a mozilla plugin consuming all memory and killing the machine. OOM doesn't kill it.
https://bugzilla.redhat.com/show_bug.cgi?id=438886
Unfortunately haven't had much time to investigate further. Basically we don't run with the pdf plugin enabled anymore.
Conrad Meyer konrad@tylerc.org writes:
That doesn't make sense. If swap is maxed out, something gets OOM killed, not slowed down.
No, the kernel does more aggressive paging of executables and other read-only pages which can be reloaded from disk. That kills whatever little performance might be leftover from the swap activity.
/Benny
Bruno Wolff III wrote:
On Wed, Feb 25, 2009 at 13:35:49 -0800, Adam Williamson awilliam@redhat.com wrote:
On Wed, 2009-02-25 at 15:25 -0600, Bruno Wolff III wrote:
You might need to be smarter than that. I have a lot installed (including some rpmfusion stuff), but hardly everything and my / is close to 40 GB.
That's really rather big. How'd you hit that? Are you sure you don't have some specific thing taking up a lot of space? What's du or baobab or something tell you?
I have all of the different language stuff installed which adds quite a bit. I don't actually use anything except English, but I like to check for conflicts, as occasionally there will be conflicts that only appear in a subpackage for a specific language.
games are something you'd see on a desktop install and those can take up quite a bit of room.
-Toshio
On Wed, Feb 25, 2009 at 13:59:31 -0800, Toshio Kuratomi a.badger@gmail.com wrote:
games are something you'd see on a desktop install and those can take up quite a bit of room.
I have all of those installed as well, so that is another chunk. Though I think having all of the optional language stuff takes up more space than all of the games.
On Wed, 2009-02-25 at 13:59 -0800, Toshio Kuratomi wrote:
Bruno Wolff III wrote:
On Wed, Feb 25, 2009 at 13:35:49 -0800, Adam Williamson awilliam@redhat.com wrote:
On Wed, 2009-02-25 at 15:25 -0600, Bruno Wolff III wrote:
You might need to be smarter than that. I have a lot installed (including some rpmfusion stuff), but hardly everything and my / is close to 40 GB.
That's really rather big. How'd you hit that? Are you sure you don't have some specific thing taking up a lot of space? What's du or baobab or something tell you?
I have all of the different language stuff installed which adds quite a bit. I don't actually use anything except English, but I like to check for conflicts, as occasionally there will be conflicts that only appear in a subpackage for a specific language.
games are something you'd see on a desktop install and those can take up quite a bit of room.
Also consider how much free space you need on / to perform a "preupgrade". Hint: a lot.
I really don't think automatically splitting /home is a good idea. Any heuristic is just that, heuristic. It's inevitably going to fail in some cases. The kind of people who just go with defaults are just the kind of Aunt Tillie's we don't want hitting such heuristic failures. Those smart enough to size / for their intended purpose aren't the ones using defaults.
On Wed, 2009-02-25 at 22:54 -0600, Callum Lerwick wrote:
I really don't think automatically splitting /home is a good idea. Any heuristic is just that, heuristic. It's inevitably going to fail in some cases. The kind of people who just go with defaults are just the kind of Aunt Tillie's we don't want hitting such heuristic failures. Those smart enough to size / for their intended purpose aren't the ones using defaults.
+1
On Wed, 2009-02-25 at 22:54 -0600, Callum Lerwick wrote:
Also consider how much free space you need on / to perform a "preupgrade". Hint: a lot.
I remember someone asking me on IRC why Mandriva bothers to split large urpmi (yum equivalent) transactions into small groups. This is the answer. :)
I really don't think automatically splitting /home is a good idea. Any heuristic is just that, heuristic. It's inevitably going to fail in some cases.
Mandriva and SUSE (and possibly Debian? Not sure) have been doing it for years and it really hasn't been hurting many (if any) people. I read every post to the Mandriva forums for four years from 2004 to 2008, I think there were maybe five or six people in all that time who filled up / (and it was usually because something had actually broken and started spewing zillions of bytes into log files or something, and in that case, it'd fill up / eventually no matter how big it is...).
From doing some Googling, it seems Ubuntu have come up with an
alternative approach, which is for the installer not to wipe out /home on an existing install...
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-May/004210.html
On Thu, 2009-02-26 at 17:55 -0800, Adam Williamson wrote:
On Wed, 2009-02-25 at 22:54 -0600, Callum Lerwick wrote:
Also consider how much free space you need on / to perform a "preupgrade". Hint: a lot.
I remember someone asking me on IRC why Mandriva bothers to split large urpmi (yum equivalent) transactions into small groups. This is the answer. :)
Actually, I think I misunderstood what preupgrade does. OK, so that's not practical in this case. So, it is a case that should be considered...have to think about that a bit.
On Thu, 2009-02-26 at 17:55 -0800, Adam Williamson wrote:
From doing some Googling, it seems Ubuntu have come up with an
alternative approach, which is for the installer not to wipe out /home on an existing install...
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-May/004210.html
You'd also need to not wipe out user accounts. But this seems like a worthwhile feature. Windows can do something like it. (There you just have to wipe out c:\windows...)
And now we start bikeshedding about implementation. Do we whitelist /home and /etc/passwd|group and wipe out everything else, or do we nuke a whitelist of known system directories? The latter is probably safer. You probably want to save /usr/local too. What if users have crap in /var/www/, or MySQL databases...
Our directory hierarchy (/var/ in particular) needs some serious rethinking.
2009/2/28 Callum Lerwick seg@haxxed.com:
On Thu, 2009-02-26 at 17:55 -0800, Adam Williamson wrote:
From doing some Googling, it seems Ubuntu have come up with an
alternative approach, which is for the installer not to wipe out /home on an existing install...
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-May/004210.html
You'd also need to not wipe out user accounts. But this seems like a worthwhile feature. Windows can do something like it. (There you just have to wipe out c:\windows...)
And now we start bikeshedding about implementation. Do we whitelist /home and /etc/passwd|group and wipe out everything else, or do we nuke a whitelist of known system directories? The latter is probably safer. You probably want to save /usr/local too. What if users have crap in /var/www/, or MySQL databases...
Or even safer -- the OS X "Archive and Install" approach, where this whitelist is moved into, e.g. /previous
There's a problem with lack of space, of course, and that /var in particular might be on a separate partition. So maybe for each whitelist entry that is mounted on its own partition, recursively do the backup, so if we are saving /var/foo and /var/bar, they end up in /var/previous/foo and /var/previous/bar if /var is mounted separately.
Callum Lerwick wrote:
On Wed, 2009-02-25 at 13:59 -0800, Toshio Kuratomi wrote:
Bruno Wolff III wrote:
On Wed, Feb 25, 2009 at 13:35:49 -0800, Adam Williamson awilliam@redhat.com wrote:
On Wed, 2009-02-25 at 15:25 -0600, Bruno Wolff III wrote:
You might need to be smarter than that. I have a lot installed (including some rpmfusion stuff), but hardly everything and my / is close to 40 GB.
That's really rather big. How'd you hit that? Are you sure you don't have some specific thing taking up a lot of space? What's du or baobab or something tell you?
I have all of the different language stuff installed which adds quite a bit. I don't actually use anything except English, but I like to check for conflicts, as occasionally there will be conflicts that only appear in a subpackage for a specific language.
games are something you'd see on a desktop install and those can take up quite a bit of room.
Also consider how much free space you need on / to perform a "preupgrade". Hint: a lot.
I really don't think automatically splitting /home is a good idea. Any heuristic is just that, heuristic. It's inevitably going to fail in some cases. The kind of people who just go with defaults are just the kind of Aunt Tillie's we don't want hitting such heuristic failures. Those smart enough to size / for their intended purpose aren't the ones using defaults.
System is going to need space for update/upgrade at some stage. Size needed for preupgrade isn't going to be any larger than for a live yum upgrade. If they upgrade via DVD/CD, they'll still need to download an iso of either 700Mb or 4Gb.
On Sat, 2009-02-28 at 13:22 +1100, Lex Hider wrote:
System is going to need space for update/upgrade at some stage. Size needed for preupgrade isn't going to be any larger than for a live yum upgrade. If they upgrade via DVD/CD, they'll still need to download an iso of either 700Mb or 4Gb.
To take the other side of the debate for a minute, that can always be downloaded to /home (and usually is).
Callum Lerwick wrote:
On Wed, 2009-02-25 at 13:59 -0800, Toshio Kuratomi wrote:
Bruno Wolff III wrote:
On Wed, Feb 25, 2009 at 13:35:49 -0800, Adam Williamson awilliam@redhat.com wrote:
On Wed, 2009-02-25 at 15:25 -0600, Bruno Wolff III wrote:
You might need to be smarter than that. I have a lot installed (including some rpmfusion stuff), but hardly everything and my / is close to 40 GB.
That's really rather big. How'd you hit that? Are you sure you don't have some specific thing taking up a lot of space? What's du or baobab or something tell you?
I have all of the different language stuff installed which adds quite a bit. I don't actually use anything except English, but I like to check for conflicts, as occasionally there will be conflicts that only appear in a subpackage for a specific language.
games are something you'd see on a desktop install and those can take up quite a bit of room.
Also consider how much free space you need on / to perform a "preupgrade". Hint: a lot.
I really don't think automatically splitting /home is a good idea. Any heuristic is just that, heuristic. It's inevitably going to fail in some cases. The kind of people who just go with defaults are just the kind of Aunt Tillie's we don't want hitting such heuristic failures. Those smart enough to size / for their intended purpose aren't the ones using defaults.
Separating '/' & /home on a 16gb netbook isn't going to be a good idea. For most use cases where HD size is reasonable, I say we agree on a Fedora Recommended Minimum Install Size.
I'm suggesting 20gb for this size & 40Gb for threshold. I'm completely open to these actual numbers being changed.
* Any HD over a certain size default partition has '/' at this size, with /home getting rest of space. * This size is documemnted in release notes & install guide. * What's on /tmp or /var is intelligently managed by default. Clear out stuff after is is no longer needed/useful. If program is going to fill '/', offer to clear out /tmp or /var/cache/yum, etc. * Is considered when developing features like preupgrade, etc. * Should be large enough to not be increased for a number of years.
My Proposal =========== Below threshold, '/' & /home on one partition. Above threshold, '/' is recommended minimum size we come up with, home gets rest. Remember I'm just talking about the default action. No-one is stopping you from doing your custom partitioning. I just think that changing the current default to this proposal would be a great improvement.
What Size Should We Recommend for '/' when '/home' is separate? ============================================================ As I see it, size needed breaks down to: * size of stuff installed. * size for downloading updates, /var/cache/yum, or new *.iso. * size in /tmp for DVD burning, ripping etc. (I assume k3b/brasero/nautilu-cd-creator,etc use /tmp for this?) * reasonable size for '/tmp' & '/var' to grow.
I'm suggesting 20Gb (don't know why my brain needs such a round number, and not 19 or 21???). Based on 8Gb for install, 5Gb for updates, 5Gb for /tmp, 2Gb for growth. I think all these numbers are on the generous size for what is needed.
Let's go through each one separately. * INSTALL. Default F10 DVD install uses 3.3G. F10 DVD install with all "groups" & languages ticked (didn't tick optional packages): 6.5G. Round this up to 7 or 8Gb sounds pretty safe?
* UPDATES. Since maximum support time for an install is around 13 months, the user is going to need to download updates. This will either be normal updates or live upgrade through yum (both into /var/cache/yum), preupgrade, (/var/cache/yum/preupgrade), or download an *.iso.
SYS-UPDATES I did a fresh F9 default DVD install, and then checked how much need to download to update system. update fresh F9-DVD-default: 714Mb update fresh F10-DVD-default: 626Mb update fresh F10-DVD-tickAll: 1.2Gb
PREUPGRADE/LIVE YUM UPGRADE I've already shown user needs better part of a gig just for system updates. Size needed for preupgrade doesn't look to much bigger than this. Some ideas of space needed for this by running "sudo yum --downloadonly --disablerepo=* --enablerepo=rawhide --installroot=/tmp groupinstall foo" Download sizes: core: 108M core+base: 292M core+base+base-x: 351M core+base+base-x+gnome-desktop: 622M all 18 groups with default set to true (what a default DVD would do): 1.1G all groups at once (yum groupinstall *): 3.1G
ISO SIZES LiveCD: 700Mb Fed 10 DVD: 3.4Gb Blank DVD Media: 4.7Gb
Let's say we allocate 5Gb to this, which should future proof this for quite some time. Maybe we suggest users download *.isos to /tmp in future?
* /TMP GENERAL USE: DVD BURN/RIP/ENCODE/ETC I assume things like nautilus-cd-creator/brasero/k3b use /tmp for making isos? Let's put 5Gb aside for this.
********* OTHER RELEVANT INFO ********************
Current new computer hard drive sizes. ============ As an example, I browsed Dell's cheapest desktop, netbook, laptop. Dell Mini: 16Gb, separating '/' & '/home' probably would be overkill, hence the threshold. Dell Inspiron lap: 160Gb. Dell Inspiron desk: 250Gb,
Other OSes minimum requirements ========== OS X: "9GB of available disk space" Vista Home: 20 GB hard drive with at least 15 GB of available space. Vista Premium, etc: 40 GB hard drive with at least 15 GB of available space XP: 1.5 gigabytes (GB) of available hard disk space* Windows 7: 16 GB of available disk space (from beta notes).
Hard drive requirements from F10 release notes: =============================================== "2.4.2.1.2. Hard disk space
All of the packages from a DVD install can occupy over 9 GB of disk space. The final install size is determined by the installing spin and the packages selected during installation. Additional disk space is required during installation to support the installation environment. The additional disk space corresponds to the size of /Fedora/base/stage2.img plus the size of the files in /var/lib/rpm on the installed system.
In practical terms the additional space requirements may range from as little as 90 MiB for a minimal installation to as much as an additional 175 MiB for a larger installation.
Additional space is also required for any user data and at least 5% free space should be maintained for proper system operation."
Thanks,
Lexual ;)
2009/2/25 Toshio Kuratomi a.badger@gmail.com:
Bruno Wolff III wrote:
On Wed, Feb 25, 2009 at 13:35:49 -0800, Adam Williamson awilliam@redhat.com wrote:
On Wed, 2009-02-25 at 15:25 -0600, Bruno Wolff III wrote:
You might need to be smarter than that. I have a lot installed (including some rpmfusion stuff), but hardly everything and my / is close to 40 GB.
That's really rather big. How'd you hit that? Are you sure you don't have some specific thing taking up a lot of space? What's du or baobab or something tell you?
I have all of the different language stuff installed which adds quite a bit. I don't actually use anything except English, but I like to check for conflicts, as occasionally there will be conflicts that only appear in a subpackage for a specific language.
games are something you'd see on a desktop install and those can take up quite a bit of room.
Also, 100 MB for boot (per original proposal) is definitely insufficient: I have a 160 MB boot and when using the preupgrade tool, it failed -- not enough space -- until I removed all but one kernel.
Let's say 256 MB boot. Everything else really depends on usage. Should we not distinguish between server-centric (large /var, smaller /) and desktop-centric (no need for separate /var and /tmp, big /) usage?
Plus, given that the default setup is LVM anyway, let's not allocate 100% of the space. That way, if the partitioning logic gets it wrong, the too-small partition can be grown without having to stick in another disk.
Regards,
On 2009/02/26 12:06 (GMT-0500) Michel Salim composed:
Let's say 256 MB boot. Everything else really depends on usage. Should we not distinguish between server-centric (large /var, smaller /) and desktop-centric (no need for separate /var and /tmp, big /) usage?
What on earth do you keep in your /boot? I've been using 204M /boot for several years, and can't remember even with 8 kernels installed finding less than 1/3 free on /boot.
On Thu, Feb 26, 2009 at 1:38 PM, Felix Miata mrmazda@ij.net wrote:
On 2009/02/26 12:06 (GMT-0500) Michel Salim composed:
Let's say 256 MB boot. Everything else really depends on usage. Should we not distinguish between server-centric (large /var, smaller /) and desktop-centric (no need for separate /var and /tmp, big /) usage?
What on earth do you keep in your /boot? I've been using 204M /boot for several years, and can't remember even with 8 kernels installed finding less than 1/3 free on /boot.
I was using the 'preupgrade' tool -- it creates an Anaconda image in /boot, and the next time you restart, it runs the installer from the boot partition. Kind of requires quite a bit of space.
And yes, before that, my 160 MB /boot is enough for multiple kernels.
Regards,
On Wed, Feb 25, 2009 at 10:58:56AM -0800, Adam Williamson wrote:
On Wed, 2009-02-25 at 20:31 +1100, Lex Hider wrote:
Bug 150670 is almost 4 years old. https://bugzilla.redhat.com/show_bug.cgi?id=150670
I'd like to see if we can get agreement on changing the default partitioning in anaconda to separate /home & "/".
I think this is vital, especially since live upgrades aren't "officially" supported, and many support docs recommend separating "/" & home, and doing a clean install when upgrading fedora versions.
A huge +1. This is just a no-brainer for end-users, having a separate /home makes it massively easier to recover from all sorts of problems. I really don't see a downside. Except in the case where you're installing to a very small amount of space - there could be a simple heuristic which uses a single / partition when there's, say, 6GB or less space available.
I know I'll regret saying anything here, but... This has been a frequent topic over the years, and I encourage some intrepid soul to head off the inevitable flood of rehashing by summarizing a previous thread from this list's archives. List the pros and cons here and we can move on from there as needed.
Eight years ago, a modest PC came with a 10-20 GB hard disk.
It sure would be nice to give new users -- even though we don't specifically cater to them -- a system that will be less painful for them to reinstall later.
-
Adam Williamson -
Benny Amorsen -
Bruno Wolff III -
Callum Lerwick -
Conrad Meyer -
Felix Miata -
Jesse Keating -
Lex Hider -
Martin Sourada -
Michel Salim -
Neal Gompa -
Orion Poplawski -
Paul W. Frields -
Simo Sorce -
Toshio Kuratomi