Hi Avraham,
I see your'e suffering from dchroot aches (as I said in previous post - the common source of trouble in deb-amd64...) One small comfort is that this is only a temporary situation, because a) Debian plan to go multiarch . The chroot thing is merely a temporary workaround. b) unstable is already moving from dchroot to schroot, which is supposed to be a little better. See my comments inline below. Generally what I'd try to do next is get some more debug info on what's happening on the ia32 side of your xv invocation. replace your ia32 xv executable with some script that prints it's cwd, it's PATH and it's commandline parameters (either to terminal or to some file). Run it with the working launcher and with the broken one, compare the results. Avraham Rosenberg wrote: > Hi Guy, > Thanks for the answer. > Most of your remarks are answered by the sentence you quoted > immediately after. In case this was not clear enough, I shall try > to do better now. > On Wed, Jun 21, 2006 at 12:57:22AM +0300, guy keren wrote: > >> so dchroot is not found under /usr/bin/dchroot. >> >> did you try to first run "which dchroot" from the shell, to see where >> dchroot is located? >> > Certainly, and the answer was: /usr/bin/dchroot. > >>> The only way it worked was: >>> #!/bin/sh >>> if [ -f /usr/bin/dchroot ]; then dchroot -c ia32 -d -q xv $*; fi >>> >> worked = executed properly? or worked = did not emit any error? >> > Worked allright. Got the expected output > I really can't figure out how comes the if clause makes any difference. You sure you ran the version without the if from the same current directory? same PATH? didn't do any changes to the ia32 chroot system between the runs? Maybe some other unrelated change which caused a different 'xv' command to be found? >> add an 'else' clause to the above if, to see that the 'if' part actually >> took place. >> > I don't understand that... > He probably means something like if [ -f /usr/bin/dchroot ]; then dchroot -c ia32 -d /usr/bin/xv $*; else echo "hmmph I got false...";fi Just more debugging. and always drop the -q while we're trying out stuff. Oh, I see you did (don't put it back until we figure out what's happnin')... >>> I tried then to combine the conditional with the original >>> do_dchroot: >>> #!/bin/sh >>> ARGS="" >>> for i in "$@" ; do >>> ARGS="$ARGS '$i'" >>> done >>> >>> #exec dchroot -c ia32 -d -q "`basename $0`" "$ARGS" >>> if [ -f /usr/bin/dchroot ]; then exec dchroot -c ia32 -d -q "`basename $0`" >>> "$ARGS"; fi >>> >>> This time there were no error messages, but no output either. >>> >> perhaps the system is playing some tricks on you? perhaps when it invokes >> this shell script, its environment gets screwed in some way? >> > The same script had worked corectly before. I'd rather think that > the many testing packages I added in the meantime, in an attempt > to build octave2.9, have brought the system to an unstable state. > If I can't guess what specifically does the harm, the only > options left are to remove the testing from sources and > preferences and make a dist-upgrade, or a fresh install. > I thought you were running "testing". Did you mean "unstable" (sid) packages, or are you using the sarge backport? Anyways, I don't think there's much chance this would make a difference. testing and unstable are not very different, and the problems in hybrid flavors usually manifest as dependencies spaghetti, not mysterious environment switching (that sounds more like dchroot's kind of troublemaking). >> to debug this, why don't you add 'echo' before the above 'exec', and see >> what it going on (or run this scrip tusing 'sh -x .....')? >> > avraham5:~$ sh -x xv /store/qtmp/qtmp/Prokudin-Gorsky/buchara.tiff > + ARGS= > + ARGS= '/store/qtmp/qtmp/Prokudin-Gorsky/buchara.tiff' > + '[' -f /usr/bin/dchroot ']' > ++ basename xv > + exec dchroot -c ia32 -d -q xv ' > '\''/store/qtmp/qtmp/Prokudin-Gorsky/buchara.tiff'\''' > > after suppressing the "-q" from the script, I got the additional > line: > (ia32) xv '/store/qtmp/Prokudin-Gorsky/buchara.tiff' > As far as I recall, this was the script that showed no error, but did not produce any output. Did it work now? > which works perfectly from the command line as > avraham5:~/scripts$ sh -x xv32 '/store/qtmp/Prokudin-Gorsky/buchara.tiff' > + '[' -f /usr/bin/dchroot ']' > + dchroot -c ia32 -d -q /usr/bin/xv /store/qtmp/Prokudin-Gorsky/buchara.tiff > (/store is bind-mounted in ia32 in my /etc/fstab) > Did this one actually work? note that this time you don't run "xv", but "/usr/bin/xv" (a good idea, btw. this way we know exactly which 'xv' we're running). Do you have several "xv" commands on the ia32 chroot? Maybe you have something on /usr/local/bin/ Maybe the chrooted shell sees the 'xv' launcher script itself (the modified do_dchroot, which you used in previous code sample). >>> I'll be damned! >>> >> until you start adding debug messages to your script. then you'll be >> puzzled - and that's a much better state of being ; >> > In my experience, these two states are not incompatible. > Puzzling indeed. Currently my best guess is that somehow the 'xv' command on the chrooted system runs the launcher script itself again (which is called xv too), and since it has that 'if' inside it, it does not do anything. Good luck, Amit ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
