Excerpts from Russ Allbery's message of Thu Mar 31 22:03:38 +0200 2011:
> Michal Suchanek <michal.sucha...@ruk.cuni.cz> writes:
> > Excerpts from Russ Allbery's message of Thu Mar 31 18:18:25 +0200 2011:
>
> >> That's not consistent with the error message that you got. The error
> >> message is from an echo, which is certainly writing a small amount of
> >> data. It's also happening inside the dkms shell wrapper, not in the
> >> OpenAFS build.
>
> > But it's not consistent with the disk space shown by df either, there is
> > disk space available.
>
> Okay, I went and looked at this some more, and tried to figure out what
> part of DKMS is producing an error. The line referenced in the error
> message is DKMS attempting to store the build logs (the standard output
> from the build process), or one of the other commands that it runs (like
> mkinitrd). It's hard to tell exactly which without knowing more context
> for when in the process the error occurred, but either way, we're not
> talking about a lot of data.
>
> It does look like it was storing things in /tmp (unless you had TMPDIR set
> to something else), so it's the 1MB of space in /tmp that's presumably the
> issue, rather than the space on the root file system, so you're correct,
> the root file system issue was a red herring. Sorry about that; I should
> have looked closer right away.
>
> I'm not sure what part of the build process is using /tmp. It may be, as
> you say, gcc while doing the build, although if that's the case that's
> controlled by the Linux kernel makefiles, not by OpenAFS. (As with most
> modules, it uses kbuild to do the actual builds.) I'm not sure if the
> Linux build system by default uses -pipe or not. There is some code in
> DKMS to do things like unpack the module source itself into /tmp, which
> will definitely not work since the OpenAFS module source is 7MB by itself,
> but I don't think any of that triggers for just a regular module build.
>
> Does the build work if you set TMPDIR to some directory in another file
> system that has more space? I just want to make sure that it's really the
> /tmp part and not the root file system part that's having trouble.
I tried on another system and there the module builds fine.
Maybe that's because it's a test system with nothing running and thus nothing
taking up space in /tmp.
Or perhaps the log got shorter between rc3 and rc4.
The error message does not give much insight into the part which fails
so I have no idea why it happens on one system but not on other:
Preparing to replace openafs-modules-dkms 1.6.0~pre4-1 (using
.../openafs-modules-dkms_1.6.0~pre4-1_all.deb) ...
-------- Uninstall Beginning --------
Module: openafs
Version: 1.6.0pre4
Kernel: 2.6.38-2-amd64 (x86_64)
-------------------------------------
Status: Before uninstall, this module version was ACTIVE on this kernel.
openafs.ko:
- Uninstallation
- Deleting from: /lib/modules/2.6.38-2-amd64/updates/dkms/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.
depmod........
DKMS: uninstall Completed.
------------------------------
Deleting module version: 1.6.0pre4
completely from the DKMS tree.
------------------------------
Done.
Unpacking replacement openafs-modules-dkms ...
Setting up openafs-modules-dkms (1.6.0~pre4-1) ...
Loading new openafs-1.6.0pre4 DKMS files...
Building only for 2.6.38-2-amd64
Building initial module for 2.6.38-2-amd64
Done.
openafs.ko:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/2.6.38-2-amd64/updates/dkms/
depmod.......
DKMS: install Completed.
root@testbox:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 5.1G 4.8G 0 100% /
tmpfs 502M 0 502M 0% /lib/init/rw
udev 496M 120K 496M 1% /dev
tmpfs 502M 4.0K 502M 1% /dev/shm
overflow 1.0M 0 1.0M 0% /tmp
/dev/sda3 177G 2.5G 166G 2% /scratch
>
> >> This is definitely not something I can do in the openafs packages; that
> >> sort of decision Debian always leaves entirely to the local
> >> administrator.
>
> > By hardcoding it in the initscript?
>
> The openafs-client init script? That doesn't make sense to me;
> openafs-modules-dkms doesn't even depend on openafs-client, plus packages
> really shouldn't make assumptions about how disk utilization or file
> systems should be handled on the local system. There's way too high of a
> risk of tromping on something the local administrator is trying to do.
>
It's hardcoded in initscripts:
# dpkg -S /etc/init.d/mountoverflowtmp
initscripts: /etc/init.d/mountoverflowtmp
# grep -Fe "-t tmpfs" /etc/init.d/mountoverflowtmp
mount -t tmpfs -o size=1048576,mode=1777 overflow /tmp
Thanks
Michal
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
