Of course! Serial debug console.
After upgrade to TOS 7, users (Windows clients) are unable to connect to VPN.
This helped:
opkg install kmod-nf-nathelper-extra
opkg install kmod-nf-nathelper
opkg install kmod-gre
opkg install iptables-mod-conntrack-extra
opkg install kmod-ipt-conntrack-extra
reboot
I have also updated my Omnia to the 7.0.0. After reboot the router seems to be running fine but I got this message:
Can't mount device /dev/sda1 as /srv for data storage.
In the reForis
Storage page, everything seems to be fine. In the CLI or LUCI I see that the /dev/sda1 is currently mounted:
root@turris:~$ df -h
Filesystem Size Used Available Use% Mounted on
/dev/mmcblk0p1 7.3G 3.8G 3.5G 52% /
devtmpfs 512.0K 0 512.0K 0% /dev
tmpfs 1007.6M 74.7M 932.8M 7% /tmp
tmpfs 512.0K 0 512.0K 0% /dev
/dev/sda3 902.5G 487.4G 412.8G 54% /mnt/nas
/dev/sda1 25.0G 3.3G 19.8G 14% /srv
I do not see any error related to it in /var/log/messages
.
Interesting. The staged updates probably need a bit more love.
Today Iāve connected one brand new Wifi 6 Omnia which came with TOS 6.0.0a factory image.
Iāve gone through the setup guide at the end of which updates were run. The updater installed 7.0.0. But then, when it finished, it generated a new update approval request, that wanted to downgrade to 6.5.2:
... the end of update to 7.0.0
Apr 17 08:28:19 turris updater[10909]: transaction.lua:249 (fun): Cleaning up control files
Apr 17 08:28:19 turris updater[10909]: updater.lua:197 (Globals): Restart your device to apply all changes.
Apr 17 08:28:19 turris updater[10909]: src/lib/logging.c:153 (log_subproc_open): Executing reboot_required hook: 50-create-notification.sh
Apr 17 08:28:23 turris updater[10909]: file:////etc/updater/conf.d/turris.lua.lua:119 (Globals): There is a newer version available, but update is scheduled after another 98.8 hours. If you want the latest and greatest all the time, switch to one of the development branches.
Apr 17 08:28:23 turris updater[10909]: repository.lua.lua:47 (Globals): Target Turris OS: 6.5.2
Apr 17 08:28:32 turris updater[10909]: planner.lua:356 (pkg_plan): Requested package reforis-diagnostics-plugin-l10n-de that is missing, ignoring as requested.
Apr 17 08:28:32 turris updater[10909]: planner.lua:356 (pkg_plan): Requested package reforis-snapshots-plugin-l10n-de that is missing, ignoring as requested.
Apr 17 08:28:32 turris updater[10909]: updater.lua:92 (Globals): Queue downgrade of libgcc/core/8.4.0-3[11.2.0-4]
... downgrade to 6.5.2
My guess is: The updater in 6.0.0 did not know anything about staged updates, so it normally found 7.0.0. But this update installed the staged-updates-aware updater, which immediately computed that it is not yet time for 7.0.0. I guess this is only a transitional problem, but it can reoccur from time to time when people use older medkits and things like that. Iād say if the system already is on hbs, donāt downgrade it to hbs-old.
I got similar error, but after another reboot it vanished.
Encountered similar situation, after forcing update editing /etc/updater/conf.d/turris.lua and reversing edit back updater wanted to downgrade OS Thus I had to edit it again so not to be downgraded, and am waiting till mine course of staged update to clean the edit once more
Had the same problem: transmission eating all CPU resources. Was able to stop it manually via shell and had to uninstall it entirely, since a reboot did not fix it.
How does it look like to upgrade to Turris 1.1 with simple configuration? Should I be afraid? I have successfully stopped the error emails with the update clock in reForisā¦
Iāll answer for myself. About an hour after I asked here, Turris 1.1 was updated to 7.0. After a reboot, everything looks ok. Thanks!
Just noticed this in system log:
Apr 17 16:07:57 turris updater-supervisor: Traceback (most recent call last):
File "/usr/bin/updater-supervisor", line 33, in <module>
sys.exit(load_entry_point('svupdater==1.5.6', 'console_scripts', 'updater-supervisor')())
File "/usr/lib/python3.10/site-packages/svupdater/__main__.py", line 109, in main
File "/usr/lib/python3.10/site-packages/svupdater/_supervisor.py", line 146, in run
File "/usr/lib/python3.10/site-packages/svupdater/notify.py", line 115, in changes
AttributeError: 'list' object has no attribute 'splitlines
it is there many times
Since there hasnāt been any feedback regarding the missing TurrisOS 7.0.0 release tag, Iāve now opened an issue in the Turris Build bug tracker.
Hello everyone,
I have been offered it since yesterday but am still hesitating. Under the details it says that ābanipā will be removed but not installed. Does this also apply to other packages which I have overlooked in the worst case?
Is it enough if I save the āconfigā of banip and then install it again?
Best regards!
do you have any solution yet ?
It is clear that they dont give a f*** about that. We do have more than hundred posts here and no single reply from them. It is pity how this project goes. Gonna flash OpenWrt.
They did not bother anymore.
No, updater still wants to remove the luci packages.
I must admit that Iām also wondering about the lack of responses from the Turris team to most of the issues here. But to be fair:
that is not true. There have been some replies from @miska (and @vcunat).
There is, however, complete silence since April 11. Maybe theyāve got holidays in Czechia ā¦
no holidays. I am here in czech rep.
Well, we know that the turris project is understaffed, and they just managed to get a massive update rolled-out, so I personally am willing to cut them a lot of slackā¦
Seems I am a choosen one now as well
Ā“Ā“Ā“
Error notifications
Updater execution failed:
INFO:Target Turris OS: 7.0.0
line not found
ERROR:
inconsistent: Requested package jool-tools that is not available.
line not found
line not found
line not found
line not found
Ā“Ā“Ā“
I installed Ėjool-toolsĖ as part of @Ondrej_Caletkaās IPv6 only/mostly-instructions. Are there other tools that replace that package (maybe @AreYouLoco have you already looked into that)?