[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#617299: dpkg-deb: should give a hint when it fails due to filling /tmp

2012/7/13 Ben Hutchings <ben@decadent.org.uk>:
> On Fri, Jul 13, 2012 at 11:02:57PM +0300, Martin-Éric Racine wrote:
>> (putting back the CC to the bug, which will probably need to be
>> reassigned to 'linux')
>> 2012/7/13 Jonathan Nieder <jrnieder@gmail.com>:
>> > (dropping dpkg maintainers from cc)
>> > Martin-Éric Racine wrote:
>> >> 2012/7/13 Jonathan Nieder <jrnieder@gmail.com>:
>> >>> Martin-Éric Racine wrote:
>> >
>> >>>>                                                      the resulting DEB
>> >>>> is a whopping 488MB in size, compared to 22MB for the stock Debian
>> >>>> linux-image-3.2.0-3-686-pae built using the exact same .config file.
>> >>>
>> >>> That's because the Debian packaging strips debugging symbols into a
>> >>> separate -dbg package.
>> >>
>> >> I'm already aware of the effects of stripping binaries. However, you
>> >> gotta admit that 488MB compared to 22MB is just ridiculous; something
>> >> is definitely broken in those 3.2 build scripts.
>> >
>> > Are the build scripts responsible for the size of debugging symbols?
>> > I don't follow.
>> >
>> > Or do you mean that the size of the kernel -dbg packages is
>> > ridiculous?
>> I mean that the size of the kernel package produced by 'make deb-pkg'
>> from the 3.2 vanilla tree, even after disabling debug symbols, is
>> highly suspicious, compared to the stock Debian kernel with the same
>> source.
> Did you actually rebuild with CONFIG_DEBUG_INFO off, or did you
> only re-run 'make deb-pkg'?

The plot thickens:

If I disable CONFIG_DEBUG_INFO again just before building, the kernel
indeed is MUCH smaller (I had probably forgotten to disable it before
attempting a new build; sorry for the confusion) and it easily builds
within the space allocated for /tmp using sysfs via initscripts.
However, it still comes out at about 8MB larger than the equivalent
stock Debian kernel:

-rw-r--r-- 1 perkelix perkelix 22M Jun 28 15:03
-rw-r--r-- 1 perkelix perkelix 30M Jul 14 01:31

This is of course a minor issue at this point and something that can
be discussed separately from this bug. :)

As for bug #617299, the actual cause is three-folds:

1) Starting with Wheezy, /tmp is mounted as a tmpfs whose size is
determined by initscripts to 20% of available memory. On my laptop
with a modest 1GB of RAM, this meant a /tmp sized at 200MB.

2) As it happens, 'dpkg-deb -b' uses /tmp (unless somewhere else is
specified using TMPDIR) as temporary space to compress packages while
building them.

3) Whenever building a kernel using 'make deb-pkg' without first
having disabled CONFIG_DEBUG_INFO, the resulting *.deb can easily near
500MB in size using the stock .config on x86. This obviously exceeds
the available /tmp space allocated as tmpfs via initscripts, which is
how gzip ends up outputing the above error message about "No space
left on device" or "File not found" despite plenty of hard-disk space
being available.

The solution to bug #617299 is therefore to either define TMPDIR to
some actual hard-disk with sufficient storage space via a commandline
environment e.g. 'TMPDIR=/var/tmp make deb-pkg' whenever using
commands that require an unusually large amount of /tmp space, or to
completely disable the usage of a tmpfs for /tmp via initscripts
defaults in /etc/defaults/rcS and /etc/defaults/tmpfs, as appropriate.


Reply to: