Svxlink problem running in read only FS in latest build

[sa2blv]

The issue is that Svxlink attempts to change the ownership of a folder at startup. This operation is not permitted on a read-only file system.

-- Subject: A start job for unit svxlink.service has begun execution -- Defined-By: systemd -- Support: https://www.debian.org/support

-- -- A start job for unit svxlink.service has begun execution.

-- The job identifier is 1602. Nov 02 22:06:11 SK3RIN sh[1109]: chown: changing ownership of '/var/lib/svxlink': Read-only file system Nov 02 22:06:11 SK3RIN systemd[1]: svxlink.service: Control process exited, code=exited, status=1/FAILURE -- Subject: Unit process exited -- Defined-By: systemd -- Support: https://www.debian.org/support

-- An ExecStartPre= process belonging to unit svxlink.service has exited.

-- The process' exit code is 'exited' and its exit status is 1. Nov 02 22:06:11 SK3RIN systemd[1]: svxlink.service: Failed with result 'exit-code'. -- Subject: Unit failed -- Defined-By: systemd -- Support: https://www.debian.org/support

[f5vmr]

In my experience there is no need to run svxlink in a read only system. I have nodes that have run successfully for at least three years. I am using Svxlink-server ver 24-02.1 svxlink v.1.8.0.

Chris g4nab

On Sat, 2 Nov 2024 at 21:13, Peter @.***> wrote:

The issue is that Svxlink attempts to change the ownership of a folder at startup. This operation is not permitted on a read-only file system.

-- Subject: A start job for unit svxlink.service has begun execution -- Defined-By: systemd -- Support: https://www.debian.org/support

-- A start job for unit svxlink.service has begun execution. -- The job identifier is 1602. Nov 02 22:06:11 SK3RIN sh[1109]: chown: changing ownership of '/var/lib/svxlink': Read-only file system Nov 02 22:06:11 SK3RIN systemd[1]: svxlink.service: Control process exited, code=exited, status=1/FAILURE -- Subject: Unit process exited -- Defined-By: systemd -- Support: https://www.debian.org/support -- An ExecStartPre= process belonging to unit svxlink.service has exited.

-- The process' exit code is 'exited' and its exit status is 1. Nov 02 22:06:11 SK3RIN systemd[1]: svxlink.service: Failed with result 'exit-code'. -- Subject: Unit failed -- Defined-By: systemd -- Support: https://www.debian.org/support

— Reply to this email directly, view it on GitHub https://github.com/sm0svx/svxlink/issues/685, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAKA5GBGB5YC5G4WHY7TX3Z6U57PAVCNFSM6AAAAABRCB4QBCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGYZTANZZHAYDCMA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[sa2blv]

Hi F5vmr, the issue becomes more challenging when nodes are deployed at remote sites that are accessible only part of the year due to factors like deep snow or difficult terrain. Over the past few years, we’ve attempted to operate repeaters continuously (24/7) using standard SD cards, but we've encountered multiple failures. These failures are often linked to the limitations of the SD card’s flash memory, where repeated write operations lead to wear.

When the filesystem switches to read-only mode, it restricts Linux applications from performing write operations on specific sectors, which can stabilize the embedded system temporarily. However, the need for persistent data logging and consistent uptime suggests we may need a more robust, industrial-grade storage solution or a write-reduction strategy (e.g., logging to RAM with periodic flushes to disk) to maintain long-term stability in these challenging environments.

[f5vmr]

Ok understood. In 15 years of svxlink, I have had only two real failures, but this has been to the user of inferior brands and speeds. A10 cards of well known brands have been very successful. These days, I have tended to use 16 gB cards. It is certainly frustrating if a remote repeater suffers a failure.

At this time I use version 24.02-1 of svxlink-server, that has been carefully archived in a repository accessible by a key, so that it can be installed on bookworm by apt. This is not currently possible with the ordinary apt as version 19-02 gets installed. The new version that is available on the GitHub still requires compiling, and the security features are still being appraised, but I do like the Talk-Group features and GPIOD on ver.24, that are not available on version 19. We have a couple of Swedish stations on svxportal-uk.ddns.net:81 that seem not to fail.

73 Chris

On Sat, 2 Nov 2024 at 22:34, Peter @.***> wrote:

Hi F5vmr, the problem is bigger when the nodes are located at sites that are only accessible some parts of the year due to deep snow or difficult-to-reach locations. In recent years, we have tried running repeaters 24/7 using ordinary SD cards, but some have failed. The read-only file system prevents Linux applications from writing repeatedly to sectors on the card, which increases stability for the embedded system.

— Reply to this email directly, view it on GitHub https://github.com/sm0svx/svxlink/issues/685#issuecomment-2453213703, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAKA5FKNXHBH6ANC5CZZ6DZ6VHQBAVCNFSM6AAAAABRCB4QBCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJTGIYTGNZQGM . You are receiving this because you commented.Message ID: @.***>

[sm0svx]

The /var/lib/svxlink directory need to be writable in the newest versions of SvxLink. There are a couple of solutions you can try.

One obvious solution is to mount a r/w partition from your SD-card at /var/lib/svxlink. If you don't want that, you can use a tmpfs instead. The only file that you need to have persisted is the key-file. The CSR will be autogenerated on each reboot and the certificate will be downloaded from the reflector. But the key-file must not change so put that in /etc/svxlink/pki/ for example and set CERT_KEYFILE to point to the path of the key-file.

You can generate a unique keyfile by just starting svxlink once with CERT_KEYFILE set to a writable location.

[sm0svx]

A note on secutity. You may also want to put the ca-bundle.crt file in /etc/svxlink/pki so that it does not have to be downloaded on each start (MITM-problem). It's not necessary but will increase security. You then also need to add the following to the configuration:

CERT_CAFILE=/etc/svxlink/pki/ca-bundle.crt
CERT_DOWNLOAD_CA_BUNDLE=0

The downside of making the CA bundle file read-only is that it cannot be updated by the reflector server. CA bundle updates should be very rare so it should not be a problem, even if your node is not reachable part of the year.