some apt-get/aptitude commands fails in debirf root

[jrollins]

For some reason that I have yet to figure out, some aptitude/apt-get commands are failing in the debirf root, which is causing some of the modules to fail. For instance:

servo:/srv/debirf/rescue 0$ debirf enter . "apt-get update"
Loading profile 'rescue'...
Hit http://localhost lenny Release.gpg
Hit http://localhost lenny Release
Ign http://localhost lenny/main Packages/DiffIndex
Hit http://localhost lenny/main Packages
E: Unable to change to /srv/debirf/rescue/root/ - chdir (2 No such file or directory)
servo:/srv/debirf/rescue 100$ 

I suspect that this may be a problem in fake{,ch}root, but I haven't figured out how to confirm that yet.

[jrollins]

This problem has mysteriously disappeared. I tried again today and everything is working fine. I don't know if there was upgrade to apt(itude) that happened to fix this issue, or local issue of mine was fixed, or what. in any event, i'm closing this bug.

[jrollins]

I am running into this same problem on a different amd64 machine, so it was definitely not a passing fluke. I still have no idea what's going on. Why is apt getting the path to the root wrong (it looks for the path to the root on the build host), but why is it trying to chdir at all?

[jrollins]

I did *not* run into this problem on a different fairly clean lenny amd64 system.

[jrollins]

So I *was* able to get it to work on the same amd64 system that i was having trouble with before after manually completely removing the profile directory and trying again. I can't think of what would be left from any old builds that would cause problems. when doing a new build, both the old root an fakechroot state file are supposedly purged.

[jrollins]

Running into this damn problem again on servo. pre-removing the root and the .fakeroot-state file does not seem to have an effect.

[dkg]

does it happen when you run debirf enter foo "apt-get update" ? That is, does it work from outside the profile directory?

do any other commands fail?

what is the specific failure? have you tried stracing the whole process to see what system calls are actually being made and where?

[jrollins]

Replying to dkg:

does it happen when you run debirf enter foo "apt-get update" ? That is, does it work from outside the profile directory?

Wow. Good call, Daniel:

servo:~ 0$ debirf enter /srv/debirf/rescue "apt-get update"
Loading profile 'rescue'...
Get:1 http://localhost lenny Release.gpg [189B]
Get:2 http://localhost lenny Release [74.5kB]
Ign http://localhost lenny/main Packages/DiffIndex
Get:3 http://localhost lenny/main Packages [6944kB]
Fetched 7019kB in 8s (824kB/s)                                                    
Reading package lists... Done
servo:~ 0$ cd /srv/debirf/rescue/
servo:/srv/debirf/rescue 0$ debirf enter . "apt-get update"
Loading profile 'rescue'...
Hit http://localhost lenny Release.gpg
Hit http://localhost lenny Release
Ign http://localhost lenny/main Packages/DiffIndex
Hit http://localhost lenny/main Packages
E: Unable to change to /srv/debirf/rescue/root/ - chdir (2 No such file or directory)
servo:/srv/debirf/rescue 100$ 

I would never have thought that would make a difference. What made you think that it would?

do any other commands fail?

This is the only one that I've found so far. I think there was a similar aptitude command that failed, but I can't remember what it was at the moment. Funnily, "aptitude update" does have this problem.

what is the specific failure? have you tried stracing the whole process to see what system calls are actually being made and where?

I haven't tried a strace yet. Need to do that. You think I should strace the whole "debirf enter ..."?

[jrollins]

Replying to jrollins:

This is the only one that I've found so far. I think there was a similar aptitude command that failed, but I can't remember what it was at the moment. Funnily, "aptitude update" does have this problem.

I meant to say that aptitude does *not* have this problem.

[dkg]

it looks like apt was in two different states in the two tries you did in comment:7 (the first one actually fetched files, and the second one ignored files that had been pre-fetched). after that transition, does the failure happen reliably when using one form versus the other? what about when you do:

cd /srv/debirf
debirf enter rescue 'apt-get update'

(i.e. not using . but not an absolute path either)? that might help to point in the direction of what the problem is..

And yeah, i'd strace the whole debirf enter invocation if possible, and use that to figure out what's being called differently. it may be that under certain circumstances apt-get invokes a system call that is not properly fakechrooted when fakechroot gets a relative path? perhaps there's some profile path canonicalization that we need to be doing to make these cases identical? i'd thought we were doing profile path canonicalization already, though.

[jrollins]

we now believe this is a problem with getcwd() in fakechroot. See DebianBug:548691. We cant get around this by making sure there are no '.' in the DEBIRF_ROOT path, which we're doing by "absolutizing" the DEBIRF_BUILDD path. This was done and released in 0.24. This doesn't "fix" the problem, but is about as good as we can do for now.