Problem after upgrading from 5.8.4 to 5.10.1

Please, describe the problem here and provide additional information below (if applicable) …
i’ve upgraded the system per opennebula’s guide
and now, when i logon to the system, the loading circle turns endlessly and i’m not getting the interface
attached oned.log, i can’t make of it to tell what the problem is

you can see a lot of :
Command execution failed (exit code: 255): /var/lib/one/remotes/datastore/vcenter/monitor


block in connect
i don’t know what those mean

thank you
oned.log (72.7 KB)

Versions of the related components and OS (frontend, hypervisors, VMs):

Steps to reproduce:

Current results:

Expected results:


Did you follow the upgrade from 5.8.x guide?

It looks like you’ve missed Step 9.

(And don’t forget to restart the sunstone service after updating the serveradmin password)

Best Regards,
Anton Todorov

i already did that. because before i did that, i couldn’t get past the logon screen, i would get an error. maybe i didn’t understand the command?

oneuser passwd --sha256 serveradmin cat /var/lib/one/.one/sunstone_auth|cut -f2 -d':'

should i set it as is? or need i change this to alter something that will match my settings?

i didn’t see in the article something that says i need to alter something in this command

It should be as is.
The plain serveradmin passowd in /var/lib/one/.one/sunstone_auth is used to update the one in the database hashed with sha256

yeah, so it’s probably not that. because as stated, when i didn’t do it, i couldn’t get past the login screen.

So you should try increasing the debug level of sunstone in /etc/one/sunstone-server.conf and check the suunstone log for clues…
It is possible to have issue with cached js files so you should try with different browser or try clearing the browser cache…

i see that it’s on level 3 = debug

about the browser, i already tried another fresh one

if oyou pen the browser’s debug console do you see some kind of js errors?

good idea

got this in errors :

GET net::ERR_ABORTED 403 (Forbidden)

there seems to bee someone here that had a similar problem and fixed it, but i’m sorry to say it’s above my knowledge

looks like a symlink problem of a sort

so what you have in /usr/lib/one/sunstone/public/dist?
in my cluster I have

[root@fe ~]# ls -la /usr/lib/one/sunstone/public/dist
total 15972
drwxr-xr-x  6 root root     175  7 май 16,08 .
drwxr-xr-x 10 root root     325  7 май 16,08 ..
-rw-r--r--  1 root root   47574  7 май 13,25 build.txt
drwxr-xr-x  2 root root      74  7 май 16,08 console
-rw-r--r--  1 root root  115201  7 май 13,25 login.js
-rw-r--r--  1 root root  123132  7 май 13,25
-rw-r--r--  1 root root 7349845  7 май 13,25 main-dist.js
lrwxrwxrwx  1 root root      29  7 май 16,08 main.js -> /var/lib/one/sunstone/main.js
-rw-r--r--  1 root root 8705831  7 май 13,25
drwxr-xr-x  2 root root      41 29 авг  2019 opennebula
drwxr-xr-x 13 root root     253  7 май 13,25 tabs
drwxr-xr-x  3 root root      21  7 май 13,25 templates

drwxr-xr-x 5 root root 4096 Jul 21 11:01 .
drwxr-xr-x 9 root root 4096 Jul 21 11:01 …
-rw-r–r-- 1 root root 48249 Dec 10 2019 build.txt
drwxr-xr-x 2 root root 4096 Jul 21 11:01 console
-rw-r–r-- 1 root root 115201 Dec 10 2019 login.js
-rw-r–r-- 1 root root 123129 Dec 10 2019
-rw-r–r-- 1 root root 7316290 Dec 10 2019 main-dist.js
lrwxrwxrwx 1 root root 29 Jul 21 11:01 main.js -> /var/lib/one/sunstone/main.js
-rw-r–r-- 1 root root 8667113 Dec 10 2019
drwxr-xr-x 11 root root 4096 Dec 10 2019 tabs
drwxr-xr-x 3 root root 4096 Dec 10 2019 templates

looks the same i guess

try stopping the sunstone service, rename /var/lib/one/sunstone/main.js and create an empty file instead. then, when you start the sunstone service the file should be re-generated…

yeah, it did regenerate, but nothing changes

the url he’s trying is and he gets forbidden. but the permissions looks fine
this is a test system. when i do the same on the production with v=5.8.4 i get the content of the main.js file

do you have a reverce proxy in front of the sunstone? Asking because the sunstone service is on port 9869, so the direct URL should be

no, no probxy. both the original system and this one is on port 80, always has been