Turris OS 6.0 is released

[tuomaz]

I’m running docker in a lxc container (followed guide here: Docker on Turris Omnia - #44 by ackstorm23)

after upgrading to 6.0 my lxc container won’t start with this error message:

lxc-start: ha: cgroups/cgfsng.c: cgfsng_mount: 1810 No such file or directory - Failed to create cgroup at_mnt 26()
lxc-start: ha: conf.c: lxc_mount_auto_mounts: 845 No such file or directory - Failed to mount "/sys/fs/cgroup"

Google says it is down to different versions of the cgroups subsystem? True or false? Anything I can do to fix it?

[dkomrska]

My Omnia got upgraded today around 12:30 and requested to schedule the reboot.
Unfortunately, my internet connectivity was lost.
I have rebooted the Omnia to get internet connectivity again.

This is a problem for me. I am working from home and had a remote session with the customer while the connectivity was lost.
Is there a way how can I avoid such network outages in future?

[Radovan_Haban]

“Is there a way how can I avoid such network outages in future?”
From my experience NO. I’ve experienced this twice.

[samm_git]

My update report:

Turris 1.0

Upgrade from HBL to HBS (the latest with a working kernel) went well. I had a lot of warnings from the updater, but all were resolved without problems. Router works fine, I am not using WIFI on it, but everything else seems to be good.

Turris Omnia 2.0

I got an update message with such text:

The device will be restarted automatically on Saturday, October 22 at 03:30 AM CEST.

Error notifications
===================
Updater failed: Failed operations:

fix-omnia-leds-migrate/postinst: Command failed: Not found

/usr/libexec/rainbow/led_activity.sh: line 165: /sys/class/leds/rgb:wan/trigger: No such file or directory

grep: /sys/class/leds/rgb:wan/trigger: No such file or directory

Warning: activity setup failed for: wan

/usr/libexec/rainbow/led_activity.sh: line 165: /sys/class/leds/rgb:wlan-2/trigger: No such file or directory

grep: /sys/class/leds/rgb:wlan-2/trigger: No such file or directory

Warning: activity setup failed for: wlan-2

/usr/libexec/rainbow/led_activity.sh: line 165: /sys/class/leds/rgb:wlan-3/trigger: No such file or directory

grep: /sys/class/leds/rgb:wlan-3/trigger: No such file or directory

Warning: activity setup failed for: wlan-3

Command failed: Not found

And after it, I got a call from the office that the internet is not working So had to visit it to find that there is no wifi at all. Reset of the router did the job and after restarting, everything works as intended. Hope the Turris team will not do major releases too often

Anyway, I would like to thank the entire Turris team for their hard work. Having 10+ years of support for the home router is just amazing.

[samm_git]

Only recommendation here would be to go to the manual update path. From other side - major releases are not happens often…

[samm_git]

@mvasilek problem is not rainbow errors, but wifi one. I think updater messed up wifi config.

[bamf]

Since update, it seems the IPv6 addresses of my pppoe-wan interface are constantly changing. Is there a new setting somewhere which I have not found yet?

[Broody]

Such a major and high-risk update should have been manual. Having to troubleshoot why internet stopped working in the middle of a work day is not very fun. And I lost all communication with another Turris at a different location, so I presume the update there also didn’t go smoothly…

[Radovan_Haban]

This router interface is accessible from the Internet publicly without any VPN. The router is after restart.

At first (after update, failure, before restart) I could access my router configuration from the Internet without any authentication.

[dkomrska]

As far as I remember, the manual update path conflicts with Sentinel…

[dkomrska]

I don’t see this issue with my Omnia, where Sentinel is enabled…
Do you have Sentinel enabled on your device?

[peci1]

@dkomrska

Is there a way how can I avoid such network outages in future?

Yes! If you run critical infrastructure on Turris (including your home office), you should enable Update approvals in the Updater page in Reforis. Otherwise, critical network infra with autoupdates at random times will always lead to disaster. With critical infra, you have to take time to test the update when it is not painful for the users of the infra.

[Broody]

Are you sure the web interface is really accessible from WAN? For me, it shows the same Turris page for my IP because of offline content saved in the browser, and asks for credentials via basic auth because I have enabled honeypot on port 80. You can try disabling the honeypot and accessing your IP from another browser / private mode window / clear browser cache.

[dkomrska]

Good idea, will do, thanks!

[Radovan_Haban]

is really accessible from WAN

Yes, I’m at work, no VPN opened.
Using my public IP, before restart the interface was fully functional I could event restart the router using it.

[Broody]

@Radovan_Haban

Using my public IP, before restart the interface was fully functional I could event restart the router using it.

And now, after the restart? Because your posts made me check and I saw the exact screenshot as you posted above, however when digging down I realized it was due to the offline content and the honeypot. After disabling the honeypot and using private mode browser window, I got a “connection refused” message.

EDIT: And after re-enabling the honeypot and using private mode browser window, I get a simple (basic auth) login query with no other UI, which I presume is how the honeypot normally functions.

[Mossroy]

My Turris Mox just got the Turris OS 6 update too.
It suddenly blocked my internet access, and I had to manually restart it (fortunately, I was around!)
As already mentioned by other ones, you should have let us anticipate that, with a manual upgrade for example.

But the worst issue for me is that the USB hard drive plugged on my Mox (module A) is not recognized any more. I’ve tried 2 different hard drives and a USB stick: none of them are detected (and they, of course, are detected when plugged on my PC):

root@turris:~# lsusb -t
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=orion-ehci/1p, 480M
root@turris:~# lsblk -f
NAME        FSTYPE FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINT
mtdblock0                                                                           
mtdblock1                                                                           
mtdblock2                                                                           
mtdblock3                                                                           
mtdblock4                                                                           
mmcblk0                                                                             
└─mmcblk0p1 btrfs        turris cc78a0ae-cb97-41da-811b-bd0abf63c974    3.6G    72% /
zram0       swap                                                                    [SWAP]

The MOX is also my NAS, shared with NFS, where most of my self-hosting data is stored.
I had to switch in emergency to a backup hard drive (hosted on another device).

How to fix the USB issue?

Edit: here is a dmesg (with the USB hard drive plugged on the Mox): ZeroBin (I did not see anything wrong regarding usb in this). If I unplug/replug my USB device, there are no new lines in dmesg
Edit2: here is the output of lsusb -v: ZeroBin

[milkandhoney]

Out of 5 Turris Omnia, two had the update installed, clients at these locations had no more internet. Router was unreachable by Wireguard and or SSH from the outside, Luci web was failing, but reForis was still reachable. So I could remotely initiate a reboot over reForis, After the reboot everything seems to work fine again.

3 others attempted to update, but failed because of package errors.
Two complained about wireguard:

Updater failed: 
inconsistent: Requested package wireguard that is not available. 

One complained about usbreset

Updater failed: 
inconsistent: Requested package usbreset that is not available.

But Wireguard is installed on all five of them.
Some of them are Silver models, others are Black. I can’t say which is which.

I probably will remove the packages manually and attempt manual updates after working-hours tonight on the ones not yet updated.

[anarcat]

I had a similar experience as others here; my network was totally down after the update, no uplink, and incoming connection would hit the router instead of my usual bastion host behind. (So there was some network, but really not enough for things to actually work.)

I also had warnings in the notification screens, related to LED stuff, but I lost those now. I don’t care much, that said: the new LED patterns is good enough for me, although I’d love to know what the different colors actually mean.

A reboot fixed most problems, although I can report that IPv6 connectivity was lost; the gateway doesn’t ping. That has always been brittle however, so I’m not sure I can lay the blame on Turris for that one.

I do wonder if there’s a big report about a reboot being required to restore connectivity, however… I don’t see anything obviously related to that in the second post. Note that all connectivity was lost, not just WiFi, in my case. (Well, technically, there was some connectivity because the router was responding to its external IP, but it wasn’t routing traffic through it. It’s as if the NAT rules had gone down in flames or soemthing.)

@samm_git

Anyway, I would like to thank the entire Turris team for their hard work. Having 10+ years of support for the home router is just amazing.

I want to emphasize this here as well. I understand some people might be upset by some of the inconveniences of this update, but this is a major upgrade, and I’m not actually surprised it’s a little more disruprive than it should be. It’s a little troubling – I would have expected a beta to catch stuff like this, for example – but nothing the call home about…

After all, which off the shelf router do you have that performs self-updates, has been supported for years and is based on free software? Most COTS hardware I buy are basically unsupported the moment they come out of the box, don’t run OpenWRT or any open OS, and even less allow reliable, transparent upgrades.

A reboot is not great, but it’s not that bad folks. Unless you’re running this stuff in production, in an actual datacenter, in which case I’d say: “phew, good thing you had a backup router that took over the traffic on that outage, right”??