TOS 7 Is Now Out of Beta — Official Release

[Blain5700]

Great, thanks!

[LordP]

This is completely absurd:

Method B: Adjust the BIOS Boot Order.
1. Check the BIOS Version.
Power off the TNAS and remove all disks. Connect the TNAS using an HDMI cable and a keyboard. Press the power button, and then immediately and repeatedly tap the Del or Esc key multiple times in short, quick succession until you enter the BIOS interface. Do not hold the key down; instead, press it at a frequency of 1-2 times per second. On the main page, check if the Project Version is one of the following:

[ultdrako07]

Hi everyone, I'm hoping someone has run into this same issue, or that a member of the TerraMaster support team (@TMzethar, @RyanYang, @HeliaWu) can help confirm whether this is a known bug for the F4-223/423 family. Device: F4-223 (device name: drskosnas) Current version: TOS_X642.0_6.0.794 Target version: TOS_X642.0_7.0.0747 Symptom: I attempted the update 3 times in a row on the same day (manual update via Control Panel, package TOS_X642.0_Update_7.0.0747_1247_2607310709.bz2). Each attempt completes with no fatal error and ends with "Completed all SpecialTreatment operations," but: - The system version never advances past 6.0.794. - The running kernel remains unchanged (uname -r → 6.1.58+, built Sep 29 2024 — the original kernel). - /usr/lib/version file is never modified. Root cause I found (via SSH diagnostics): In all 3 install logs, this step consistently fails for both boot partitions (/dev/sda1 and /dev/sdb1): Delete unnormalized original kernel files /tmp/bootdev/boot/initrd.img-6.12.41+tos-amd64 /tmp/bootdev/boot/vmlinuz-6.12.41+tos-amd64 ShellExec err: exit status 1 I checked via SSH and confirmed my F4-223 uses a monolithic bzImage kernel file — there are no vmlinuz-* / initrd.img-* files on this system at all. It looks like the installer's cleanup step is hardcoded to look for Debian-style kernel filenames that simply don't exist on this model, causing the deletion (and likely the actual kernel replacement afterward) to silently fail, while everything else (GRUB config, EFI binaries, permissions, login screen branding) updates just fine. What I've already ruled out: - Free space: plenty available (5.1GB free on the system partition). - Boot RAID (md9 / UTOSCORE-X86-S64): healthy, active, no degradation. - Missing reboot: confirmed via uptime that the NAS did reboot after each attempt. - Docker containers running during update: killed cleanly by the installer, not the cause. - NVMe boot order: my system is NOT installed on an M.2 NVMe SSD — the root partition (md9) lives on the SATA drives (sda2/sdb2), confirmed via SSH. So this shouldn't be related to the NVMe BIOS boot order note mentioned below. What I noticed in your official docs: In the "TOS 7 Is Now Out of Beta" announcement (viewtopic.php?t=10183), the F4-223 isn't listed under "Models that can be updated directly" — it only appears under "Special Notes" together with F2-223, F2-423, F4-423, T6-423, T9-423, T12-423, U4-423, U8-423, and U12-423 (that note specifically mentions adjusting BIOS boot order for M.2 NVMe installs, which doesn't apply to my setup as noted above). This makes me think this whole model family might need a different update path than the generic installer, independent of the NVMe-specific note. I also found an older thread where a F4-423 user got stuck on an old version and had to install an intermediate version before jumping to the target one (viewtopic.php?p=34875) — I'm wondering if something similar applies here. Questions for the community / support: 1. Has anyone else with an F4-223, F2-223, F4-423, or related model run into this exact kernel replacement failure? 2. Is there a corrected installer package for this model family, or a required intermediate version before updating to 7.0.0747? 3. Is a remote engineer session available to complete this safely, given the NAS is holding multiple TB of production data? I have the full installer logs (3 attempts) and SSH diagnostic output (mdstat, grub.cfg, journalctl, disk info) available if that helps troubleshoot. Already reached out via email to [email protected] as well, posting here in case anyone in the community has seen this before.

Thanks in advance!

[CursaYang]

This is how to enter the BIOS. What problem did you encounter? Could you describe it in detail?

[CursaYang]

The F4-223 can be upgraded directly from version 6.0.794 to version 7.0.0747, with no intermediate versions required for this process.
To resolve your issue more quickly, please visit the link below to connect with our online support team:
https://salesiq.zoho.com.cn/emailsignat ... cf77e403f5

[MarioPlBe]

Hi.
I think I faced exact same issue. Running latest TOS 6. Run TOS 7 upgrade and all looks fine until reboot. After reboot OS is back to TOS 6 with full config reset.
What I did to work around this issue was:
- restore TOS 6 config from backup.
- reboot to BIOS and change boot sequence to Hard Disk. I disabled UEFI USB boot option completely.
(Seems like if you leave boot from built-in USB it will not find new boot image and will trigger TOS 6 installation)
- run another TOS 7 upgrade.

Hope it helps

M

[EriChan]

Thank you for sharing your experience.

If any user encounters an issue where the device boots back into the system installation page after updating to TOS 7, please refer to the corresponding model-specific instructions in the special notice.

Should you need any assistance during the process, please feel free to contact our online technical support via the link below:
https://salesiq.zohopublic.com/signatur ... 97d0be8892

[Flyingbike]

Hello

I must share my feedback on updating to TOS 7.0.0747 on a F2-423.
I am on latest macOS and use Safari.
After updating, Application center and storage manager GUIs were KO. Folders were not accessible except for root folder. I had no proposition to upgrade permissions.

Updating to 7.0.1105 was no better.

I logged in to the NAS using a private navigation window. Here the GUIs were OK and I got the window proposing the permissions thing.

[EriChan]

Thank you for your feedback.

We have confirmed that this issue indeed exists and is caused by browser cache conflicts. Please clear your browser cache in Safari, which will restore the normal GUI display.

We have already submitted this issue to our product team, and we will evaluate optimization solutions in future releases.

Thank you for your patience and support!

[Flyingbike]

Thank you for your feedback.

We have confirmed that this issue indeed exists and is caused by browser cache conflicts. Please clear your browser cache in Safari, which will restore the normal GUI display.

We have already submitted this issue to our product team, and we will evaluate optimization solutions in future releases.

Thank you for your patience and support!

Hello

Actually clearing the cache by GUI was not a solution.

Here is the summarized issue and solution, I had to get help from ChatGPT to solve that.


Safari issue after upgrading from TOS 5/6 to TOS 7

Problem:
After upgrading to TOS 7, Safari kept showing the old TOS 5.1 interface and repeatedly displayed “Session expired, please log in again.”
Private browsing or using another hostname/IP worked correctly.

Diagnosis:
An old TOS Service Worker was still active in Safari and was serving cached TOS 5.1 files, even though the NAS was running TOS 7. Clearing Safari website data and caches did not remove it.

Solution:
In Safari Web Inspector → Console:

Code: Select all

navigator.serviceWorker.getRegistrations().then(regs =>
  regs.forEach(reg => reg.unregister())
)

Then clear the Service Worker caches:

Code: Select all

caches.keys().then(keys =>
  keys.forEach(key => caches.delete(key))
)

Close all TOS tabs, completely quit Safari, and reopen it.

TOS 7 then loads normally.

Suggestion for TerraMaster: TOS 7 upgrades should automatically invalidate/unregister Service Workers installed by previous TOS versions.

Best