TerraMaster Forum

What do these error messages mean? I have an F2-422 running TOS 7.0.0791.

We're looking into this further. We'll let you know as soon as we have something.
In the interim, have you experienced any operational anomalies?

I haven’t noticed anything so far.
If I don’t need the uart_key, I’d be happy to disable it, if that’s possible.

I tried to narrow down the error messages with Claude, and he then put together a report. Perhaps you’ll find it useful.

# Bug Report: uart_key crash loop on TOS 7.0.000 Beta

## Summary
On TOS 7.0.000 (build 2026-07-08), the helper process `uart_key` (spawned by
`TOSDaemon`) crashes immediately on every start and is respawned in an
infinite loop (multiple restarts per second), flooding the system journal.

## System Info
- TOS Version: **7.0.000**
- Build Time: **2026-07-08 08:38:36**
- CPU/Platform: Intel Celeron/Pentium/Atom Apollo Lake series (N3350/N4200/E3900)
- Network: Realtek RTL8153 USB-Ethernet adapter present (unrelated)

## Observed Behavior (journalctl -f)
```
TOSDaemon[2831]: resetkey: restarting uart_key
TOSDaemon[2831]: resetkey: uart_key exited err=exit status 1
```
Repeats continuously, several times per second.

## Additional warning seen in TOSDaemon output
```
2026/07/23 17:50:28 WARN read btrfs root subvols failed err="open /var/subvols: no such file or directory"
```
(Possibly unrelated to the uart_key issue, noting it in case it's relevant.)

## Diagnosis performed

**1. Manual run of the binary:**
```
$ sudo /usr/sbin/uart_key
Pls give tty file name and shell name
+++ exited with 1 +++
```
Running under `strace -f -e trace=open,openat,read` shows no `read()` call on
stdin before exit — the prompt text appears to be a static usage message, not
an actual interactive prompt.

**2. Running with explicit arguments:**
```
$ sudo /usr/sbin/uart_key /dev/ttyS0 /bin/sh
Open failed! Exit!

$ sudo /usr/sbin/uart_key --tty /dev/ttyS0 --shell /bin/sh
Open failed! Exit!
```
Both argument styles are accepted (no more usage prompt) but fail identically
at the `open()` step.

**3. Serial hardware check:**
```
$ cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:unknown port:000003F8 irq:4
1: uart:unknown port:000002F8 irq:3
2: uart:unknown port:000003E8 irq:4
3: uart:unknown port:000002E8 irq:3
```
All four legacy 8250 ports report `uart:unknown` (no responding hardware
detected at the standard I/O addresses).

**4. No alternative serial device found:**
```
$ ls /sys/class/tty/ | grep -v -E "^tty[0-9]*$|^vc"
console
ptmx

$ lsusb
Bus 002 Device 002: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$ lspci | grep -i -E "serial|uart|communication"
00:0f.0 Communication controller: Intel Corporation ... Trusted Execution Engine (rev 0b)
00:1a.0 Serial bus controller: Intel Corporation ... PWM Pin Controller (rev 0b)
```
No PCI UART, no USB-serial adapter, no ttyS4+ present. Only ttyS0–ttyS3 exist
(created generically by the 8250 driver, not hardware-confirmed).

## Conclusion / suspected root cause
The physical debug/reset-key UART on this board does not appear to be
responding at the classic COM port addresses. Possible causes (not
confirmed):
- Serial port disabled in BIOS/UEFI
- Missing GPIO/ACPI enable step for a level-shifter chip during boot
(regression in this beta build)
- Port not physically populated on this model

Regardless of the hardware cause, **TOSDaemon should not respawn a failing
helper process in a tight infinite loop** — this floods the journal and
wastes CPU cycles. A backoff/retry-limit for `uart_key` would be a reasonable
mitigation even if the underlying UART detection issue is separate.

## Request
Could you please:
1. Confirm whether `uart_key` / the reset-key UART requires a BIOS setting to
be enabled on this hardware, or whether this is a known regression in TOS
7.0.000.
2. Consider adding a restart backoff/limit for `uart_key` in `TOSDaemon` to
avoid the log/CPU spam while this is investigated.

Happy to provide further logs or run additional diagnostics on request.

Okay. Thanks for the additional information — we hope it helps.
We'll keep you posted here if there are any updates.

Hi.
After further investigation, we've found this only happens on older TNAS models. It doesn't impact actual functionality.
We intend to implement either a limit or a full disablement of this function in a forthcoming update to prevent it from repeatedly and endlessly generating log entries.