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. >> 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. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
