Well it’s a big kernel jump between TOS 5 and 6, I have no idea why exactly you see this but there have been plenty of improvements in the successive 5.x kernel versions… networking, CPU schedulers, ARM optimisations… even btrfs has improved, although for a router I don’t think i/o is an important factor. But overall we should all expect performance improvements.
The reason is that dhcp-script.sh sources the other file, but it is not a shell script, but a Python script, so it simply does not work and spits out those errors.
1 Like
So did you check whether that port forwarding is still in place? Just guessing here: Did you maybe allow incoming connections on the WAN side to make the port forwarding on port 80|443 work and due to the renaming of interfaces the forwarding isn’t working any more but the port is still open?
Hello,
After the update, i no longer had the network connection. After the hard reboot, it’s fine. But the webUI is down.
Any port 80 and 443 are listening on the turris.
Same here, router interface is accessible from the outside.
Thanks einar, much appreciated. Fixed it with
...:/usr/lib/dnsmasq# diff dhcp-script.sh.original dhcp-script.sh
3c3,9
< [ -f "$USER_DHCPSCRIPT" ] && . "$USER_DHCPSCRIPT" "$@"
---
> if [ -f "$USER_DHCPSCRIPT" ]; then
> if ! cat "$USER_DHCPSCRIPT" | head -1 | grep python 2>&1 > /dev/null; then
> . "$USER_DHCPSCRIPT" "$@"
> else
> "$USER_DHCPSCRIPT" "$@"
> fi
> fi
Seems silly that it didn’t occur to me from the get-go that it must’ve been the shell attempting to source it 
TYVM!
Upgraded my Omnia Turris 2GB today. No issues aside from the known bug with the LED and some error output here and there during pkgupdate. But everything works as expected as far as I can see.
Well done! Nice to run a much more recent kernel and much more recent versions of just about everything. Thank you. 
2 Likes
One more thing I noticed.
I used to have a port 80 forward rule (to a server on LAN), as well as a traffic rule that opened port 80 on the wan side.
For some reason, the forwarding rule apparently did not apply if lighttpd was listening on port 80; moving lighttpd to port 8080 fixed things.
This wasn’t immediately obvious - my lighttpd.conf still said
...:/etc/lighttpd# cat lighttpd.conf | grep 80
server.port = 8080
$SERVER["socket"] == "[::]:8080" { }
However, I found the culprit in /etc/lighttpd/conf.d/90-turris-root.conf:
...:/etc/lighttpd/# cat conf.d/90-turris-root.conf | grep 80
# Listen on IPv4 "*:80" (default) and on IPv6 "[::]:80"
$SERVER["socket"] == "*:80" { }
$SERVER["socket"] == "[::]:80" { }
After changing those to use 8080, the redirect worked once more.
Posting this just in case it might help others.
EDIT: if you try this, don’t forget to sudo /etc/init.d/lighttpd restart (no sudo required if you’re logging in as root)
EDIT #2: in my case, I’m using a bunch of socat's to redirect IPv6 traffic to IPv4; if you’re doing the same, don’t forget to sudo /etc/init.d/socat restart bit as well. Seems unlikely, but you never know
Should I create a different thread for my USB problem? Contact the support?
Anybody else has this issue? I’m using one of the first Turris Mox (indiegogo campaign)
I did not touch the USB port when upgrading.
It is powered (lights of USB devices are on).
I think it’s a problem regarding USB Mass Storage: if I plug another kind of USB device, it’s detected:
[ 9342.096437] usb 2-1: new full-speed USB device number 2 using xhci-hcd
[ 9376.835406] usb 2-1: USB disconnect, device number 2
[ 9458.555336] usb 2-1: new low-speed USB device number 3 using xhci-hcd
[ 9480.586570] usb 2-1: USB disconnect, device number 3
But nothing happens in dmesg when I plug an USB stick or hard drive.
2 Likes
This was really breaking upgrade - my Omnia broke around 14:00 - I was at work on important call and girlfriend on HO was without internet just as she was also expecting online call. Not funny guys. At least just turning it off and on by disconnecting power supply helped
3 Likes
Please disregard the below - didn’t notice you were on the MOX. My results are from Omnia.
Sorry for the confusion.
–
Weird one. For me it looks like
[13297.908344] usb 3-1: new SuperSpeed USB device number 2 using xhci-hcd
[13297.939921] usb 3-1: USB controller f10f0000.usb3 does not support streams, which are required by the UAS driver.
[13297.939935] usb 3-1: Please try an other USB controller if you wish to use UAS.
[13297.939942] usb-storage 3-1:1.0: USB Mass Storage device detected
[13297.945286] scsi host2: usb-storage 3-1:1.0
[13298.968518] scsi 2:0:0:0: Direct-Access Corsair Voyager GTX 0 PQ: 0 ANSI: 6
[13298.969502] sd 2:0:0:0: [sda] 500118192 512-byte logical blocks: (256 GB/238 GiB)
[13298.969822] sd 2:0:0:0: [sda] Write Protect is off
[13298.969829] sd 2:0:0:0: [sda] Mode Sense: 43 00 00 00
[13298.970026] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[13298.971316] sda: sda1 sda2 sda3 sda4
[13298.972658] sd 2:0:0:0: [sda] Attached SCSI disk
The device works just fine in MSC mode, even if UAS is unavailable (and plain MSC devices seem to work just fine).
Is it possible that your device is simply drawing too much power?
PS. Interestingly enough, ntfs-3g (and ntfs-3g-utils) were gone after the upgrade - but sudo opkg update; sudo opkg install ... worked just fine. Even more interesting - for some reason, sudo mount /dev/sda2 /mnt failed with mount: /mnt: unknown filesystem type 'ntfs' - I could swear it worked.
Not that it mattered, since sudo mount -t ntfs-3g /dev/sda2 /mnt worked just fine.
One more LED related error:
Updater selhal: Failed operations:
fix-omnia-leds-migrate/postinst: Warning: Unsupported trigger ‘sda’ for: system.cfg058bba (rgb:wlan-3)
Command failed: Not found
My Omnia took the update overnight, and our home network was down this morning when I woke up. It was not a big deal in our case–the worst of it was the fact that since I’ve only had the Omnia for about a week, I did have to suffer the hairy eyeball from my wife while I brought it back up. 
In my case, after the update some of my SBCs that have static IPs were not detected as being online in the DHCP portal–even after the Omnia was rebooted. 
One of the devices is a PiHole that serves DNS for the network, so even after rebooting the Omnia I did not have normal internet access (no DNS).
Rebooting the SBCs brought them all back online normally and the network is doing fine. Probably rebooting was more than was necessary; I likely could have just restarted NetworkManager or similar, if I had thought of it.
Approved the update this morning and it looked like wifi still wasn’t working after a reboot so reverted to the pre-update snapshot to look at later. Annoyingly seems the snapshot is created after approval (which does make sense) so the update auto-installed again later rather inconveniently.
After a couple of reboots everything seems to be working okay now, other than the PCI LEDs, which are just off. I guess I need to add custom configurations for them now?
Thanks for the major upgrade though!
1 Like
Not sure about this - do you have honeypot activated?
In case yes: is is security feature, not gap.
Okay, I’m done testing the thing. sudo schnapps create "Turris 6.0 fix1 all-working"
Other than the fact that the LED intensity is not preserved on Omnia (need to push the button 8 times after every reboot; apparently the old level is read, but not applied), I’m good. Also running the fix pack on top of 6.0 - it’s all good.
And even if the LED intensity bug sticks, I’m very happy with having moved from linux 4.14 to 5.15.
Great job Turris team! 
PS. Also had to rename the LEDs - rgb-indicator-1 and rgb-indicator-2 used to be called omnia-led:user1 and omnia-led:user2 respectively; but after doing that, I’m good (TBH, I’m also not sure if the change came with TOS6 or earlier, and I simply didn’t notice)
1 Like
Ahoj, ja mam teda opacny problem nez nekteri - lighttpd mne vubec nenastartuje, ale nevim jak to debugovat, jelikoz zmizelo /var/log/lighttpd/error.log… Takze GUI kompletne down…
Mam teda MOX std. verzi, zatim tedy rollback na 5.44.
E.
1 Like
I’m seeing the same temperature drop. I’m just curious if it can’t be because some services fail to start - most importantly sentinel firewall logs collector.