Don Pedro

  • Posts

    22
  • Joined

  • Last visited

Recent Profile Visitors

765 profile views

Don Pedro's Achievements

  1. 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
  2. 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
  3. 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.
  4. 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!
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. Igor, thanks for the clarification! Do I understand that correctly that I cannot boot from NAND, however it will be accessible after booting? Don
  12. 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
  13. 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... ;-(
  14. 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