Hi, while configuring T 1.1 on remote location and as it’s a bit more complicated set up, no rollback eventually helped getting back some semi-working state.
As I’m mainly Omnia user rather this one original HW line, unknowingly what it will cause, processed with red button, the reset.
There is no information(!) in documentation at all that if this is performed, overall it’s not possible to get back - or at least it seems to me.
Well the device ended up in state that I can connect it only into another already functioning gateway or there can’t be any connection at all (somehow managed that in LuCI as the source for WAN is passthrough from some LTE modem…). The web UI froze many times for each step and only way out from that state is to reboot device several times even if the skip it is chosen.
(Same happened after sdcard image update - working connection into internet can be done only after several restarts - unplugging cable - and until LAN is not set up different from the router you are connected at the time - ie. for most of the situations 192.168.2.1 will do it → another restart must be done - Turris won’t connect itself into internet.)
Also as https if forced mostly nowadays it wont load web UI - so new router ip must be inserted manually avoiding that redirection.
The web UI Reforis showed 3.8.5 but no access for ssh (Connection refused) nor opkg update (from LuCI).
After connecting into Turris through serial it won’t still allow opgk as there were no package, same for ssh.
Not knowing what to do I found here this post giving me hope this could be pushed up to higher versions.
But in my case updated always ended up:
Updater failed:
corruption: Signature validation failed
Even disabled DNSSEC as that can be done on 3.8.5 (but now on 3.6.5 can’t).
After few restarts with no success find here on forum there is a possibility to load some image with SD card and serial.
In hope of obtaining working SSH so can continue on it not being tied with machine connected directly into serial, did that.
Thanks to this page “Obnova systému a zavaděče z microSD karty [Turris wiki]” (there is another a bit different version on webarchive).
This link (https://doc.turris.cz/doc/cs/troubleshooting/sdcard_recovery) from here is not existing anymore and on archive it says is deleted.
After procedure:
Image moving into SD card had to be done with the program win32diskimager-1.0.0 as simple copy&paste will not work on Win10/11 and Rufus won’t recognize image (unfortunately my linux machine does not have sd card slot). Had to reformat the SD card - with Win ‘Create and format hard disk partitions’ tool.
If it’s messed up (the SD card image) - you will hear quite silent ‘bsssh’ from blinking diode for each light up. The diode (R414 D26) is located on MB - in middle between WAN port and CPU/aluminium block. In terminal, nothing will happen.
Otherwise if all good the diode blink only once and the process will start itself - wait until ‘=> HOTOVO’ is printed.
The switches had to be set up before and after procedure.
The system bot up successfully - it does even have opkg. But no ssh still (Connection refused - the sshd is not listed in LuCI) - so far I do have console so that is ok.
The update won’t be downloaded because there is some bad signature already (DNSSEC key change because of KSK rollover) - did find this info here.
So added the signature in /ets/root.keys, as second row.
Rebooted device (the service unbound restart does nothing, can’t remember correctly), run the updater.sh - but it still end up with:
curl: (22) The requested URL returned error: 404 Not Found
+ die Could not download list pack
+ echo error
+ echo Could not download list pack
+ echo Could not download list pack
Could not download list pack
+ echo Could not download list pack
+ my_logger -p daemon.err
+ logger -t updater -p daemon.err
+ kill -SIGABRT 3020
+ rm -rf /tmp/update /tmp/update-state/pid /tmp/update-state/lock /usr/share/updater/packages /usr/share/updater/plan
+ exit 1
+ rm -rf /tmp/update /tmp/update-state/pid /tmp/update-state/lock /usr/share/updater/packages /usr/share/updater/plan
+ exit 1
And opkg update as well:
curl: (60) SSL certificate problem: unable to get local issuer certificate
Signature check failed.
Remove wrong Signature file.
Collected errors:
* opkg_download: Failed to download https://repo.turris.cz/turris/packages//turrispackages/Packages.gz, curl returned 60.
This is for every repo url.
The content of root.keys changed - from 2 lines here (one original, one added by me) it ended up with:
"autotrust trust anchor file
;;id: . 1
;;last_queried: 1726094189 ;;Thu Sep 12 00:36:29 2024
;;last_success: 1726094189 ;;Thu Sep 12 00:36:29 2024
;;next_probe_time: 1726134248 ;;Thu Sep 12 11:44:08 2024
;;query_failed: 0
;;query_interval: 43199
;;retry_time: 8639
. 172800 IN DNSKEY 257 3 8 - some key XxxxxxxxxxxxxxxxxxxxX"
But situation still the same - so this does not help at all.
Therefore as no nor-update can be processed → no 3.8.5 → no possibility for BTRFS migration and latest OS(?).
From here and few another similar post it seems to me that some signature had to be downloaded rather manual update.
Unfortunately all the “wget http://217.31.192.101/openwrt-repo/turris/packages/turrispackages/” links with whatever could presumably help are no accessible to me.
Getting only
"Connecting to 217.31.192.101 (217.31.192.101:80)
wget: error getting response: Connection reset by peer"
for all of them.
The ‘217.31.192.101’ is dead, no PING response. From 2 networks.
So the unsecure noSSL source is not an option nowadays(?).
Searching for solution with the errors from wget/updater (in Foris/LuCI/serial cmd) found out this post - pointing mainly for this one.
So:
root@turris:# curl -kv https://repo.turris.cz/turris/packages/base/ca-certif
icates_20190110-1_mpc85xx.ipk
returning:
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
/*some more steps during - deleting it for readability/*
* TLSv1.2 (IN), TLS handshake, Finished (20):
> GET /turris/packages/base/ca-certificates_20190110-1_mpc85xx.ipk HTTP/1.1
> Host: repo.turris.cz
> User-Agent: curl/7.53.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.22.1
< Date: Thu, 11 Sep 2024 09:00:00 GMT
< Content-Type: application/octet-stream
< Content-Length: 129705
< Last-Modified: Mon, 13 Dec 2021 14:57:24 GMT
< Connection: keep-alive
< ETag: "61b75f54-1faa9"
< Strict-Transport-Security: max-age=31536000
< X-Frame-Options: SAMEORIGIN
< X-Content-Type-Options: nosniff
< Content-Security-Policy: default-src 'self' 'unsafe-inline' data:; frame-ancestors 'self'
< Accept-Ranges: bytes
and continue for a while printing this (few seconds):
ґ▒bhn▒▒~▒:Km▒1t▒?▒n▒▒▒4▒▒▒▒n▒m▒▒▒▒▒▒-+d▒▒▒ỡ}g4▒<Rؓ▒MZ%▒`▒
▒▒▒▒M▒?C{~5}▒{▒̐~3▒▒0u▒▒▒,▒_
▒c▒$r▒.▒▒l"▒0U▒=▒▒▒▒▒ri▒qv/▒=▒E▒*ٵ<
I*▒▒;▒▒n▒▒▒▒▒r▒#2,L▒▒^h▒q)▒{▒▒+▒w▒▒y▒Y▒q̝▒▒▒w<▒ӯ▒▒▒;`▒▒q▒x▒OʆTQ,▒▒?▒Ğ▒|_▒2▒▒▒▒i▒▒▒▒o▒▒▒▒▒▒▒`
ending:
root@turris:#
PuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPu
TTYPuTTYPuTTYPuTTYuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuT
TYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuT
If the process is uninterrupted - it ends like above, terminal unusable, not reacting on any key action, had to be terminated manually.
If interrupted - the usability of session remain but in both cases there is no file to be found (as in the dir I’m running curl).
This is the last meaningful step done - from here as the ca-certificates can’t be installed therefore I can’t download and use https://repo.turris.cz/turris/packages/turrispackages/updater-ng_61.1.5.4-3.6-1_mpc85xx.ipk to push myself at (presumably) 3.11.23 - meaning get the Turris OS on 3.8.5 at least.
From that point AFAIK the way is straightforward:
opkg update
opkg install turris-btrfs
btrfs_migrate
and finally
cd ~
wget https://repo.turris.cz/hbs/medkit/turris1x-medkit-latest.tar.gz
schnapps import -f turris1x-medkit-*.tar.gz
schnapps rollback factory
reboot
But no way I’m able to get here.
Somehow according at least this and this post seems to me it’s possible - given no more communication about this stuck scenario I’m in.
So far from perfectly working Turris 1.1 BTRFS (yes, due to my misconfiguration) ended up after reset on 3.8.5 and after SD image with 3.6.5.
(That is the the version inside image - because 3.8.5 is to big. 6.5 should be updated on 8.5 automatically but that is the past info possibly pre-that-key change).
No SSH except the console for both factory versions (no sshd in /cgi-bin/luci/admin/system/startup).
Now don’t now what to do - seems to me, that all the info here is pre-KSK rollover(?) so as this is really old device it’s now stuck in this old version of OS?
What will all users do when they press the reset button?
At least I’m capable to know that I don’t know.
It took me several hours to even get here.
Maybe I’m missing something obvious as in the process of doing it long one can’t see his mistakes?
(And well I’m not czech native so using translator for forum posts…).
@FWWW and @mamuf - how did you managed the update process?
–
Useful links for me (maybe for anyone ending up with Turris 1.1 after reset):
2 roky neaktualizovaný Turris 1.0
Nefunguje DNS, ale jen na Turrise
Nemožnost dostat se na SSH, nefunkční DNS
Cannot update Turris 1.1 after factory reset to 3.8.5 - updater.sh fails
Návod: Jak na Turrisu 1.x správně provést aktualizaci NOR a přechod na btrfs
Modry Turris potíže s připojením
Optional migration from Turris OS 3.x for advanced users
–
The official documentation related links: