The Manjaro-provided heroic-games-launcher package (relevant PKGBUILD) installs Heroic’s files into subfolders of /usr/, which breaks titles that rely on Origin/EA app integration. Our official heroic-games-launcher-bin package on the other hand installs into /opt/ which, while not being an ideal location, avoids the issue
The following error is printed in Heroic’s game log when launching an Origin game:
pressure-vessel-wrap[30492]: W: Unable to share "/usr/lib/heroic/app.asar.unpacked/build/bin/x64/linux" with container: Path "/usr" is reserved by the container framework
bwrap: Can't chdir to /usr/lib/heroic/app.asar.unpacked/build/bin/x64/linux: No such file or directory
I believe the root cause of the error is that due to the game technically not being installed at all, Heroic does not change the working directory to the game install path (and it thus stays in the location our helper binaries live in, mentioned in the error message). When umu then tries to create a runtime and tries exposing the CWD in the container, the error occurs
I’m not sure what you guys want to do here, this is definitely a bug we can resolve, but at the same time this bug wouldn’t happen with our official packages
Thanks for the quick fix! I’ve contacted the user who originally reported this issue so they can re-test. Testing on my own system (running regular Arch) suggests the issue is indeed resolved with that change
@Yochanan that script cant write to /usr folder at all due to a non changing folder switch. Using /opt works around that. Until upstream cant handle a regular install we need to use it as is.
I understand the difference between system & bundled Electron, and the changes in folder structure the packaging guidelines recommend because of that. The issue here is that changing the folder structure causes an issue in the program itself. As I mentioned in my original post, I don’t know how you want to deal with this issue, since it is resolve-able by us, but also wouldn’t happen if these changes weren’t made.
To launch games from the Epic Games platform, Heroic invokes a CLI program called Legendary. Legendary is shipped with Heroic (in the app.asar.unpacked directory). For Origin games specifically, Legendary generates a protocol URL (link2ea://launchgame/...) and executes that with Wine. When this happens, Legendary does not change the working directory of the Wine process (usually it would use the game install directory, but Origin games aren’t installed that way at all), so it stays in the directory the Legendary executable is in. That’s the first piece of the puzzle.
Heroic (and Lutris, and various other launchers) also use umu to launch Proton in the Steam runtime it’s built for. When creating this container, pressure-vessel seems to attempt to share the current working directory (I’m not an expert there, but judging by the error messages that seems to be happening)
Putting those pieces together, PV tries to share /usr/lib/heroic/app.asar.unpacked/build/bin/x64/linux/, which isn’t possible (since, as the error message mentions, Path "/usr" is reserved by the container framework). With Legendary living in /opt/Heroic/, this issue is bypassed (since /opt/ is not reserved).
We’d have to modify Legendary to change the working directory to a more neutral path before invoking Wine, which is a little harder than just “Set cwd to <wineprefix path>” (for unrelated reasons). Certainly possible however, and I’m fine with making that change. Just wanted to ask here first how you’d like the issue to be handled (I assume you’ve had a case of packaging changes causing unrelated issues before?)
