New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Electron-updater: Appimage linux updater fails with ENOSYS: function not implemented #4046
Comments
I'm having the same issue. |
Yep, same issue. |
same here |
Same issue on arch. |
@develar Any chance we could get some input from you here? I'd be willing to contribute, but I have no clue how to get the actual appimage path as of right now. |
I came up with a very dirty workaround that I'm not going to ship to my users because it feels way too brittle. I think until this is resolved I have to warn my users to not use AppImageLauncher Anyway, when AppImageLauncher has launched an app, it sets the environment variable Additionally, the environment variable // HACK(mc, 2019-09-10): work around https://github.com/electron-userland/electron-builder/issues/4046
if (process.env.DESKTOPINTEGRATION === 'AppImageLauncher') {
// remap temporary running AppImage to actual source
// THIS IS PROBABLY SUPER BRITTLE AND MAKES ME WANT TO STOP USING APPIMAGE
updater.logger.info('rewriting $APPIMAGE', {
oldValue: process.env.APPIMAGE,
newValue: process.env.ARGV0,
})
process.env.APPIMAGE = process.env.ARGV0
} else {
updater.logger.info('Not running in AppImageLauncher')
} I am categorically not going to ship this to users but your risk-tolerance may be different than mine |
If |
@mcous - Thanks for posting the workaround. I guess the long-term solution is probably to start using the AppImageUpdate utility instead to provide updates to end users. I am not happy about it either as we have (had) a perfectly working system... I don't think that the Looking for There's also the option of asking users to uninstall |
Okay, so for my use-case it's important that the update process is autonomous. By default the update process would create a new file in the Applications directory and execute it. This would prompt the user for 'integrate' or 'run once' dialog. I am not using version in the file name, so that electron-updater would overwrite the file so that the prompt wouldn't pop up. This works, however the appimagelauncher will still run the old version (from a cache somewhere), though the file itself has updated. I even went so far to manually replace the .AppImage with a different file in the Applications folder, and renamed the new AppImage exactly the same as previously 'integrated' one. It still runs the old version... |
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
I believe this issue is still relevant. AppImageLauncher is recommended by electron-builder for desktop integration, but electron-updater does not work with AppImageLauncher installed AppImages |
I had this issue on Arch for almost half a year, it was never fixed, I did a new clean Arch reinstall and only that fixed it. |
Indeed this is more of an issue with Electron's updater than AppImageLauncher, this problem has been fixed in AppImageUpdate itself IIRC. Basically, the issue disappears if you don't use AppImageLauncher. Right now there's nothing we can do in AppImageLauncher to help fix this issue, Electron's updater needs to implement a tiny workaround. @develar I'd like to help get this fixed, please feel free to ping me. |
I have the same issue now. Looking forward for a fix. |
I'm running into the same issue, also from a user on Manjaro Linux. FWIW. |
@quanglam2807 my company does not use that workaround in production, so I cannot vouch for it. We currently tell our users that they should not use AppImageLauncher |
Thank you for the clarification! I couldn’t wait for your answer so I decided to use it anyway in production. But luckily, I haven’t heard any complains. |
I could not get this workaround to work properly, it could be because I had an additional requirement that the updated AppImage should have the same filename as before. What happened in that case was that the file was overwritten with a new file, however when launched, it still launched the old version of the app from some AppImage cache/storage. After spending half a day on the issue I also gave up and concluded this is not something we can work around from inside our app (or the solution would be too hacky). We detect the AppImageLauncher and advise our users to uninstall it if they want automatic updates to work properly.
For users that did not uninstall AppImageLauncher we simply don't install updates to keep their current version running without the errors. |
It's sad to see zero reaction from the electron builder team. I'm not a fan reading when people (have to?) recommend users to uninstall AppImageLauncher entirely for some auto-update (which I'm not a fan of) or general updates to work as intended. If there were a workaround I could implement, that'd be no problem, but it's really not that hard to fix the problem in the Electron updater itself. The AppImage type 3 currently discussed here fixes the need for AppImageLauncher to ship with a custom FUSE filesystem which could cause trouble. @ozooner @mcous please recommend your users AppImageLauncher Lite instead of uninstalling AppImageLauncher entirely. The Lite version is not affected by this bug. And it provides at least some better desktop integration. |
@TheAssassin would you recommend users (of electron-builder) to set X-AppImage-Integrate=false in the .desktop file for now? I've been forced to do that for one of my other apps (not electron) because my self updating appimage is not working well with appimagelauncher. |
No, that would not solve the issue at all. Neither does uninstalling, it's basically just a baaaad hack. |
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Not stale, bot. |
Any update? |
this solution #4046 (comment) works for me but you should include it inside of update-downloaded event otherwise users cant see update progress. If you dont use it in update-download event, it works so fast or doesnt work well
|
* workaround for issue electron-userland/electron-builder#4046 with automatic updates under Linux with AppImageLauncher
Should be resolved once the upcoming release of AppImageLauncher has been published. It replaces the FUSE filesystem with a (hopefully) more robust solution. See TheAssassin/AppImageLauncher#361 for more information. No need for additional workarounds. Looking for testers of the new method! Please report feedback in TheAssassin/AppImageLauncher#361. Edit: tried two AppImages (one of them is Jitsi Meet), the update worked as intended. Still not a fan of the custom method (would prefer an integration with AppImageUpdate), but it works now. |
The AppImageLauncher fix was released. I tried it and it worked fine for me. This could be closed? |
@adam-lynch do you know which version contains the fix? |
@ozooner 2.2.0, see TheAssassin/AppImageLauncher#361 |
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
This was still happening with uninstall and reinstall for me for the last 15 months till today. Finally today I noticed that the latest/edge channel that I was on hasn't been updated since the problem started. latest/stable has the actual latest version. I uninstalled and then switched channels and reinstalled. I guess next time there is an update I'll know if this is still broken or if it can update now. If you're reading this, make sure you switch to latest/stable since if you were on edge to try to get the fix faster, you were stuck on an old version. |
hm, maybe I am remembering how this bug worked wrong... it looks like I'm using snap now, not appimage, and this bug was for app image. I must have switched in my attempt to get it working and long forgot. Regardless, you do need the latest/stable channel for snap or you'll be stuck on the broken version. |
Electron updater errors out with the following logs:
What's interesting to note here is that
/run/user/1000/appimagelauncherfs/
contains copies of appimages that are currently running. The error log implies thatprocess.env.APPIMAGE
does not return the path where the file was started from (by the user). I suspect that this is an issue with AppImageLauncher, which is the default method of integrating and running appimages on a lot of systems. This could easily be solved if there was some way of knowing what directory the appimage was actually started from.Package.json: https://gitlab.com/nullworks/accgen/accgen-electron-app/blob/CD/package.json
Node ver: v11.15.0
Npm ver: 6.10.0
The text was updated successfully, but these errors were encountered: