-
Notifications
You must be signed in to change notification settings - Fork 26
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
Not starting anymore since v23.5.5 (arm64) #226
Comments
I don't know if this is related but I also have troubles with loading Collabora Online - Built-in CODE Server after upgrading to v23.5.5 . Only error I get in apache log is:
|
same problem for me. nothing in nextcloud log.
Collabora 22.5.1301 works without issues |
Does anyone even read this issues? Some acknowledgement would be great. More and more people are reporting similar problems... I am aware this is free and opensource project but I think they at least should not be forcing this update if it is breaking things. |
This looks like a serious issue, right? |
Hmm, even Ubuntu 16.04 has glibc-2.23. The issue needs further investigation. |
@timar If you need any more information or want me to test something, just tell me. :) |
coolwsd from AppImage logs at weird places, can you please try to find it? In /tmp for example (find /tmp -name coolwsd.log). |
@timar Sure! Here are the webserver log files: The coolwsd.log don't get generated at all when using the new version. When using v22.5.1301 there is a log file. This is what I did from enabling the app to picking the log files:
I hope this helps! If you need anything else, just tell me. |
@timar Maybe the new AppImage needs a new dependency that is not installed on my system? 🤔 EDIT: I'm sorry, but I will not be able anymore to provide more details sadly. Aber long time of waiting I moved my server to a new hardware with more perfoemave and different architecture. The Built-In CODE app work here now. |
unable to get Collabora to run on Rock5 since NC26 update. please see my issue here: |
After migration from Centos7 to Alma9 (which has support for newer versions of GLIBC) everything works ok. |
I'm on a shared host and have all the latest versions of NC and collabora installed. I'm on PHP 8.2. Since 23.5.102 all versions of collabora server are not loading. When downgrading to 23.5.5 it loads. I don't know what the issue is. Maybe it has something to do with fontconfig. Anyway I will stay on 23..5.5 until a newer version is loading again. I think this might affect also other users on shared hosts. If any developer is interested in researching this issue, I can provide access to my test server. Just give me an email. |
Everyone who still read this: Did you try to install all required libraries? On Ubuntu Server 22.04 it is common that See: https://github.com/CollaboraOnline/richdocumentscode#system-requirements Just found that out while searching for a similar issue. Sadly, I can't test it myself anymore, I'm on amd64 now. :/ |
I am happy to test this on my arm (rock5) setup. can you let me know how I could install these two on armbian? |
Try this: |
Ich denke beide sind schon installiert.
|
habe glib installiert - hat leider nicht verbessert. akutelle version vom collabora started nicht
|
This worked for me. Edit proxy.php on lines 152 an 153: 151 exec('( /sbin/ldconfig -p || scanelf -l ) | grep fontconfig > /dev/null 2>&1', $output, $return); Fontconfig is installed and running on my server. However Collabora still thinks it's not. |
@Jolopu Interesting. But we're close. What is the output of this command on your system? Mine is: libfontconfig.so.1 (libc6,x86-64) => /lib/x86_64-linux-gnu/libfontconfig.so.1 ... while |
Also, what is the output of this address? |
{"kind":"fontconfiguration","server":"Myserver (https://mycloud.tv)","fonts":[]} |
I'm on a shared host. Sorry. |
Ok, thank you anyway for tryit it out. Then, maybe another library is still missing. 🤔 |
@timar We wrote a guide how to install Collabora Online & Built-In CODE on a fresh installed Ubuntu Server 22.04 LTS on x86_64 devices. This should be the same for ARM64. Please, follow my steps here and you will be able to reproduce and debug the issue, I'm 100% sure!
I hope you can take you the time, there are many users affected. Please try my guide on a ARM64 VM or device. Thanks in advance! :) |
Exact same issue here too - let me know if I can help test anything! |
Some extra notes... Arm64 Ubuntu 22.04.3 LTS VM (Parallels on Mac M1 host) - latest Nextcloud Snap.
I tried editing Proxy.php as mentioned in #226 (comment) but this did not work - although, I question my changes were loaded. After editing the file, how can I ask NextCloud to ensure it is using my modifications? @Jolopu I also ensured all packages were installed... I see green ticks in admin confirming server is reachable, but creating and opening a new ODT file shows an infinite spinning wheel. I am here for assistance if needed and would love to help. |
Arm64 support has been broken for months. Readme has been updated to reflect this. This is the honourable thing to do, otherwise users will waste their time assuming it is supported, when it is not. See CollaboraOnline#226
I don't think its fair users are wasting time assuming they or their devices are at fault when in reality, arm64 simply isn't supported for last few months. Even if issue is fixed someday, I believe updating the readme until the issue is fixed is the minimum fair thing to do, to avoid users wasting hours of time today. |
Can you tell me more about how you tested this please? |
@LMRW I understand your frustration, and I'm sorry for the problems. I tried the app with nexctcloud docker on arm64 host and it worked. So it's not entirely broken.
Then I tried snap as suggested by @Pilzinsel64
WTF?! This is unexpected. I installed the arm64 version.... Hmm, that is also there, in richdocumentscode_arm64 folder. Manually starting the AppImage lead to success...
Something may be wrong with the nextcloud snap. |
@timar Thank you very much for trying thisa out! Well, the result is unexpected for me. 🤔 The only idea I have could be a missing or wrong dependency. What exactly has changed in-between this both version (23.5.5 and 22.05.1301) regarding dependencies? Edit: I just see that it tries to start the x86_64 version and not the arm64 version.Do you have installed both? (Maybe "recommended apps" installed the non-arm64 version) |
As a point of interest this appears to be an issue with NextCloud not running the code server rather than with the code server itself. Running the following locally on the server will start up the code server and allow a NextCloud snap to connect to it with no issues:
I am able to create, edit, save, and reopen files without any issues. To note, I have run the following in an attempt to make things work but it does not seem to have made a difference:
Digging a bit deeper this appears to be where it is crashing on startup in the proxy.php file. It would appear that something is pssing 'ui_theme=light' when it should be passing a 'status' or 'req=...' parameter. Will update if I find when this issue was introduced:
|
Ok, I think I have the when and why it started breaking now. This nextcloud/richdocuments#2964 pull request was just before everything started breaking. It included this commit nextcloud/richdocuments@e192ccf . This introduced a new uiTheme that they appear to render and extract ui_theme from which is why it doesn't show up in searches. They seem to be using some new system to pass this information to the code server. I am not well versed enough in NextCloud development to attempt a fix currently but hopefully this at least helps get things started. |
A few further updates, as a temporary measure commenting out this else clause will allow the program to continue at least. It then fails silently on the launch command:
With some trial and error it turns out that both the FUSE and non-FUSE commands are failing in the snap environment. The FUSE version works when run as a normal linux user but fails in the snap environment. It functions even if running the exact command as a normal use. The non-FUSE version fails with a glibc error. My first thought is trying to fix the FUSE error first since it is probably just a configuration issue for the arm64 build. The non-FUSE issue is similar to what has been seen above and I am not sure how to go about fixing it. Here is the FUSE only code error:
Here is the non-Fuse information:
|
In Nextcloud snap However, for me on my amd64 devices it worked to install that libraries manually via |
Theoretically this is true, but snap does some weird stuff. It is very poorly documented but unless the no-system-libraries build attribute is used snapcraft will pull any libraries from the system that it can find that it has marked as needing. Here is the documentation as such and here is an example of someone having issues on different project due to it. From my understanding the first issue that caused problems came from the change with ui_theme being passed, and my far less certain but not entirely unfounded guess is that in the meantime the build environment changed. Without knowing what the environment looked like for builds that did work I can't confidently say that snapcraft wasn't pulling in either the fuse or glibc libraries from the build environment. One way or another one of the two libraries are likely required to get it working again along with handling the ui_information better than just discarding all errors. P.S. no-system-libraries may have been removed at some point but the snapcraft documentation search is down for me at the moment so I can't verify it unfortunately. If for some reason it was removed that could possibly explain that set of issues. |
I think I found where the other issue began, I haven't been able to confirm it or look into a fix yet but this commit was made just before v23.5.5 and moved the docker build system from Ubuntu 18.04 to DebianSlim. Given that the nextcloud snap runs on core18 it should have had full compatibility with the old docker builder. Why it only broke on arm64 and not x86_64 is yet to be determined but it seems pretty likely that it has something to do with this. They have a couple libraries that are prebuilt in their docker container if the documentation is up to date. I am not sure why snap seems to act different in this case on different architectures but it appears at the point poco and libc6 were built DebianSlim had slightly newer versions than core18. Unfortunately this is still all kinda in the "why is this happening" rather than a fix, hopefully I can find something about path usage on different architectures but I don't know if that documentation will exist. Edit: |
Ok, think I have enough evidence now. There is very little doubt that the zlib and poco libraries were built in differently configured systems,. The arm64 version requires glibc to be at 2.28 as is reported by my own install. On the other hand the x86_64 build only requires 2.25. I checked by downloading the current appimage build and examining the coolwsd requirements after manually extracting it. Here is the report for the x86_64 version:
And here is the report for the arm64 version:
I used this guide to find the command to list glibc dependencies. As you can see x86_64 only requires up to 2.25 which is met by the 2.27 library provided by core18. On the other hand the arm64 requires 2.28 which can not bet met. As stated above the FUSE command can't work without the snap interface for it but there is no plan to support that as per this. This leaves two main options, either moving the nextcloud-snap to core20 or above or shipping a prebuilt glibc with this plugin for arm64 users. I understand that the bump to core20 is not likely in the near future and shipping glibc is not anywhere near optimal. Mostly leaving this here for documentation, I don't really have much expectation that this will be fixed in the near future. This does bring up an interesting other point though, which is why I went ahead and confirmed my suspicions. If collabora ever has an issue with the zlib and poco libraries there is a strong chance that they will be rebuilt and it will stop working on all builds based around ubuntu 18.04. Depending on when this occurs it could even break on much newer bases since they are using Debian stable as the basis of their docker build environment. Given that it hasn't been updated in over half a year this probably isn't going to be a common issue but is probably worth considering if someone does decide to create a fix for this. I am probably going to move to using containers for my nextcloud install since I really would like collabora support so I may or may not be able to test easily if a fix is introduced. P.S. it is quite likely that #246 is based on this issue as well. I don't have a CentOS 7 machine to test it on at the moment but it seems to be a very similar issue. |
This has been broken for over one year for arm snap users, maybe consider updating the readme until it is resolved? I made a PR Many users are wasting time assuming this should work when a simple readme note might save them hours |
Issue
I'm using the app Collabora Online Built-in CODE (arm64). Since the last update (v23.5.5) the CODE server seems to have problems to start.
When downgrading to the previous version (v22.5.1301) and trigger everything works fine again.
But I need to do the downgrade each time the server restarts (basically every night) now since there is no possibility to disbale auto-updates in the snap packages.
Log
There isn't any new entry in the Nextcloud log. If you want the log anyway, please tell me.
System report
Link: https://dragoncloud.ddnss.de/index.php/s/XFe5CdWLnyBC5nf
Passwort:
cBKcRkWcNs
Environment infos
The text was updated successfully, but these errors were encountered: