Toto dostavam v poslednej dobre, obnovoval som setup aj z medkitu … ci uz na 3.5 (kde som robil medkit restore), alebo aj po update na 3.6. Instaloval som Netdata, ktore podla GUI nainstalovane nie je, no ide 
skus nainstalovat netdata cez terminal
opkg update
opkg install netdata
netdata // tym ho spustis
potom bude dostupny netdata interface na adrese http://192.168.1.1:19999 tato verzia balicku netdata je ale dost stara
edit aha sry pisem na tablete nevsimol som si ze ti to ide… ten segmentation fault som dostaval aj ja
No praveze vyzera ze sa vsetko nainstalovalo a funguje, ale neni to nasledne ani v zozname, no ist to ide … vyzera ze tam je total nesuhlad medzi LuCi a realom, co si fakt neviem predstavit ako je mozne.
Je niekde novsia verzia netdata? Co som lahko googlil tak som nenasiel
Zhruba před měsícem někdo vytvořil pull request pro nejnovější verzi netdata a už je to mergle v OpenWRT - https://github.com/openwrt/packages/pull/3928
Bohužel se to stále nedostalo do TurrisOS.
Planuji se dva způsoby:
a) Ondřej Surý se pokouší o zprovoznění TurrisOS na aktualni verzi LEDE. https://github.com/CZ-NIC/turris-os/issues/50
b) miska plánoval aktualizaci všech balíčků do release 3.7 - https://gitlab.labs.nic.cz/turris/turris-os-packages/merge_requests/17 / https://gitlab.labs.nic.cz/turris/openwrt/issues/38
Každopádně pokud by si rád měl aktuální netdata, tak jsou dva způsoby:
- zkompilovat si ho sám.
- stáhnout .ipk z dev tree OpenWRT a doufat, že to bude fungovat
One month ago somebody did pull request for latest version of netdata (https://github.com/openwrt/packages/pull/3928)
It still didnt get into TurrisOS.
There are three options:
- You can compile it by yourself.
- download it from OpenWRT and you can hope it will work
- wait
1 Like
vdaka
thanks
Tak tohle pozoruju i u sebe, objevuje se to prakticky u všeho, co jsem se pokoušel na instalovat přes LuCI. V terminálu není problém. Objevilo se to ve “stabilní” verzi 3.6, v nightly verzích s tíhto problém nebyl.
Tak asi před týdnem se u mně poprvé objevil problém “Segmentation fault”. Zatím na tento problém nebylo nalezeno (pokud čtu dobře forum) řešení ?
So about a week ago, I first discovered the problem of “Segmentation fault”. So far on this issue could not be found (if I read well forum) solution?
I think it will be useful, when you will report this issue to them via email.
I would guess, if this isnt relevant to the
setenv.set-environment = ( "PATH" => "/usr/bin:/usr/sbin:/bin:/sbin" )
which was added to lighttpd config since 3.6. And it doesnt work correctly, according to lighttpd log.
Anyway, installing packages through opkg (that means also Luci) isnt good idea. Much better is use updaters user.lua (/etc/updater/user.lua), in your case
Install "collectd-mod-thermal"
and then run /usr/bin/updater.sh
That way updater will be aware of your custom packages, and you dont loose them after each update. That should be mentioned on the official wiki page. Turris team are aware of problem opkg raw use VS updater. And since they need force users to use updater (far less problems through updates), I think this isnt emphatised enough.
Simple custom field or basic UI in foris, which would edit user.lua will be solution for those, who doesnt know opkg/ssh etc. I mean user would be able to write there custom modules, which want install and preserve during updates. There are groups of their packages (nas, majordomo), which is fine, but there are far many more plugins usefull for end users.
Also I recommend add those lines into /etc/config/updater. You will have opportunity to check new configs, delivered by updater against your and decide, if change is welcomed or not.
config override 'override'
option disable '1'
P.S.: thermal package doesnt work within luci - doesnt show graphs.
Thank you for the advice and I’ll try.
Using the updater is for the “experienced user”. Installation via the LuCI is suitable for a normal (common) user.
I assume that the final status of LuCI will be such that the installation package will be possibly as follows
Imho your info isn’t 100% correct because all packages I installed through opkg are listed in /etc/updater/auto.lua so updater should take care of them.
it can be… I start using Omnia since 3.5 I think, and my packages was wiped out. Its good news, if this already take care of them… But anyway, sureness is sureness. Anyway, thanks for info, I wouldnt like to spread misinterpretation…
my auto.lua contains
-- A file with auto-generated Install commands. Do not edit.
I am not sure, if thats related to opkg install commands, or updater install commands (at the end, this is conf for updater). Actually, contents of auto.lua is different from my user.lua, so I am unsure how those works against each other and opkg 
It could be that way it lists only opkg installed packages, as you stated, and user.lua’s installs arent tracked at all.
Guys please write Czech/Slovak, this is not EN part of forum, thanks
Pani, prosim piste po Cesky/Slovensky, toto nie je Anglicka cast fora, dakujem
1 Like