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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
