Jump to content

barish

Members
  • Posts

    76
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    Bremen Germany

Contact Methods

  • Website URL
    https://nashorn.eu
  • Github
    heaterC

Recent Profile Visitors

2370 profile views
  1. Due to systemd, Journal is going to replace all journals sooner or later, it's already one of the busiest journaling on the sytem. The logs are binary and can't be rotated like text logs, they are already compressed and can't be read by text editor, instead only by journalctl. Thus, in /usr/lib/armbian/armbian-ramlog , the directory /var/log/journal is excluded from standard log rotation and copying to HDD. Instead, it is copied once to /var/log.hdd/journal and a soft-link is created: /var/log/journal pointing to -> /var/log.hdd/journal . The RAM logging was introduced to spare the SD card, preventing many write actions that wear the SD card quickly. But this really busy log, including all system messages, is now written directly to the SD card. If this is the only way of preserving older systemd logs, shouldn't we then at least reconfigure journald in a way to e.g. log into RAM /run/log/journal and only snyc to SD card every n hours? Or maybe we could reduce the log level of journald (which is by default "debug") to e.g. "err" and reduce the write activity in that way? For me, it appears right now, that all the benefits of logging to RAM disk are canceled out by having journald log to SD card? Please correct me if I am mistaken in any of my assumptions above.
  2. I find it hard to imagine that maybe bash scripts interfere with each other and bash variables get confused across shell borders!?! It’s up to now the only guess I can come up with. This is maybe related to the early boot process where not everything is aligned yet? This is all wild guessing, I haven’t found a way to further analyze, because even auditd is failing on the armbian image I am using.
  3. I haven't found the cause, but I deactivated armbian-hardware-optimize.service, and did about 70 reboots afterwards, without any file corruption taking place. So I hope that armbian-hardware-optimization.sh (which is called by the above service) is involved in the error and its deactivation prevents any further file corruption.
  4. Thanks @Werner, as I understand it, audit is a component of SELinux, but can be activated standalone, too. I don't know how to troubleshoot this, all output (systemctl status auditd) is identical to a working auditd on other board, just the log file stays empty. For the record, I am running Armbian 21.02.3 Espressobin Debian buster current, kernel is 5.10.21-mvebu64 .
  5. In my case, /boot/armbianEnv.txt looks like this (but I have had variations, of this, too): /var/log/alternatives.log { monthly rotate 12 compress delaycompress missingok notifempty create 644 root root } usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x0bc2:0x231a:u Then, in /etc/logrotate.d, two files seem to be corrupt: 1. alternatives, 2. armbian-hardware-monitor, which had the complete contents of armbianEnv.txt. I run nginx, sambad, forked-daapd, nextcloud, mini-dlna and dnsmasq. No apache though. Edit: /etc/logrotate.conf is also truncated, thus corrupted. Hadn't noticed before, thanks @schwar3kat.
  6. This is about three Helios, one Pine64 and two EspressoBin boards. @Werner could we move this thread to a place visible to others than Rockchip please?
  7. Found this in /var/log/kern.log : Jun 28 09:14:51 localhost kernel: [ 0.026499] audit: initializing netlink subsys (disabled) Jun 28 09:14:51 localhost kernel: [ 0.026793] audit: type=2000 audit(0.024:1): state=initialized audit_enabled=0 res=1 And I tried auditd on another board of mine (Olinuxino micro) also running Buster, where it is working fine. So either it is a board topic or it's a stupid user topic... 😕
  8. I am not shure if this is board specific so I post it here and hope that you might be willing to try this on your board: - I installed audit: apt install auditd - I set up a rule for a file audit should watch: auditctl -w /boot/armbianEnv.txt -p wa - I change or touch the file being watched: touch /boot/armbianEnv.txt - I have a look at the log of audit: cat /var/log/audit/audit.log And then ––– I see nothing... Any hints what's going wrong? My guess is that the kernel might be lacking the audit module?!
  9. Unfortunately, auditd is not working at all. It just doesn't show any file access whatsoever, even though the demon is running and the rule is set. So this is of no help on my system. edit: Maybe the Armbian kernel is compiled without audit kernel module!?
  10. Same has happened on EspressoBin running Buster 5.10. I don‘t believe it to be a filesystem problem. It looks like something happening at boot time perhaps while running /usr/lib/armbian-hardware-optimization.sh ? I will try to go further into it.
  11. There is no way I know of to change environment parameters or U-Boot of the onboard SPI without UART access (I broke one off myself, it seemed to be very poorly connected to the board at the v5 models). If you compare the contents of the /boot directory: has there changed anything from the version that was running and the one you are trying now? Because, if boot.cmd (boot.scr) and armbianEnv.txt are still the same, the old U-Boot shouldn't have issues booting. Have a look if you can use the old files instead of the ones that come with the new Armbian, maybe that works (actually, boot.scr is the important file, the compiled version of boot.cmd ).
  12. With help from @Pali, I managed to put the Pull Request at the right spot, so when it's accepted, EspressoBin v7 1GB and 2GB will be stable with most current U-Boot and Marvell sources! Unfortunately, I have no board with 2GB, so maybe someone can test it who owns a 2GB v7. Armbian builder is using older branches for stability reasons up to now to compile the U-Boot images – maybe with all the new patches in place, Armbian can also use the newest U-Boot version. Edit: The Pull Request has just been merged. I will make a PR at Armbian Build to use newest Marvell repo branches.
  13. Finally, Globalscale did the trick and pushed the modifications, that they had added to make 17.10 stable for all EspressoBin-Boards, to 18.12 as well. Thanks a lot, Globalscale!! Unfortunately, they did this in their repos and not in the official Marvell repos. I extracted the changes and made a pull request at the Marvell repo. I hope the changes will be merged soon, because I can then use the official Armbian build tools to generate a U-Boot/firmware that flawlessly works with my EspressoBin v7 DDR4 1cs 1GB boards. For now, I compile using the Globalscale repo and got a really stable firmware (tested on three boards for now), I am using the mainline U-Boot (2020.10), too and have no problems – but have not tested this with PCIe periphery (like wifi or SATA adaptors).
  14. Could one of the experienced developers advise me please, if I am right with my above assumption? I don't want to make an unnecessary PR for the documentation, if I haven't understood correctly the process.
  15. I followed the documentation and cloned the repo in the Host first, changed to config/templates and started the Vagrant virtual machine. If I am not mistaken, inside the Guest, the repo is cloned again for the actual development. This implies that cloning on the Host system has only the purpose to provide config/templates/Vagrantfile and config-vagrant.conf, is that right? All other cloned files on the HOST have no relevance (except for the directories userpatches and output, which are mounted)? I find that quite confusing and if I am right with my assumption, I would like to add a note to the documentation for future users. Or: Would it be possible to mount the whole repo to the Guest?
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines