Don Pedro

This seems to work, however on Armbian you need to set SystemMax... and RuntimeMax... as well (likely because it's logging to a RAM-disk first). Then it does have the desired effect.

This might be a solution! I'll wait for some time to see if the flooding has gone away and afterwards mark your answer as solution.

Hello, I have a few small questions: Cubietruck with latest Armbian Two log folders, /var/log and /var/log.hdd, the first kept in RAM that's regularly copied to the SD-Card, keeping the wear of the SD small This used to work flawlessly, I don't know when this changed Lately I realized that the RAM-disk is flooded very quickly by something that is writing to /var/log/journal/random_hex_number/ until it runs OOM. Almost all other logs are empty, likely because a lot more gets written to the journal log. Unfortunately the content of all files in the journal subfolder contain binary data, the only commonality I see is that all files start with "LPKSHHRH". So I'm unable to find out what daemon is writing to them, why it is writing that much and if this has a reason. If I delete these log files it gets recreated. So my questions are: How to find out who is writing to that folder? Why does so much get written? Is it important what is logged there? If I can't see everything I would prefer to see what should get written to the other log files, instead of big files in journal, that might be of little value. Any idea what's wrong here and what could be done to stop it?

I know. My boot.cmd also contains crap :-/ Recreating boot.scr was my first attempt. But as we engineers say: Junk in, junk out. Is that already a FIFO? ;-) I extracted boot.scr from the original armbian image. I also was able to create one on a Linux machine alternatively. However when I realized even more files got corrupted I decide to dump the installation on the SD-card, you never know what other files were corrupted and I'm not keen on a semi-broken system showing mysterious errors. Of course a quality card doesn't mean it ain't gonna die one day. Plus SD card has the disadvantage that it can't be trimmed like an SSD. However this card is not old, I just setup the whole system (not upgraded) a couple of weeks ago, the card was newly bought for that purpose. I will check it with a test program before reinstalling the OS. Edit: I tested the card with Heise's H2testw and it found broken areas on the card. So it seems my card is broken. I will pick a new one and reinstall the OS. THX Don

Hello, after the usual apt update/apt upgrade the OS requested a reboot. However it then fails to boot. Here's the output of the console: I guess the critical stuff is what I marked in bold? So what happened here and what to do to recover? Not keen to reinstall the whole OS... Edit: I pulled th SD-Card and read it from a Linux PC. When I take a look at /boot/boot.scr it is clearly corrupted! If I'm correct there's binary data inside, however in the hexdata I can see some segments with ASCII text fragments inside that releates to my private data (e.g. names of mp3 files!!) and that shoud definitely not be in boot.scr. So whatever happened, something during apt update/upgrade killed the boot.scr - and hopefully nothing else. Can I somehow repair boot.scr without reinstalling the whole OS? My Cubietruck is on Stretch. Edit: Further analysis showed that several more files than just boot.scr from /boot have been corrupted, where originally was a script there's binary junk now. So probably I need to reinstall the OS, as I cannot know which files were destroyed. The question here of course is what did corrupt all those file in /boot? I'm aware that I might never find out. The SD Card used is not a no-name product, it's an emtec (http://www.emtec-international.com/de/home), so this should not be due to a crappy card. So what remains is a stale feeling about the system suddenly dying... :-// THX Don

Done! https://github.com/armbian/config/issues/18

Yep, I did it via arbian-config, correct. Running it as root comes from the installer there. I'll open an issue on github, sure.

I can check that, sure: Syncthing has no debug option set and also no verbose switch. So I don't have a problem with its chattiness, it's just possible that it does a lot of things and thus generating a lot of log entries. But as already mailed, I found the source of the problem . THX anyway!

I found the cause of the problem myself! Syncthing does write a lot of log entries, depending of what it does. So it happens very easily that it floods the small 40M partition of log2ram. Things get totally stuck then, as with a 100% filled partition logrotate fails as well: It cannot compress logfiles anymore and bails out. You end up with a clogged logging and a failed log rotation, stuck eternally without manual interaction. The solution here is: Manually delete two or three of the oldest or biggest log files Enforce a rotation: logrotate /etc/logrotate.conf -f Edit or create a /etc/logrotate.d/synthing and set it to daily rotate and a maxsize of let's say 10M Then during the next couple of days check how the log size develops, if necessary rotate more often and/or limit the logfiles to smaller sizes. HTH Don

Hello! This thread here: https://forum.armbian.com/topic/3728-varlog-varloghdd/ triggered the question in me how I could extend the log2ram. My problem is the following: I have installed syncthing. The default in armbian runs it as root - which is not recommended for syncthing, see here: https://forum.syncthing.net/t/running-syncthing-as-root/6316! So I downgraded the syncthing daemon to a standard user account "syncthing". In order to enable a non-root user to write logfiles it's common practice to create a subdir /var/log/syncthing/ and give it write rights for syncthing. This works, however my logfiles stay completely empty! Nevertheless I can see that something's constantly touching the logfiles, the last modified date is always set to the current time. I'm assuming this is due to the log2ram mechanism (is that assumption correct?), so I'd like to know how to extend that to include my added log files and log subdirectories. THX Don

Thanks for explaining more detailed! Yes, I should have NAND on it. According to this: http://cubieboard.org/2017/04/07/how-to-use-cubietruck-tsd-version/, section 3 I have Hynix chips on my machine, not Foresee, so this should be NAND. I had to learn that there seems to be more different version of Cubietruck than I knew of (which also explains the mmc2), didn't know that. They also say TSD version was launched in 2017, mine is older. I don't need to preserve the content of the NAND, reformatting would be OK. I surely don't intend to go Stretch with legacy kernel as the leagacy kernel does not receive security updates any longer. I could've stayed with Jessie then, such an update is useless in my eyes. OK, then let's put this (NAND) beast to rest, I'll switch off nand and mmc2 in my hardware configuration again and call it a day! THX Don

That is exactly what I was asking before: So I relied on Igor's answer which I read as "in mainline kernel you cannot use the NAND to boot from it but after boot you will be able to see and use it". Anyway, why then should we include a hardware option "nand" in armbian-config if it was completely inoperable? So again to make the answer very clear and correct: What is the case for mainline kernel? Is NAND completely inaccessible or am I just unable to use it for booting? It's not a big deal if NAND access gets lost completely, I already ate it that booting is not available in any case and I'm using a SD card now to run Stretch. However my Cubietruck has even 16GB of NAND (not 8GB as the standard versions have) so this is not a completely useless piece of storage for such a small machine, it served me as a reliable boot mechanism for quite some time with the legacy kernel and if possible I would like to use it for storing data in Stretch as well. Regards Don

As said, I already switched that on before mailing: BTW, what is mmc2? Only enabled it as a test as I could not see the NAND with nand enabled, but the cubie has of course no second sd card slot. But still no nand in /dev or /proc: Any ideas? The NAND itself is OK, if I eject the SD card I can boot to the legacy kernel that is installed on NAND like I did before upgrading to armbian stretch. So it must be a problem of the mainline kernel or some setting there. What does the toggle for "nand" in armbian-config do? I always like to make sure by directly checking a configuration file instead of relying on some GUI display, so where do I find the respective configuration file? THX Don

I tried to install the stretch based distro and this is largely successful. However on the contrary to what you said my NAND became completely invisible. There's no such thing as /dev/nand or /proc/nand. In armbian-config I also enabled NAND and (as this had no success) as a test also mmc2 - whatever mmc2 shall be on the cubietruck - but still no luck. Am I missing anything here? What else is needed to make the NAND visible? Don

Igor, thanks for the clarification! Do I understand that correctly that I cannot boot from NAND, however it will be accessible after booting? Don