Giunti
-
Posts
18 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Giunti
-
-
Thanx a multitude, Igor.
"apt-get update" seems to work again, however, "upgrade" yielded another error.
I then tried upgrade --fix-missing" and that seemed to do the job alright.
See screenshots attached in chronological order.If that conforms with your expectations, I'm happy, too.😁
All the best,
Giunti
PS.: I'm sorry for the German representation of the messages in the screenshots.
-
In search posts referring to a similar (?) problem I ran across this post hoping to find some remedial hints.
Upon trying to update/upgrade my Cubietruck Bookworm OS I received this error message:
root@CT:~# apt-get update
OK:1 http://deb.debian.org/debian bookworm InRelease
OK:2 http://deb.debian.org/debian bookworm-updates InRelease
OK:3 http://deb.debian.org/debian bookworm-backports InRelease
OK:4 http://security.debian.org bookworm-security InRelease
Ign:5 http://fi.mirror.armbian.de/apt bookworm InRelease
Fehl:6 http://fi.mirror.armbian.de/apt bookworm Release
404 Not Found [IP: 65.21.120.247 80]
Paketlisten werden gelesen… Fertig
E: Das Depot »http://apt.armbian.com bookworm Release« enthält keine Release-Datei mehr.
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art durchgeführt werden, daher ist es standardmäßig deaktiviert.
N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).
The stated address does not seem to hold a release file anymore, which does not allow for a secure upgrade. Otherwise my Armbian/Debian system runs flawlessly.Is there a way to get over this problem?
Many thanks in advance for help.
-
Hi all,
I've been using Armbian on two Cubietrucks for a decade and had to install the latest version (CLI Armbian 23.8 Bookworm Kernel of Aug 31, 2023) to one of them. The other still runs Buster to my fullest satisfaction. What I noticed, however, is that - among other changes - APM is no longer available.
Therefore: Is there any other way to reliably cause HDD spindown after a certain time (say 20 min) even if there's no battery-power mode but 24/7 AC power?
Thanks in advance for any help.
Giunti
-
How about that new thread? Has it ever been started? If yes, please provide link. Thanx,
-
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 the Armbian docs linked to by Igor above.
Many thanx in advance for any hints on this.
-
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.
-
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 ...
-
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.logTest 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 !
-
Thanx for the additional info !
-
Well now, after rebooting the system, "dmesg" still lists Bluetooth in the startup log:
QuoteSat Apr 29 15:54:36 CEST 2017 sun7i armv7l 4.10.12-sunxi Cubietruck 5.25
### dmesg:
. . .
[ 19.096299] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=writeback,commit=600,errors=remount-ro
[ 21.809943] Bluetooth: Core ver 2.22
[ 21.810151] NET: Registered protocol family 31
[ 21.810163] Bluetooth: HCI device and connection manager initialized
[ 21.810203] Bluetooth: HCI socket layer initialized
[ 21.810231] Bluetooth: L2CAP socket layer initialized
[ 21.810308] Bluetooth: SCO socket layer initialized
[ 21.824968] Bluetooth: RFCOMM TTY layer initialized
[ 21.825025] Bluetooth: RFCOMM socket layer initialized
[ 21.825080] Bluetooth: RFCOMM ver 1.11
[ 21.905001] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[ 21.905046] Bluetooth: HIDP socket layer initialized
[ 21.997144] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
[ 22.158662] fuse init (API version 7.26). . .
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.
-
Thank you, martinayotte and pfeerick !
I followed your hints and got this in return.
Quoteroot@CT:~# systemctl disable bluetooth
Synchronizing state for bluetooth.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d bluetooth defaults
Executing /usr/sbin/update-rc.d bluetooth disable
insserv: warning: current start runlevel(s) (empty) of script `bluetooth' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `bluetooth' overrides LSB defaults (0 1 6).
Removed symlink /etc/systemd/system/dbus-org.bluez.service.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.
-
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
-
Many thanks, Zador, 4 ur prompt reply.
Cheers
-
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.
-
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.
-
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.
-
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.
Changing keyboard layout/language to German on Armbian/Bookworm highly erratic
in Beginners
Posted
I've had two Cubietrucks running almost flawlessly for about 10 years on Armbian/Buster and previous versions. I recently decided to install Bookworm using Armbian_23.8.1_Cubietruck_bookworm_current_6.1.47.img.xz. On this I encountered several problems, whose causes I never fully uncovered, but got over them.
One of these problems was that neither manual setup nor the use of armbian-config allowed for a lasting configuration of the German keyboard layout, although "Personal Setting" says the opposite (see att. image No.2). It's a pain in the neck, really.
All I could filter out is a commandline message that's only visible a second. See the last screenshot with four lines saying
I spent a long time figuring out what this means. I simply re-installed the relevant packages via "apt-get" hoping this would help, but there was no obvious change. At some stage of my manifold attempts I suddeny noticed that the keyboard had changed to German on the CT_1. However, I couldn't recall what had caused the change. So I approached my CT_2 and now I'm stuck again with the same issue. 😒
I wonder if others have experienced the same and were more competent in finding a way out. If so, please let me in on your secrets. 🙏