I have flagged this as `important' because (a) it impacts people using
default settings from guided partitioning, and (b) it seems essential to
be able to have at least two kernels installed concurrently, otherwise
upgrades are impossible.  However, it does not leave the system broken.

This is a wheezy box that I set up a few months ago (not long before the
freeze).  During install, I used guided partitioning, and I accepted the
default recommendations for root, which is not so big:

root@wheezy1:~# df -lh /
Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/wheezy1-root  330M  266M   48M  85% /



Now, running `apt-get dist-upgrade' chokes on updating the linux-image
package.  Two issues come to mind:

a) are the kernel packages bigger in wheezy?  does the guided
partitioning need to leave more space so that people can have two
kernels installed at any one time?

b) why didn't apt-get detect the lack of space early on?



# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  linux-image-3.2.0-3-amd64
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
424 not fully installed or removed.
Need to get 0 B/23.3 MB of archives.
After this operation, 2,109 kB of additional disk space will be used.
Do you want to continue [Y/n]? y
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 255116 files and directories currently installed.)
Preparing to replace linux-image-3.2.0-3-amd64 3.2.21-3 (using
.../linux-image-3.2.0-3-amd64_3.2.23-1_amd64.deb) ...
Unpacking replacement linux-image-3.2.0-3-amd64 ...
dpkg: error processing
/var/cache/apt/archives/linux-image-3.2.0-3-amd64_3.2.23-1_amd64.deb
(--unpack):
 cannot copy extracted data for
'./lib/modules/3.2.0-3-amd64/kernel/drivers/scsi/libfc/libfc.ko' to
'/lib/modules/3.2.0-3-amd64/kernel/drivers/scsi/libfc/libfc.ko.dpkg-new': failed
to write (No space left on device)
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.2.0-3-amd64
/boot/vmlinuz-3.2.0-3-amd64
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.2.0-3-amd64
/boot/vmlinuz-3.2.0-3-amd64
Errors were encountered while processing:
 /var/cache/apt/archives/linux-image-3.2.0-3-amd64_3.2.23-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Neither of those things would be bugs in the linux kernel package, so
I'm not sure why you filed it there...

Cheers,
Julien

On the first point, (a), can anyone comment on how much space is
really required for root filesystem and give feedback for partman?

The second point, (b), apt-get seems to be unable to calculate space
required for the kernel package

I actually did a successful `apt-get dist-upgrade' for the whole
system, hundreds of packages, and only this package had an issue.  I
don't know if there is anything unusual about the package (for
example, during preinst) that may contribute to the problem, for
example - are there any obvious issues that you are already aware of?

If I had to guess, apt probably uses the Installed-Size header, which
doesn't discriminate between filesystems.

Cheers,
Julien

Perhaps more importantly, it can't account for the initramfs.

Ben.

Well, if this was me hacking around on some embedded device I would
take full responsibility and would never have opened a bug report for
the issue

But as these are the filesystem sizes created by partman auto/guided
partitioning, and as it seems like wheezy's kernel packages will be
bigger than squeeze's 2.6 kernels, I can't help imagining this problem
will confront other people when they install or upgrade.

Could the preinst script be adapted to test disk space and give a
helpful warning?

I've had the same problem recently with two different machines, both fresh
installs following the guided "encrypted LVM-partitioning" in the installer.
It's guite problematic not to be able to update the kernel on a default
install, and I guess this affects quite many people.

On both machines I've tried, it seems that the root-partition is made very
small (322 M) by the partitioner during the install, even on systems where
there's plenty of space to make the root-partition bigger.

I propose that this bug gets moved somewhere to partman / guided-install-
process, as it doesn't seem to be a problem only concerning this particular
package (I've experience the problem both on i868 and adm64).

Best regards,
Emil

Control: reassign -1 partman-auto
Control: fixed -1 123
Control: tag -1 wheezy

Wow, that is really much too small.  How large is the whole disk?

For the upcoming Debian 8 'jessie' release, I've changed partman-auto to
combine the / and /usr partitions, with the size (or proportion of the
disk) being the sum of the old sizes.

But it sounds like we still need a fix for Debian 7 'wheezy'.

Ben.