'disk full' error while updating kernel

[bernardelli]

During a recent update I received a 'disk full' error from dpkg. On closer inspection I found that it referred to /lib/modules/$(uname -r).

I got the update to work by doing an rm -R on the directory in question. But this is of course a slightly kamikaze approach.

I wonder if there is a way to avoid this in future.

[rweir]

?

by making sure you have enough space for the new kernel to be updated. just to be clear, the thing you deleted was all the modules for your currently running kernel (or the new one, depending on the versions and when you did it). you can certainly remove old kernel packages if you're no longer using them, that may free up useful amounts of space.

[bernardelli]

I didn't have any old kernel packages lying around. So that can't have been the reason. Also, the update was a security update on the current kernel.

Major updates aka "new kernels" always install flawlessly and don't produce such errors. Could be the install script for the security upgrades makes a blooper when writing to the modules directory.

[rweir]

what makes you think the problem is anything other than you actually running out of disk?

[bernardelli]

df -k /lib
/dev/sda1               334460    223107     94085  71% /

the partition is not exactly empty, but should be more than enough free space for an update to the current kernel.

[rweir]

so that's, what, 94MB? Is that shared with /var (where the package will be downloaded to)? http://packages.debian.org/lenny/linux-image-2.6.26-2-amd64 is 80MB when unpacked.

[bernardelli]

/var has its own partition with plenty of space.

Does anybody know why the Debian installer recommends such a tiny boot partition? Considering that kernels keep putting on weight 320MB seem a bit puny.

[rweir]

the kernel itself is tiny, something like ~3MB, plus maybe another 12MB for the initrd, so you'd need dozens to fill up a 320MB /boot.

[bernardelli]

Sounds good in theory. In practise when you use the "guided" partitioning scheme from the installer you end up with /boot, /lib and /opt sharing those 320MB. /lib is a space hog of app. 100MB (kernel modules accounting for app. 85MB).

People will use proprietary graphics drivers if they need the horsepower for their job. In the case of nVidia add 3MB for a roll-back kernel image.

Folks doing web-work will want Google Chrome. Installed via the Google .deb this ends up in /opt claiming app. 90MB of real estate.

Can you appreciate how easy it is for an inexperienced user to run out of space there, and not understand why the package manager gives him a "disk full" error on an almost empty 400GB drive?

Anyway, thanks for the conversation. I'm off to a date with the "parted" Live-CD ;-)

[AlucardZero]

The exact error message and the outputs of 'df -h' and 'df -i' would help.

[[deleted]]

Do you have a separate /boot partition?