Closed fat-tire closed 1 year ago
To fix the black hanging screen, you need to ensure that you have openssl 1.0 libraries installed.
What's odd is it was installed and subsequent runs have no issue. Might have been something weird on my side....
The black screen hang is caused by the on-boarding app not being able to find openssl 1.0 libraries. The on-boarding app only runs the first time after an installation. If you kill the QtWebEngine process or restart the container, the next time the container runs, the on-boarding app will not execute and everything will be fine.
tl;dr - The run-time environment needs to have openssl 1.0 libraries installed to prevent a black screen hang when Resolve runs the first time after installation.
Yes, you are so right! Thanks! Running
/opt/resolve/Onboarding $ ./DaVinci_Resolve_Welcome
does indeed seem to run into ssl errors:
qt.network.ssl: QSslSocket: cannot resolve CRYPTO_num_locks
qt.network.ssl: QSslSocket: cannot resolve CRYPTO_set_id_callback
qt.network.ssl: QSslSocket: cannot resolve CRYPTO_set_locking_callback
qt.network.ssl: QSslSocket: cannot resolve ERR_free_strings
qt.network.ssl: QSslSocket: cannot resolve sk_new_null
qt.network.ssl: QSslSocket: cannot resolve sk_push
etc
The issue tho is that older versions of 1.0.2 up to 1.0.2w have at least one CVE and "All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of support and should not be used."
Wonder what the best course of action is. Could bring in an old/outdated 1.0.2 but if there's a better way to not rely on EOL libraries (especially ones related to security) that would be preferred. Any thoughts?
It's only the on-boarding app that uses the openssl 1.0 libraries and, to the best of my knowledge, the on-boarding app does not actually make any connections to the network. The openssl 1.0 requirement needs to be satisfied only to start QtWebEngine, even if the SSL features are not being used for anything.
The main Resolve binary uses a newer version of openssl and therefore does not exhibit the same hanging issue and, just as importantly, is not affected by the CVEs of concern.
From a security point of view, it should be safe to go ahead and install the openssl 1.0 compatibility libraries as their usage is very limited.
The "official"/old Centos 7 packages appear to be incompatible with a zillion dependencies. I don't know the centos world very well-- is pkgs.org a legit source to get rpms-- the centos-9 stream derivative distros don't seem to have the package:
$ sudo dnf install compat-openssl10
Last metadata expiration check: 1:23:17 ago on Tue Nov 15 12:06:24 2022.
No match for argument: compat-openssl10
Error: Unable to find a match: compat-openssl10
(the other option is just build it)
Well FWIW the almalinux version from 8 works in 9, at last enough to get to that main screen, though it then dies like this:
$ ./DaVinci_Resolve_Welcome
Failed to connect to Resolve server.
But I don't care too much. At least it gives me the onboard feature screen, though it's teensy-tiny on my screen.
K for now, commit f546536 takes care of the dependencies which the Resolve installer asked for. Not sure which compat-openssl10 to use with certainty in alma/rocky/stream 9... but thoughts are appreciated!
(also checked in some env variables to support Resolve scripting...)
Since this should be addressed in PR #34, I'm going to close this. So to get compat-openssl10 for the onboarding app, if you want to use it, just be sure to use the Rocky Linux 8.6 (default) image as your base. This is what's officially supported by BMD.
Feel free to comment on the PR thread if there are any issues.
A quick note that for the just-released Resolve 18.1, the following packages are apparently now dependencies and required to be added to the
Dockerfile
installed packages:apr apr-util libXinerama libxkbcommon libxkbcommon-x11 libXrandr xcb-util-image xcb-util-keysyms xcb-util-renderutil xcb-util-wm
I added these manually and it seems to be working okay. These specific packages were reported as required by the 18.1 installer:
So I added them, and the built completed without issue. I did not test to see whether they were ALL actually needed, I just blindly added them.
When running for the first time, I got a weird frozen splash screen, and had to go into the container where I saw these two processes:
When I killed those two, suddenly DR started running, and I got this:
The libraries needed to be updated:
I decided to do a backup of the database first, just in case. You can do this by clicking on the "i" with the circle around it next to the database name.