Turris OS 3.10 is out now!

opkg-auto.lua doesn’t contain automatically installed packages. Explicitly requested ones are tracked inside it. And if some package manager drops explicitly installed package just because it is no longer available then it’s bug I think. What user requests that is sacred by package manager. Removing obsoleted packages that are no longer available without explicit user notice is just bad design.
So no. Reading error message was enough. You clearly know what that error message meant so why you were asking for “hints”? From my point of view it’s like saying: I have no idea what am I doing. You should rather ask question like: Is this package no longer available? Then I would know that you have read the message. You know I can do some magic but divination with crystal ball is not skill I posses. In future rather then immediately being jumpy try to go mile on your own before you ask. And tell us in that question that you went that mile because otherwise we don’t know and have to assume that you haven’t.

I see no point in continuing this argument, cynerd. apt is certainly capable of asking the user whether to remove an obsolete package if called interactively, but of course we can argue “who is right” endlessly. I opt out of this loop. Thanks.

Also the error message reads Requested package luci-i18n-wshaper-en that is not available. Why should I assume it means that the package has been obsoleted? It certainly does not say so. It just says it is not available – which could have about any reason. So before I assume anything, I think its more appropriate to paste the error message and then ask “Any hints?” – just as I did. I certainly did not have the conclusion that the package might be outdated.

I can confirm this bug (kresd not resolving AAAA records after upgrade to TOS 3.10)

@protree if you restart kresd is the problem still there? @vcunat hasn’t been able to reproduce so far.

After upgrade, mosquito and mosquitto-client packages were replaced with nossl versions…

another one bites the dust…

[ 143.620850] BTRFS error (device mmcblk0p1): Remounting read-write after error is not allowed

support says i have to reflash with medkit :frowning:

I confirm I have observed same “feature”

The problem is solved. Had contacted the support and @Pepe answered me then. It was up to my SSID, this was longer than 32 characters.
But why it worked before that is puzzling to me. Have the name of SSID since October 2016 with the acquisition of Omnia.

Best regards

  1. Pakon works on Chromium based browsers, Firefox and IE nothing happens.
    Static entries must contain the MAC addresses in uppercase and lowercase letters. Then Pakon also shows the hostnames.
  2. The problem with the Wi-Fi tab has @Pepe been resolved, see my post about it.
  3. ddns-scripts also solved see Problems configuring DDNS with Turris Omnia and Turris OS 3.10

Now everything works perfectly

Best regards

Interesting. I tried a chrome browser, put pakon still gives spinning wheel and chrome tells me ‘‘Failed to load data’’. This time both ucollect & fw logs are uploading though…
can someone tell me what syslog msg are relevant to watch for this ?

best, DIKKE (nOOb)

Edit : funny activity ( from the HQ ? :slight_smile: ) in the syslog, and now everything works !

Edit 2 : and pakon is now back to the round spinning thing…in chrome. no failed to load data.

Edit 3 16-05 . Omnia is suddenly hanging for the first time ever.Removed Pakon, this is to buggy?

Sorry fo being numb. Can you please advise me how to apply the patch to my system? Thanks in advance.

You can log in your router via ssh and then run
wget https://gitlab.labs.nic.cz/turris/turris-os-packages/raw/test/cznic/turris-cagen/files/cagen-status.sh -O /usr/bin/turris-cagen-status

2 Likes

That simple? Now I feel really stupid I didn’t think of that… Thanks a lot…

i’ve managed to revive my omnia via serial console with rescue shell

it took about 30 min so be patient if you try this

/ # btrfs check --repair /dev/mmcblk0p1
enabling repair mode
Warning, could not drop caches
Warning, could not drop caches
Checking filesystem on /dev/mmcblk0p1
UUID: 30605799-ecc5-4556-ac68-6a0b46c6ff76
checking extents
Fixed 0 roots.
checking free space cache
cache and super generation don’t match, space cache will be invalidated
checking fs roots
Deleting bad dir index [77272,96,1087] root 296

repairing missing dir index item for inode 77273
Deleting bad dir index [77272,96,1087] root 436
Deleting bad dir index [77272,96,1803] root 436
repairing missing dir index item for inode 77273
warning line 3715
checking csums
checking root refs
found 4412447514 bytes used err is 0
total csum bytes: 3391936
total tree bytes: 1030586368
total fs tree bytes: 967536640
total extent tree bytes: 57294848
btree space waste bytes: 250379557
file data blocks allocated: 30517055488
referenced 26079805440
Warning, could not drop caches

My problems with 3.10 (I have started from scratch - flashed medkit ):

1- set up wizard ends with error after wan dhcp setting ( I have to skip wizard and set everything later in foris menu )

2- storage plugin is not working - Format&set then reboot but after reboot internal storage is till used, disk get formated , but no data are saved on usb disk and foris is also telling that internal storage is used

3- if you set guest WiFi QoS in foris it’s not working. In foris everything looks ok but for some reason foris only make config file but don’t start sqm service

1 and 3 are no concern but if I wasn’t able to make storage plugin work

Mee too. I started with a type-4 reset, using latest medkit image (TO 3.10).

So, if I am reading this correctly - is it wise to wait with a factoryreset? It made all updates without any errors, but when the last 3.09 was issued, there was an advise to save settings and factoryreset after updating to 3.10…

Thanks for all the work,
Vienna

Where did you see that advice? I didnt do any factory reset so far, nowadays I am on 3.9.6, and for my understanding, 3.9.10 contains mostly NIC (Foris, plugins) changes, regarding to “major” things… So I wouldnt expect need for factory reset…

Personally I waiting for WAN6 fixes in 3.10.1, then I will proceed with upgrade, because there is DVB-T2 driver for my TV stick included in this release (without few paches, but still).

1 Like
1 Like