• Content Count

  • Joined

  • Last visited

  1. Thanx a lot, sky_khan, for the description of your experience with trying to get VGA resolution to work on mainline kernel for Cubietruck. However, there are more unexperienced CT owners out there (like myself) who would be grateful to receive a failsafe step-by-step HOW-TO. At least there should be a hint on how to enter the u-boot console at startup while there's a VGA monitor plugged into CT's VGA-socket and a keyboard connected to USB. Pressing the ESC button while pre-kernel boot-up procedure is visible on the screen won't work. None of this is explained in t
  2. Thanx a lot ! That did it and I certainly learned a new lesson! And yes it's a cron job, which normally syncs the data files to an external HDD mounted to /Backups, that caused the mount point "/Backups" on sdb to fill up when the external NTFS disk had problems due to power failure. Of course, I first googled and searched the ARMbian site but my search words received no returns that would address my problem. Thanx again for your prompt reply.
  3. Hi Armbians, I'm running two identical Cubietrucks with Armbian Jessie systems in headless (very lean) mode without any X-Windows or the like. Both boot from 16GB SD-Cards. Now one of them, which had encountered a number of power failures, suddenly ran out of space on the SD-Card (100% usage of / ), while the other CT only shows 22%. I ran across this phenomenon, when the system failed to carry out an apt-get update at one point and important services Samba were no longer started. I then searched the root filesystem for culprits but there was nothing suspicious ...
  4. I'm currently running ARMBIAN 5.31 Debian GNU/Linux 8 (jessie) 4.11.5-sunxi on my Cubietruck, which otherwise works fine as a headless data and media server. However, for quite some time (also on previous ARMBIAN builds) I get two failure messages every time I boot the system: > [FAIL] Starting up cgroup management Error: /var/log is in use ... failed ! ramlog-tmpfs 2.0.0 In /var/log/boot it says: Sat Jun 17 19:53:57 2017: INIT: Entering runlevel: 2 Sat Jun 17 19:53:57 2017: [^[[36minfo^[[39;49m] Using makefile-style concurrent boot in runlevel 2. Sat Jun 17 19:53
  5. Well now, after rebooting the system, "dmesg" still lists Bluetooth in the startup log: However, when checking service status, it tells me that there is no such service running. >root@CT:~# service bluetooth status >[FAIL] bluetooth is not running ... failed! I don't quite get that.
  6. Thank you, martinayotte and pfeerick ! I followed your hints and got this in return. So currently bluetooth isn't active any more. However, I haven't had the chance to reboot the system, as a weekly backup is running at the moment. So I'll have to postpone that. Then I'll see if the current status prevails. @pfeerick: The sole reason for my wanting to get rid of bluetooth was that I wanted to keep the headless system as slim as possible, save resources for purposes I do need and keep power consumption as low as posible. That's all.
  7. I'm currently running ARMBIAN 5.25 Debian GNU/Linux 8 (jessie) 4.10.12-sunxi on my Cubietruck, which otherwise works fine as a headless data and media server. However, as I don't need any Bluetooth service whatsoever in the given environment, I have been trying to get rid of it - in vain. Is there a safe and lasting method of preventing the Bluetooth module from loading on reboot? Can it be stripped from the system at all completely? Many thanx in advance
  8. Many thanks, Zador, 4 ur prompt reply. Cheers
  9. I'm currently running ARMBIAN Debian GNU/Linux 8 (jessie) 4.9.7-sunxi on my CT. On my last apt-get upgrade I noticed this line reoccurring in log: > dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.8.4-sunxi': Directory not empty Accordingly there are serveral older versions of 'linux-headers-4.8.x-sunxi' in /usr/src. Should/Can these be deleted mannually and, if so, why can't the upgrade procedure do this in the first place? On searching this forum, I found several log clips posted containing the same warning messages, however, without any response as to how thes
  10. Hi all, how come you're assuming that the cause of the rsyslog message is overheating of CPU ??? This is what I find in /var/log/syslog of my Cubietruck [ARMBIAN Debian GNU/Linux 8 (jessie) 4.4.1-sunxi] almost infinitely: Mar 20 10:58:00 localhost rsyslogd-2007: action 'action 17' suspended, next retry is Sun Mar 20 10:58:30 2016 [try ] But there's nothing like an overheating of the CPU and all functions seem to be there without any obvious flaws. And yet, I'd like to find a remedy for the syslog entries as mentioned above. Is there anyone who c
  11. Thanx for the links, EtlARM. That did it. There are actually six lines in my inittab file. However, only two of them were activated by Igor's default. So it was just a simple process of removing the hashes in front of as many lines as I wanted extra ttys to become available. Still learning to "master" as much of Linux as I need.
  12. After upgrading my Cubietruck with the latest armbian image (Vanilla Debian Jessie) I noticed that command line access is restricted to two parallel consoles (via ALT+F1, ALT+F2, -) only. Is there a way to overcome this limitation? Any remedial hint would be greatly appreciated. Thanx in advance. By the way, SSH terminal access seems to be possible almost inititely in number.