Blackmagic Forum

This is a thread for collecting questions regarding DaVinci Resolve on Debian and its derivatives such as Ubuntu and Linux Mint. Post your Debian and MakeResolveDeb related issues and ideas here.

When posting issues please include installation method, software/OS versions and log files.

If you are running Resolve on Debian, please also post here with information on your setup.

Right now several users have reported problems with Resolve getting stuck at "Loading Waveform Monitor". How wide spread is this issue?

Daniel Tufvesson wrote:This is a thread for collecting questions regarding DaVinci Resolve on Debian and its derivatives such as Ubuntu and Linux Mint.

According to the most recent Resolve Configuration Guide documents, BMD says this:

You can install DaVinci Resolve and DaVinci Resolve Studio for Linux on your own system that has CentOS or RHEL 7.3.

https://documents.blackmagicdesign.com/ ... _Guide.pdf

You can try to use other Linux distros, but officially they only support CentOS and Red Hat. Similarly, Baselight is restricted to CentOS, and even then, they have their customers use a very specific customized version of CentOS (not an off-shelf version).

What Blackmagic support generally tells me is, "it might work on that OS, but there's no guarantee."

dear marc!

i really esteem the huge amount of experiences, which you often share with other users here in this forum, but i really have my doubts, that you would be even able to describe the actual technical differences and incompatibilities, which divide Debian/Ubuntu/Mint from CentOS. and as long as you do not have more insight into this particular technical question and its rational consequences, it would be more helpful, if you just keep a little bit more silent concerninmg this topic. just quoting the resolve manual or config guide like the holly bible in very stupid and dogmatic manner all the time, doesn't help anybody! in this regard it would be perhaps more constructive to propagate rsp. remember immanuel kants maxim: "Sapere aude" ("Dare to think for yourself!").

Daniel, I did a few tests this morning and I confirm that the deb built by makeresolvedeb_16.1b3-2.sh does not work at home because Resolve leaves in a loop as you saw in the log I posted yesterday .
By contrast, makeresolvedeb_16.1b3-1.sh does not have this problem.

On the other hand, I may be the reason that could explain the flickering that I encounter. They appear as soon as I use the auto balance in color tab.

Marc, I know that Blackmagic does not support anything other than Centos or RH but despite a few tries, I really was not convinced of their superiority and soon returned to a distribution that I mastered and which seems despite very close to normal operation.
BMD have actually made a lot of progress in supporting linux and I think the problems I am experiencing today will eventually be resolved in the near future .

Guys, I can really see both sides of this. Try to be nice. I know that we are treading unsupported grounds here but we really can not ignore the fact that there is a very big community out there that run their entire workflow on Debian based setups. It's sad that Resolve can not be officially supported on this platform but at the same time I understand that BMD will not set aside the extra resources required to support another platform at this point.

That is why we have to help each other and I hope that the developers will make use of the discoveries we do in this community. Fixing the issues that the Debian users face, if done properly, will not cause problems for the CentOS side. My vote is for the opposite actually. By fixing things the Debian community wishes for will only make Resolve better and stronger. And eventually, who knows, perhaps we will see official support in the end. Right now I'm just happy that BMD has given us the opportunity to experiment. I believe that together we can make something good out of this.

Philippe, what version of the NVIDIA driver are you running?

makeresolvedeb_16.0-4 worked fine for me.
I will add some ram this week and retest the flickering issue again.
Regards!

Boris Kovalev wrote:makeresolvedeb_16.0-4 worked fine for me.
I will add some ram this week and retest the flickering issue again.
Regards!

Good to hear that Boris. Thank you for the update!

16.0-2 is working with DR16 (lite)on Debian 10.1 without any issues. The only thing I had to do post install was symlink libcuda.so to keep Fusion from crashing.

Even the Intensity Pro 4K works for video monitoring and audio playback.

Solid work.

Looking forward to trying it with Studio.

Philippe GALLE wrote:Marc, I know that Blackmagic does not support anything other than Centos or RH but despite a few tries, I really was not convinced of their superiority and soon returned to a distribution that I mastered and which seems despite very close to normal operation.

What's the problem with just using CentOS? Last I checked, CentOS 7.0 is free. Why use something else when the software developer specifically tells you this is what they're going to support, and you want to argue with them?

Note that CentOS and Red Hat are nearly identical. Red Hat Linux is $299 (when I last checked it), but I think Blackmagic will send a free CentOS-formatted distro of Resolve for Resolve Advanced Linux users if they ask for it.

I think a lot boils down to familiarity and existing investment in one or the other platform. Resolve is changing and the user base is increasing. Gone are the days when Resolve was primarily installed as a big blackbox turnkey system in a dedicated air-gapped room. That use case still exist but now there are also a lot of users who expect to run Resolve on their main workstations along with other software suits. More and more collaboration is done online and this increases the demand on the OS in use with regards to compatibility, security, configuration and regular maintenance. In those situations it makes sense to have as few platforms as possible in your environment. Get to know them well and maintain them properly. CentOS is currently on DistroWatch place 13 and the top ten is dominated by Debian based alternatives. Odds are that most new users will not be RH or CentOS based.

I will only speak for myself but in my case there was a lot less effort required in adapting Resolve to run on Debian than it was to to integrate CentOS into my existing environment.

it's very hard to find numbers for objective market share resp relevance of different distributions and argue for their pros and cons, but to me it was a very interesting observation, how many users here in this forum first followed BMDs suggestion to utilize CentOS, but came back after a while using debian based distros again. sure, that's just my very subjective observation of this matter, but because i'm really interested in this kind of stuff, i try to watch it attentively.

and i agree with danieel, that the actual needed changes for debian/ububuntu/mint compatibility are more or less trivial and realizable without much pain. they would just make resolve better! it's therefore more a kind of miracle, why BMD does refuse this concession resp. acceptance of the real world and vast majority of linux users in such an unyielding manner?

Daniel,

I use the nvidia-driver-435 ubuntu bundle driver.

I just tried makeresolvedeb_16.1b3-3.sh this morning but the result is still the same with Resolve that hangs during the "loading Waveform Monitor".
ResolveDebug.txt reports "Unable to load libcuda from /usr/lib64/libcuda.so". I believe that the symlink that is created at installation is not correct because this library is located in /usr/lib/x86_64-linux-gnu.
Today in /usr/lib64 I have a symlink to x86_64-linux-gnu and another to ld-linux-x86-64.so.2

Philippe GALLE wrote:Today in /usr/lib64 I have a symlink to x86_64-linux-gnu and another to ld-linux-x86-64.so.2

I'm not sure I understand. MakeResolveDeb will only create one symlink (/usr/lib64) and if there already is a link or directory there then MakeResolveDeb will back away and not touch anything. I suspect that may be what's happening here. This is how it should look:

Code: Select all

$ ls /usr/lib64 -l
lrwxrwxrwx 1 root root 26 Sep 30 11:53 /usr/lib64 -> /usr/lib/x86_64-linux-gnu/

Resolve will always try to load libcuda.so from /usr/lib64/ so that is normal. It's hard coded in the binary. That's why this ugly symlink hack is needed in the first place.

I use Resolve Studio Linux 16 final on a AMD 2700 computer with M2 SSD, 32 Gb ram and a Vega 56 card. My system is Ubuntu Budgie 19.04 with the ROCm video drivers ( https://github.com/RadeonOpenCompute/ROCm ) and Mesa from: https://launchpad.net/~paulo-miguel-dia ... buntu/mesa
It works great, stable and very fast. I use the computer for all my work so i need things like whatsapp, libreoffice, mail latest browsers like Vivaldi, Gimp, wine running smoothly with Silkypix and much more, so Cent OS is a no way. Too much hassle. I installed Resolve with makeresolvedeb and it worked at first try. Using the Davinci installer don't worked.

Daniel Tufvesson wrote:I will only speak for myself but in my case there was a lot less effort required in adapting Resolve to run on Debian than it was to to integrate CentOS into my existing environment.

Exactly.

Martin Schitter wrote:the actual needed changes for debian/ububuntu/mint compatibility are more or less trivial and realizable without much pain.

Exactly.

Martin Schitter wrote:why BMD does refuse this concession resp. acceptance of the real world and vast majority of linux users in such an unyielding manner?

Exactly (and not exactly). They have already fixed most of the install issues, they just don't admit it. I install new Resolve versions on Ubuntu by simply double clicking the install file. I've never used makeresolvedeb. Couldn't be much simpler.

Daniel Tufvesson wrote:I'm not sure I understand. MakeResolveDeb will only create one symlink (/usr/lib64) and if there already is a link or directory there then MakeResolveDeb will back away and not touch anything. I suspect that may be what's happening here.

Yes it is indeed the case. I was forced to create a symlink to directly access libcuda.so from the directory /usr/lib64.
Since that seems to work normally and I have no more flickering, resolve launch without blocking on "Loading Waveform Monitor" (makeresolvedeb_16.1b3-3.sh is ok for me now).

Thank's for your help !

Noel Sterrett wrote:

Daniel Tufvesson wrote:I will only speak for myself but in my case there was a lot less effort required in adapting Resolve to run on Debian than it was to to integrate CentOS into my existing environment.

Exactly.

Martin Schitter wrote:the actual needed changes for debian/ububuntu/mint compatibility are more or less trivial and realizable without much pain.

Exactly.

Martin Schitter wrote:why BMD does refuse this concession resp. acceptance of the real world and vast majority of linux users in such an unyielding manner?

Exactly (and not exactly). They have already fixed most of the install issues, they just don't admit it. I install new Resolve versions on Ubuntu by simply double clicking the install file. I've never used makeresolvedeb. Couldn't be much simpler.

+1 to Noel, Daniel and Martin
Can confirm that from v16 stable I'm installing directly from the .run package.

I'm a firm believer in Debian packaging. It really is a great way to manage installations and modifications to a system. Debian should really not be modified in any other way. That's the whole concept that keeps it the stable and robust system it is. Without package management there really is no way to keep track of system changes. Let alone reverse them in an controlled manner. BMD has done a great job packaging DesktopVideo and the BMRAW player in Debian packages (as well as RPMs) so they sure know how to do it. Let's hope they eventually decide to do the same for Resolve. Until then I will keep maintaining MakeResolveDeb.

Those of you who install using the .run file, how is Resolve stability? Especially the Fusion page? Please share your setups if you have that running properly.

Daniel Tufvesson wrote:Those of you who install using the .run file, how is Resolve stability? Especially the Fusion page? Please share your setups if you have that running properly.

Resolve is quite stable. Fusion has never worked for me, even with CentOS.

Noel Sterrett wrote:Resolve is quite stable. Fusion has never worked for me, even with CentOS.

I recommend you trying the lib64 fix. That along with the NVIDIA 430.50 driver has been very stable for me and several other users I've been in contact with. With this in place the Fusion panel works very well.

For those who wonder, the lib64 fix involves creating a symlink in the path were CentOS stores x86_64 libs to make it point to the proper location in the Debian world. That way the dynamic library loading in Resolve can locate and load libraries properly. This breaks the Debian concept and should be avoided but in the current state of Resolve we don't have much of a choice.

Code: Select all

ln -s /usr/lib/x86_64-linux-gnu/ /usr/lib64

That's the reason for implementing this fix in MakeResolveDeb so that we at least can perform this workaround in a reasonably controlled and reversible manner. It really makes all the difference. I hope BMD acknowledge this and implements a better solution for the dynamic library loading.

Only perform the lib64 workaround manually if you really (really!) know what you are doing. Otherwise I strongly recommend doing it through latest versions of MakeResolveDeb. At this time 16.0-4 or 16.1b3-3.

Just added 32gb of RAM and retested.
16.1b3-1 - runs fine, flickering problem
16.1b3-2 - (stuck during bootscreen)
16.1b3-3 - (stuck during bootscreen)

Strace output 16.1b3-3:
select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=10000}) = 0 (Timeout)
Just looping indefinitely.
Inside logs i see:

ResolveDebug.txt:[0x7f1eedeeb700] | DVIP | INFO | "timeanddate" | Unable to load libcuda from /usr/lib64/libcuda.so

Also no package provides this location for me:
#apt-file search libcuda.so
libcuda1: /usr/lib/x86_64-linux-gnu/nvidia/current/libcuda.so
libcuda1: /usr/lib/x86_64-linux-gnu/nvidia/current/libcuda.so.1
libcuda1: /usr/lib/x86_64-linux-gnu/nvidia/current/libcuda.so.418.74
libnvidia-legacy-340xx-cuda1: /usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libcuda.so
libnvidia-legacy-340xx-cuda1: /usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libcuda.so.1
libnvidia-legacy-340xx-cuda1: /usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libcuda.so.340.107
libnvidia-legacy-390xx-cuda1: /usr/lib/x86_64-linux-gnu/nvidia/legacy-390xx/libcuda.so
libnvidia-legacy-390xx-cuda1: /usr/lib/x86_64-linux-gnu/nvidia/legacy-390xx/libcuda.so.1
libnvidia-legacy-390xx-cuda1: /usr/lib/x86_64-linux-gnu/nvidia/legacy-390xx/libcuda.so.390.116
nvidia-cuda-dev: /usr/lib/x86_64-linux-gnu/stubs/libcuda.so
nvidia-cuda-dev: /usr/share/man/man7/libcuda.so.7.gz

This line fails, because of the presence of /usr/lib64 with one or two links:
> test ! -e /usr/lib64 && ln -s /usr/lib/x86_64-linux-gnu/ /usr/lib64 && touch /usr/lib64_link_created_by_makeresolvedeb
So do you suggest to create that link manually?

16.0-4 - all fine, no flickering

Regards!

Hi Boris! What does your /usr/lib64 look like? It sounds like you have made some changes to the path manually. Was those changes made for Resolve? If that's the case I would recommend you to remove /usr/lib64 entirely and reconfigure the resolve package.

Code: Select all

sudo dpkg-reconfigure davinci-resolve

or

Code: Select all

sudo dpkg-reconfigure davinci-resolve-studio

That will recreate the link.

Also I see that you are on NVIDIA 418.74 as well as have several legacy libraries installed. That may cause trouble. The BMD recommended driver for 16.0 and 16.1 is 430.40. Make sure you only have one NVIDIA driver installed and preferably something newer than 418.74. I think 430.50 is available for your dist.

This is my situation:
16.1b3-1 - no problems
16.1b3-2 - hangs on "Loading Waveform Monitor"
16.1b3-3 - hangs on "Loading Waveform Monitor"
I'm on Ubuntu 18.04 with an NVidia GTX1060, latest stable driver 430.50
I must say that in the past I always got a screen after the first start after a new installation of DR.
That screen appeared during the "Loading Waveform Monitor" and it said that DR was not reacting.
I could chose between "Force closing" or "Wait". If I chose "Wait" then after a few seconds DR started working.
Afterwards everytime I start DR again there are no problems.
Now I just reinstalled with the 16.1b3-1 installer and everything is back ok.
If you need more info, just ask.

Jef Damen wrote:If you need more info, just ask.

Do you have /usr/lib64 folder? Could you show it's content? Probably it contains just a few links like these:
x86_64-linux-gnu
ld-linux-x86-64.so.2
I checked on another debian installation and it lacks /usr/lib64 folder entirely. Still i don't recall linking something manually

A lot of stuff is in it:

Code: Select all

jef@jef-P95xER:/usr/lib64$ ls
accountsservice                 libGraphicsMagick++-Q16.so.12
apg                             libGraphicsMagick++-Q16.so.12.3.1
apt                             libGraphicsMagick-Q16.so.3
aspell                          libGraphicsMagick-Q16.so.3.17.2
at-spi2-core                    libGraphicsMagickWand-Q16.so.2
avahi                           libGraphicsMagickWand-Q16.so.2.8.2
bfd-plugins                     libgstbase-0.10.so.0
binfmt.d                        libgstbase-1.0.so.0
blackmagic                      libgstreamer-0.10.so.0
bluetooth                       libgstreamer-1.0.so.0
chromium-browser                libgunicode.so.4
cin                             libgunicode.so.4.0.0
cnf-update-db                   libgutils.so.2
colord                          libgutils.so.2.0.0
command-not-found               libhardsid-builder.so.0
compat-ld                       libhardsid-builder.so.0.0.1
compiz                          libmbim
cuda                            libmfhdfalt.so.0
cups                            libmfhdfalt.so.0.0.0
dbus-1.0                        libnatpmp.so.1
dconf                           libnetpbm.so.10
debug                           libnetpbm.so.10.0
deja-dup                        libnvidia-gtk2.so.418.56
dkms                            libnvidia-gtk3.so.418.56
doublecmd                       libogdi.so.3
dpkg                            libogdi.so.3.2
eid-mw                          libpodofo.so.0.9.5
eject                           libqmi
emacsen-common                  librarian.so.0
environment.d                   librarian.so.0.0.0
evince                          libreoffice
evolution                       libresid-builder.so.0
evolution-data-server           libresid-builder.so.0.0.1
file                            libsidplay2.so.1
firefox                         libsidplay2.so.1.0.1
firefox-addons                  libvpf.so.3
frei0r-1                        libvpf.so.3.2
fwupd                           lightworks
fwupdate                        linux
gcc                             linux-boot-probes
gcr                             locale
gdm3                            lp_solve
geoclue                         man-db
geoclue-2.0                     memtest86+
gettext                         mime
ghostscript                     modules-load.d
gimp                            mozilla
girepository-1.0                msttcorefonts
gjs                             mutter
glib-networking                 networkd-dispatcher
gnome-control-center            NetworkManager
gnome-disk-utility              notification-daemon
gnome-initial-setup             nux
gnome-online-accounts           nvidia
gnome-session                   nvidia-cuda-toolkit
gnome-settings-daemon           nvidia-visual-profiler
gnome-settings-daemon-3.0       ogdi
gnome-shell                     openssh
gnome-terminal                  os-prober
gnome-tweak-tool                os-probes
gnupg                           os-release
gnupg2                          p7zip
gold-ld                         packagekit
GraphicsMagick-1.3.28           pcmciautils
groff                           pcsc
grub                            phantomjs
grub-legacy                     pkgconfig
gst-install-plugins-helper      pkg-config.multiarch
gvfs                            pm-utils
i386-linux-gnu                  policykit-1
ibus                            policykit-1-gnome
indicators3                     pppd
initramfs-tools                 pulse-11.1
ispell                          python2.7
jayatana                        python3
jvm                             python3.6
kernel                          python3.7
klibc                           qt5
ladspa                          rhythmbox
language-selector               rsyslog
libarmadillo.so.8               rtkit
libarmadillo.so.8.400.0         sane
libcue.so.1                     sasl2
libcue.so.1.0.4                 shim
libDaVinciPanelAPI.so           shotwell
libdfalt.so.0                   snapd
libdfalt.so.0.0.0               software-properties
libdvd-pkg                      speech-dispatcher-modules
libepub.so.0                    ssl
libepub.so.0.2.1                sudo
libfontforgeexe.so.2            sysctl.d
libfontforgeexe.so.2.0.0        syslinux
libfontforge.so.2               SYSLINUX
libfontforge.so.2.0.0           syslinux-legacy
libgdal.so.20                   systemd
libgdal.so.20.3.2               system-service
libgdraw.so.5                   sysusers.d
libgdraw.so.5.0.0               tar
libgimp-2.0.so.0                tc
libgimp-2.0.so.0.800.22         thunderbird
libgimpbase-2.0.so.0            thunderbird-addons
libgimpbase-2.0.so.0.800.22     tmpfiles.d
libgimpcolor-2.0.so.0           transcode
libgimpcolor-2.0.so.0.800.22    ubiquity
libgimpconfig-2.0.so.0          ubuntu-release-upgrader
libgimpconfig-2.0.so.0.800.22   udisks2
libgimpmath-2.0.so.0            unity-settings-daemon
libgimpmath-2.0.so.0.800.22     unity-settings-daemon-1.0
libgimpmodule-2.0.so.0          update-notifier
libgimpmodule-2.0.so.0.800.22   upower
libgimpthumb-2.0.so.0           valgrind
libgimpthumb-2.0.so.0.800.22    vino
libgimpui-2.0.so.0              wx
libgimpui-2.0.so.0.800.22       X11
libgimpwidgets-2.0.so.0         x86_64-linux-gnu
libgimpwidgets-2.0.so.0.800.22  xdg-desktop-portal
libgioftp.so.2                  xorg
libgioftp.so.2.0.0              xserver-xorg-video-intel
libgjs.so.0                     zeitgeist
libgjs.so.0.0.0

Jef Damen wrote:A lot of stuff is in it:

Jef, is /usr/lib64 a folder or a symlink?
Do you have this file present /usr/lib64_link_created_by_makeresolvedeb?

I'm not really a terminal guy but I think usr/lib64 is a symlink:

Code: Select all

jef@jef-P95xER:/usr$ ls -al
totaal 156
drwxr-xr-x  12 root root  4096 jul  3 10:34 .
drwxr-xr-x  24 root root  4096 okt  2 09:29 ..
drwxr-xr-x   2 root root 69632 okt  2 09:28 bin
drwxr-xr-x   2 root root  4096 dec 14  2018 games
drwxr-xr-x  82 root root 20480 sep 19 21:32 include
drwxr-xr-x 163 root root 12288 okt  2 10:19 lib
lrwxrwxrwx   1 root root     8 dec 21  2018 lib64 -> /usr/lib
drwxr-xr-x   2 root root  4096 sep 21 16:58 libexec
drwxr-xr-x  10 root root  4096 jul 25  2018 local
drwxr-xr-x   3 root root  4096 apr 27 22:41 locale
drwxr-xr-x   2 root root 12288 okt  2 09:28 sbin
drwxr-xr-x 351 root root 12288 sep 23 10:44 share
drwxr-xr-x  12 root root  4096 okt  2 09:29 src


And there is no /usr/lib64_link_created_by_makeresolvedeb file

Jef Damen wrote:A lot of stuff is in it:

Looks about right. Directory listing of /usr/lib64 and /usr/lib/x86_64-linux-gnu should be identical if the symlink is created correctly.

When there is no valid /usr/lib64/libcuda.so then Resolve will only partly load CUDA and may appear to startup and work correctly but several functions will not work. Most obvious is the Fusion page.

Jef Damen wrote:I'm not really a terminal guy but I think usr/lib64 is a symlink:

That symlink is not correct and since it already existed makeresolvedeb did not create a new link. Remove it and run "sudo dpkg-reconfigure davinci-resolve" or "sudo dpkg-reconfigure davinci-resolve-studio"

Daniel Tufvesson wrote:Remove it and run "sudo dpkg-reconfigure davinci-resolve" or "sudo dpkg-reconfigure davinci-resolve-studio"

Make sure you have some ubuntu USB near. These manipulations can lead to unusable system.
In that case, just boot from USB and change it back. Maybe renaming this link is a better idea, so it's easier to rollback.

Daniel Tufvesson wrote:Most obvious is the Fusion page

If i switch to OpenCL, resolve seems unstable after few minutes, but cuda seems to work fine.
Will retest since i don't have proper symlink from /usr/lib64
Maybe you could add some warning to your script, so there is a message informing that needed libraries will not be loaded

Boris Kovalev wrote:

Daniel Tufvesson wrote:Remove it and run "sudo dpkg-reconfigure davinci-resolve" or "sudo dpkg-reconfigure davinci-resolve-studio"

Make sure you have some ubuntu USB near. These manipulations can lead to unusable system.
In that case, just boot from USB and change it back. Maybe renaming this link is a better idea, so it's easier to rollback.

I can assure you. There is no risk involved in re-configuring these packages.

Daniel Tufvesson wrote:There is no risk involved in re-configuring these packages.

Yes, but you mentioned deleting /usr/lib64 and i just broke my setup yesterday doing so

Boris Kovalev wrote:

Daniel Tufvesson wrote:There is no risk involved in re-configuring these packages.

Yes, but you mentioned deleting /usr/lib64 and i just broke my setup yesterday doing so

Yes, sorry, you are absolutely correct. Directly modifying system files is generally a bad thing. And once manually modified, the only way to reverse it may be by modifying again
That's why I recommended only removing the bad link and then let the deb package recreate it in a controlled and beforehand tested procedure. That way the deb package will also automatically remove the link once we find a better solution.

Boris Kovalev wrote:Maybe you could add some warning to your script, so there is a message informing that needed libraries will not be loaded

That is a good idea. I think it will help users understand what is going on. Especially in this case where this specific workaround is relatively common and many accidentally get it wrong when doing it manually.

I just renamed /usr/lib64 to /usr/lib64old for safety and reinstalled DR with your 16.1b3-3 installer.
After that DR started up without a problem.
But now I´m reading the last posts in this thread and I´m a little bit scared.
My system seems to be running ok but there is a lot of difference between the old and new /usr/lib64
The old usr/lib64 has 154 items in it and the new 1873 items.
In the new usr/lib64 I´m missing a firefox, thunderbird, virtualbox directory and probably a lot more.
Is this a problem/
Or should I just have to delete the symlink? But how do I do that in the terminal.

Jef Damen wrote:I just renamed /usr/lib64 to /usr/lib64old for safety and reinstalled DR with your 16.1b3-3 installer.
After that DR started up without a problem.
But now I´m reading the last posts in this thread and I´m a little bit scared.
My system seems to be running ok but there is a lot of difference between the old and new /usr/lib64
The old usr/lib64 has 154 items in it and the new 1873 items.
In the new usr/lib64 I´m missing a firefox, thunderbird, virtualbox directory and probably a lot more.
Is this a problem/
Or should I just have to delete the symlink? But how do I do that in the terminal.

I'm glad you got Resolve running! If I remember correctly the reason in your case for the difference is that the old lib64 was pointing to /usr/lib instead of /usr/lib/x86_64-linux-gnu. There is no harm in leaving the old link in place if you feel unsafe removing it.

On a fresh debian 10.1 install i already have the /usr/lib64 directory with ld-linux-x86-64.so.2 link inside it.
So the script should always fail
Still on my work pc i don't have it, really don't know why.
The only difference i can recall, is that i started with debian testing and only after a while and tons of updates i got debian 10.1 it is now.
Any ideas? What would be the safe way to install the script? I got /usr/lib64 renamed and system was unable to locate binaries anymore, so i restored the folder back in place using live usb.
Sure i can manually point it to where it should be, but only booting external linux

Boris Kovalev wrote:On a fresh debian 10.1 install i already have the /usr/lib64 directory with ld-linux-x86-64.so.2 link inside it.

That is very odd. There really should not be any /usr/lib64 on a standard Debian. Since you see ld-linux-x86-64.so.2 it sounds like the contents of /lib64 which is normal and should be there. /lib64 and /usr/lib64 is not the same thing.

If you see /usr/lib64 there must be some modification performed to the system or perhaps some other installed 3rd party program has performed a similar hack but it's very strange to put ld-linux-x86-64.so.2 in /usr/lib64. It will not do any good.

Do not make any changes to /lib64 !

Daniel Tufvesson wrote:There really should not be any /usr/lib64 on a standard Debian. Since you see ld-linux-x86-64.so.2 it sounds like the contents of /lib64 which is normal and should be there. /lib64 and /usr/lib64 is not the same thing.

I just retested, steps to reproduce:
Install https://cdimage.debian.org/debian-cd/cu ... etinst.iso on VM
During installation i selected no packages at all, so just basic console debian is installed.
After first reboot /usr/lib64 folder is on site. /lib64 is a link to /usr/lib64

'/lib64' is usually created by extracting the package 'libc6' which installs '/lib64/ld-linux-x86-64.so.2'
(see also: https://wiki.debian.org/Multiarch/Libra ... nterpreter)

'/usr/lib64' shouldn't be there, but it could exist on some machines, because some stupid closed source software (e.g. the brother scanner driver debian packages) simply ignore the relevant distribution specific standards resp. the rules behind multi-arch support and still [try to] install some libs at this particular location and thereby also create the directory entry.

it always leads to very hard foreseeable troubles, if you violate this kind of standards and try to establish exceptions just for your own package. IMHO this should be really avoided as much as possible by anybody and handled in a more exemplary manner, because there will be always one or the other software, which will be affected by this changes and subsequently produce very hard reproducible errors.

You are right Boris! The directory structure has changed in Debian 10

Debian 9:
Debian 10:
Installs upgraded from Debian 9 keep the old structure but new installations of 10 and up will get the new structure. I did my testing on systems upgraded from 9 to 10 and 11... Not sure about Ubuntu but I think 19.04 is still using the old structure as well.

We need to work out a new solution. This means the /usr/lib64 is from now on used for the ELF interpreter on those systems. While I do like this new approach in principle, it will cause problems in this case.

Martin Schitter wrote:'/lib64' is usually created by extracting the package 'libc6' which installs '/lib64/ld-linux-x86-64.so.2'
(see also: https://wiki.debian.org/Multiarch/Libra ... nterpreter)

Yes, i do have on work pc /lib64 folder with this link inside:
ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.28.so,
And /usr/lib64 is not present.
But since i'm retesting clean install on vm and a pc now, and get /usr/lib64 folder, i'll assume is fairly standard to have it.
So what makeresolvedeb should do in those cases? Can we create links to particular dependencies and leave the old workaround only for cases where /usr/lib64 is absent?

Daniel Tufvesson wrote:You are right Boris! The directory structure has changed in Debian 10

Oh so that was it. Since i upgraded debian on work, i still have the old structure.
Let me know if you need some more testing, always glad to help

Daniel Tufvesson wrote:You are right Boris! The directory structure has changed in Debian 10.

i think, it's the consequence of replacing most of the top level dirs by links lto subdirectoris of /usr

see:
https://www.debian.org/releases/stable/ ... merged-usr
https://www.freedesktop.org/wiki/Softwa ... eUsrMerge/

Thank you for digging through the release notes Martin. Then we know that this effectively sets stop for this hack on Debian and probably soon also on Ubuntu and others. I feel a little embarrassed for not knowing this. I do most my work with Debian 9 as a base so it totally went under my radar

I did some more investigating. With no /usr/lib64/libcuda.so in place my Resolve Studio 16.1b3 hangs on "Loading Waveform Monitor" with this in the log:

Code: Select all

[0x7f849c1dc700] | DVIP                 | INFO  | 2019-10-05 08:48:36,907 | Unable to load libcuda from /usr/lib64/libcuda.so
...
[0x7f849b848700] | DVIP                 | INFO  | 2019-10-05 08:48:36,933 | Unable to load libcuda from /usr/lib64/libcuda.so

Two times it fails to load libcuda.co and eventually grinds to a halt. 16.0 have the same in the logs and does eventually startup but things like the Fusion tab is unusable.

It looks like there are three direct references to /usr/lib64:

Code: Select all

$ strings /opt/resolve/bin/resolve | grep "/usr/lib64"
/usr/lib64/libDaVinciPanelAPI.so
/usr/lib64/libcuda.so
/usr/lib64/ImageMagick-7.0.8//config-Q16/

The panel API, libcuda and for some reason a specific version of ImageMagick. If the first two strings are the constants used for dynamically loading the libraries (and I really think that is the case) then the full path should not be needed. If these two constants are changed I believe Resolve will load the libraries properly on all platforms.

Code: Select all

"/usr/lib64/libDaVinciPanelAPI.so" --> "libDaVinciPanelAPI.so"
"/usr/lib64/libcuda.so" --> "libcuda.so"

So please Resolve devs, can you have a look at this? If you for some reason need these full paths for some special use case then perhaps keep it but make a fallback in case of a load fail that simply tries to load again with just the library name?

There is a similar case for viewing the PDF manual from the Help menu where Resolve depends on /usr/bin/evince. Using xdg-open would be a better choice and that is actually what is used when opening the URLs in the same menu so the proper functionality is in place but not used.

Daniel,

I'd say the best way to drive attention to this path issue is to create another topic.
The description should be just to use relative path for libs, not to make resolve work on debian derivatives (becasuse oficially it should'n work anyway).
We can use this one for workarounds and makeresolvedeb usage.

What do you think?

So, I broke the piggybank and I have a 2060 super on the way.
I'm still an AMD supporter, the experience on Linux (not with bleedeng edge hardware) is spectacular, you install your distro and basically you're good to go.
Yes there are some rough edges with Resolve and OpenCL, but in some compute workloads Vega and the venerable Polaris are still competent.
So I'm quite familiar with AMD drivers on linux, and I hope that the switch to the green side will not be traumatic.

TLDR;
2060 super inbound, Ubuntu 18.04,
how do you recommend installing the drivers and cuda?
those provided in the repositories are sufficiently up to date? Does 16 requires cuda 10?
thank you

Resolve 16 does not require CUDA 10. I'm using it with a 2060 on Debian 10.1 without any issues.