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

Hello, I'm running a Cubietruck with legacy kernel (3.4.113) since a long time. The use of the legacy kernel is mainly due to the fact that I'm booting from onboard NAND and this was not supported by the mainline kernel for a long time. Meanwhile Armbian's mainline kernel became Stretch in its server flavor and I'm thinking about migrating. However I'm suspicious this will still break NAND boot, despite the fact that the documentation claims plus "missing NAND support" is not listed under "known issues" for the Cubietruck. Can anyone confirm or deny that mainline kernel meanwhile does/does not support booting from NAND on Cubietruck? And if NAND is not supported (and will then likely never be) and I'll have to switch to MMC to change to Stretch: Is there a way to dist-upgrade to MMC & Stretch without the need to re-install the Cubietruck's OS? THX Don

Yep! Would be interested in learning how to do that! Unfortzunately I don't understand much of what is written in the two links you posted... ;-(

Yes, I have this configuration working here since quit a long time on a cubietruck, it's stable and does it's work. Boot from NAND and OS on NAND. Let me add a few things: I prefer booting from NAND as this is soldered on the PCB and it avoids the contacts of the SD card. There are quite a couple of reports on the web with SD card failures due to contact problems on the card slot. Thus - though NAND may have been outdated by eMMC - it still has it's advantages compared to SD and you cannot simply chose between NAND and eMMC for a specific board. However - due to lack of NAND support in mainline kernel - I will probably also switch to an SD card as soon as stretch on A20 becomes stable. The old legacy kernel becomes more and more a pain in the ass. But for A20 there are other things that might throw you back on the old legacy kernel, namely lack of support for the MALI GPU in case you want to run a desktop. As I use my cubie in a headless setup I don't give a damn about Mali but for other usage scenarios this might of course be a no-go issue. I'm aware of the fact that the bad Mali support is not the fault of armbian but of Arm not suplying the necessary DDK under the GPL. Maybe the situation will change one day in the future as Lima resurrected, see here (German only): https://www.golem.de/news/lima-projekt-freier-linux-treiber-fuer-mali-gpus-wiederbelebt-1706-128680.html Cheerz Don

THX!

Hi there Yes, I can confirm, I observed the very same behavior! I had the problem of a bricked Cubie before, see my posts above, and I was able to reanimate it with Igor's help. At that time I just realized that something had gone wrong during the update, the uImage was missing, despite the fact that there's plenty of room on the NAND (I'm even using a 16G Cubie). Now, couple of months later I did an update again that came with a kernel (and presumably with some firmware) update. And bang, this also failed like the time before: Preparing to unpack .../linux-jessie-root-cubietruck_5.16_armhf.deb ... mv: cannot move ‘/boot/bin’ to ‘/boot/bin.old/bin’: Directory not empty Unpacking linux-jessie-root-cubietruck (5.16) over (5.11) ... dpkg: error processing archive /var/cache/apt/archives/linux-jessie-root-cubietruck_5.16_armhf.deb (--unpack): unable to make backup link of `./boot/bin/bananapi.bin' before installing new version: Operation not permitted Processing triggers for systemd (215-17+deb8u4) ... Processing triggers for man-db (2.7.0.2-5) ... Errors were encountered while processing: /var/cache/apt/archives/linux-jessie-root-cubietruck_5.16_armhf.deb E: Sub-process /usr/bin/dpkg returned an error code (1) somebody@cubietruck:~$ Take note of the line "mv: cannot move ‘/boot/bin’ to ‘/boot/bin.old/bin’: Directory not empty" At that time I was already clairaudient due to previous experiences. And, yes, a short glance at /boot revealed me the the very same situation like on your cubie, an existent, incomplete /boot/bin.old, a wrong /boot/bin.old/bin inside and a missing uImage - No chance to survive a reboot. And I did what you did, rename /boot/bin.old and relaunch the update, this time successfully: Setting up linux-firmware-image-sun7i (5.16) ... Setting up linux-headers-sun7i (5.16) ... Compiling headers - please wait ... Setting up linux-image-sun7i (5.16) ... Image Name: Linux kernel Created: Sat Jul 30 15:02:29 2016 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 5605944 Bytes = 5474.55 kB = 5.35 MB Load Address: 40008000 Entry Point: 40008000 Now I had a Kernel uImage again and after a final reboot the Cubie came up back without a hitch: ____ _ _ _ _ / ___| _| |__ (_) ___| |_ _ __ _ _ ___| | __ | | | | | | '_ \| |/ _ \ __| '__| | | |/ __| |/ / | |__| |_| | |_) | | __/ |_| | | |_| | (__| < \____\__,_|_.__/|_|\___|\__|_| \__,_|\___|_|\_\ Welcome to ARMBIAN Debian GNU/Linux 8 (jessie) 3.4.112-sun7i System load: 4.85 Up time: 1 min Memory usage: 5 % of 1998Mb IP: 192.168.xxx.xxx 192.168.xxx.xxx CPU temp: 39°C HDD temp: 34°C Usage of /: 24% of 15G storage/: 50% of 3.6T So, yes, could you please create a small bug report. This is clearly reproducible and should be easily fixable.

Yep, serial console cable is indeed helpful, if not indispensable. Without it I wouldn't have been able to quickly analyse the problem, as Igor's image is completely headless. You don't even get a text console output if you plug in a monitor and keyboard. So until the cubie has completed booting and you can ssh the box you're nailed down to the serial. One additional fact I forgot to mention: After I was able to reanimate my Cubie I dared to install Igor's workaround, provoking re-bricking it: Guess what, this did install without a hitch. To be safe I also did a reboot and it came up alive again without a problem. So I guess the following: I did a regular apg-get update/upgrade at that time. This installed some updates but failed to install linux-jessie-root-cubietruck. It was one of those other updates that seemingly installed correctly but bricked the Cubie, not linux-jessie-root-cubietruck. I didn't realize at that time because I didn't reboot - why should I, it's not a Windows machine ;-) I learned that days later when I shut down the Cubie for some hardware changes and it wouldn't come up again. So, as linux-jessie-root-cubietruck isn't the culprit this easily explains why Igor did not succeed reproducing the failure when testing this. The interesting remnant would be to find out which update bricked the Cubie. Unfortunately I don't know if I could backtrack which updates were installed in conjunction with linux-jessie-root-cubietruck, so this leaves plenty of room for speculations. BR Don

Hello, yep, that did the trick, Cubie is alive again: Strange however that nand1 does have sufficient space: I was able to create the image directly where it belongs and I didn't have to delete vmlinuz. Thus insufficient space couldn't be the reason uImage did get lost. Guess I'll never find out... Anyway, thanks a lot Igor, you saved my day! So, amhairghin and EtlARM, maybe this is also the problem of your bricked systems? BR Don

One additinal remark I forgot to mention, dunno if this is relevant for the problem: I'm using a Cubie with 16GB Nand (instead of the standard 8GB). Regards Don

Hi, I ran into the same problem "unable to make backup link of `./boot/bin/cubieboard.bin' before installing new version: Operation not permitted" when doing a regular apt-get update/upgrade. After reading this thread and getting aware it may cause problems when booting from NAND I did not install Igor's workaround. Nevertheless I had to realize my Cubie is bricked after a reboot. I guess this is due to some other updates apt-get spilled on the NAND during the update that triggered the error. Igor, is there any news why this break NAND booting and how to overcome this? If this is of any help I attach the console output of my cubie here. Maybe this eases determining the reason why things broke: Remarkable things in the output: Dunno what this "_RepairLogBlkTbl start" ... "_RepairLogBlkTbl end" section should tell me. It is being output at every boot try, maybe this is normal. There's a really strange line at 3.898: "can't find c:\drv_de.drv ERR: wBoot_driver_install display driver failed" WTF is it searching for a DOS path??? Then there's a complaint about a missing misc partition and several entries complaining about mount failures for an unrecognized filesystem type. Then it finally fails to read the uImage and of course and this brings the boot process to a halt. The Cubie is still alive however, I end up on a promt with limited functionality, a "?" gives a list of commands but this seems to be all very low level (no ls but fatls, ext2ls, etc. with strange syntax, e.g. "usage: fatls <interface> <dev[:part]> [directory]"). I managed to do a "fatls nand 0:0", this gives me As you can easily see there ain't no such thing as a "uImage" (while the other files needed are there). So now the questions are: How come something has killed uImage? How can I bring it back there? I dont want to reinstall the Cubie, it's a lot of work and I made a lot of settings specific to my needs. How to avoid this will happen again? So, does this help fixing the problem? Hopefully there will be a quick solution... Regards Don

As an alternative, if you want/need a PL2303 based converter that's also operable on latest windows system I could recommend this here: http://www.amazon.de/PL2303TA-RS232-Konverter-Serial-Cable/dp/B00T60QTUK/ref=sr_1_19?ie=UTF8&qid=1455911912&sr=8-19&keywords=pl2303 This has a PL2303TA chip inside, means it will work with Win 8 and 10 out of the box (i. e. with the drivers that come with windows). It is 3.3V (but has no 5V switch), so it can operate savely on a cubie or raspberry. The cable coloring the supplier states in the link is correct (at least for mine it was). The only disadvantage is that it's beeing shipped directly from China, so it may be you'll have to wait 1 or even 2 months for delivery (depends on how fast it will pass the toll). BTW: Good to hear in time that enforcing an update might brick the installation, I was already tempted to do it, too. So I will wait for what Igor's research will yield. I'm also using my cubie as a production system (Backup, Owncloud, AP), so of course I'm not keen on bricking it! ;-) This is a bit OT, I know, nevertheless: Syncthing plus dirvish plus samba (with RO shares) make up an open-source-only, fully automated, versatile and almost maintenance-free backup system, where even unexperienced (Windows-only) users can access their backups themselves and without the risk of any ransomware gaining write access to the backups. This is highly recommended! HTH Don