Giunti

Members
  • Content count

    12
  • Joined

  • Last visited

  1. SDCARD (rootFS) used up 100 %

    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.
  2. 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 ... So I thought there might be a partial "destruction" of the filesystem caused by the power failures mentioned above. This would most likely mean that I would have to buy a new SD-Card and set up the system from scratch. Are there other members of this forum who experienced similar phenomena and might share their (successful) ways to do away with them. Any remedial hints will be highly appreciated ! Many thanx in advance ...
  3. 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:59 2017: [....] Starting cgroup management daemon: cgmanager[....] Starting ramlog-tmpfs 2.0.0: Sat Jun 17 19:54:00 2017: The list of open files: (You need to close below daemons if you want to start/stop ramlog manually) Sat Jun 17 19:54:00 2017: Sat Jun 17 19:54:00 2017: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME Sat Jun 17 19:54:00 2017: lsusb 1502 root 1w REG 179,1 186584 2284 /var/log/armhwinfo.log Sat Jun 17 19:54:00 2017: Sat Jun 17 19:54:00 2017: Test result: ramlog cannot be started or stopped at the moment. As a consequence ramlog is not running ! On testing startstop function of ramlog I get the following: root@CT:~# /etc/init.d/ramlog teststartstop The list of open files: (You need to close below daemons if you want to start/stop ramlog manually) COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME minidlnad 1499 minidlna 4w REG 179,1 2018 2188 /var/log/minidlna.log nmbd 1858 root 2w REG 179,1 1863 128555 /var/log/samba/log.nmbd nmbd 1858 root 8w REG 179,1 1863 128555 /var/log/samba/log.nmbd smbd 2056 root 2w REG 179,1 933 128812 /var/log/samba/log.smbd smbd 2056 root 8w REG 179,1 933 128812 /var/log/samba/log.smbd squeezebo 2093 squeezeboxserver 6w REG 179,1 167550 128891 /var/log/squeezeboxserver/server.log squeezebo 2093 squeezeboxserver 7w REG 179,1 0 142384 /var/log/squeezeboxserver/perfmon.log Test result: ramlog cannot be started or stopped at the moment. The second boot-up failure message refers to LIRC not working: > [FAIL] Starting remote control daemon(s) : LIRC : failed In /var/log/boot log it says: Sat Jun 17 19:54:08 2017: /etc/init.d/lirc: 1: /etc/lirc/hardware.conf: î\007SK9XJ¤\005í\00714.8.4-sunxiSK9X£Þ\005ñ\00744.8.4-sunxi: not found Sat Jun 17 19:54:08 2017: [....] Starting remote control daemon(s) : LIRC :^[[?25l^[[?1c^[7^[[1G[^[[31mFAIL^[[39;49m^[8^[[?25h^[[?0c ^[[31mfailed!^[[39;49m As I don't use any IR functions on the Cubietruck, this doesn't really matter, I suppose. But most likely there is a way to get rid of this error message. Trouble is I don't know it. Any remedial aid would be appreciated, many thanx in advance !
  4. Thanx for the additional info !
  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. Jessie Upgrade-log Issues

    Many thanks, Zador, 4 ur prompt reply. Cheers
  9. Jessie Upgrade-log Issues

    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 these could be avoided. Secondly, I ran across these lines upon entering the upgrade command: >root@CT:~# apt-get upgrade ... >The following packages have been kept back: > linux-jessie-root-next-cubietruck >The following packages will be upgraded: > linux-dtb-next-sunxi linux-firmware-image-next-sunxi > linux-headers-next-sunxi linux-image-next-sunxi linux-libc-dev >5 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. >Need to get 0 B/27,1 MB of archives. >After this operation, 4.890 kB disk space will be freed. Why would 'linux-jessie-root-next-cubietruck' not be installed? Am I missing anything here? Many thanx in advance for any information on these two issues.
  10. Cubox-i (2gb) freezing after sustained use

    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 http://www.rsyslog.com/e/2007 ] 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 can shed a little light on this. Many thanx in advance.
  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.