Bug#640377: debian-installer: /usr partition is too small, even on hugh hard disk
Package: debian-installer
Severity: normal
Hi.
I am normally using FAI to installing Debian boxes,
but I was evaluating migration to amd64 from i386,
so needed some more control. Mostly applications
(some are i386 only), and some user testing if
everything is OK.
I done this manually using squeezy installer,
as our FAI box is configured to serve i386 Debian,
and I do not see any easy way to have both
i386 and amd64 on the same FAI machine.
I just wanted to do this quickly so used squeeze biarch
DVD. I also just used "guided partitioning".
It is similar to the #575914 bug
( debian-installer: cannot resize partitions after "guided partitioning" step )
So, I have 250GB SATA disk, and automatic partitioning
with multiple partitions ended with /usr having 8.3GB (df -h).
I rebooted, and started installing sofware with apt-get.
I was in the middle of installing software (everything from
normal Debian repositories), when /usr space
run out. I comparred to the other boxes, and most use about 12GB
of space in /usr.
It is not really big installation, just a workstation software,
full gnome, kde, xfce, openoffice, few other important software,
multiple compilers and development libraries.
Inspecting packages on other machines,
we have about 3000-3380 packages installed.
We have list of packages which are automatically installed
by FAI, and I was using exactly same list.
http://smp.if.uj.edu.pl/~baryluk/fai/KOLO_WS
I guess, this 8GB /usr partition is some kind
of celling in the debian-installer, but 14GB will be much
better for really big HDDs, especially if someone
wants to install both kde and gnome, and still wants 1-2 GB
for things like Mathematica or Quake 3 in /usr/local. :)
User will be safe, if he/she puts everything on single partition,
or separate /home probably, but when he/she choose
separate /var, /usr and /tmp, he will have trouble.
I just checked recipes/multi file in the
git://anonscm.debian.org/d-i/partman-auto.git
and it says 9000 MB is the max for /usr
I think we can assume amd64 is new enough,
and user have quite big hard disk. (at least on amd64).
Actully I find that not so long ago (Oct 2010),
in commit b639042b331dc, changed /usr
from 6000MB to 9000MB.
Previous change was from 5000MB to 6000MB,
in May 2010 in commit 0cfe282142e2905.
I know 14GB may sound like huge jump from 9GB.
So, I think limiting this to amd64, and maybe some
additional small logic (like having at least 200GB free
space used for autopartitioning), should solve it.
I inspected serveral different machines installed
by me, desktops, laptops, installed manually,
or using FAI. And 12GB used in /usr was almost
on all of them. Some machines used about 14GB,
because for example of Mathematica or Intel Compiler.
It is also good to slightly over-estimate size, as
over-estimating doesn't hurt much (maybe other partition
will have smaller size), in the oposition to under
estimating size. Also having /usr filled too much
will make it highly fragmented, thus drastically
decressing performance and boot+login speed.
Also people who use multi parition profile,
tend to be a) wanting server, b) wanting
workstation used by multiple people, c)
desktop or laptop of advanced user, which
likes to experiment.
In cases 2 and 3 in most situations, we will need
quite big /usr space needs, in range about 12-14GB
range.
Other aspect is LVM. On LVM it is much smaller issue,
as one can increase file system by borowing space
from other logical volume. However, I always
find that I decress /home LV, and give some more
room for /usr, not always just after installation,
but it always happen, even if I was partitioning
disk manually. By making defaults bigger we can
avoid that, and we will not waste space anyway,
as user still can use LVM to do the reverse
(decress size of /usr, and give it to /var or /home, etc).
Reverse however is less probably, it will also
make underlaying partition extents of /usr, be
more continous on the disk, thus also improving
seek times and file system layout.
Another reason is that amd64 binaries tends to be slightly
larger than i386 (about 10%), and that gcc 4.6 recently often
produces bigger object files (depending on flags).
Actually ia64 architecture would see biggest
benefit from this change, binaries there are 2.1x bigger
on avarage (sometimes more) than on i386 or amd64.
ia64 have currently only 7000 MB in /usr in multi partition scheme,
by default, combining it with much bigger object files,
it would be good to increase it. Other archs, could also
have similar problem, but probably only alpha and sparc64,
are reasonable candidates.
Here is good, representative example
http://packages.debian.org/sid/links
which shows how installed package size varies
beetwen arcitectures. This pattern is common
for lots of binary packages.
tl;dr: Increase default maximal size of /usr to 13GB
on amd64, kfreebsd-amd64 and ia64
Still would be good to have #575914 fixed, one could
adjust partition sizes after autopartitioning assigned
sizes automatically.
Thanks.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.1.0-rc4-t43-prod-00131-g9e79e3e-dirty (SMP w/1 CPU core)
Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) (ignored: LC_ALL set to pl_PL.utf8)
Shell: /bin/sh linked to /bin/dash
Reply to: