I had a misconfiguration, and the catalyst-env.sh script wasn't found. Then, catalyst ends with: -------- !!! catalyst: Can't find envscript /stuff/s3os/snodbuild/catalyst-env.sh umount: /stuff/catalyst/tmp/default/stage1-x86-snod-20040727/dev: device is busy umount: /stuff/catalyst/tmp/default/stage1-x86-snod-20040727/dev: device is busy catalyst: Couldn't umount bind mount: /stuff/catalyst//tmp/default/stage1-x86-snod-20040727/dev ----- First dev/pts should be unmounted. Then dev isn't busy.
Oh, I'm using version: Gentoo catalyst, version 1.0.8.1
When I had all the configuration right, catalyst still complains about that error, after this: ------- Running command "/bin/bash /usr/lib/catalyst/targets/stage1/stage1.sh preclean" i686-pc-linux-gnu-3.3.3 * Switching to i686-pc-linux-gnu-3.3.3 compiler... [ ok ] ------- I've looked at the code in generic_stage_target.py, and the umounting is done reversing the array of mounted paths. I don't understand what's happening, but the stage 1 isn't created. Oh, I didn't mention it... I was creating stage1.
are you by chance using distcc?
I think I'm not using distcc. For the first time I tried using distcc, but after seeing some distcc error (process which cannot be stopped or something similar), I disabled it. After that error, /dev/pts is mounted...
I've been trying version 1.0.9, and the problem remains. I'm using catalyst in two computers, and in one it works. In the other, it gives those errors. In the first system there is only "root" partition mounted. A big partition. In the system where catalyst cannot do those umounts, there is this mount table: /dev/hda1 on / type reiserfs (rw,noatime) none on /dev type devfs (rw) none on /proc type proc (rw) /dev/hda5 on /usr type reiserfs (rw,noatime) /dev/hda6 on /home type xfs (rw,noatime) /dev/hdb1 on /stuff type reiserfs (rw) /dev/hdb2 on /stuff2 type reiserfs (rw,noatime) none on /dev/shm type tmpfs (rw) none on /proc/bus/usb type usbfs (rw) With these addons after the failed umounts: /dev on /var/tmp/catalyst/tmp/default/stage1-athlon-snod-20040807/dev type none (rw,bind) /dev/pts on /var/tmp/catalyst/tmp/default/stage1-athlon-snod-20040807/dev/pts type none (rw,bind) /var/tmp/catalyst/packages/default/stage1-athlon-snod-20040807 on /var/tmp/catalyst/tmp/default/stage1-athlon-snod-20040807/usr/portage/packages type none (rw,bind) ----------- I've been trying setting "storedir" to /stuff/catalyst, and also using a symlink from /var/tmp/catalyst to /stuff/catalyst. I get the same problems. I cannot manage to compile. I use the same spec files for catalyst in the two computers. Same catalyst version. Maybe there's something I miss... but I cannot catch it. Thanks for the support!
thanks for all of the information :) On the machine that does not build, try unmounting those mounts by hand and then cleaning everything out of the storedir and pkgcache. you may be picking up a bad package somewhere. Also, please post your catalyst.conf. Thanks!
I've changed the "self.unbind()" code of Catalyst 1.0.9 to: for x in myrevmounts: warn("Trying umount: " + mypath+x); if not os.path.exists(mypath+x): warn("Path doesn't exist"); continue if not ismount(mypath+x): # it's not mounted, continue warn("Path isn't mounted"); continue retval=os.system("umount "+mypath+x) if retval!=0: ouch=1 warn("Couldn't umount bind mount: "+mypath+x) # keep trying to umount the others, to minimize damage if developer makes a mistak And with those mount points: /dev on /var/tmp/catalyst/tmp/default/stage1-athlon-snod-20040807/dev type none (rw,bind) /dev/pts on /var/tmp/catalyst/tmp/default/stage1-athlon-snod-20040807/dev/pts type none (rw,bind) /var/tmp/catalyst/packages/default/stage1-athlon-snod-20040807 on /var/tmp/catalyst/tmp/default/stage1-athlon-snod-20040807/usr/portage/packages type none (rw,bind) I get those messages: /dev is still mounted; performing auto-bind-umount... !!! catalyst: Trying umount: /var/tmp/catalyst/tmp/default/stage1-athlon-snod-20040807/var/tmp/ccache !!! catalyst: Path isn't mounted !!! catalyst: Trying umount: /var/tmp/catalyst/tmp/default/stage1-athlon-snod-20040807/usr/portage/packages !!! catalyst: Path isn't mounted !!! catalyst: Trying umount: /var/tmp/catalyst/tmp/default/stage1-athlon-snod-20040807/usr/portage/distfiles !!! catalyst: Path isn't mounted !!! catalyst: Trying umount: /var/tmp/catalyst/tmp/default/stage1-athlon-snod-20040807/dev/pts !!! catalyst: Path isn't mounted !!! catalyst: Trying umount: /var/tmp/catalyst/tmp/default/stage1-athlon-snod-20040807/dev umount: /var/tmp/catalyst/tmp/default/stage1-athlon-snod-20040807/dev: device is busy umount: /var/tmp/catalyst/tmp/default/stage1-athlon-snod-20040807/dev: device is busy !!! catalyst: Couldn't umount bind mount: /var/tmp/catalyst/tmp/default/stage1-athlon-snod-20040807/dev !!! catalyst: Trying umount: /var/tmp/catalyst/tmp/default/stage1-athlon-snod-20040807/proc !!! catalyst: Path isn't mounted Take a look at the lines (!!!): !!! catalyst: Trying umount: /var/tmp/catalyst/tmp/default/stage1-athlon-snod-20040807/dev/pts !!! catalyst: Path isn't mounted But that's mounted. A page about python's function "ismount()", says: ismount( path) Return True if pathname path is a mount point: a point in a file system where a different file system has been mounted. The function checks whether path's parent, path/.., is on a different device than path, or whether path/.. and path point to the same i-node on the same device -- this should detect mount points for all Unix and POSIX variants. I'm using Python 2.3.3. (Now I'm updating this to 2.3.3-r1, but if only the release version is changed, I think that won't be solved). I'm using kernel 2.4.24-xfs-r3 from gentoo. Maybe I should upgrade 'baselayout' or something similar? I don't know what to do. It really seems the problem is in my computer, and not in your code.
Ok! I've found a solution! I changed my running kernel 2.4.24 to 2.6.4, and now everything works. It may be a kernel 2.4 issue.
very interesting ... I am cc'ing plasmaroo since he does some kernel stuff. maybe he has some answers ;)
See if you can reproduce this on 2.4.26 or 2.4.27 please, either vanilla- or gentoo- sources. Thanks!
There's something new.... I've had the same problem, but this time unbinding directory "packages". Exactly the same. The directory was mounted, and python result of "ismount()" was false. And now I'm in 2.6.4. I changed my local catalyst code, and I've removed the check of "ismount()" (also the exception raising). I will upgrade glibc, recompile python, and I will tell something about that. I will also try those kernels. Thanks!
did the new kernels change anything?
I'm sorry. I've still not tried them. I wanted to get CDs generated from catalyst first. But I still couldn't generate the grp. I plan try them after some days. I must say that those problems appear only in ONE of my computers. I have the latest python installed. Is there another lib between python and the kernel, which could be buggy?
I've tried newest kernels, and the problem remains. I've just noticed that "ismount(path)" function isn't Python's! So I looked at its code (in catalyst-support), and I've seen that: def ismount(path): "enhanced to handle bind mounts" if os.path.ismount(path): return 1 a=open("/proc/mounts","r") mylines=a.readlines() a.close() for line in mylines: mysplit=line.split() if path == mysplit[1]: return 1 return 0 The simple expression "path == mysplit[1]" may not be true, if the path string contains doubled "slashes", or ends with a slash. There should be a path-compare-function, which has in mind those slashes' issues. (Certainly, I had doubled slashes in my paths. That's why ismount() returned 0) I'll try to solve it by myself. But I'm not a Python programmer. :) I'm getting mad looking for a function which applies a 'substitute regular expression'. I hope I'll success. hehe
Created attachment 39578 [details, diff] Improves "ismount()" function It does a better "path comparision" than string == string.
Created attachment 39623 [details, diff] Improves "ismount()" function (now it works :) Well, that said. Now it works. I learnt a bit of python with that. I'm not a python programmer... so I think the aim is that; maybe there's a better way of coding that. So, finally, I concluded that it isn't a kernel issue. Sorry for not noticing that before.
thanks for the patch! I am looking forward to testing it. Could you do me a favor though and create the patch using `diff -urN`? It is easier to read the changes from that output.
Created attachment 39629 [details, diff] Improve "imount()" - diff -urN I didn't know which diff output would be the best. I'll keep that in mind for future patches.
Comment on attachment 39629 [details, diff] Improve "imount()" - diff -urN Oh. I mistyped "urN". I think there is another change: the solution (IMO) of bug # 64001.
thanks so much for the patch! it is in cvs now.
