Hi Valeriu, In general it's a good idea to clean out your $MODULEPATH variable before installing easybuild (i.e. EB shouldn't be able to see any of the system installed modules when it is building something). Use 'module purge' and 'module unuse UNWANTEDPATH' to give yourself the cleanest possible environment, one that only has the eb module path in it.
Alan On 19 November 2014 14:49, Kenneth Hoste <[email protected]<mailto:[email protected]>> wrote: Hi Valeriu, On 19/11/14 14:27, Valeriu Codreanu wrote: Hi Fotis, Kenneth, Pablo, Thanks for all your suggestions. I have finally managed to get EasyBuild installed and loaded. It was indeed a problem related to the two module environments that were conflicting. However, when I try to build the WRF package I get this error: valeriuc@login3:~$ eb WRF-3.5.1-goolf-1.4.10-dmpar.eb -Dr == temporary log file in case of crash /scratch/easybuild-l0Rfu9/easybuild-7kKi7g.log ERROR: EasyBuild crashed with an error (at easybuild/software/EasyBuild/1.15.2/lib/python2.6/site-packages/easybuild_f ramework-1.15.2-py2.6.egg/easybuild/tools/modules.py:541 in run_module): homkat(4):ERROR:154: Version symbol 'default' loops We have a module homkat installed on the system but it is not loaded or used when calling eb. If I try to do: module load homkat, I hit exactly the same error (homkat(4):ERROR:154). Do you have any suggestion for how to tackle this? I am also attaching the complete log file. Hmm, that's very weird... Are you also seeing this problem if you're running a "module avail"? Can you enable the --debug (or -d) command line option, and send us the debug log? I'm missing some info with a regular log to really tell what's going on. Also: are you actually interested in WRF as an application? If not, I'd suggest trying to build another application instead (the build should work, but you may as well build something you care about). In any case, you'll need to get EasyBuild to build & install a toolchain (e.g., goolf) first, which will be done as a part of "eb WRF...eb --robot", so it doesn't hurt. regards, Kenneth Best wishes, Valeriu On 19/11/14 10:45, "Fotis Georgatos" <[email protected]<mailto:[email protected]>> wrote: Hi Valeriu, Kenneth, On Nov 18, 2014, at 9:35 PM, Kenneth Hoste <[email protected]<mailto:[email protected]>> wrote: It may have something to do with the modules being loaded with the old modulecmd binary (v3.1.6), and then manipulating/querying the state with the latest version 3.2.10. Or, perhaps there is something that tickles environment variables LOADEDMODULES and _LMFILES_; I¹d suspect either shell init files or, fancy hooks living inside modulefiles themselves. I'd suggest a clean-fresh build of modulecmd, visible by a very restricted $PATH, if possible, done from a new clean account. That may help in differential debugging. cheers, F. -- echo "sysadmin know better bash than english" | sed s/min/mins/ \ | sed 's/better bash/bash better/' # signal detected in a CERN forum -- Dr. Alan O'Cais Application Support Juelich Supercomputing Centre Forschungszentrum Juelich GmbH 52425 Juelich, Germany Phone: +49 2461 61 5213 Fax: +49 2461 61 6656 E-mail: [email protected]<mailto:[email protected]> WWW: http://www.fz-juelich.de/ias/jsc/EN ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------
