Testing dotNET *arr packages with ARMv7 archs #5574
Comments
|
Package tested: Sonarr, Radarr and Lidarr for armv7.7.1 |
|
on DS115j (armada370) with |
|
BTW: |
Thanks for the feedback. Yes, I am aware of this however I have two users now (one on EDIT: I've confirmed in the specifications that the |
|
As discussed on the Servarr discord, the synocommunity packages may fail even if the CPU supports vfpv3-d32 because the dsm system libraries are too old. The workarounds in the servarr package are required. Rehashing the fact that the synocommunity packages are broken isn't super helpful... |
|
I can confirm Sonarr v4 Beta 20230118-1 is running here for a week now on a DS414 (armadaxp) DSM 7.1.1-42962. Radarr installed and booted fine as we speak, didn't have time yet to have a better look. |
|
FYI For those unsupported or difficult architectures (I blame Synology for not having consistent lib versions, why they have to have different ones for different architectures is beyond me) @ta264 got them working with bubblewrap https://wiki.servarr.com/en/synology-packages and debian filesystem from docker https://github.com/Servarr/spksrc/tree/master/cross it requires some simple commands in the terminal to work however (root). |
|
IMHO it might be better to just integrate @ta264 's work rather than confuse users with 3 different ways to install *arr packages. synocommunity, docker and servarr. |
Thanks for the feedback. I do agree that much of the work done by the team at Servarr should be incorporated here. In my conversation on their discord I asked about the differences in the two regarding Lidarr and was advised that:
I then took another look at the In picking through the differences, many were insignificant including:
The major changes were seen in these scripts:
Granted my understanding of some of the differences in the files appearing to have major changes may be limited, the core difference seems to be the inclusion of bubblewrap for the SERVICE_COMMAND. This 'bubblewrap' seems to require very specific setup and according to their wiki, and in DSM7 some manual setup is required after installation. I am not clear on the exact function of the 'bubblewrap' but it seems to be effectively allowing packages in DSM7 to run with increased privileges, to be executed in a closer manner as they used to under DSM6. If this is the case, I am not sure this regression in security is the best approach. Personally, this presents some overhead on the end-user which they may not be comfortable with and would rather avoid. It also seems to apply this 'bubblewrap' for every architecture supported by the package even when not required (since we have shown via this issue that some archs do not require it). My thinking is thus that unless we have current evidence, we continue gathering current compatibility information on ARMv7 archs and update the list of archs we build for so as to not exclude older platforms which are in fact compatible with existing synocommunity builds. For archs which are confirmed as incompatible (like armada370), we can update the documentation and formally exclude these archs. |
|
Bubblewrap is the magic that makes the package work on older devices. If you strip that out you're just left with the synocommunity packages. There may be a handful of dsm 6 devices that don't currently require the bubblewrap workaround but I would wager they will need it when radarr moves to .NET 7 (already out) or 8 (out in November) Trying to maintain a list of which dsm6 devices do or do not need bubblewrap is a fools errand in my opinion. |
|
PS I suggest educating yourself on what bubblewrap is doing before making assumptions about its 'overhead' would be wise. It's the container used to run games on a steam deck. I don't think they'd be happy with unnecessary overhead, do you? |
|
@mreid-tt bubblewrap is the only solution for the ARMv7 archs to run dotnet core apps, and probably it is a solution for x86 (32-bit, evansport) too. The archs x64 (AMD64) and aarch64 (ARMv8) run dotnet (core) out of the box. IMHO it is only worth to investigate in a bubblewrap solution for armada38x archs. All other ARMv7 archs (and evansport) will soon be deprecated. So the remaining question is, whether armada38x archs run dotnet core apps out of the box or need bubblewrap. sometime ago I supported @ta264 to test bubblewrap with armada370 of my DS115j and at that time it did not work |
|
@mreid-tt Thanks very much for looking into this. RADARR TEST RESULTS: I did manual update through package manager with radarr_armv7-6.1_20230122-20.spk, but this did not update Radarr itself. I made a backup and uninstalled Radarr, then proceeded to install your package. It failed to start. Command line tests: /volume1/@appstore/radarr/share/Radarr/bin$ ./Radarr SONARR TEST RESULTS: Updated the package sonarr_armv7-6.1_20230122-1.spk through package manager which uninstalled the previous Sonarr install. Command line: /volume1/@appstore/sonarr/share/Sonarr/bin$ ./Sonarr Anything I can provide to assist? |
|
@AnonTester, thanks for the feedback. It is curious that a fresh install of the test package of Radarr as well as Sonarr v4 both fail to run on your DS414. Earlier reports from @lajuffermans indicated that he was running the exact same packages successfully on his DS414 (armadaxp). The only difference I can detect is that he is running DSM 7.1.1-42962 whereas you are running DSM 6.2.4-25556 Update 6. With regard to your indication that Radarr was working up to the internally updated version 4.0.0.5503, I do wish to know what version of dotNET is deployed with this version. I see in a release just after that one (4.0.0.5745), one of the changes listed was "Upgrade to .NET 6". I was curious if the version that was running for you was perhaps an older dotNET 5? With regard to the Sonarr v4 upgrade, yes it is designed to uninstall your previous Sonarr v3. Did you create and download a backup of the configuration? If not there may be a way to manually move the AppData to a safe place and then re-install Sonarr v3. Let me know if this is needed. |
|
This is a well known issue. Glibc on dsm6 for that arch is too old for .net 6 which radarr uses (it's bundled with radarr, you don't need the .net 6 Synology package). Bubblewrap is required in this case. Most non x64 devices on dsm6 require bubblewrap. |
|
@mreid-tt I made full tar backups of both my radarr and sonarr installs before starting the test, all good and nothing lost. thanks. I'm back running Radarr 4.0.0.5503 .NET and Sonarr 3.0.9.1549 Mono 5.20.1.34. As for Radar, 4.0.0.5503 it is using .NET 5.0.10 as per System info. |
Thanks for the comments. I will defer to those more versed in this topic since it was not clear to me exactly how 'bubblewrap' fixed dotNET core apps. There is discussion in its readme on 'user namespaces' and 'sandboxing' but these seem to be related to privileges whereas other comments suggest a deficiency in DSM itself.
Hmm, this is indeed a consideration. At the same time though we do have users on these older devices which still run DSM6 rather than upgrading to DSM7 so it may be worth considering builds for this reason even if they can't go to DSM 7.2. I guess what may need more clarity is the deprecation schedule for SynoCommunity packages and if there should be a standard for matching with Synology DSM compatibility.
I guess some more data may be needed for this. Initial tests from @BenjV confirmed all test packages ran successfully on his DS116 (armada38x). However he was running DSM 7.1.1-42962 and based on recent feedback from other users this may not be the case under DSM6.
Based on the issue reported for this platform the limitation was the VFP3-16 FPU but as I learn more about dotNET core there are many other nuances which may come into play. It would be nice to have a better understanding of all the factors which affect dotNET core compatibility. That way a matrix of sorts can be created. |
|
@mreid-tt If @lajuffermans can confirm both work fine with some more testing, I'm willing to risk upgrading. However, I could also stay on DSM6 for a while longer to assist testing if this would be helpful. |
Thanks for confirming 'bubblewrap' as the key ingredient that makes compatibility with older devices possible. This was not clear to me from our discord chat which is why I looked into it myself. What is still not clear though is how it does what is does. I'm not very comfortable with terms like magic and would prefer a clear and logical perspective on what it does specifically for dotNET core apps on DSM.
I appreciate your perspective on this and I thank you for sharing your opinion.
My comment on the overhead is with regard to the user experience documented in your wiki page which seems to require DSM7 users manually create a scheduled task to fix restrictions in DSM 7.0+. Many non-technical users would much rather have a package just install and run without tinkering. I was not suggesting any technical or efficiency limitation of containers since I am not in a position to make that assertion. |
|
Ok I downloaded this https://github.com/SynoCommunity/spksrc/suites/10511877481/artifacts/521921554. |
|
hey @mastervol, thanks for the comment. If you already had Radarr installed then installing a new package will not replace the binaries. This is done so as not to disturb any existing configurations and let the internal updater handle the updating. If you want to test Radarr specifically, you will need to perform and download a backup of your configuration, uninstall Radarr and then re-install it. While the process is not too difficult, I would not recommend this if you are not comfortable with the process. Alternatively, if you wish you can try another one of the packages for a clean install to get the test results. If you do, please leave a comment with your details and any other observations (see notes in the description above). Appreciate your assistance in helping us get feedback on ARMv7 platforms running dotNET 6 core packages. |
|
DSM: DSM 7.1.1-42962 Update 1 So I uninstalled the radarr app from the package center and reinstalled it along with your additional files. Radarr app: Klicked on the update button within radarr app. /volume1/@appdata/radarr/.config/Radarr/logs# tail radarr.txt It then took a while (~5 mins) for the update process to complete but - hey - it worked. Great. Radarr app reports now: Looking good! UpdateLog: Maybe this procedure for Radarr also works for Readarr? |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@mastervol thanks for the feedback. While you didn't use the package included at the top of this issue, you did test successfully and confirm that the dotNET 6 core in Radarr v4 works on your platform. As for Readarr, this package is not yet released. If you have feedback you can put it under the PR (#5110) for that. |
@ta264, apologies if this was covered elsewhere but can you expand the history of the versions that use mono? I was working on an update for Jackett recently and I see they build a number of releases including one for Mono. The framework then just incorporates this one when building a package which seems simple enough. I don't know the demand for SPK packages on older NAS units but I am thinking of looking more into this once the current rounds of dotnet testing is done. For this, I was considering whether bringing back mono versions would make sense or if bubblewrap is the best way to go. Seeking your input on the pros/cons of either direction. |
|
After two months of testing I believe we can close this |
|
Adding to this thread based on testing by @russholio: Package tested: Radarr (20230216-19) This is despite the CPU info containing the |
|
Based on another post, the |
|
Package tested: Radarr v4 Package tested: Sonarr v4
|
|
@Po352 thanks very much for testing the packages on |
I have noted some comments regarding excluded ARMv7 archs for *arr packages (Sonarr, Radarr, Lidarr) which suggest that these architectures may not actually be incompatible. In fact, based on the source code, many of these architectures are listed as not fully tested for dotNET.
I would like to solicit support for explicit testing of these packages on ARMv7 archs. Specifically, these include
alpine, alpine4k,armada370, armada375, armada38x, armadaxp, monaco and comcerto2k. My suspicion is that these archs may be affected by specific dotNET versions. Given that a number of the newer *arr releases have updated their included dotNET binaries, I'd like some assistance from the community in narrowing down which versions work and which do not.If you'd like to assist with this effort I'd be very grateful for your feedback. As there is a lot to test, please keep your feedback brief. Do include the specific model, the package you tested as well as any short error messages. While I do appreciate longer error messages and logs, I would ask that these be uploaded to a site like Pastebin.com and include only the link in your comment so that this thread does not get too long. A great comment example would be as follows:
With the community's help we can hopefully re-include these excluded ARMv7 archs in future dotNET *arr packages. To get started, you can download the ARMv7 packages for testing here:
Sonarr v4:
(DSM6) armv7-6.1, (DSM7) armv7-7.1, comcerto2k-7.1Radarr:
(DSM6) armv7-6.1, (DSM7) armv7-7.1, comcerto2k-7.1Lidarr:
(DSM6) armv7-6.1, (DSM7) armv7-7.1, comcerto2k-7.1Once you have downloaded the zip file, please unzip it to get to the included
.spkfile which you can use to perform a manual package install. Do remember to consult the Architecture per Synology model web page to verify the specific NAS architecture you have and whether it can be used for this test.Detailed Results: Synology ARMv7 CPUs
EDIT:
alpineandarmada370archs as well as running on DSM6 confirmed as incompatible with dotNET 6.The text was updated successfully, but these errors were encountered: