Hello,
In the context of a big data challenge I have to install brainvisa 3.2.1 on some grid sites, for most of them it's working without any problem, but for one particular grid site it fails with the following error (it's on a SL5.3 x86_64):
Loading toolbox My processes
The log file for this session is '/home/pool/vo.neugrid.eu/sgmneusns005/.brainvisa/brainvisa.log'
Database /opt/exp_soft/vo.neugrid.eu/brainvisa-3.2.1/share/shfj-3.2 must be updated because there is no database file.
/opt/exp_soft/vo.neugrid.eu/brainvisa-3.2.1/share/shfj-3.2: parse directories and insert items
ERROR Cannot insert items in database
/opt/exp_soft/vo.neugrid.eu/brainvisa-3.2.1/share/shfj-3.2. You should update this database.
--------------------------------------------------------------------------------
Error
neuro.py (224) in main:
exec f in globals(), localsStartup
<string> (5) in <module>:
?
sqlFSODatabase.py (415) in update:
self.insertDiskItems( ( i for i in self.scanDatabaseDirectories(
directoriesToScan=directoriesToScan, recursion=recursion ) if i.type is not None ), update=True )
sqlFSODatabase.py (697) in insertDiskItems:
raise Database.Error( "Cannot insert items in database "+self.name+". You should update this database." )
Hi Baptiste,
I don't remember having ever seen this error upon installation.
Do you require BrainVisa version 3.2.1 or can you try with a newer version ?
Normally at this step of installation, everything is correctly installed except the internal database of BrainVisa. Could you try running brainvisa, and manually updating the internal database using the "update databases" process ? (I assume you have actually run the setup from the unix account who owns the BV files)
Denis
The fact is that this failure occurs on a grid site that we do not manage, but I can send a job that could accomplish the task.
Could you please be a bit more precise on the task I have to do?
Please also note that we have no access to the X server, we can only use CLI tools...
- for the 3.2 version and the RIC toolbox, it sounds a good reason. I don't remember if I have tried it on BV 4, but it might work because the processes API and database organization have not changed since 3.2. It needs to be checked, anyway.
- I guess you should not need to really run a job on the cluster to install brainvisa: it can be installed from the cluster frontal, if all nodes see the same filesystem where you install BV. It does not explain your problem anyway.
- BV installation script does not require a X server: it uses it if it finds one and can use it, but otherwise installs in text mode. So I don't think it explains the problem too.
- Are you the owner of the directory /opt/exp_soft/vo.neugrid.eu/brainvisa-3.2.1/share/shfj-3.2 or did it install as a different user ? The problem actually seems to be an access rights problem on this directory: the setup script must be able to write the database sqlite file in it.
Hi,
I will ask our "neuro-imaging-specialist" if he can test the extension against the 4.0.0, but for the current Data Challenge it is too late for switching to the new version.
We are working on top of glite (deployed in VMs in XenServer), not in a cluster, thus their is no cluster frontal, all the software installations have to be done using grid jobs, and we can only access the Worker Node and Software area directory (which is nfs-shared between the nodes) using grid jobs as a privileged user.
When I spoke about the fact that we are running headless, it was in reference to the command you asked me to use, I was thinking it was a menu entry, how should I run this command using command line? (sorry, I am not really a BrainVisa user...)
The /opt/exp_soft/vo.neugrid.eu/brainvisa-3.2.1 directory is created at the beginning of the installation procedure (after the deletion of the older one if any) and all the installation process is done by a single job and by a single user. Couldn't this be a dependency problem for the python sqlite module or else?
Please note that our installation script worked well on 5 sites, there is only one sites were we face the aforementioned problem.
Yes I was referring to the graphical database update process. It is possible to use it (like any other process) in a non-graphical mode.
Normally the setup scripts just calls: