Not working and Error in developer tools console when running on Linux x86_64

[singularo]

Nothing appears to happen, except the spinner keeps going, and in the Developer tools console:

VM512 sandbox_bundle:2 Uncaught (in promise) Error: Error invoking remote method 'start': Error: Command failed: /tmp/.mount_DrupalpmZjvA/resources/app/bin/php -r (new Phar("composer.phar"))->extractTo("composer");
    at IpcRenderer.invoke (VM512 sandbox_bundle:2:118258)
invoke @ VM512 sandbox_bundle:2
await in invoke
start @ VM513:6
(anonymous) @ renderer.js:27
load
(anonymous) @ renderer.js:26

Linux details:

$ inxi 
CPU: 8-core AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics (-MT MCP-)
speed/min/max: 2195/400/5134 MHz Kernel: 6.14.4-arch1-1 x86_64 Up: 3h 59m
Mem: 25.25/58.5 GiB (43.2%) Storage: 1.82 TiB (77.6% used) Procs: 778
Shell: Bash inxi: 3.3.38

[phenaproxima]

Thanks @singularo! My theory here is that the bundled php executable isn't marked with 755 permission, so it can't be executed and there's no further information.

That's merely an educated guess, but I'll open a PR that actively changes the permission and can send you a new artifact to try.

[singularo]

Hmm, doesn't appear to be that php isn't executable:

simon@p16s:/tmp/.mount_DrupalZltInr/resources/app/bin $ ls -al
total 24851
-rw-r--r-- 1 root root  3114082 Apr 28 10:55 composer.phar
-rwxr-xr-x 1 root root 22333488 Apr 28 10:55 php
simon@p16s:/tmp/.mount_DrupalZltInr/resources/app/bin $ 

[phenaproxima]

True...but it is rather innerestin' that root owns the file :) Are you actively logged in as root?

[phenaproxima]

Could you try running the launcher with sudo privileges? That would definitely point to a permissions-related bug...

[singularo]

Tried with: sudo ./Drupal.CMS.for.Linux.x64.AppImage --no-sandbox

Got same error in the console, and a bunch of X errors before as not running logged in as root user:

Error occurred in handler for 'start': Error: Command failed: /tmp/.mount_DrupalePEENN/resources/app/bin/php -r (new Phar("composer.phar"))->extractTo("composer");
    at genericNodeError (node:internal/errors:984:15)
    at wrappedFn (node:internal/errors:538:14)
    at checkExecSyncError (node:child_process:906:11)
    at execFileSync (node:child_process:942:15)
    at func (node:electron/js2c/node_init:2:2559)
    at composer (/tmp/.mount_DrupalePEENN/resources/app/binaries.js:19:13)
    at async module.exports (/tmp/.mount_DrupalePEENN/resources/app/installer.js:16:23)
    at async /tmp/.mount_DrupalePEENN/resources/app/main.js:19:5
    at async WebContents.<anonymous> (node:electron/js2c/browser_init:2:87428) {
  status: 255,
  signal: null,
  output: [
    null,
    <Buffer 0a 46 61 74 61 6c 20 65 72 72 6f 72 3a 20 55 6e 63 61 75 67 68 74 20 52 75 6e 74 69 6d 65 45 78 63 65 70 74 69 6f 6e 3a 20 55 6e 61 62 6c 65 20 74 6f ... 178 more bytes>,
    <Buffer >
  ],
  pid: 77202,
  stdout: <Buffer 0a 46 61 74 61 6c 20 65 72 72 6f 72 3a 20 55 6e 63 61 75 67 68 74 20 52 75 6e 74 69 6d 65 45 78 63 65 70 74 69 6f 6e 3a 20 55 6e 61 62 6c 65 20 74 6f ... 178 more bytes>,
  stderr: <Buffer >
}

[singularo]

Extracting with --appimage-extract and then executing ./AppRun in the squashfs-root subdir seemed to get a lot further, but it might be using system installed php in that case, as was quite fast.

[phenaproxima]

Maddening! Thanks for the very detailed bug report -- I'll have to dig into this further.

[gitressa]

This looks really interesting, thanks @phenaproxima!

I also just get the "Installing" message, after enabling "Executable as program" -- both when double-clicking and the --appimage-extract and then execute ./AppRun method

Installing...

This might take a minute.

Perhaps the feedback message could be more verbose, so that us users will know immediately if something is happening "behind the scene", or not ... Either make the message itself more verbose, or perhaps it's possible to add a --verbose parameter?
EDIT: I just saw this issue, which takes care of that:

• Inform users when an error happens #58

Debian 12 / x86_64

[bircher]

for what it is worth, I don't have php on my system (I use docker-relay)
But I went and ran the php from the temp directory and found another fun source of the problem:

:/tmp/.mount_DrupalhCEz6U/resources/app/bin$ ./php -r '(new Phar("composer.phar"))->extractTo("composer");'

Fatal error: Uncaught RuntimeException: Unable to create path "composer" for extraction in Command line code:1
Stack trace:
#0 Command line code(1): Phar->extractTo('composer')
#1 {main}
  thrown in Command line code on line 1

I think one of the problems is that this is all readonly

https://docs.appimage.org/reference/architecture.html

[phenaproxima]

I wonder if this is improved of late. In df56039 -- the commit just before 0.1.9 was tagged -- I changed our build process so that Composer is unpacked before the app is bundled, which means the app doesn't need to modify itself to get Composer running. Worth trying again with HEAD, perhaps?

[phenaproxima]

The extractTo thing is squashed in 0.1.9 and later, and it looks like the only other error that is being encountered on Linux, generally, is the AppImage running into Ubuntu 24's heightened sandboxing restrictions. What can be done about this, I am not sure, but there are documented workarounds in #61 (comment).