WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Very odd filesystem problem in dom0

Yeah, I'm inclined to agree - it's a very subtle, very weird 
situation.

I can confirm that it ISN'T system libraries:

"""
root@durandal:~# ldd bash-static 
        not a dynamic executable
root@durandal:~# ./bash-static 
root@durandal:~# ls /var/adm/packages/*
: : No such file or directory
: : No such file or directory
: : No such file or directory
: : No such file or directory
...

root@durandal:~# ldd ./ls-static 
        not a dynamic executable
root@durandal:~# ./ls-static /var/adm/packages/*
: : No such file or directory
: : No such file or directory
: : No such file or directory
"""

Static LS fails from both inside static bash and inside dynamic bash.

It -definitely- seems to be tied to those directories - I can move the old
one, create a new one of the same name, and the new one is fine - but I can't
copy the files from the old one over:

"""
root@durandal:/var/adm# cp packages/* tem/
: `': specified destination directory does not exist
"""

I can't find any variables being set that have anything to do with the
uname, and I've run uname-variant kernels on the same slack10 base installs
before with no odd issues.

I've tried booting off the old kernel (and the install cd) and re-copying
the /var directory (mv /var /old-var, cp -av /old-var /var) so that if its
some sort of low-level fs corruption, that SHOULD get past it:  No luck.

set -o xtrace shows bash is expanding the globbing correctly:
"""
root@durandal:/var/log# ls packages/*
+ /usr/bin/ls --color=auto -F -b -T 0 packages/aaa_base-10.0.0-noarch-1 
packages/aaa_elflibs-9.2.0-i486-1 ...
"""

Turning off color-ls doesn't do any good, either.

Ah-hah.  It was just sugested to me that the size of the directory might matter:
It's not quite the number of files, it's the lengh of the argument character
string.  (Sorry, writing this email stream-of-thought as I test different
thing)

Filling a test directory with 100 files (for x in `seq 0 100`; do touch $x; 
done)
doesn't trigger it, but filling a test dir with 100 files with long names
(touch aaaaaaaaaaaaaaaaaaaaaa-$x) does.

Is xeno changing the size of the exec string buffer in the kernel?

-m

On Tue, Oct 05, 2004 at 10:24:53PM +0100, Ian Pratt wrote:
> Bizarre. It's hard to figure out how Xen/Linux could be doing
> this, unless there's some terrible memory corruption going on
> that would cause things to be segfaulting or kernel oops.  Xen
> just doesn't do subtle bugs ;-)
> 
> Can you do an ldd on /bin/ls just to see what libraries you're
> using. Are there alternative libraries under /lib (e.g. non tls
> or non i686) that you could try?
> 
> Finally, just make sure that there's nothing in your environment
> that is switching on something subtle returned from uname or
> arch...


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel