Turris OS 3.8.2.1 pro Turris 1.x je venku

commar · October 5, 2017, 12:59pm

Poznatky pište sem…

vlk · October 5, 2017, 1:03pm

Nemám co psát, vše, zdá se, funguje na první dobrou… Turris v1.0, UBIFS, BTRFS. Rád bych se na Vás, chlapce statečné, přijel do Prahy podívat, ale mám to z OV trochu z ruky a zlobí mě nějaký bacil, tak aspoň přeju ať zvítězí ten nejlepší Turtrisák

Vaclav · October 5, 2017, 2:13pm

Ještě dodám změny, které jsou obsahem 3.8.2.1, která šla ven jen pro Turrisy 1.x.

Oprava flashování kernelu na Turrisu 1.0
oprava instalace kernelu po migraci na btrfs

Tedy řešení obou chyb, které přišly s 3.8.2. Pokud jste obdrželi aktualizaci na 3.8.2 a ještě nerestartovali, 3.8.2.1 Vás zachrání.

Nones · October 5, 2017, 2:18pm

Děkujeme, děkujeme, děkujeme!

Vaclav · October 5, 2017, 2:18pm

Děkujeme za trpělivost.

mkyral · October 5, 2017, 4:16pm

Jsem z FM, na LinuxDays jedu. Mám ti něco přivézt?

vlk · October 5, 2017, 4:27pm

Hehe, díky za nabídku … baterku jsem měnil nedávno, SD kartu mám také svou (tleskám Turris týmu, i taková drobnost se počítá a o něčem vypovídá), všechny ostatní dárečky si zaslouží @Nones, tak snad už jen za mě jim to nandej v tom Turtrisu

qxstyles · October 5, 2017, 5:44pm

Děkuju za řešení. Nakonec se to podělalo i mně - potažmo routeru u rodičů. Naštěstí jsem narychlo před odjezdem do Německa před dvěma týdny dodělal ten přechod na BTRFS (kartu a předešlé kroky jsem měl již hotové) a vytvořil i snapshot. Bohužel byl asi problém s elektrikou či co a router se zrestartoval a celej den rodičům nešel internet. Nakonec jsem tátu navigoval po telefonu - rolbacknul přes PuTTY a zbytek jsem po restartu dodělal přes vzdálenou plochu (snapshot 3.8.2.1 a nastavení Aktualizace je nutné schválit). Jedna věc mě ale zaráží, jak je možné, že se to nainstalovalo když to tak bylo nastaveno i předtím? Slouží to snad k jen pro ty dodatečné balíky či co, nebo je chyba na mém příjmači? Nechci to nějak moc řešit - už vše šlape jak má, moc to nakonec nebolelo, ale spíš mě zajímá jestli je to vlastnost nebo nějaká chyba, aby se to případně nějak příště ošetřilo.

S474N · October 5, 2017, 9:14pm

Aktualizace probehla, provedl jsem restart a od te doby se zblaznilo DCHP. Vsiml jsem si v logu, ze je spousta podobnych a opakujicich se warningu:

2017-10-05T22:57:41+02:00 warning odhcpd[5063]: received DHCPV4_MSG_REQUEST from XX:XX:XX:XX:XX:XX
2017-10-05T22:57:41+02:00 warning odhcpd[5063]: sending DHCPV4_MSG_ACK to XX:XX:XX:XX:XX:XX - 192.168.100.250
2017-10-05T22:58:37+02:00 warning odhcpd[5063]: received DHCPV4_MSG_INFORM from XX:XX:XX:XX:XX:XX
2017-10-05T22:58:37+02:00 warning odhcpd[5063]: sending DHCPV4_MSG_ACK to ff:ff:ff:ff:ff:ff - 255.255.255.255
2017-10-05T23:01:57+02:00 warning ucollect[6384]: epoll_wait on 3 interrupted, retry
2017-10-05T23:04:48+02:00 warning odhcpd[5063]: received DHCPV4_MSG_DISCOVER from XX:XX:XX:XX:XX:XX
2017-10-05T23:04:48+02:00 warning odhcpd[5063]: sending DHCPV4_MSG_OFFER to XX:XX:XX:XX:XX:XX - 192.168.100.218
2017-10-05T23:04:48+02:00 warning odhcpd[5063]: received DHCPV4_MSG_REQUEST from XX:XX:XX:XX:XX:XX
2017-10-05T23:04:48+02:00 warning odhcpd[5063]: sending DHCPV4_MSG_ACK to XX:XX:XX:XX:XX:XX - 192.168.100.218
2017-10-05T23:04:54+02:00 warning odhcpd[5063]: received DHCPV4_MSG_RELEASE from XX:XX:XX:XX:XX:XX
2017-10-05T23:05:02+02:00 warning watchdog: Restarted nethist
2017-10-05T23:05:08+02:00 warning odhcpd[5063]: received DHCPV4_MSG_REQUEST from XX:XX:XX:XX:XX:XX
2017-10-05T23:05:08+02:00 warning odhcpd[5063]: sending DHCPV4_MSG_ACK to XX:XX:XX:XX:XX:XX - 192.168.100.7
2017-10-05T23:08:37+02:00 warning odhcpd[5063]: received DHCPV4_MSG_INFORM from XX:XX:XX:XX:XX:XX
2017-10-05T23:08:37+02:00 warning odhcpd[5063]: sending DHCPV4_MSG_ACK to ff:ff:ff:ff:ff:ff - 255.255.255.255

Kdyz jsem se podival do LuCi, tak v Sit > Aktivní propůjčené DHCP adresy (leases mam vsechny zarizeni petkrat, vzdy je stejna IP, jen vzdy konci /32, MAC adresa je bez dvojtecek a hlavne leasetime je 7410d 6h 1m 21s.

Tak nejak se descim, co me jeste ceka.

Bendys · October 6, 2017, 7:49am

Turris 1.0 s BRTFS update na 3.8.2.1 proběhl ok.
Pokusu o mountovaní disku přes LUCI končí stále s chybou

http://192.168.1.1/cgi-bin/luci/admin/system/fstab

/usr/lib/lua/luci/util.lua:610: Unable to establish ubus connection
stack traceback:
[C]: in function ‘assert’
/usr/lib/lua/luci/util.lua:610: in function ‘ubus’
/usr/lib/lua/luci/dispatcher.lua:347: in function ‘dispatch’
/usr/lib/lua/luci/dispatcher.lua:141: in function </usr/lib/lua/luci/dispatcher.lua:140>

Odstřelí to webserver a SSH cko po restartu ok.

miska · October 6, 2017, 8:40am

Jop, tohle jeste neni vyreseny, LuCI mountovani pro majitele starych Turrisu s Btrfs nefunguje. Bude treba nejak vyresit kdo pouziva kartu jen jako uloziste a kdo na ni ma system a zakomponovat to nejak do LuCI.

Tenhle update resil aby se lidem co jeste nerestartovali nerozbil router, mountovani pres LuCI po migraci na Btrfs ma mensi prioritu nez veci co ovlivni vyznamne velkou cast uzivatelu.

Michelle · October 6, 2017, 8:40am

Mám to samé. Při mountování flash disku přes Luci mi to odpojí i MicroSD odkud spouštím systém s BTRFS a musím restartovat. @miska kouknete na to? Mám zkusit poslat nějaké logy, nebo se o tom ví?

ocko · October 6, 2017, 8:54am

@miska to se týká jen verze 1.0 ? Na 1.1 s BTRFS mám přes luci mountnuté dva disky a vše OK

Michelle · October 6, 2017, 9:48am

Nám se automaticky mountne také, ale když chci provést jakoukoliv změnu v LuCi (přimountovat, odmountovat), tak to crashne a odpojí vše včetně MicroSD odkud běží systém… takže restart nutný.

Pepe · October 6, 2017, 9:53am

Na tohle přesně sedí reakce @Nones , který má pravdu.
https://forum.test.turris.cz/t/turris-os-3-8-2-je-venku-dns-a-bezpecnostni-opravy/5172/3?u=pepe

Ten, kdo má BTRFS, tak si bude muset počkat a tohle přetrpět než to @miska opraví.

miska · October 6, 2017, 11:16am

Tyka se to vsech modrych Turrisu, mountovani pres nastaveni v uci funguje, v LuCI se to v nejaky okamzik rozsype, to LuCI se chova k tem diskum trochu divne, tusim kde to opravit, casem vymyslim jak a nejak to opravim.

S474N · October 6, 2017, 3:59pm

Tak jsem si s tim zkousel hrat, po restartu mi ve vypisu je v LuCi kazda IP celkem 16x s opetovne nesmyslnym leasetime.

Mimo to se mi v logu zacaly dost mnozit tyto zaznamy:

2017-10-06T17:53:02+02:00 info kernel[]: [  185.701405] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:02+02:00 info kernel[]: [  185.716881] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:07+02:00 info kernel[]: [  190.616244] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:07+02:00 info kernel[]: [  190.631553] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:12+02:00 info kernel[]: [  196.381710] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:12+02:00 info kernel[]: [  196.399923] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:17+02:00 info kernel[]: [  201.243825] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:17+02:00 info kernel[]: [  201.257457] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:22+02:00 info kernel[]: [  206.219178] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:22+02:00 info kernel[]: [  206.235097] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:27+02:00 info kernel[]: [  211.358058] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:27+02:00 info kernel[]: [  211.376727] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:32+02:00 info kernel[]: [  216.266410] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:32+02:00 info kernel[]: [  216.281550] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:37+02:00 info kernel[]: [  221.224309] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:37+02:00 info kernel[]: [  221.243439] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:42+02:00 info kernel[]: [  226.429242] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:42+02:00 info kernel[]: [  226.444191] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:47+02:00 info kernel[]: [  231.229406] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:47+02:00 info kernel[]: [  231.243972] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:52+02:00 info kernel[]: [  236.211441] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:52+02:00 info kernel[]: [  236.228147] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:57+02:00 info kernel[]: [  241.402214] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready
2017-10-06T17:53:57+02:00 info kernel[]: [  241.417008] IPv6: ADDRCONF(NETDEV_UP): tmp.radio0: link is not ready

Je to zvlastni, protoze WiFi mam uplne vypnute.

Da se nejak vyresit to dodrbany DHCP a pripadne, jde nejak opravdu trvale zakazat IPv6 uplne vsude?

S474N · October 6, 2017, 4:13pm

Pri prochazeni logu jsem jeste narazil na tohle:

> 2017-10-06T17:50:39+02:00 crit dnsmasq[7953]: illegal repeated keyword at line 10 of /var/etc/dnsmasq.conf
> 2017-10-06T17:50:39+02:00 crit dnsmasq[7953]: FAILED to start up
> 2017-10-06T17:50:39+02:00 notice kernel[]: [   13.269438] Key type dns_resolver registered
> 2017-10-06T17:50:40+02:00 emerg syslog[]: lt_dlopen ("/usr/lib/collectd/dns.so") failed: file not found. The most common cause for this problem are missing dependencies. Use ldd(1) to check the dependencies of the plugin / shared object.
> 2017-10-06T17:50:40+02:00 emerg syslog[]: Unable to load plugin dns.
> 2017-10-06T17:50:40+02:00 emerg syslog[]: Found a configuration for the `dns' plugin, but the plugin isn't loaded or didn't register a configuration callback.
> 2017-10-06T17:50:44+02:00 crit dnsmasq[9024]: illegal repeated keyword at line 10 of /var/etc/dnsmasq.conf
> 2017-10-06T17:50:44+02:00 crit dnsmasq[9024]: FAILED to start up
> 2017-10-06T17:50:45+02:00 crit dnsmasq[9193]: illegal repeated keyword at line 10 of /var/etc/dnsmasq.conf
> 2017-10-06T17:50:45+02:00 crit dnsmasq[9193]: FAILED to start up
> 2017-10-06T17:50:45+02:00 info procd[]: Instance dnsmasq::instance1 s in a crash loop 6 crashes, 0 seconds since last crash

commar · October 6, 2017, 4:13pm

Ahoj, ty dlouhý časy v DHCP mi to dělalo taky, myslím že mi chyběl nějaký parametr v /etc/config/dhcp, porovnej to s dhcp-opkg který ti tam asi zanechala aktualizace. Pravděpodobně se něco změnilo.
EDIT: a nepomáhal restart, pomohlo jen úplné vytažení ze zásuvky…

S474N · October 6, 2017, 4:49pm

Ten soubor je pomerne jiny, hlavne tam neni tohle:
> option dhcpscript ‘/etc/resolver/dhcp_host_domain_ng.py’

Vytazeni ze zasuvky nepomohlo, je to tam porad.