Hi once more
after some conversation with
Jeff Gunter <[EMAIL PROTECTED]>
from which I've got some new ideas I post some parts of this discussion to
the list and add some new aspects of my problem. (The new aspects are the
reason why not posting only to Jeff.)
JG>Sounds like dselect is df-ing the /var to figure out if there is file space.
JG>That's a bug in my opinion. It should probably also check to see if you
JG>have a remote mounted /var/lib or /var/lib/dpkg or /var/lib/dpkg/methods/ or
JG> /var/lib/dpkg/methods/ftp etc.
I tried to verify this idea by moving the complete /var-tree to the
HP-machine. I thought it wouldn't be a good idea because of the low speed
of NFS-access, but now I tested this.
The result was the same:
Approximate total space required: 28526k
Available space in debian:
40%k
Space required is greater than available space,
you will need to select which items to get.
But a df says:
... Available ... Mounted on
/dev/hda2 5288 /
hp.workstation:/<path>/usr 1038027 /usr
hp.workstation:/<path>/var 1038027 /var
It seems to be enough space to store under /var where the packages
are stored while installing.
JG> packages are compressed and I *think* they get uncompressed BEFORE
JG> installation and so require more file space.
JG>
JG> What happens if you only install one very small package? Does it put
JG> things on the HP ok? Assuming you are installing via ftp ... you could
JG> look on the HP and see if the files got put there ok
Yes, the packages come in /var/debian/stable/binary-i386/admin. Now I
observed a further strange behaviour: I selected only the packages in the
beginning of the dselect-list which were preselected as default. Some
packages I deselected because I thought I wouldn't need them in the first
step. For instance I deselected taper-x.x.deb. BUT taper-x.x.deb EXISTS
in this path. I think this isn't a clever behaviour. (I checked my list
twice to be sure taper is deselected!)
OK, the *.deb-Packages are stored on the workstation which should
become the NFS-Server for my Debian box. May be that it is usual when
installing only the packages in the admin/ directory were stored.
While installing them I ended up with error messages.
JG> What are the error messages?
Here es the output:
Unpacking acct (from .../admin/acct_6.2-2.deb) ...
Stopped process accounting.
dpkg: error processing debian/stable/binary-i386/admin/acct_6.2-2.deb
(--install):
package control info contained directory `/var/lib/dpkg/tmp.ci/control'
dpkg: error while cleaning up:
failed to rmdir/unlink `/var/lib/dpkg/tmp.ci': File exists
dpkg: error processing debian/stable/binary-i386/admin/adjtimex_1.2-5.deb
(--install):
failed to rmdir/unlink `/var/lib/dpkg/tmp.ci': File exists
dpkg: error processing debian/stable/binary-i386/admin/at_2.9b-1.deb
(--install):
failed to rmdir/unlink `/var/lib/dpkg/tmp.ci': File exists
Errors were encountered while processing:
debian/stable/binary-i386/admin/acct_6.2-2.deb (--install):
debian/stable/binary-i386/admin/adjtimex_1.2-5.deb (--install):
debian/stable/binary-i386/admin/at_2.9b-1.deb (--install):
DPKG ERROR
I can't imagine any reason for this behaviour. What the hell is the
task of the files in tmp.ci? An `ls -l' says:
drwxr-xr-x root root tmp.ci
But this directory does *not* contain a file `control' in the moment
the error messages mentioned above apeared on the screen (may be it
is deleted but any rm-call failed but which???). Questions, questions ...
JG> This sounds like a good bug, but I wouldn't be surprised if nobody had
JG> stumbled across it yet.
I also think this but I want to give a description which makes sure that
this bug can be reproduced. It me seems so strange that I'm afraid it
would be ignored. I want to make sure to give the true reason for this bug.
JG> I would check the permissions. Try creating directories and such on the
JG> /var/lib filesystem.
Yes, I've done this and all worked fine. I had the supposition that dselect
uses some quite different rights from root but this makes no sense at all.
This supposition is provided by the following fact. Former I mounted only
/var/lib on the HP-server. Now I tar-ed the complete /var-tree, mounted
/var on the HP-server and un-tar-ed it. I've got some mysterious error
messages from tar when unpacking the *.deb files:
tar: cannot chown file var/debian/stable/binary-i386/<abc>.deb to uid 47653 gid
64696
tar: cannot chown file var/debian/stable/binary-i386/<xyz>.deb to uid 2282 gid
64976
The "possibility" of the second uid/gid combination was much higher (1:5)
but it seems to be randomly if a *.deb package failed to chown to one or
the other user. What about this uid/gid numbers. May be the root of my
problem is here.
Any more ideas to fix this bug out there? Without any clue
Andreas.
