Frostbyte

I guess that will give me the peace of mind that I need. Good thing I kept configuration backups! Thank you for the assistance.

Instantly, sadly..

I see, thank you for the insight so far. I'll see what I can do with it and hopefully I will have something to share back.

Everything is commented out here too, but from what I know - commented values are the default ones, unless manually overridden. In the case of "Storage" it's comment reads "auto", thus means that it'll collect journals if it finds a /var/log/journal folder, otherwise it will do nothing. The manual entry for journald.conf describes the configuration under /etc and I have already perused it. I tried to stop journal collection by setting the Storage value to "volatile" and "none", each without success. After a reboot it will be filled to the brim again. The odd thing here (at least for me) is that when I delete the contents of /var/log/journal but not the folder itself, journal collection will halt. So I have to do this every reboot or set up a crontab (too hacky of a solution for my liking). The underlying folders and files appear to be random hexadecimal jibberish, how do we know where they originate from? Also, I suppose I will ask this too: We obviously run a risk if we turn the journal off and thankfully I have my device on a UPS.. but even these can go out during long outages. I remember that the TinkerBoard survived plenty of power outages and crashes when I had it with the Xenial image, that one had it's journaling off by default, no? I always keep backups; but I'd rather avoid accidentally/unwillingly tearing it a structurally superfluous new behind, as my reasoning to use them.

Excuse me if I'm being ignorant at this point, but if the journal is supposed to be off in the first place, then do it's contents really matter at this point? How can I turn it off if it's not obeying the configuration? Am I missing something? Do I have to turn it off somewhere else? Also, I will need to do some RTFM before I'll be able to decipher the contents, any pointers will be most welcome.

No one? Or at least an image recommendation that's latest?

Sorry if this has been posted before. Today I took the liberty and upgraded to 18.04.1 LTS via do-release-upgrade. I'm noticing that /var/log almost immediately fills up by the journal, no matter how many times I delete it (I know you're not supposed to delete the filesystem journal) Reaching 100% usage on /var/log causes a multitude of problematic behaviors (i.e. apt-get breaks) user@TinkerBoard:/var/log$ df -h Filesystem Size Used Avail Use% Mounted on udev 1000M 0 1000M 0% /dev tmpfs 201M 16M 186M 8% /run /dev/mmcblk0p1 29G 6.4G 23G 23% / tmpfs 1004M 0 1004M 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1004M 0 1004M 0% /sys/fs/cgroup tmpfs 1004M 4.0K 1004M 1% /tmp /dev/zram0 49M 48M 0 100% /var/log tmpfs 201M 0 201M 0% /run/user/1000 user@TinkerBoard:/var/log$ du -hsc /var/log/journal 48M /var/log/journal 48M total Changing the SystemMaxFileSize value (i.e. to 30M) on /etc/systemd/journald.conf does not make the journaling system obey - it still fills up (even after a reboot).

That's very nice to hear! Good job everyone!

Has anything been changed, in regards to stability or voltage control, with the last couple of kernels? My board is being surprisingly stable, currently with an up time of 35+ days. *knocks on wood*

Thanks!

Are these kernels out of beta? I do a dist-upgrade and see nothing as of yet, still on 4.11.6

I've just finished writing my SHT31-D (I2C) Nagios plugin. As promised, it can be found here for anyone else interested.

Are there any instructions available? Any precautions, etc? Thanks. PS: In the meantime, can I somehow downclock the SoC a little bit? Would that help any?

My tinker board appears to have crashed again after 1.8 weeks of uptime. Power supply is the micro-USB "official" RPi one, and it's rated at 2.5A , the SD card appears to be fine. Symptoms: Only the red led was powered on, I had no green (I/O) or yellow led (heartbeat) activity. When removing the power cord and reinserting it, it would power-on for a couple of seconds and then it would power-off by itself. I left it powered-off for around 2 minutes and then powered it on and it's working ok so far. I checked my graphs and I see that over the course of the last 2 weeks, the CPU was sustaining temps between 61-65.5 °C. Right now I'm noticing a 74°C temperature spike, which is slowly coming down to the previously observed temperatures. (This graph displays the last 24h) I'm not sure why the CPU raises it's temperature if the system has crashed. I've also reviewed the syslog and kernel logs, but I cannot find anything that would point me to the cause of the crash. It also must've refused to start because it was overheated, but why does it always work fine for almost two weeks and then suddenly decides to die? I would appreciate any pointers to help me investigate. Using mainline kernel. root@Tuxbox:~# lsb_release -a && uname -r No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.2 LTS Release: 16.04 Codename: xenial 4.11.6-rockchip

Ah okay, thanks for clarifying - I'll wait then.

It doesn't appear to be. I ran apt-get update, upgrade and dist-upgrade and I get the following: root@Tuxbox:~# uname -r 4.11.5-rockchip Perhaps it's not going to reach the repo until it's thoroughly tested?

Any clue when we can expect the 4.12.3 kernel to hit the repo? It still has the 4.11.5-rockchip one.

I am aware that this board has severe powering issues when using the USB power connector.. After struggling a lot to find a reliable PSU, I ended up buying the "official" RPi PSU that's supposed to provide 2.5 amps, however I still get a shutdown once every 2.5-3 weeks. (I suspect it's power) Are these patches going to improve this by any chance, or will I forced to craft and use a 3A GPIO PSU? I'm kind of reluctant, because I've heard that there are no fuses/protection in the GPIO and you can easily toast the board that way. The reboot fix will be awesome, however. PS: I'm also coding a nifty little Nagios check for the SHT31-D I2C sensors that just arrived, when my friend takes care soldering the pin headers and making the wires for me, I expect to get it on github soon.

So, until I get an I2C sensor to play around with; I decided to not let my existing DHT22 to go to waste. I studied the wiringPi library a little bit and came up with my own DHT22 nagios plugin. It can be found here for anyone else interested.

These two I2C buses on the Tinkerboard GPIO header that you're speaking about, are these dependent or independent of the CPU? I plan on measuring values once every minute, so I guess I won't need to run it at high speed. Thanks for all the info, it's really been helpful!

Incredible find, I may just go get a couple of HTS221 to replace my DHT22 then. I would like however to pose the following questions (excuse my ineptitude, as I'm fairly new to sensors): Since you mentioned that the current adafruit implementation may return garbage if another process takes over the CPU while the sensors are being read, are I2C-based sensors also susceptible to that? From my understanding I2C uses some sort of special bus, but how exactly does this all work out? Does it interface with the kernel to figure out what to do? (instead of talking directly with the GPIO) If it's main purpose is to be hardware-agnostic, in theory it should work for every system that there's kernel support for it, right? In order to use it, do I just plug the necessary cables to designated pins (like 3.3v, GND and Data), and just run a sensor check specifying the GPIO # and the sensor type? (I see that Nagios has a designated check_sensor plugin) I've read that there are some cable-length limitations with I2C, I currently use 1-meter wires, will I face a problem? Do sensors share the bus? Can I use multiple I2C sensors on the same board? Provided I have enough GPIO pins and power to feed them. Thanks in advance.

I just happened to use it on the RPi3 simply because it was more accessible and easy to install. My sensor is a DHT22. I could try the code in the last link you provided, but I'm afraid that it won't work as it's not designed for the tinkerboard. I had a read on the available ASUS.GPIO code here and here, to see if I can get any hints on how I can modify the pdif2_DHTXXD to work with the tinkerboard, but I just can't understand anything..

Nah they don't read off of the CPU. DHT11/DHT22 are environmental sensors that you connect to the GPIO. They provide temperature and humidity readings wherever you place them.

Any chance someone could include support for the tinker board on this? I've already asked on the adafruit forums and they shot me down. I tried meddling around to see if I can do it myself, but my coding skills are not up to par.. my brain got fried once I reached the actual GPIO parts.