No, the code block I posted shows the difference between my broken config (
-), and the new, working config (
I’m fairly certain that the
include_shell line(s) are what breaks the config.
Same problem here. No error message when running /etc/init.d/lighttpd start but the daemon does not start. Nothing in /var/log/messages/
What worked for me was to edit
/etc/lighttpd/lighttpd.conf to replace the last two lines:
include_shell "cat /etc/lighttpd/modules.d/*.load" include_shell "cat /etc/lighttpd/conf.d/*.conf"
include "/etc/lighttpd/modules.d/*.load" include "/etc/lighttpd/conf.d/*.conf"
Pity that it was not done automatically (and pity that lighthttp breaks the compatibiity).
Of course the replacement of
include works. But not for me. I used to not load SSL configuration from default but to use my one with my certificate.
Somethign must changed in upgraded lighttpd so now the config which was perfectly fine is no longer working.
In fact I played a bit and it seems not to be only issues of
include_shell itself but also the content of the files in
conf.d. Once I removed
foris-ws.conf it works again. At least the conifguration is startable and not complaining of syntax.
And pity it was not caught during regression testing of the update. Actually I can’t understand how is it possible that regular updates break even mostly “untouched” systems like mine… As far as I remember, it was not for the first time.
If the quality product releases I’m involved in were like this, MS Windows would be a super-seamless, super-safe, super-stable system compared to your cars! (OK, almost…)
When opting for the TO I didn’t think I should leave my current job, study hard to become a Linux guru and baby-sit my router on a daily basis to keep my basic infrastructure running…
Well, I just updated and restarted my Turris 1.1 and all works. No need to manually change lighttpd config.
Well, I just updated and restarted my Turris 1.0 and my Omnia too and all works. No need to manually change lighttpd config.
I hit an unusual issue where in 3.10.6 the storage plugin was no longer configured, and writes to /srv were hitting the internal flash. My external storage (connected to USB) was no longer detected by the storage plugin as storage it could use.
I removed the external storage, reformatted it and plugged in back into the Turris. At that point it was detected by the router and I was able to configure the storage plugin to use the external storage again.
Has anyone else seen this? It may be worth checking if you make heavy use of the storage plugin (eg for lxc)
must agree with you. Been waiting for vanilla OpenWRT support for quite some time as well.
The updates might bring something nice for most users but if you want something solid,
without much plugins and “Forises”, OpenWRT is the way to go.
after upgrade (Turris 1.0) no more usb devices:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
dmesg | grep usb
[ 2.735277] usbcore: registered new interface driver usbfs [ 2.740817] usbcore: registered new interface driver hub [ 2.746190] usbcore: registered new device driver usb [ 2.837036] usbcore: registered new interface driver usb-storage [ 2.843845] usbcore: registered new interface driver uas [ 18.898750] usbcore: registered new interface driver cdc_wdm [ 18.998716] usbcore: registered new interface driver ums-alauda [ 19.006228] usbcore: registered new interface driver ums-cypress [ 19.013922] usbcore: registered new interface driver ums-datafab [ 19.021438] usbcore: registered new interface driver ums-freecom [ 19.029025] usbcore: registered new interface driver ums-isd200 [ 19.036709] usbcore: registered new interface driver ums-jumpshot [ 19.044316] usbcore: registered new interface driver ums-karma [ 19.052334] usbcore: registered new interface driver ums-sddr09 [ 19.059870] usbcore: registered new interface driver ums-sddr55 [ 19.067685] usbcore: registered new interface driver ums-usbat [ 19.075432] usbcore: registered new interface driver usblp [ 19.091563] usbcore: registered new interface driver usbserial [ 19.097468] usbcore: registered new interface driver usbserial_generic [ 19.104053] usbserial: USB Serial support registered for generic [ 19.131945] usbcore: registered new interface driver cdc_ether [ 19.139999] usbcore: registered new interface driver ftdi_sio [ 19.145824] usbserial: USB Serial support registered for FTDI USB Serial Device [ 19.169749] usbcore: registered new interface driver qmi_wwan [ 19.177360] usbcore: registered new interface driver rndis_host [ 19.330915] usbcore: registered new interface driver option [ 19.336587] usbserial: USB Serial support registered for GSM modem (1-port)
lsmod | grep usb
mii 3736 1 usbnet ums_usbat 7408 0 usb_common 2381 1 usbcore usb_storage 43570 11 ums_usbat usb_wwan 5896 1 option usbcore 144292 29 option usblp 9072 0 usbnet 19267 3 rndis_host usbserial 19951 3 option
I’d like to speak about the configuration file of lighttpd, because somebody here complains that it that it wasn’t caught before releasing Turris OS 3.10.6 for everybody and that’s why we’d like to release Turris OS 3.10.7 soon, which will include at least 4 things:
- a new version of wireguard and kernel,
- fix for ath10k-ct,
- and what is the most interesting thing for you is the automatic change in lighttpd.conf to replace two lines with another.
I understand that it is quite annoying, but who didn’t touch lighttpd.conf then there shouldn’t be any issue caused by this release.
If you edit lighttpd.conf somehow that I’m so sorry for any inconvenience caused by this, but we can’t fix things, which we are not aware of. Somebody from our team is using a nightly branch on regular basis at home.
At work, we’re testing the release, if it is prepared to release it to RC. Once we released RC, we’re happy to hear any opinion about it.
When we released Turris OS 3.10.6 into RC and then also for everyone, I have been looking all the time to our support system to catch any email regarding the release, but none of them showed.
If you want, you can look into the thread about releasing 3.10.6 into RC. It’s unfortunate that nobody didn’t mention this issue. Even you have the opinion to improve future release(s) when you decide to opt-in for RC.
If I’m not mistaken OpenWRT would replace the file with a new one without doing a backup of the file, which it replaced and it will do without any permission.
For example, I have as somebody of you know Turris 1.1 at home and I didn’t need to do any change and everything went smooth. Even I have two routers at work for testing and playing with them and still, I didn’t come to lighttpd issue, which was reported to us on Friday.
This issue might not be related to this release as this cannot be solved on our forum. Would you please reach us at email@example.com?
Also, please include diagnostics, which you can generate in the administration interface Foris.
Looking forward to hearing from you,
regarding WiFi tab in Foris:
Would you please tell me, if you have swapped WiFi cards?
You might have in /etc/config/wireless one network or radio, which you don’t use and it shouldn’t be there. Once you’d remove it, then the tab will work for you. I’m ready to help you if you reach me on firstname.lastname@example.org
Can I know if the Data collection and the Cloud Backups works for you after restarting your router?
The notification for you should appear to you once you reboot your router. There are many cases, when you don’t want to run LXC containers on the storage from which are you booting as it means to unscrew the top case, unplug RAM and remove microSD card and insert it the new microSD card, plug the RAM back and screw the top case. Sometimes it could be very difficult to unplug the router.
I hope you can understand, why the notification is there, and we can understand that you don’t like it, while you’re booting from microSD card. We’ll try to improve it in future releases.
This is odd. Would you please run in the terminal following commands and send us the compressed file, so we can take a look closer on it?
pkgupdate -e TRACE 2>&1 | tee updater.log gzip updater.log
Just getting back into this topic. A tornado destroyed the main electrical substation for the city and I was out of power for 3 days.
Anyway, my lighthttd.conf issue was:
root@turris:/etc/lighttpd# /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf Duplicate config variable in conditional 0 global: rrdtool.binary 2018-09-24 09:47:37: (configfile.c.1289) source: /etc/lighttpd/conf.d/local.conf line: 3 pos: 1 parser failed somehow near here: (EOL)
(my conf file was already using
include and not
local.conf's content was simply setting
rrdtool.binary so on a whim I did
mv /etc/lighttpd/conf.d/local.conf /etc/lighttpd/conf.d/local.conf_old
and I was able to restart lighttpd after a reboot.
local.conf still in use? Am I shooting myself in the foot in the near future?
OK - yes as part as my internal flash dieing I installed a SSD and moved one of the radio cards. Upon inspection of the wireless config there was indeed a Radio2 entry sharing the same path details. Upon removing that the wifi config page now works
I think the wiki page needs some more info on other things to watch out for when adding an internal SSD. Ensuring the wifi config paths match the new location of the radio card and that no new entries have been added probably need highlighting.
Any idea on a fix for the data collection page?
The lighttpd config issue is specific to people who have changed the config file, and would not show up in any standard configuration systems (as your test subjects most likely where in this case).
Not when the file in question has been marked as a config file (which
/etc/lighttpd/lighttpd.conf is), and that config file has been changed (checksum no longer matching).
This is working like intended, as you, as a package manager, don’t want to destroy user configs.
# opkg info lighttpd Package: lighttpd Version: 1.4.50-2 Depends: libc, libopenssl, libpcre, libpthread Status: install user installed Architecture: mvebu Conffiles: /etc/lighttpd/lighttpd.conf 73511417d45a9fd89ae3ab9125e841467e14c66e0db004e37a7252196085edda Installed-Time: 1537452822
I’ll get the update log to you ASAP. Let me know best email address to send to you…
There is a bug in a just released 3.10.6 minidlna. If you add a new media file, minidlna got a sigsev. It’s 100% repeatable.
[2018/09/25 19:45:20] minissdp.c:309: maxdebug: Sending ssdp:alive  [2018/09/25 19:45:20] minissdp.c:309: maxdebug: Sending ssdp:alive  [2018/09/25 19:45:24] monitor.c:709: debug: The file /mnt/voo_black/test.mp4 was changed. [2018/09/25 19:45:24] monitor.c:396: debug: Adding: /mnt/voo_black/test.mp4 Segmentation fault root@turris:~#
MiniDLNA crash after copy movie file
Please send it to email@example.com, and we’ll look at it.