For collectd, install luci_statistics and use /etc/init.d/luci_statistics start instead of starting collectd.
Reason: the collectd package init script assembles a configuration which ignores everything that’s being made in LuCi.
I just did opkg update
then opkg install luci_statistics and nothing has been found
Did you also configure the whole shebang in LuCi and got the whole collectd-mod-* installed? (I assume luci-app-statistics is also installed).
What do you mean?
#! - shebang? * - asterisk, or so called wildcard.
Should I install whole collect-mod?
And something else?
Sorry, it’s an idiomatic form for “the whole thing”. Well, not the whole collectd-mod but you should have some installed by default with statistics. Next you need to check in LuCi if they’re enabled.
This is what I have in my /etc/config/luci_statistics (I have installed a few more collectd modules in addition to the default ones):
config statistics 'collectd'
option BaseDir '/var/run/collectd'
option Include '/etc/collectd/conf.d'
option PIDFile '/var/run/collectd.pid'
option PluginDir '/usr/lib/collectd'
option TypesDB '/usr/share/collectd/types.db'
option Interval '30'
option ReadThreads '2'
config statistics 'rrdtool'
option default_timespan '1hour'
option image_width '600'
option image_path '/tmp/rrdimg'
config statistics 'collectd_rrdtool'
option enable '0'
option RRAMax '0'
config statistics 'collectd_csv'
option enable '0'
option StoreRates '0'
option DataDir '/tmp'
config statistics 'collectd_email'
option enable '0'
option SocketFile '/var/run/collectd/email.sock'
option SocketGroup 'nogroup'
config statistics 'collectd_logfile'
option enable '0'
option LogLevel 'notice'
option File '/var/log/collectd.log'
option Timestamp '1'
config statistics 'collectd_network'
option enable '1'
option Forward '0'
config statistics 'collectd_unixsock'
option enable '0'
option SocketFile '/var/run/collectd/query.sock'
option SocketGroup 'nogroup'
config statistics 'collectd_apcups'
option enable '0'
option Host 'localhost'
option Port '3551'
config statistics 'collectd_conntrack'
option enable '0'
config statistics 'collectd_contextswitch'
option enable '0'
config statistics 'collectd_cpu'
option enable '1'
option ReportByCpu '1'
option ReportByState '1'
option ValuesPercentage '1'
config statistics 'collectd_cpufreq'
option enable '0'
config statistics 'collectd_df'
option enable '0'
option Devices '/dev/mtdblock/4'
option MountPoints '/overlay'
option FSTypes 'tmpfs'
option IgnoreSelected '0'
config statistics 'collectd_disk'
option enable '0'
option Disks 'hda1 hdb'
option IgnoreSelected '0'
config statistics 'collectd_dns'
option enable '0'
option Interfaces 'br-lan'
option IgnoreSources '127.0.0.1'
config statistics 'collectd_entropy'
option enable '0'
config statistics 'collectd_exec'
option enable '0'
config statistics 'collectd_interface'
option enable '1'
option IgnoreSelected '0'
option Interfaces 'eth2 br-lan'
config statistics 'collectd_iptables'
option enable '0
config collectd_iptables_match
option table 'nat'
option chain 'luci_fw_postrouting'
option target 'MASQUERADE'
option source '192.168.1.0/24'
option outputif 'br-ff'
option name 'LAN-Clients traffic'
config collectd_iptables_match
option chain 'luci_fw_postrouting'
option table 'nat'
option target 'MASQUERADE'
option source '10.61.230.0/24'
option outputif 'br-ff'
option name 'WLAN-Clients traffic'
config statistics 'collectd_irq'
option enable '0'
option Irqs '2 3 4 7'
config statistics 'collectd_iwinfo'
option enable '1'
option IgnoreSelected '0'
config statistics 'collectd_load'
option enable '1'
config statistics 'collectd_memory'
option enable '1'
option ValuesAbsolute '1'
option ValuesPercentage '0'
config statistics 'collectd_netlink'
option enable '0'
option IgnoreSelected '0'
option VerboseInterfaces 'br-lan'
option QDiscs 'br-lan'
config statistics 'collectd_nut'
option enable '0'
list UPS 'myupsname'
config statistics 'collectd_olsrd'
option enable '0'
option Port '2006'
option Host '127.0.0.1'
config statistics 'collectd_openvpn'
option enable '0'
config statistics 'collectd_ping'
option enable '0'
option TTL '127'
option Interval '30'
option Hosts '127.0.0.1'
config statistics 'collectd_processes'
option enable '0'
option Processes 'uhttpd dnsmasq dropbear'
config statistics 'collectd_sensors'
option enable '0'
config statistics 'collectd_splash_leases'
option enable '0'
config statistics 'collectd_tcpconns'
option enable '0'
option ListeningPorts '0'
option LocalPorts '22 80'
config statistics 'collectd_thermal'
option enable '0'
option IgnoreSelected '0'
config statistics 'collectd_uptime'
option enable '1'
@einar do you have a backup from 3.x so I could look at it to found out what could go wrong in your case? I really do not see what could be the cause of the issues you experienced. There was never issue with syslog-ng but any custom configuration added to it might be incompatible with the new version and that might cause the syslog-ng to not start. Considering the network the switch configuration should be correctly migrated in most cases but there might be some cases I missed so your backup of configuration would be welcome in this regard.
@Comodore125 can you please share the 3.x and resulting configuration with me? (PM would be fine) I would like to investigate what went wrong with your network configuration as well.
Regarding the notifications. That is expected unfortunately but there should be at least one notification about the finished update at the end. The network access is, due to switch configuration migration, broken during the update and unconditional reboot is performed at the end to bring it back up. This causes none of the intermediate notifications to be sent and they are wiped on reboot (as right now we do not store notifications on permanent storage).
@cynerd Unfortunately I only have a backup of the 3.x configuration as I wiped everything with the medkit. It looked however like the system was a half-finished upgrade somehow. top also wasn’t working properly, for one. But due to logs not working I couldn’t figure out what was going on.
I can however send it if you want (I need to wipe a couple of private details there but that’s it).
@einar please do. The router should reboot itself automatically after all components are updated. Is that something that happened or did update in your case halt before that? (That would mean some big fault in updater as once updater is updated it is instructed to ignore missing packages and requests it can’t satisfy to prevent unfinished update)
So, I have tried this again after few months on my Turris 1.0:
Result - partial success after 3rd try:
- Via Foris. After hitting Save in Updater, green stripe about successfull settings, then erron in Foris page → 30s reset → wizard + update to 3.11.23
- Following instructions, via SSH - message about missing btrfs and SD Card. Didn´t know that it was even possible to install 3.11.23 outside the SD card. → installed btrfs
- Via SSH, installation was running about few hours, router became unreachable, no automatic reboot even after 8 hours. After removing of power supply, router was updated to 5.2.7
Result after update:
No wifi card was detected. Have been trying to: reset wifi settings, reboot to default settings (this didn´t worked at all), copying wireless settings from omnia, install additional CandelaTech wifi drivers via packages.
Nothing helped. So I have tried 30s reset again and I am back on 3.11.23 running from internal flash, then I gave it up for yesterday.
Is there any way to use some medkit copied to SD card with latest OS for Turris 1.x routers, which will fall to 5.x after reset?
Once you are on SD card you can import medkit as factory image (although you can’t rollback to it with normal factory operation) using wget https://repo.turris.cz/hbs/medkit/turris1x-medkit-latest.tar.gz && schnapps import -f turris1x-medkit-latest.tar.gz. To reset to 5.x factory then you have to run schnapps rollback factory.
If you have some free time I would be interested in to what failed in your case. The migration should work pretty reliably now, even on 1.0. The common cause is that either something went wrong such as not enough space on storage or Internet disconnect after initial updater update (which updates libc and thus breaks rest of the system). If you have some free time on your hand I would be interested in console logs to see what could go wrong in your case. Also if you get at least some sort of access to router after update but something just not work, running pkgupdate might fix it as it might finish update that way. On the other hand if the issue was only WiFi cards it might be just that you are missing drivers. Do you have only standard card possibly with upgrade pack or some other card? (although I suspect that you tried to install the correct drivers so I do not expect much)
So, it is enough, to get that factory image and router will boot to 5.x without messing with this update torture?
Honestly, I don´t know what went wrong, I have run pkgupdate many times before and after the update. Turris 1.0 is only as reserve for case, when my, or my parent´s Omnia will die, it has just default settings + one wifi network, nothing else. Wifi card in blue turris is original 2,4GHz card from Omnia, so it should be supported.
Will it be possible, in the future, to program the reset button to run that factory rollback?
It actually rebooted. But it did reboot into that non-functional state. Where should I send the configuration?
Hello @michalko58,
you can do the upgrade manually. Insert the blank SD card to the Turris and perform the factory reset to 3.11.23. Hook it up to the internet, update the package list by running opkg update and install the turris-btrfs package by running opkg install turris-btrfs
Now perform the migration to the btrfs by btrfs_migrate followed by reboot. After the reboot your system will be running from SD card. Follow now the steps outlined by @cynerd - wget https://repo.turris.cz/hbs/medkit/turris1x-medkit-latest.tar.gz && schnapps import -f turris1x-medkit-latest.tar.gz && schnapps rollback factory && reboot
Now you should run the latest stable TOS release.
@hagrid @cynerd thank you, this way it was much easier.
Only one thing, wget is not part of standard installation and it has to be added before.
It is a bi step so starting clean is also a good idea over migrating sometimes five years old configuration. At the same time, I can’t request that from all users so we have to attempt migration.
That would require the update of the rescue image that right now only unpacks factory image to internal storage. We might switch it to do a rollback to the factory on SD card if that is detected. It won’t be soon but it is possible to do that. At the same time (although it is not your request) I have to remark that it is not possible to implement boot modes as Omnia and Mox has.
@einar please PM it to me. If you are willing I would appreciate even exported snapshot as that would allow me to attempt migration with the same system as you had.
@cynerd OK, I’ll send it to you in a couple days (I need to expunge some details like private keys and what not; I’ll note them in the message I’ll send to you).
1 Like