Posts by chewitt

You can use a bind mount (in autostart.sh) to make it appear in /usr/bin/rsync

207094.html

^ currently on the 16th revision of the patch series, so probably a few revisions to go yet

Definitely not going to return.

Go read about "WannaCry" ..

No idea what the issue is, but the backup is just a tar archive so it can be extracted to a local folder and you can manually move back the important bits instead of the whole file.

RK3399 can work with panfrost but needs a mainline kernel .. so you hit some issues:

a) There's only partially working video drivers for mainline RK at the moment

b) Device-trees are for the mali blob and panfrost requires some changes

b) There are plenty of bugs (as with S912) that impact stability

So it works, but, YMMV

See http://opensource.rock-chips.com/wiki_status_matrix for the list of RK chips we can support. RK3228 is not on the list.

Our definition of a working driver is "doesn't need another out of tree realtek driver to be added" .. and since we plan to drop support for all wifi devices that don't have in-kernel drivers in LE 10.0 we're aren't in a rush to add more of them now.

As a random thing to try .. do you have any USB/external WiFi adaptors you can try?

Have a read of Infrared Remotes [LibreELEC.wiki]

The flirc case has an internal heatsink 'finger' that requires the SoC to be in exactly the same position as the RPi one so I suspect the answer is no, but I can't give you an answer until I finish a work trip in a couple of weeks time. The black case is awesome though..

Backporting media_build driver for support to the older 3.10 kernel is challenging and the main developer who works on that doesn't have a WP1 so the status is probably "could probably work but doesn't and isn't being tested" .. and I doubt that will change. That's probably not the response you'd like but that's the honest reality.

MikeKL the memleaks and other glitches are known to the panfrost developers. Panfrost still has a high overall rate of change and some of the leaks won't be resolved until a proper kernel driver evolves (at the moment we're still using a hacked version of the ARM driver). VIM2 lite WiFi should be able to work with the right combination of firmware/nvram files but VIM2 max was still lacking mainline driver support last time I looked; although that was last summer .. I'll get around to it eventually. No need for logs at this stage.

openssh: drop support for ssh-dss keys by chewitt · Pull Request #3316 · LibreELEC/LibreELEC.tv · GitHub

PROJECT=RPi DEVICE=RPi2 ARCH=arm scripts/create_addon customtest

^ that will build the add-on (assuming the package.mk is good) but this outputs the add-on zip file for an online repo. It does not embed the add-on into the image.

To save me looking at the debug logfile on a phone .. are you using the onboard Pi wifi or an external dongle?

Tos26 the log is good .. and appears to show connman attempting to connect to 0/1/2/3.pool.ntp.org servers. The DNS record for each host returns multiple A records and each time you query the ordering of A records in the response changes (aka DNS "round robin" load balancing). Connman picks the first entry in the list of A records and makes an NTP request to the server. If it gets no response it goes through the list of NTP servers and repeats. If it completes the entire list, it goes into a retry pattern that waits progressively longer before trying the list again. Eventually it hits "95.81.173.74" from 3.pool.ntp.org which responds and the time is adjusted. It will now continue to use that server unless it fails to get a response (and the process restarts) or you reboot the box (and the process starts again).

Connman devs modified the ntp workflow in the last year based on feedback we gave about common ntp failures on Pi hardware. I was involved in that and connman is following what I understand to be updated workflow. I can't explain why you get no response from 3-4 ntp servers before finally getting a response. Some ISP's do block NTP but they're not common and it tends to be a "block everything apart from our own server" and this looks to be more random.

Configure "95.81.173.74" as the only NTP server and reboot. Does that solve (work around) the problem?