(Manjaro) error during build: ./DaVinci_Resolve_17.4.6_Linux.run: no such file or directory about resolve HOT 20 CLOSED

FWIW DaVinci beta4 seems to work fine.

(with pipewire on the Ubuntu 22.04 host and in the Alma Linux 9 container)

from resolve.

Yeah the issue is especially weird since it's a "file not found error"-- when you do it interactively (that is, manually running the installer) do you still have issues running it? The idea about some kind of unusual security issue being related isn't bad-- does changing the permissions of the .run file make any difference?

If using podman, maybe try to add (on the HOST) to: ~/.config/containers/containers.conf

   [engine]
   cgroup_manager = "cgroupfs"

I read somewhere this can help with permissions-related issues.

It's really strange that the file shows up when you ls but then it can't find/run it when run by name...

When you play with it more interactively, hopefully the issue will be obvious and fixable. In that case, please do let us know. And good luck with your exam!

from resolve.

And it seems to work very well! I just put together an animated effect and an audio track to see if I can get it to render something without crashing and

• the interface is fast and responsive
• audio playback is not choppy! This is a huge issue with the regular (non-containerized) installation on Pipewire, where Resolve basically cannot play back audio and I'm so happy to hear it play back audio as it should!
• export finished quickly without errors
• exported video can be played back properly

I went with the AlmaLinux 9 base image and Resolve 18 beta 4 (18.0b4) for this installation.

from resolve.

A big thank you! This is awesome news. I was kind of amazed too at how well it works in the container, right? Glad it's playing audio without choppiness!

So we should definitely check to make sure that the fonts and /etc/alternatives/x-cursor-theme folders actually exist before linking them as I guess they don't get created automatically on all distributions (See the README.md about the fonts folders and why the LOCAL fonts were get preference over the SYSTEM fonts-- there were just too many in Ubuntu!)

The scaling issue is also mentioned in the README, but I wonder if we should have a RESOLVE_SCALE_FACTOR to override the default (1 was too tiny on my screen), which can be added to the resolve.rc file.

The big deal seems to be that patch to the run file. I should experiment to see if doing it on my version breaks anything, or if we need to specifically check for manjaro/arch systems to do that patch.

Does this version work? (from here)

 sed '0,/AI\x02/{s|AI\x02|\x00\x00\x00|}' -i "$linuxdeploy"

from resolve.

Sure, I'll check the sed version, too, soon. Yes, please do check whether the patch works with an Ubuntu host, too. If it works there as well, then maybe it can be included in the build.sh file (I'll gladly submit a PR with it). If it breaks the installer, then we can include this specific patch only for Manjaro/Arch (or at least mention it in the README).

I'm still curious what it is specifically that breaks AppImages in containers under Manjaro. Though the issue seems to be sort-of fixed in the AppImageKit repo, Blackmagic Design might be using an older version to bundle Resolve that does not fiddle with these magic bytes - which is why might have to manually do that.

from resolve.

Yeah this is weird because the error sees to be INSIDE the container, not on the host, right? That's where the issue is-- but I would think the container would be the same no matter what the host is...

The issue appears to be on this line:

     && ./*DaVinci_Resolve_*_Linux.run  --appimage-extract \

And when I google this error, error while running runtime: exit status 127 I see the following:

 The 127 error code indicates “command not found”. This occurs when any given command within your Bash script or on Bash command line is not found in any of the paths defined by PATH system environment variable.

Could this mean that for some reason it can't find the "DaVinci_Resolve_17.4.6_Linux.run" file even though there is a cd /tmp right above it and the .run file should be right there?

Maybe one thing to try would be to explicitly tell it to run **/tmp**/DaVinci_Resolve_17.4.6_Linux.run -- for some reason you might need to explicitly name the path (?) in Manjaro although if it's not "in" /tmp I dunno where it will put all those files and it may break on the next command... but you could try that to see if it works? Perhaps for whatever reason you need to explicitly name the path.

Another thought... if you were to delete all the lines in the Dockerfile from 55-51, you would get an image without Resolve installed. At this point you should be able to start that image in a container with:

 ./resolve.sh /bin/bash

(I think that will work anyway... if not you may need to make slight adjustments to resolve.sh just to get it running...)

at which point you'll be dropped into a bash shell inside the container. Now you can experiment doing each of the lines 55-61 manually in real time to see where exactly things are breaking and even better, since you're inside the container, you can try different things to get it to work without having to re-run the build.sh every time.

Once you think you got it installed, then you can run it with

$ /opt/resolve/bin/resolve

If it works, then we'll have the answer! (Remember that if you quit and restart your container, you'll have get a fresh image so any chages you've made will be gone. To make them permanent, just modify the build.sh with whatever you did, rerun build.sh and it should now be there permanently. )

Out of curiousity-- are you using podman or docker? Also, what were the packages you installed (with pacman, right?) to get everything started? It would be nice to add them to the instructions once everything's working.

Thanks again for the investigation. I'm sure you'll have it working soon!

(ANOTHER QUICK THOUGHT-- maybe it's getting a file not found because of the wildcard * in the file name-- try replacing it with the actual full name of the .run file and see if that makes a difference!)

from resolve.

Thank you very much for the detailed guidance. I don't see how it not occurred to me to just build the "pre-Resolve" container and play with it instead of constantly rebuilding it 😅 I'll have an exam in two weeks but I'll want to experiment with getting this running on Manjaro, too (and help document how it started to work, naturally), so I'll come back to it shortly.

Yes, the issue is weird, because the system seems to replace the asterisks with the actual filename (so it probably found it). I also tried using a fixed file name (with no asterisks) and got the same error. I executed ls before trying to extract the Resolve installer and the file shows up inside the container in the current working directory. I'm also wondering if the error has to do with some kernel-level security settings (or something else that's kernel-related) that don't allow me to execute an AppImage file inside of a container -- which is weird again, because the NVIDIA installer also seems to be an AppImage file and it executes correctly, only the Resolve installer doesn't run.

I'm (primarily) using Podman but it didn't work with Docker either (sudo-ing didn't help, either). I installed everything that was recommended in the README, so podman, fuse-overlayfs, nvidia-container-runtime and crun (these are available on the same names in the Manjaro repos).

I'll play around inside the container with the Resolve installer once I have some free time again :)

from resolve.

Okay, I got it to execute and extract the files! 🎊 The issue does seem to partially come from outside of the container, since this is not an issue on e.g. Ubuntu, but it is on Manjaro. Very shortly here's what worked:

Steps to get the Resolve installer to execute

• after extracting the DaVinci Resolve run file, execute: dd if=/dev/zero bs=1 count=3 seek=8 conv=notrunc of=DaVinci_Resolve_18.0b4_Linux.run (on the actual Resolve file, naturally) -- see AppImage/AppImageKit#828
• then the file should execute (and extract its contents) correctly ✔️

What to edit in the Dockerfile

Add the above line to the Dockerfile (after unzip, before running the --appimage-extract command):

diff --git a/Dockerfile b/Dockerfile
index 2416874..636d04e 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -58,6 +58,7 @@ COPY "${ZIPNAME}" /tmp/DaVinci_Resolve_Linux.zip
 
 RUN cd /tmp \
     && unzip *DaVinci_Resolve_Linux.zip \
+    && dd if=/dev/zero bs=1 count=3 seek=8 conv=notrunc of=$(find . -name "*DaVinci_Resolve_*_Linux.run" | tail -n 1) \
     && ./*DaVinci_Resolve_*_Linux.run  --appimage-extract \
     && cd squashfs-root \
     && ./AppRun -i -a -y \

Note. The whole $(find ...) is needed because dd only accepts a concrete file name for of= (it didn't work for me with the *DaVinci_Resolve_*_Linux.run glob pattern). There's probably an easier way to expand the glob pattern into a file name.

A guess on what goes wrong

If I understand correctly, AppImage files seem to contain some magic bytes that break some interpreters, causing emulators like qemu and seemingly containers to not execute these files correctly. I've ran into the issue that mentions this (AppImage/AppImageKit#828) a lot of times now but have not tried its proposed solution (the above command) until now. Then I downloaded the AppImage runtime and tried to execute the Resolve installer through that runtime and nothing happened in the container (no output etc.) but it worked on the host machine. I'm not exactly sure what is different regarding this issue on Manjaro to e.g. Ubuntu but stripping these magic bytes (again, if I understand correctly, this is what the dd command does) seems to solve the issue of not being able to execute the file and unpack its contents.

If someone can chime in with some more information on why executing AppImages in containers goes wrong on Manjaro but not on Ubuntu, let us know! Also, my mistake was supposing that the NVIDIA installer is an AppImage, it is apparently not (file reports a completely different output on it).

For now I managed to extract the files, I'll add the command to the Dockerfile to start the installation and report back.

Also, I had to comment out two lines from ./resolve.sh to start the container:

• --mount type=bind,source=${HOME}/.local/share/fonts,target=/usr/share/fonts,readonly (no such directory on my Manjaro machines: ~/.local/share/fonts - possibly because I installed all fonts globally?)
• --mount type=bind,source=/etc/alternatives/x-cursor-theme,target=/usr/share/icons/default/index.theme,readonly (again, the folder /etc/alternatives/x-cursor-theme does not exist)

from resolve.

Woohoo! It works! Now the only problem is that the Resolve windows are about 2-3x zoomed in 😅 (I'm using KDE Plasma, though, so it might have to do with that, I'll take a look around). This is mostly visible on the splash screen which fills the entire 1080p screen.

from resolve.

Nevermind: I got it fixed by setting --env QT_SCALE_FACTOR=1 (instead of the original 2) in resolve.sh, and only that variable :)

from resolve.

I just tried

diff --git a/Dockerfile b/Dockerfile
index 2416874..de05c68 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -58,6 +58,7 @@ COPY "${ZIPNAME}" /tmp/DaVinci_Resolve_Linux.zip
 
 RUN cd /tmp \
     && unzip *DaVinci_Resolve_Linux.zip \
+    && sed '0,/AI\x02/{s|AI\x02|\x00\x00\x00|}' -i *DaVinci_Resolve_*_Linux.run \
     && ./*DaVinci_Resolve_*_Linux.run  --appimage-extract \
     && cd squashfs-root \
     && ./AppRun -i -a -y \

And it didn't break anything... still ran. Does it fix for you? I'd rather use sed as it feels less "dangerous" and is at least checking what bytes it replaces...

But anyway I can confirm that the above doesn't break 18b4 anyway... One thing now that I think about it, we probably want to be sure sed will fail gracefully if it doesn't need to change anything - I think it will return 0 regardless.. That's anticipating that at some point Blackmagic Design updates their AppImageKit, we don't want this to retoractively break.

And actually, let's say they DO fix it, but the magic string also appears later on randomly in the file... it might patch the wrong place. Hmm. Maybe there should be an initial check to see if the first bytes at offset 8 contain the string, and only THEN replace it? Or is that overthinking things? Or maybe go back to dd? Hmm.

from resolve.

Installation worked with the sed command, too (and Resolve started correctly, too).

I think the worries around BMD updating their AppImageKit are real, but I also think that people would come to report that the installation breaks after a certain version. Also, maybe instead of checking for the bytes, we can just check in a separate step if the Resolve file executes correctly (e.g. with the --appimage-version argument that does nothing but prints the AppImageKit version the bundle was built with). If it doesn't execute (it probably throws a non-zero return code), perform the magic byte removal, otherwise just execute normally. I'm not exactly sure how that can be done in the Dockerfile, but I'd see this as a feasible solution to future-proofing against this error.

from resolve.

I think that could work-- although the non-zero error code might stop the Dockerfile from continuing.

Here are the first few bytes of the file before and after the change (using xxd DaVinci_Resolve_Studio_18.0b4_Linux.run | head -n 2)

BEFORE:

 00000000: 7f45 4c46 0201 0100 4149 0200 0000 0000  .ELF....AI......
 00000010: 0200 3e00 0100 0000 a04f 4000 0000 0000  ..>......O@.....

AFTER:

 00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
 00000010: 0200 3e00 0100 0000 a04f 4000 0000 0000  ..>......O@.....

So if we wanted to be sure that the bytes that change are there, we could use od:

 od -An -j 8 -N 6 -x --endian=big DaVinci_Resolve_Studio_18.0b4_Linux.run

To check for a result of:

  4149 0200 0000

And only do that patch if those values are there in that position. Presumably, if BMD updates AppImageKit, those will be different and the test will fail.

Weirdly this 2017 issue complains about the opposite of our problem and they put the 4149 0200 in!

So putting this all together, we get something like:

diff --git a/Dockerfile b/Dockerfile
index 2416874..869fc05 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -56,8 +56,13 @@ RUN echo "${USER} ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/90-$USER
 
 COPY "${ZIPNAME}" /tmp/DaVinci_Resolve_Linux.zip
 
+# Note: for Arch & Manjaro distributions, we need to work around a potential AppImage "magic bytes" bug that may be in the run file
+# see https://github.com/fat-tire/resolve/issues/16
+
 RUN cd /tmp \
     && unzip *DaVinci_Resolve_Linux.zip \
+    && if [ "`od -An -j 8 -N 6 -x --endian=big *DaVinci_Resolve_Studio_*_Linux.run`" = " 4149 0200 0000" ]; then \
+            sed '0,/AI\x02/{s|AI\x02|\x00\x00\x00|}' -i *DaVinci_Resolve_*_Linux.run; fi \
     && ./*DaVinci_Resolve_*_Linux.run  --appimage-extract \
     && cd squashfs-root \
     && ./AppRun -i -a -y \

If this works, I can check this into the main branch and close this bug (and you can open one for the other issues-- ie, check for the missing directories and maybe a 2nd one for specifying the scale factor-- I'm actually curious if that one QT_SCALE_FACTOR is sufficient..)

from resolve.

btw not sure why I needed to set --endian=big (x86_64 is little endian) but if I didn't the bytes were flipped around.

from resolve.

Fwiw the last patch works via Docker on PopOs 22.04.

from resolve.

Not sure if I pasted something in wrong, but the latest one doesn't work for me. Installation output is the same as before the patch:

Edit - oh it's looking for the Studio version :)

Archive:  DaVinci_Resolve_Linux.zip
  inflating: DaVinci_Resolve_18.0b4_Linux.run  
  inflating: Linux_Installation_Instructions.pdf  
od: '*DaVinci_Resolve_Studio_*_Linux.run': No such file or directory
/bin/sh: line 1: ./DaVinci_Resolve_18.0b4_Linux.run: No such file or directory
error building at STEP "RUN cd /tmp     && unzip *DaVinci_Resolve_Linux.zip     && if [ "`od -An -j 8 -N 6 -x --endian=big *DaVinci_Resolve_Studio_*_Linux.run`" = " 4149 0200 0000" ]; then         sed '0,/AI\x02/{s|AI\x02|\x00\x00\x00|}' -i *DaVinci_Resolve_*_Linux.run; fi     && ./*DaVinci_Resolve_*_Linux.run  --appimage-extract     && cd squashfs-root     && ./AppRun -i -a -y     && cat /tmp/squashfs-root/docs/License.txt     && rm -rf /tmp/*.run /tmp/squashfs-root /tmp/*.zip /tmp/*.pdf": error while running runtime: exit status 127

from resolve.

Fixing the pattern used in od (*DaVinci_Resolve_Studio_*_Linux.run -> *DaVinci_Resolve_*_Linux.run) makes it work again, so works on Manjaro, too!

diff --git a/Dockerfile b/Dockerfile
index 2416874..f58d786 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -58,6 +58,8 @@ COPY "${ZIPNAME}" /tmp/DaVinci_Resolve_Linux.zip
 
 RUN cd /tmp \
     && unzip *DaVinci_Resolve_Linux.zip \
+    && if [ "`od -An -j 8 -N 6 -x --endian=big *DaVinci_Resolve_*_Linux.run`" = " 4149 0200 0000" ]; then \
+        sed '0,/AI\x02/{s|AI\x02|\x00\x00\x00|}' -i *DaVinci_Resolve_*_Linux.run; fi \
     && ./*DaVinci_Resolve_*_Linux.run  --appimage-extract \
     && cd squashfs-root \
     && ./AppRun -i -a -y \

from resolve.

Yes! Sorry that was my stupidity including the Studio in there! :) I'll push this to the main branch. And I suppose I should merge that branch with this one. I would rebase, but I think that would break the repo for everyone... so I guess if I merge main into this, it will effectively include it in this branch but the pull request would remain the same, right? (I haven't done this on github for a while...)

I just want to sync this branch/PR to include all the stuff from main and resolve any conflicts (there shouldn't be any as I can merge branches fine locally)... I think a merge should do it. I'll do this stuff tonight!

Thanks for testing @cowmix and @Hanziness!

from resolve.

Since you're going to merge the pipewire branch into main anyway, both rebasing (which would then require force-pushing the pipewire branch) and merging should be fine - whichever you like better :)

from resolve.

Fixed in 6b8053c! Thanks! (I'll just do a merge into the pipewire branch from main soon-- don't wanna make everyone --force pull if I rebase...)

from resolve.