Testing dotNET *arr packages with ARMv7 archs

[mreid-tt]

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:

Package tested: Sonarr v4 NAS used: DS216se (armada370) DSM version: 7.1.1 Update 2 Installation status: failed to start Service log: https://pastebin.com/6GfvYRFH (/var/packages/sonarr/var/sonarr.log)

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.1 Radarr: (DSM6) armv7-6.1, (DSM7) armv7-7.1, comcerto2k-7.1 Lidarr: (DSM6) armv7-6.1, (DSM7) armv7-7.1, comcerto2k-7.1

Once you have downloaded the zip file, please unzip it to get to the included .spk file 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: alpine and armada370 archs as well as running on DSM6 confirmed as incompatible with dotNET 6.

[BenjV]

Package tested: Sonarr, Radarr and Lidarr for armv7.7.1 NAS used: DS116 (armada38x) DSM version: 7.1.1-42962 Installation status for all three : installed and runs , no intensive testing done yet

[hgy59]

on DS115j (armada370) with DSM 6.2.4-25556 Update 6 all three packages fail with segmentation fault:

ash-4.3# uname -a
Linux DS-xxxxxx 3.2.40 #25556 Thu Jul 1 14:30:20 CST 2021 armv7l GNU/Linux synology_armada370_ds115j

ash-4.3# tail radarr.log lidarr.log sonarr.log
==> radarr.log <==
2023/01/23 22:28:45     End service_clean_tmpdir
2023/01/23 22:28:45     Granting 'sc-radarr' unix ownership on /volume1/@appstore/radarr/var
2023/01/23 22:28:45     install radarr 20230122-20 End postinst ret=[0]
2023/01/23 22:28:45     install radarr 20230122-20 Begin /bin/rm -rf /volume1/@tmp/pkginstall
2023/01/23 22:28:45     install radarr 20230122-20 End /bin/rm -rf /volume1/@tmp/pkginstall ret=[0]
2023/01/23 22:29:07     install radarr 20230122-20 Begin start-stop-status start
/var/packages/radarr/scripts/start-stop-status: line 151: 25935 Segmentation fault      (core dumped) ${service} >> ${OUT} 2>&1
2023/01/23 22:30:41     install radarr 20230122-20 End start-stop-status start ret=[1]
2023/01/23 22:30:46     (system) trigger radarr 20230122-20 Begin start-stop-status stop
2023/01/23 22:30:46     (system) trigger radarr 20230122-20 End start-stop-status stop ret=[0]

==> lidarr.log <==
2023/01/23 22:37:42     End service_clean_tmpdir
2023/01/23 22:37:42     Granting 'sc-lidarr' unix ownership on /volume1/@appstore/lidarr/var
2023/01/23 22:37:42     install lidarr 20230122-12 End postinst ret=[0]
2023/01/23 22:37:42     install lidarr 20230122-12 Begin /bin/rm -rf /volume1/@tmp/pkginstall
2023/01/23 22:37:43     install lidarr 20230122-12 End /bin/rm -rf /volume1/@tmp/pkginstall ret=[0]
2023/01/23 22:38:11     install lidarr 20230122-12 Begin start-stop-status start
/var/packages/lidarr/scripts/start-stop-status: line 151:  7140 Segmentation fault      (core dumped) ${service} >> ${OUT} 2>&1
2023/01/23 22:39:45     install lidarr 20230122-12 End start-stop-status start ret=[1]
2023/01/23 22:39:47     (system) trigger lidarr 20230122-12 Begin start-stop-status stop
2023/01/23 22:39:47     (system) trigger lidarr 20230122-12 End start-stop-status stop ret=[0]

==> sonarr.log <==
2023/01/23 22:42:33     End service_clean_tmpdir
2023/01/23 22:42:33     Granting 'sc-sonarr' unix ownership on /volume1/@appstore/sonarr/var
2023/01/23 22:42:33     install sonarr 20230122-1 End postinst ret=[0]
2023/01/23 22:42:34     install sonarr 20230122-1 Begin /bin/rm -rf /volume1/@tmp/pkginstall
2023/01/23 22:42:34     install sonarr 20230122-1 End /bin/rm -rf /volume1/@tmp/pkginstall ret=[0]
2023/01/23 22:42:56     install sonarr 20230122-1 Begin start-stop-status start
/var/packages/sonarr/scripts/start-stop-status: line 151: 15052 Segmentation fault      (core dumped) ${service} >> ${OUT} 2>&1
2023/01/23 22:44:29     install sonarr 20230122-1 End start-stop-status start ret=[1]
2023/01/23 22:44:31     (system) trigger sonarr 20230122-1 Begin start-stop-status stop
2023/01/23 22:44:31     (system) trigger sonarr 20230122-1 End start-stop-status stop ret=[0]

[hgy59]

BTW: currently the following archs are defined not supported for dotnet in mk/spksrc.archs.mk:

DOTNET_UNSUPPORTED_ARCHS = $(PPC_ARCHS) $(ARMv5_ARCHS) $(ARMv7L_ARCHS) 
# .NET for x86 (32-bit) is supported on windows only (for linux, it must be built from source)
DOTNET_UNSUPPORTED_ARCHS += $(i686_ARCHS)
# ARMv7_ARCHS without full vfpv3 support (having only vfpv3-d16) are not supported
# issue #5315
DOTNET_UNSUPPORTED_ARCHS += armada370
# issue #5302
DOTNET_UNSUPPORTED_ARCHS += alpine
# issue #5089
DOTNET_UNSUPPORTED_ARCHS += monaco
# issue #4790
DOTNET_UNSUPPORTED_ARCHS += armadaxp

# compatibility with .NET not yet confirmed:
# alpine4k armada375 armada38x comcerto2k

[mreid-tt]

BTW: currently the following archs are defined not supported for dotnet in mk/spksrc.archs.mk:

Thanks for the feedback. Yes, I am aware of this however I have two users now (one on armadaxp and another on armada38x) who each confirmed that Sonarr v4 works fine on their NAS. It is the reason I lodged this issue, to source evidence from the community to help validate which archs are actually incompatible with current dotNET builds and which are not.

EDIT: I've confirmed in the specifications that the armada370 only supports VFP3-16 for its FPU. As this was noted as limiting factor for dotNET, your results above confirms this position. The other Marvell CPUs (armada38x and armadaxp) I've confirmed in the specifications support VFP3-D32. The remaining Marvell CPU (armada375) may support this too but the documentation is unclear.

[ta264]

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...

[lajuffermans]

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.

[publicarray]

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).

[publicarray]

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.

[mreid-tt]

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:

The lidarr app itself is the same The difference is in the packaging Synocommunities version doesn't work on older dsm

I then took another look at the .spk packages from both repositories. In considering Lidarr (and excluding things like the PACKAGE_ICON, WIZARD_UIFILES and the package.tgz -- app itself), I did find the following differences:

% diff -rq lidarr_official_1.0.2.2592-spk78_armv7-dsm7.0 lidarr.v10.f41890\[alpine4k-armada375-armada38x\]
Files lidarr_official_1.0.2.2592-spk78_armv7-dsm7.0/INFO and lidarr.v10.f41890[alpine4k-armada375-armada38x]/INFO differ
Only in lidarr.v10.f41890[alpine4k-armada375-armada38x]: LICENSE
Files lidarr_official_1.0.2.2592-spk78_armv7-dsm7.0/conf/privilege and lidarr.v10.f41890[alpine4k-armada375-armada38x]/conf/privilege differ
Files lidarr_official_1.0.2.2592-spk78_armv7-dsm7.0/conf/resource and lidarr.v10.f41890[alpine4k-armada375-armada38x]/conf/resource differ
Files lidarr_official_1.0.2.2592-spk78_armv7-dsm7.0/scripts/installer and lidarr.v10.f41890[alpine4k-armada375-armada38x]/scripts/installer differ
Files lidarr_official_1.0.2.2592-spk78_armv7-dsm7.0/scripts/postinst and lidarr.v10.f41890[alpine4k-armada375-armada38x]/scripts/postinst differ
Files lidarr_official_1.0.2.2592-spk78_armv7-dsm7.0/scripts/postuninst and lidarr.v10.f41890[alpine4k-armada375-armada38x]/scripts/postuninst differ
Files lidarr_official_1.0.2.2592-spk78_armv7-dsm7.0/scripts/postupgrade and lidarr.v10.f41890[alpine4k-armada375-armada38x]/scripts/postupgrade differ
Files lidarr_official_1.0.2.2592-spk78_armv7-dsm7.0/scripts/preinst and lidarr.v10.f41890[alpine4k-armada375-armada38x]/scripts/preinst differ
Files lidarr_official_1.0.2.2592-spk78_armv7-dsm7.0/scripts/preuninst and lidarr.v10.f41890[alpine4k-armada375-armada38x]/scripts/preuninst differ
Files lidarr_official_1.0.2.2592-spk78_armv7-dsm7.0/scripts/preupgrade and lidarr.v10.f41890[alpine4k-armada375-armada38x]/scripts/preupgrade differ
Files lidarr_official_1.0.2.2592-spk78_armv7-dsm7.0/scripts/service-setup and lidarr.v10.f41890[alpine4k-armada375-armada38x]/scripts/service-setup differ
Files lidarr_official_1.0.2.2592-spk78_armv7-dsm7.0/scripts/start-stop-status and lidarr.v10.f41890[alpine4k-armada375-armada38x]/scripts/start-stop-status differ
Only in lidarr.v10.f41890[alpine4k-armada375-armada38x]: syno_signature.asc

In picking through the differences, many were insignificant including:

1. The 'conf' files only having expected differences in username and package name
2. The 'INFO' file having expected differences in build names, change logs and versions, doc links as well as supported archs
3. The 'scripts' files (with the exception of installer, service-setup and start-stop-status) only differing in shell syntax

The major changes were seen in these scripts:

1. The 'installer' from synocommunity included an additional function syno_sync_var_folder which is called from the postinst and postupgrade functions but is not included in the servarr version
2. The 'service-setup' differing in a few areas including the approaches to retaining/replacing the app binaries as well as the servarr version including references to a 'bwrap' binary (included or as standalone package) which is then called from the SERVICE_COMMAND
3. The 'start-stop-status' differing in a number of areas in terms of logic approach and logging commands but seem similar in execution

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.

[ta264]

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.

[ta264]

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?

[hgy59]

@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. The next DSM generation (DSM 7.2) will only support x64, aarch64 and armada38x archs.

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

[AnonTester]

@mreid-tt Thanks very much for looking into this. I'm on DS414 armadaxp on DSM 6.2.4-25556 Update 6

RADARR TEST RESULTS: The last Radarr version that worked and has been working since is 4.0.0.5503 from base package armv7-6.1_20210311-15. Ever since that version the updater and the radarr.exe fail with segfault.

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: sudo /usr/syno/sbin/synopkgctl start radarr Password: ======== start radarr ======== Failed to execute '/var/packages/radarr/scripts/start-stop-status start' (err=1)

/volume1/@appstore/radarr/share/Radarr/bin$ ./Radarr Segmentation fault (core dumped)

SONARR TEST RESULTS: Current version running on my NAS is 3.0.9.1549 with Mono Version 5.20.1.34

Updated the package sonarr_armv7-6.1_20230122-1.spk through package manager which uninstalled the previous Sonarr install. It failed to start.

Command line: udo synopkgctl start sonarr ======== start sonarr ======== Failed to execute '/var/packages/sonarr/scripts/start-stop-status start' (err=1)

/volume1/@appstore/sonarr/share/Sonarr/bin$ ./Sonarr Segmentation fault (core dumped)

Anything I can provide to assist?

[mreid-tt]

@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.

[ta264]

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.

[AnonTester]

@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.

[mreid-tt]

@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.

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.

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. The next DSM generation (DSM 7.2) will only support x64, aarch64 and armada38x archs.

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.

So the remaining question is, whether armada38x archs run dotnet core apps out of the box or need bubblewrap.

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.

sometime ago I supported @ta264 to test bubblewrap with armada370 of my DS115j and at that time it did not work

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.

[AnonTester]

@mreid-tt dokuwiki and debian-chroot packages not available for DSM 7 held me back and the fear that I would not be able to use sonarr/radarr on it either. While I replaced dokuwiki with native webstation approach and moved what I used debian-chroot for to another system, other users may well be stuck at DSM6 for some other reason.

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.

[mreid-tt]

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)

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.

Trying to maintain a list of which dsm6 devices do or do not need bubblewrap is a fools errand in my opinion.

I appreciate your perspective on this and I thank you for sharing your 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?

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.

[mreid-tt]

@mreid-tt dokuwiki and debian-chroot packages not available for DSM 7 held me back and the fear that I would not be able to use sonarr/radarr on it either. While I replaced dokuwiki with native webstation approach and moved what I used debian-chroot for to another system, other users may well be stuck at DSM6 for some other reason.

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.

@AnonTester thanks for the feedback on your environment. As the purpose of this issue is to gather feedback only, do not feel pressured into upgrading your DSM if you are not ready to do so. It may be useful to remain on that version should continued discussion on this matter bring about solutions that work with your existing DSM version. If there is not a pressing reason, staying at DSM6 may also help with future testing since you can't easily downgrade DSM versions.

[ta264]

Bubblewrap allows you to create a container so we can use different system libraries. When in use, Radarr is running in a Debian container so new enough system libraries are present.

[BenjV]

As far as I can conclude from all the post is that on DSM 7 the package is working at least for some cpu versions but on the same cpu DSM 6 is a no go. I would suggest to leave it as it is and people who want/need DSM 6 must use an old version with uses mono and only support DSM 7 for the cpu's who are reported working.

Besides the DS116 on DSM7 I have also a DSM414 (ArmadaXp) that for now is running DSM 6, so if some other solution is found for DSM 6, let me know and I wil test it.

[ta264]

The wrinkle here is we don't offer support for out of date *arr, and certainly not for versions that use mono. But if your preference is to leave things as is, we can leave the servarr SPK packages available for users with devices the synocommunity packages don't work on.

[mreid-tt]

I would suggest to leave it as it is and people who want/need DSM 6 must use an old version with uses mono and only support DSM 7 for the cpu's who are reported working.

Hmm, interesting. If we were to consider this option and let's suppose that the outcome of this testing is that we confirm that dotNET 6 core apps only have issues on the following ARMv7 archs: all running DSM6 and armada370 (DSM6 or DSM7), how should we construct the Makefile?

I've only seen the ability to exclude an arch or set a minimum build version but I've not seen commands to be able to exclude archs on specific DSM versions. Any ideas for this thought experiment?

EDIT: I did eventually find a way to make that specific build exclusion and incorporated it into #5524, #5529, #5584 and #5587.

[mreid-tt]

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.

Thanks for this insight, I'm getting a clearer picture now of the nuances in supporting dotNET core apps. Just to confirm, I would imagine this limitation would also preclude having a separate .net 6 Synology package of any kind on ARMv7 archs running DSM6 correct?

With your expertise in dotNET, are there any other well known issues?

[ta264]

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.

Thanks for this insight, I'm getting a clearer picture now of the nuances in supporting dotNET core apps. Just to confirm, I would imagine this limitation would also preclude having a separate .net 6 Synology package of any kind on ARMv7 archs running DSM6 correct?

With your expertise in dotNET, are there any other well known issues?

I don't understand the question, sorry. It works if you include bubblewrap and a minimal Debian image in the package on dsm6. This is what the servarr packages for dsm6 do.

[mastervol]

Ok I downloaded this https://github.com/SynoCommunity/spksrc/suites/10511877481/artifacts/521921554. AFAIK it did publish some additional binaries which should be used when using the update button within radarr? I am currently on the latest version, so I guess I have to wait until there is a new release?

[mreid-tt]

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.

[mastervol]

DSM: DSM 7.1.1-42962 Update 1 Model name: DS216play CPU: STM Monaco STiH412

So I uninstalled the radarr app from the package center and reinstalled it along with your additional files.

Radarr app:

Version
3.2.2.5080
Package Version
armv7-7.0_20220515-18 by Team Radarr
.NET
Yes (5.0.5)
DB Migration
195
AppData directory
/volume1/@appdata/radarr/.config/Radarr
Startup directory
/volume1/@appstore/radarr/share/Radarr/bin
Mode
Console
Uptime

Klicked on the update button within radarr app.

/volume1/@appdata/radarr/.config/Radarr/logs# tail radarr.txt

2023-02-05 13:13:09.2|Info|CommandExecutor|Starting 2 threads for tasks.
2023-02-05 13:13:36.9|Info|InstallUpdateService|Downloading update 4.3.2.6857
2023-02-05 13:13:42.7|Info|InstallUpdateService|Verifying update package
2023-02-05 13:13:45.5|Info|InstallUpdateService|Update package verified successfully
2023-02-05 13:13:45.5|Info|InstallUpdateService|Extracting Update package
2023-02-05 13:14:09.3|Info|InstallUpdateService|Update package extracted successfully
2023-02-05 13:14:09.3|Info|BackupService|Starting Backup
2023-02-05 13:14:10.5|Info|InstallUpdateService|Preparing client
2023-02-05 13:15:03.6|Info|InstallUpdateService|Starting update client /volume1/@apptemp/radarr/radarr_update/Radarr.Update
2023-02-05 13:15:03.6|Info|InstallUpdateService|Radarr will restart shortly.

It then took a while (~5 mins) for the update process to complete but - hey - it worked. Great. See the update log file.

Radarr app reports now:

Version
4.3.2.6857
Package Version
armv7-7.0_20220515-18 by Team Radarr
.NET
Yes (6.0.8)
DB Migration
214
Database
Sqlite 3.34.1
AppData directory
/volume1/@appdata/radarr/.config/Radarr
Startup directory
/volume1/@appstore/radarr/share/Radarr/bin
Mode
Console
Uptime
00:01:20

Looking good! Thanks a lot.

UpdateLog:

2023-02-05 13:15:07.8|Info|UpdateApp|Starting Radarr Update Client
2023-02-05 13:15:09.8|Info|AppFolderInfo|Data directory is being overridden to [/volume1/@appdata/radarr/.config/Radarr]
2023-02-05 13:15:09.9|Debug|UpdateApp|Radarr process ID: 17670
2023-02-05 13:15:09.9|Debug|UpdateApp|Arguments:
2023-02-05 13:15:09.9|Debug|UpdateApp|  17670
2023-02-05 13:15:09.9|Debug|UpdateApp|  /volume1/@apptemp/radarr/radarr_update
2023-02-05 13:15:09.9|Debug|UpdateApp|  /volume1/@appstore/radarr/share/Radarr/bin/Radarr
2023-02-05 13:15:09.9|Debug|UpdateApp|  /data=/volume1/@appdata/radarr/.config/Radarr
2023-02-05 13:15:09.9|Debug|UpdateApp|  /nobrowser
2023-02-05 13:15:09.9|Debug|UpdateApp|Using executing application: /volume1/@appstore/radarr/share/Radarr/bin/Radarr
2023-02-05 13:15:09.9|Debug|UpdateApp|Executable location: /volume1/@appstore/radarr/share/Radarr/bin/Radarr
2023-02-05 13:15:09.9|Info|InstallUpdateService|Installation Folder: /volume1/@appstore/radarr/share/Radarr/bin
2023-02-05 13:15:10.0|Info|InstallUpdateService|Updating Radarr from version 3.2.2.5080 to version 4.3.2.6857
2023-02-05 13:15:10.1|Info|InstallUpdateService|Verifying requirements before update...
2023-02-05 13:15:10.1|Debug|ProcessProvider|Finding process with Id:17670
2023-02-05 13:15:10.3|Debug|ProcessProvider|Found process 17670:Radarr [/volume1/@appstore/radarr/share/Radarr/bin/Radarr]
2023-02-05 13:15:10.3|Info|InstallUpdateService|Verifying Update Folder
2023-02-05 13:15:10.3|Debug|ProcessProvider|Found 0 processes with the name: Radarr.Console
2023-02-05 13:15:10.4|Debug|ProcessProvider|Found 1 processes with the name: Radarr
2023-02-05 13:15:10.4|Debug|ProcessProvider| - [17670] Radarr
2023-02-05 13:15:10.4|Info|BackupAndRestore|Creating backup of existing installation
2023-02-05 13:15:10.4|Debug|DiskTransferService|Mirror Folder [/volume1/@appstore/radarr/share/Radarr/bin] > [/volume1/@apptemp/radarr/radarr_update/radarr_backup/]
2023-02-05 13:15:10.5|Debug|DiskTransferService|Mirror Folder [/volume1/@appstore/radarr/share/Radarr/bin/Localization] > [/volume1/@apptemp/radarr/radarr_update/radarr_backup/Localization]
2023-02-05 13:15:10.5|Debug|DiskTransferService|Mirror Folder [/volume1/@appstore/radarr/share/Radarr/bin/Localization/Core] > [/volume1/@apptemp/radarr/radarr_update/radarr_backup/Localization/Core]
2023-02-05 13:15:10.5|Debug|DiskTransferService|Copy [/volume1/@appstore/radarr/share/Radarr/bin/Localization/Core/hu.json] > [/volume1/@apptemp/radarr/radarr_update/radarr_backup/Localization/Core/hu.json]

etc.

2023-02-05 13:20:09.1|Debug|DiskTransferService|Copy [/volume1/@apptemp/radarr/radarr_update/Radarr/Radarr.Mono.dll] > [/volume1/@appstore/radarr/share/Radarr/bin/Radarr.Mono.dll]
2023-02-05 13:20:09.7|Debug|DiskProvider|Setting permissions: 755 on /volume1/@appstore/radarr/share/Radarr/bin/Radarr
2023-02-05 13:20:09.9|Debug|DiskProvider|Setting permissions: 755 on /volume1/@appstore/radarr/share/Radarr/bin/ffprobe
2023-02-05 13:20:09.9|Info|TerminateNzbDrone|Killing all running processes
2023-02-05 13:20:10.0|Debug|ProcessProvider|Found 0 processes with the name: Radarr.Console
2023-02-05 13:20:10.0|Debug|ProcessProvider|Found 0 processes to kill
2023-02-05 13:20:10.1|Debug|ProcessProvider|Found 1 processes with the name: Radarr
2023-02-05 13:20:10.1|Debug|ProcessProvider| - [17670] Radarr
2023-02-05 13:20:10.1|Debug|ProcessProvider|Found 1 processes to kill
2023-02-05 13:20:10.1|Debug|ProcessProvider|Killing process: 17670 [Radarr]
2023-02-05 13:20:10.3|Info|ProcessProvider|[17670]: Killing process
2023-02-05 13:20:10.3|Info|ProcessProvider|[17670]: Waiting for exit
2023-02-05 13:20:10.5|Info|ProcessProvider|[17670]: Process terminated successfully
2023-02-05 13:20:10.6|Warn|ProcessProvider|Cannot find process with id: 17670
2023-02-05 13:20:10.6|Info|InstallUpdateService|Waiting for external auto-restart.
2023-02-05 13:20:11.6|Debug|ProcessProvider|Found 0 processes with the name: Radarr
2023-02-05 13:20:12.6|Debug|ProcessProvider|Found 0 processes with the name: Radarr
2023-02-05 13:20:13.7|Debug|ProcessProvider|Found 0 processes with the name: Radarr
2023-02-05 13:20:14.7|Debug|ProcessProvider|Found 0 processes with the name: Radarr
2023-02-05 13:20:15.7|Debug|ProcessProvider|Found 0 processes with the name: Radarr
2023-02-05 13:20:16.8|Debug|ProcessProvider|Found 0 processes with the name: Radarr
2023-02-05 13:20:17.8|Debug|ProcessProvider|Found 0 processes with the name: Radarr
2023-02-05 13:20:18.8|Debug|ProcessProvider|Found 0 processes with the name: Radarr
2023-02-05 13:20:19.9|Debug|ProcessProvider|Found 0 processes with the name: Radarr
2023-02-05 13:20:20.9|Debug|ProcessProvider|Found 0 processes with the name: Radarr
2023-02-05 13:20:20.9|Debug|ProcessProvider|Found 0 processes with the name: Radarr
2023-02-05 13:20:20.9|Info|StartNzbDrone|Starting Radarr
2023-02-05 13:20:21.0|Info|StartNzbDrone|Starting Radarr
2023-02-05 13:20:21.0|Debug|ProcessProvider|Starting /volume1/@appstore/radarr/share/Radarr/bin/Radarr /data=/volume1/@appdata/radarr/.config/Radarr /nobrowser
2023-02-05 13:20:21.0|Info|UpdateApp|Update completed successfully

Maybe this procedure for Radarr also works for Readarr?

[mastervol]

Ok I tried also Readarr. Here I get the following error:

2023-02-05 13:46:33.2|Info|InstallUpdateService|Downloading update 0.1.2.1558
2023-02-05 13:46:46.3|Info|InstallUpdateService|Verifying update package
2023-02-05 13:46:52.3|Info|InstallUpdateService|Update package verified successfully
2023-02-05 13:46:52.3|Info|InstallUpdateService|Extracting Update package
2023-02-05 13:48:05.5|Info|InstallUpdateService|Update package extracted successfully
2023-02-05 13:48:06.2|Info|BackupService|Starting Backup
2023-02-05 13:48:30.5|Info|InstallUpdateService|Preparing client
2023-02-05 13:49:27.5|Info|InstallUpdateService|Starting update client /tmp/readarr_update/Readarr.Update
2023-02-05 13:49:27.5|Info|InstallUpdateService|Readarr will restart shortly.
2023-02-05 13:49:27.9|Info|InstallUpdateService|Updater Arguments: 29540 /tmp/readarr_update /volume1/@appstore/Readarr/Readarr
2023-02-05 13:49:29.3|Error|CommandExecutor|Error occurred while executing task ApplicationUpdate

[v0.1.2.1532] System.ComponentModel.Win32Exception (13): An error occurred trying to start process '/tmp/readarr_update/Readarr.Update' with working directory '/usr/syno/synoman/webapi'. Permission denied
   at System.Diagnostics.Process.ForkAndExecProcess(ProcessStartInfo startInfo, String resolvedFilename, String[] argv, String[] envp, String cwd, Boolean setCredentials, UInt32 userId, UInt32 groupId, UInt32[] groups, Int32& stdinFd, Int32& stdoutFd, Int32& stderrFd, Boolean usesTerminal, Boolean throwOnNoExec)
   at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start()
   at NzbDrone.Common.Processes.ProcessProvider.Start(String path, String args, StringDictionary environmentVariables, Action`1 onOutputDataReceived, Action`1 onErrorDataReceived) in D:\a\1\s\src\NzbDrone.Common\Processes\ProcessProvider.cs:line 196
   at NzbDrone.Core.Update.InstallUpdateService.InstallUpdate(UpdatePackage updatePackage) in D:\a\1\s\src\NzbDrone.Core\Update\InstallUpdateService.cs:line 166
   at NzbDrone.Core.Update.InstallUpdateService.Execute(ApplicationUpdateCommand message) in D:\a\1\s\src\NzbDrone.Core\Update\InstallUpdateService.cs:line 284
   at NzbDrone.Core.Messaging.Commands.CommandExecutor.ExecuteCommand[TCommand](TCommand command, CommandModel commandModel) in D:\a\1\s\src\NzbDrone.Core\Messaging\Commands\CommandExecutor.cs:line 111
   at CallSite.Target(Closure , CallSite , CommandExecutor , Object , CommandModel )
   at System.Dynamic.UpdateDelegates.UpdateAndExecuteVoid3[T0,T1,T2](CallSite site, T0 arg0, T1 arg1, T2 arg2)
   at CallSite.Target(Closure , CallSite , CommandExecutor , Object , CommandModel )
   at NzbDrone.Core.Messaging.Commands.CommandExecutor.ExecuteCommands() in D:\a\1\s\src\NzbDrone.Core\Messaging\Commands\CommandExecutor.cs:line 42

2023-02-05 13:50:29.8|Info|RssSyncService|Starting RSS Sync
2023-02-05 13:50:32.2|Info|DownloadDecisionMaker|Processing 199 releases
2023-02-05 13:50:36.1|Info|RssSyncService|RSS Sync Completed. Reports found: 199, Reports grabbed: 0

The directory in question is owned by root. I guess the update restart process is supposed to start with another working directory.

/var/services/homes/sc-readarr/.config/Readarr/logs# ls /usr/syno/synoman/ -l
total 56
drwxr-xr-x  2 root root  4096 Oct 16 14:00 DSFile
lrwxrwxrwx  1 root root    16 Oct 16 14:00 error.cgi -> webman/error.cgi
lrwxrwxrwx  1 root root    16 Oct 16 14:00 index.cgi -> webman/index.cgi
drwxr-xr-x  5 root root  4096 Oct 16 14:00 indexdb
drwxr-xr-x  4 root root  4096 Oct 16 14:00 mobile
-r-xr-x---  1 http http   207 Aug 25 11:50 redirect.cgi
-rw-r--r--  1 root root    26 Aug 25 11:50 robots.txt
drwxr-xr-x 15 root root  4096 Oct  7  2021 scripts
drwxr-xr-x  4 root root  4096 Oct 16 14:00 sharing
lrwxrwxrwx  1 root root    16 Oct 16 14:00 sharing.cgi -> webman/index.cgi
drwxr-xr-x  2 root root  4096 Jan  4 16:52 ssdp
drwxr-xr-x  3 root root  4096 Oct 16 14:00 synohdpack
drwxr-xr-x  3 root root  4096 Oct  7  2021 synoSDSjslib
drwxr-xr-x  4 root root 12288 Jan 22 19:19 webapi
drwxr-xr-x 14 root root  4096 Oct 16 13:59 webman

[mreid-tt]

@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.

[mreid-tt]

The wrinkle here is we don't offer support for out of date *arr, and certainly not for versions that use mono. But if your preference is to leave things as is, we can leave the servarr SPK packages available for users with devices the synocommunity packages don't work on.

@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.

[mreid-tt]

After two months of testing I believe we can close this

[mreid-tt]

Adding to this thread based on testing by @russholio:

Package tested: Radarr (20230216-19) NAS used: DS1517 (Alpine AL-314) DSM version: 7.1.1 Update 4 Installation status: failed to start (5590 Segmentation fault) Service log: https://github.com/SynoCommunity/spksrc/issues/5302#issuecomment-1487986989

This is despite the CPU info containing the neon vfpv3 vfpv4 features. This is definitive confirmation of the initial report from https://github.com/SynoCommunity/spksrc/issues/5089. The alpine processor will be marked as incompatible with dotnet 6 packages moving forward.

[mreid-tt]

Based on another post, the alpine4k arch will likely be incompatible as well since the CPU info is nearly identical:

> uname -a
Linux liloak-nas 3.2.40 #5592 SMP Wed Jul 29 14:39:21 CST 2015 armv7l GNU/Linux synology_alpine4k_ds215+

> cat /proc/cpuinfo
Processor : ARMv7 Processor rev 4 (v7l)
processor : 0
BogoMIPS : 2793.47

processor : 1
BogoMIPS : 2793.47

Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc0f
CPU revision : 4

Hardware : AnnapurnaLabs Alpine (Device Tree)
Revision : 0000
Serial : 0000000000000000

[Po352]

Package tested: Radarr v4 NAS used: DS416 Alpine4k DSM version: 7.1.1-42962 Update 6 Installation status: Successfully installed and running with test package created from radarr.v21.f42661 package

Starting radarr command env HOME=/volume1/@appdata/radarr /volume1/@appstore/radarr/share/Radarr/bin/Radarr -nobrowser -data=/volume1/@appdata/radarr/.config/Radarr
[Info] Bootstrap: Starting Radarr - /volume1/@appstore/radarr/share/Radarr/bin/Radarr - Version 5.6.0.8846 
[Info] AppFolderInfo: Data directory is being overridden to [/volume1/@appdata/radarr/.config/Radarr] 
[Debug] Bootstrap: Console selected 
[Info] AppFolderInfo: Data directory is being overridden to [/volume1/@appdata/radarr/.config/Radarr] 
[Info] AppFolderInfo: Data directory is being overridden to [/volume1/@appdata/radarr/.config/Radarr] 
[Info] MigrationController: *** Migrating data source=/volume1/@appdata/radarr/.config/Radarr/radarr.db;cache size=-20000;datetimekind=Utc;journal mode=Wal;pooling=True;version=3;busytimeout=100 *** 
[Info] FluentMigrator.Runner.MigrationRunner: DatabaseEngineVersionCheck migrating 
[Info] FluentMigrator.Runner.MigrationRunner: PerformDBOperation  
[Info] NzbDrone.Core.Datastore.Migration.Framework.NzbDroneSQLiteProcessor: Performing DB Operation 
[Info] DatabaseEngineVersionCheck: SQLite 3.34.1 
[Info] FluentMigrator.Runner.MigrationRunner: => 0.8935693s 
[Info] FluentMigrator.Runner.MigrationRunner: DatabaseEngineVersionCheck migrated 
[Info] FluentMigrator.Runner.MigrationRunner: => 0.9524737s 
[Info] MigrationController: *** Migrating data source=/volume1/@appdata/radarr/.config/Radarr/logs.db;cache size=-20000;datetimekind=Utc;journal mode=Wal;pooling=True;version=3;busytimeout=100 *** 
[Info] FluentMigrator.Runner.MigrationRunner: DatabaseEngineVersionCheck migrating 
[Info] FluentMigrator.Runner.MigrationRunner: PerformDBOperation  
[Info] NzbDrone.Core.Datastore.Migration.Framework.NzbDroneSQLiteProcessor: Performing DB Operation 
[Info] DatabaseEngineVersionCheck: SQLite 3.34.1 
[Info] FluentMigrator.Runner.MigrationRunner: => 0.0420761s 
[Info] FluentMigrator.Runner.MigrationRunner: DatabaseEngineVersionCheck migrated 
[Info] FluentMigrator.Runner.MigrationRunner: => 0.0428141s 
[Info] Microsoft.Hosting.Lifetime: Now listening on: http://[::]:8310 
[Info] CommandExecutor: Starting 2 threads for tasks. 
[Info] Microsoft.Hosting.Lifetime: Application started. Press Ctrl+C to shut down. 
[Info] Microsoft.Hosting.Lifetime: Hosting environment: Production 
[Info] Microsoft.Hosting.Lifetime: Content root path: / 
[Info] ManagedHttpDispatcher: IPv4 is available: True, IPv6 will be disabled

Package tested: Sonarr v4 NAS used: DS416 Alpine4k DSM version: 7.1.1-42962 Update 6 Installation status: Successfully installed and running with test package created from Sonarr.v21.f42661 package

Starting sonarr command env PATH=/volume1/@appstore/sonarr/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin HOME=/volume1/@appdata/sonarr /volume1/@appstore/sonarr/share/Sonarr/bin/Sonarr -nobrowser -data=/volume1/@appdata/sonarr/.config/Sonarr
[Info] Bootstrap: Starting Sonarr - /volume1/@appstore/sonarr/share/Sonarr/bin/Sonarr - Version 4.0.4.1491 
[Info] AppFolderInfo: Data directory is being overridden to [/volume1/@appdata/sonarr/.config/Sonarr] 
[Debug] Bootstrap: Console selected 
[Info] AppFolderInfo: Data directory is being overridden to [/volume1/@appdata/sonarr/.config/Sonarr] 
[Info] AppFolderInfo: Data directory is being overridden to [/volume1/@appdata/sonarr/.config/Sonarr] 
[Info] MigrationController: *** Migrating data source=/volume1/@appdata/sonarr/.config/Sonarr/sonarr.db;cache size=-20000;datetimekind=Utc;journal mode=Wal;pooling=True;version=3;busytimeout=100 *** 
[Info] FluentMigrator.Runner.MigrationRunner: DatabaseEngineVersionCheck migrating 
[Info] FluentMigrator.Runner.MigrationRunner: PerformDBOperation  
[Info] NzbDrone.Core.Datastore.Migration.Framework.NzbDroneSQLiteProcessor: Performing DB Operation 
[Info] DatabaseEngineVersionCheck: SQLite 3.34.1 
[Info] FluentMigrator.Runner.MigrationRunner: => 0.208563s 
[Info] FluentMigrator.Runner.MigrationRunner: DatabaseEngineVersionCheck migrated 
[Info] FluentMigrator.Runner.MigrationRunner: => 0.2205618s 
[Info] FluentMigrator.Runner.MigrationRunner: 193: add_import_list_items migrating 
[Info] NzbDrone.Core.Datastore.Migration.Framework.NzbDroneSQLiteProcessor: Beginning Transaction 
[Info] add_import_list_items: Starting migration of Main DB to 193

[mreid-tt]

@Po352 thanks very much for testing the packages on Alpine4k arch. This reverses a previous assumption I made regarding incompatibility. Will revise our builds moving forward.