The ARM Version of TOS 7 Public Beta is Now Officially Available

[Frynes]

I have had my struggles getting my F4-212 to run stable. It is still not perfect, however, it is working well enough for my use case. I, with the help of Claude CLI, have done pretty extensive troubleshooting on the 5.1.73 version of TOS. I would not mind upgrading to an improvement and there are some specific issues that are outstanding on my F4-212. Is it possible to respond whether the following issues have been addressed on TOS7?

# TOS 7 ARM Beta — upgrade criteria

What needs to be true before upgrading from TOS 5.1.73.

## What "better base system" actually means for us

TOS 7 brings Ubuntu 22.04, systemd, kernel 6.8.9, and apt. In practice, for our specific problems, this provides better tooling for diagnosing the same issues — not fixes for them. The crashes appear to be in TerraMaster's application layer (TOSDaemon, samba VFS stack, service initialization), which carries forward to TOS 7. Evidence: xzil3d reported the identical lockup pattern (ping alive, services dead) on TOS 7 x86 with kernel 6.8.9, and the nginx boot race condition also exists in TOS 7 despite systemd. A newer kernel would matter if the bug was in md/RAID, ext4, or the SATA driver — but the TOS 7 crash reports suggest it isn't.

## Current kernel: 5.10.107

Realtek RTD1619B BSP, built Aug 2023 with GCC 8.2. Approximately 83 point releases behind the 5.10.x LTS branch at the time it was built. Known gaps:
- ext4/jbd2 journal deadlock bugs fixed in 5.10.150+
- libata error recovery limitations that can escalate AHCI port resets to full controller hangs
- Page reclaim codepath bugs under swappiness=0 conditions
- No `CONFIG_DETECT_HUNG_TASK` compiled in (can't detect stuck processes)
- No `netconsole` module compiled (can't capture kernel output during lockup)
- CMA (contiguous memory allocator) bugs fixed in later releases

TOS 7 ships kernel 6.8.9 which would include all of these fixes. However, xzil3d's identical crash on TOS 7 x86 suggests the lockup may not be kernel-version-specific.

## Problems that TOS 7 would need to fix

### 1. Filesystem lockup from idle
The NAS wedges with no warning — CPU idle, memory available, SMART clean, no kernel panic. All I/O to the RAID5 volume stops. Only fix is power cycle. This has happened repeatedly on TOS 5.1.73.

### 2. TOSDaemon memory leak
TOSDaemon grows ~6MB/day and never releases memory. On a 2GB system this eventually becomes a problem. TOS 7 presumably ships a rewritten TOSDaemon. Needs confirmation that the leak is gone.

### 3. Volatile logs
All logs on TOS 5 are on tmpfs and lost on power cycle. We built custom persist scripts to work around this. TOS 7 with Ubuntu 22.04/systemd should have journald with persistent storage by default. Needs confirmation.

### 4. No netconsole
The TOS 5 kernel doesn't compile the netconsole module, so there's no way to capture kernel output during a lockup. TOS 7 with Ubuntu base and developer mode should allow installing kernel modules or the module may already be included.

### 5. No working NTP daemon
The TOS 5 UI has a "Sync with server" option pointing at `pool.ntp.org`, but `ntpd` doesn't actually run as a persistent daemon. The clock only syncs on boot or when you manually click Update. We added a cron entry to run `ntpdate` every 6 hours as a workaround. TOS 7 with Ubuntu/systemd should have `systemd-timesyncd` or `chrony` for proper continuous time sync — needs confirmation.

### 6. ter_smartfan / disk sleep
`ter_smartfan` runs every ~60 seconds trying to call `hdparm` to put drives to sleep. We renamed the `hdparm` binary to prevent disk sleep (drives should never sleep on a single-user NAS — wake-up delays make files unavailable for minutes). The daemon still runs and logs errors in a loop. TOS 7 still has disk sleep management issues — an x86 user (luismartin) reported the sleep timer got stuck at 10 minutes and couldn't be changed. No evidence TOS 7 fixes this. Our current workaround (renamed `hdparm` binary) would not carry over to TOS 7 — the disk sleep mechanism would be different (systemd-based) and would need a new workaround.

[TMzethar]

Hi, since TOS 5.1.73 arm is a version from a long time ago, and since then TOS6 Arm Beta and TOS7 Arm Beta have been released, we need to spend some time trying and confirming before we can reply to you
The known situation is
Reply ### 3.The logs will still be placed in tmpfs, so as not to affect HDD hibernation. When you enable Debug mode, the logs will be persistently written to the Volume
Reply ### 4.TOS7 Arm Beta also supports Debug mode, which can be used to capture the output kernel information during a crash.

[Frynes]

Thanks. I appreciate the answers so far!

I imagine I am not the only f4-212 sitting at TOS 5.1.73 with these issues. If there was a way forward in TOS 5, I would definitely have tried it.

[Frynes]

Sorry to bomb the forum with questions, but I just got around to looking at this update...

Downloading and snooping the package a bit, it looks like this is shipping with kernel 5.10.107 rather than the current 6.8.9 kernel. Any intention to bring the ARM version of TOS forward the latest kernel?

[Felix]

Hi,

1. Regarding the file system locking issue you mentioned during idle periods, we have not received any feedback yet. Device 212 in the lab has been stable for 20 days without any related issues.


5. Regarding the lack of NTP service, we have updated the relevant daemons. Automatic time synchronization can now be achieved.

6. Regarding ter_smartfan/disk sleep, the user setting you mentioned is a configuration issue. We have verified that the hibernation time can be modified.

[TMzethar]

Reply ### 2. The newly refactored version will not have this issue
If you unfortunately discover it again, please let us know.
Reply ### 6. We are currently optimizing the disk hibernation feature in TOS 7. We have already identified this issue and fixed it in the new version. Thank you for your feedback.

[Frynes]

Thanks for the feedback so far.

1. With respect to the system lockup while idle, it appears that is a result of my UPS failing a selftest and signaling LOWBAT to the NAS which then goes into safemode. This happens even when the UPS is still on MAINS. It is documented elsewhere. I put a wrapper on upssched-cmd to work around this for now.

5. Good for NTP service add.
6. The disc sleep/hibernation issue became apparent when I attempted to set sleep to NEVER.

2. Good news on the memory leak.

What about the kernel...is that going to freeze at version 5.10.107?

Thanks!

[Lukin]

Hello

For about two days now, my NAS has been using an excessive amount of RAM. All applications are disabled, but my NAS continues to use 65% of the RAM. Most of the RAM usage comes from Tos Daemon, which is being used by Tos Daemon 146mb.
https://ibb.co/NdgmKBKN

[Felix]

Thanks for the feedback so far.

1. With respect to the system lockup while idle, it appears that is a result of my UPS failing a selftest and signaling LOWBAT to the NAS which then goes into safemode. This happens even when the UPS is still on MAINS. It is documented elsewhere. I put a wrapper on upssched-cmd to work around this for now.

5. Good for NTP service add.
6. The disc sleep/hibernation issue became apparent when I attempted to set sleep to NEVER.

2. Good news on the memory leak.

What about the kernel...is that going to freeze at version 5.10.107?

Thanks!

Regarding the questions you raised, here are our unified responses:
* UPS Compatibility: We suggest you check the "UPS Compatibility List" on this forum; you can usually find a suitable solution there.

* Hard Drive Hibernation Issue: To more accurately pinpoint the fault, we would like to confirm whether this issue first appeared after upgrading to TOS7, or whether it has always existed in previous versions?

* Kernel Update: Due to hardware limitations, it is currently impossible to effectively update the kernel to the latest version. Therefore, there are no related upgrade plans at this time. We apologize for any inconvenience.

[Felix]

Hello

For about two days now, my NAS has been using an excessive amount of RAM. All applications are disabled, but my NAS continues to use 65% of the RAM. Most of the RAM usage comes from Tos Daemon, which is being used by Tos Daemon 146mb.
https://ibb.co/NdgmKBKN

It's normal for the TOS Daemon to use 146MB of memory. Roll, as you described, all programs have been disabled. However, in the screenshot you provided, I found that related processes such as TFM_Backup are still running. You can check if they are completely disabled and if snapshots, media indexing, and other related functions are enabled. Please check again.