Page 1 of 2
Is something rotten in the state of "Update"?
Posted: 10 Mar 2025, 22:35
by Gremlin
With apologies to Will Shakespeare (or whomever wrote that stuff) ...
Twice now I have hit the same issue while updating F2/5-221 from Tos 5.1.45 to tos 6.0.530 (.530 as the intermediate step to latest)
The main bug (as I see it) is that the usb
init-boot fails to be re-written correctly. for the (future) Tos6 installations/re-installations.
I know this since I just decided to reset to factory default my F5-221 after several
system errors* started showing up (following update).
Having reset I realised I was not able to reboot my device. In case no-one else has noticed, the "old" legacy iinitboot has a typo which shows up on console monitor as:
"
Booting form ...... disk"
and, in this case, that was as far as it went.
Previously I had updated F2-221 and similar issue showed up when doing something similar but I wrote that off as a fluke. (In that case a re-install reverted to Tos5.1 which it should not have done.)
In both cases I felt obliged to prepare new usb drives with the appropriate image file(s). In the case of the recent F5-221, having removed the case, replaced the usb and refitted the case the re-install went directly to Tos6.0.648.
*I have downloaded an error report and that has gone to @TMSupport.
content = """Notification email: test email generates "logout", but click on screen re-instates. Cannot set new email (custom) attributes.
Lan aggregation (active backup) does not survive reboot.
That is just 2 things found so far."""
Re: Is something rotten in the state of "Update"?
Posted: 11 Mar 2025, 19:16
by Gremlin
To make matters (somewhat) worse:
Even after a successful (it seemed) re-install yesterday, on this morning's re-start (automated) the "Active Backup" LAG failed again. Eth0 failed to get it's IP setting from DHCP
(eliciting default 169.254.n.n). output from 'ifconfig':
Code: Select all
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 169.254.0.1 netmask 255.255.0.0 broadcast 169.254.255.255
ether 6c:bf:b5:02:5f:b2 txqueuelen 1000 (Ethernet)
RX packets 7393 bytes 680760 (680.7 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 133 bytes 44160 (44.1 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.155.17 netmask 255.255.255.0 broadcast 192.168.155.255
inet6 fe80::158c:915b:335b:2f87 prefixlen 64 scopeid 0x20<link>
ether 6c:bf:b5:02:5f:b3 txqueuelen 1000 (Ethernet)
RX packets 15515 bytes 2203401 (2.2 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10824 bytes 9417287 (9.4 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 44744 bytes 19893544 (19.8 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 44744 bytes 19893544 (19.8 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Connection was possible on eth1 with DHCP assigned IP and used:
Code: Select all
systemctl restart NetworkManager.service
via terminal which restored LAG
Code: Select all
ME@NAS-T3:/# systemctl restart NetworkManager.service
ME@NAS-T3:/# ifconfig
bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST> mtu 1500
inet 192.168.155.16 netmask 255.255.255.0 broadcast 192.168.155.255
inet6 fe80::cb2:f6cb:78cb:9fb3 prefixlen 64 scopeid 0x20<link>
ether 6c:bf:b5:02:5f:b2 txqueuelen 1000 (Ethernet)
RX packets 128 bytes 86367 (86.3 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 29 bytes 11698 (11.6 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500
ether 6c:bf:b5:02:5f:b2 txqueuelen 1000 (Ethernet)
RX packets 8025 bytes 805139 (805.1 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 174 bytes 59296 (59.2 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.155.17 netmask 255.255.255.0 broadcast 192.168.155.255
inet6 fe80::158c:915b:335b:2f87 prefixlen 64 scopeid 0x20<link>
ether 6c:bf:b5:02:5f:b3 txqueuelen 1000 (Ethernet)
RX packets 17171 bytes 2416570 (2.4 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 12207 bytes 9886779 (9.8 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 50385 bytes 20635918 (20.6 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 50385 bytes 20635918 (20.6 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Nothing obvious in 'dmesg' that I could see at first glance.
Maybe start putting this basic reset stuff in automated tasks at startup.
Re: Is something rotten in the state of "Update"?
Posted: 11 Mar 2025, 22:30
by TMzethar
Regarding the USB Initboot rewrite issue when upgrading from TOS5 to TOS6, it typically requires two full reboots to achieve complete rewriting. If you find that it has not been replicated, you may try restarting again.
Concerning the mentioned spelling error, we have not detected it for now but will continue to monitor.
As for the two issues you sent to the technical support email, our engineers are currently analyzing them.
If I understand correctly, you are indicating that both your F5-221 and F2-221 have encountered similar issues, correct?
Re: Is something rotten in the state of "Update"?
Posted: 12 Mar 2025, 00:59
by Gremlin
Re: Is something rotten in the state of "Update"?
Posted: 12 Mar 2025, 01:02
by Gremlin
TMzethar wrote: ↑11 Mar 2025, 22:30
Regarding the USB Initboot rewrite issue when upgrading from TOS5 to TOS6, it typically requires two full reboots to achieve complete rewriting.
When was that announced? I do not recall it being mentioned anywhere. In which case does that mean the user has to reboot twice after update is "complete". Or is the reboot from the update counted as "one"?
Re: Is something rotten in the state of "Update"?
Posted: 12 Mar 2025, 15:24
by TMzethar
Gremlin wrote: ↑12 Mar 2025, 01:02
When was that announced? I do not recall it being mentioned anywhere. In which case does that mean the user has to reboot twice after update is "complete". Or is the reboot from the update counted as "one"?
This mentions the need for sufficient waiting time. However, this may indeed lack specificity and clarity. We will add 'restart twice' for further clarification.
viewtopic.php?t=6809
3.
The entire update process will take approximately 10-20 minutes. Please be patient and do not forcibly shut down or unplug the power during the update.
Re: Is something rotten in the state of "Update"?
Posted: 12 Mar 2025, 19:03
by Gremlin
These are my network settings as of 11/03/25:
Note that in T2, above, the bond has taken the LAN 2 MAC and speed (1Gbe) instead of the LAN 1 BUT with the LAN1 IP (and expressed in Service Order (if that means anything.)
In this case T3 is using the LAN1 MAC and speed as intended.
This is network state this morning after T2 and T3 both restarted:
Note that T3 LAN1 has gone walkabout; Bonds have switched ports so other devices loose connections (or cannot reconnect). T2 appears to be offline but has actually moved to LAN2 IP and is accessible.
All devices are currently set to use default DHCP mode with DHCP reservations in the router
NAS-T1 (no image) has 2x2.5Gbe, reports 5Gbe bandwith but took LAN2 port as BOND in Balance-alb mode
NAS-T2 was updated to 6.0.650 yesterday but nothing has changed.
If the "consistent inconsistency" of the LAG setup can be explained, I would be very grateful
Re: Is something rotten in the state of "Update"?
Posted: 12 Mar 2025, 19:37
by TMlinda
We will verify this issue in our lab.
Re: Is something rotten in the state of "Update"?
Posted: 12 Mar 2025, 19:52
by Gremlin
Re: Is something rotten in the state of "Update"?
Posted: 12 Mar 2025, 20:34
by Gremlin
Just as a note fyi: I noticed that during the startup this appears:
Code: Select all
Netscript ifup eth1
Netscript ifup eth0
In that order. So, presume this was
designed to start LAN2 before LAN1 so that may be an explanation for the LAG/Bond behaviour.