Bug#617299: dpkg-deb: should give a hint when it fails due to filling /tmp
2012/7/13 Martin-Éric Racine <martin-eric.racine@iki.fi>:
> 2012/7/13 Martin-Éric Racine <martin-eric.racine@iki.fi>:
>> Package: dpkg
>> Version: 1.16.4.3
>> Followup-For: Bug #617299
>>
>> I also encounter the same bug when trying to build kernel 3.2.21 from upstream tarball:
>>
>> $ LOCALVERSION=-git-686-pae make deb-pkg
>> [...]
>> dpkg-deb: building package `firmware-linux' in `../firmware-linux_3.2.21-git-686-pae-1_i386.deb'.
>> dpkg-deb: building package `linux-headers-3.2.21-git-686-pae' in `../linux-headers-3.2.21-git-686-pae_3.2.21-git-686-pae-1_i386.deb'.
>> dpkg-deb: building package `linux-libc-dev' in `../linux-libc-dev_3.2.21-git-686-pae-1_i386.deb'.
>> dpkg-deb: building package `linux-image-3.2.21-git-686-pae' in `../linux-image-3.2.21-git-686-pae_3.2.21-git-686-pae-1_i386.deb'.
>> dpkg-deb (subprocess): data member: internal gzip write error: 'File not found'
>> dpkg-deb: error: subprocess <compress> from tar -cf returned error exit status 2
>> make[1]: *** [deb-pkg] Error 2
>> make: *** [deb-pkg] Error 2
>
> This seems to be caused by either 'tar' or 'gzip' using /tmp to build
> the package. Since recent Debian systems default to using tmpfs for
> /tmp, systems with insufficient memory or with another process using
> all available memory resources will make the build fail. Would there
> perhaps be a way to make this process use /var/tmp or some other
> normal storage space to avoid these nonsensical failures?
Actually, this feels like an upstream kernel 3.2 bug: as a test, I
purposely disabled TMPFS for /tmp just to see if the kernel package
would finally build as expected. It did, except that 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.
When I built another kernel using the 3.5-rc6 tree instead, the build
produced a kernel package similar in size to the stock Debian one, so
I suspect that the issue lies in kernel 3.2's build scripts and was
evidently fixed recently.
Would the people on debian-kernel@l.d.o perhaps know more about this?
Martin-Éric
Reply to: