loeriver

Thank you - I should have checked w/ df. The reason is that /var/log is mapped to /dev/zram1 which is 47M for my system and auditd.conf requested space_left=75 (MiB, that is). I changed this to space_left=25% and admin_space_left=5%. No it starts to log something at least.

Hi and thank you for the advice. The USB end of the dongle goes to my desktop PC. I compared the time stamps of the last issue and found that the PC was actually switched off during the last issue, having been switched on 10 minutes after the last sysrq log entry. So for the moment I will watch the findings of auditd, although the startup msgs from yesterday looked somewhat suspicious (?): 2025-06-23T18:23:09.799581+02:00 bananapipro2 systemd[1]: Starting auditd.service - Security Auditing Service... 2025-06-23T18:23:09.910646+02:00 bananapipro2 auditd[18408]: Audit daemon is low on disk space for logging 2025-06-23T18:23:09.911684+02:00 bananapipro2 auditd[18408]: Audit daemon is suspending logging due to low disk space. 2025-06-23T18:23:09.912308+02:00 bananapipro2 auditd[18408]: No plugins found, not dispatching events 2025-06-23T18:23:09.917468+02:00 bananapipro2 auditd[18408]: Init complete, auditd 3.0.9 listening for events (startup state enable) 2025-06-23T18:23:10.181350+02:00 bananapipro2 systemd[1]: Started auditd.service - Security Auditing Service. Greetings.

Thank you for this very helpful hint. I have installed auditd, I thought I have to systemctl (start, enable) auditd also to have it watching: but this seems to have been done by the install cmd already, as it is running. As I saw a burst of 7225 (!) sysrq messages in the log for 2025-06-18, between 08:55 and 09:50 again I am rather nervous about this topic. Since then no new messages again. Mysterious ... Greetings.

Hi, thank you for your comments, at least I learned about the SysRq sequence this way. I actually have no clue which process should send this sequence, an hardware issue of the RX line seems also unlikely to me (very short wire to the RS232-USB converter). The only additional observations: -it is a rare event, 24x7 system, most recent events: Jun 9th: at the end of a shutdown sequence Jun, 5th: no obviously related entries in syslog before it May, 28th: no obviously related entries in syslog before it May, 24th: at the end of a shutdown sequence May, 23rd: at the end of a shutdown sequence May 22nd: at the end of a shutdown sequence -it always occurs in pairs, timestamps separated by some µs, e.g. 16:50:49.191219 and 16:50:49.191355 Meanwhile on v25.5.1 for Banana Pi Pro running Armbian Linux 6.12.30-current-sunxi. I guess I will have to live with this effect, which is not harmful as long as the system continues to run. Greetings.

From time to time I see a message like this in my log files: 2025-06-05T11:29:33.367636+02:00 bananapipro2 kernel: [934985.549250] sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) show-blocked-tasks(w) dump-ftrace-buffer(z) replay-kernel-logs(R) The system continues to work (although I remember that it stooped at this point in older releases). Is there any action required? I am afraid that this could stop my system which is running unattended for longer periods usually. I am running v25.2.2 for Banana Pi Pro running Armbian Linux 6.12.20-current-sunxi.

When using armbian-config to select an overlay ("DTO001")e.g. for uart2, one is offered the full names w/ overlay prefix, e.g. sun7i-a20-uart2. The system adds this to armbianEnv.txt: overlays=sun7i-a20-uart2 But it has also the line overlay_prefix=sun7i-a20 In the end, uart2 is not activated (no output from /dev/ttyS1) - after changing the overlay line to overlays=uart2, I can read from /dev/ttyS1. System is Armbian 25.2.2 stable (bookeworm), Armbian Linux 6.12.20-current-sunxi.

I updated my Armbian on another board, saw the same brcm error an generated the required data, upload is here: https://paste.armbian.de/togofunode

Hi, unfortunately something seems not to work with armbianmonitor for me. I entered the above line as sudo and got this: <PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u System diagnosis information will now be uploaded to gzip: /var/log/armbian-hardware-monitor.log.1.gz: No such file or directory <!doctype html> <html lang=en> <head> <meta charset=utf-8> <title>&nbsp;</title> </head> <style> body { font-family: monospace; margin: 2em; } </style> <body> <p>ix.io is taking a break &#127867;</p> <img src="/underconstruction.gif" width="200px"> </body> </html> Please post the URL in the forum where you've been asked for. >

I am running a headless Bananapipro server that acts as an AP. Recently I found that its WiFi net was gone. In the log I found a crash of brcm: Dec 19 02:40:14 localhost kernel: [3919907.052132] ieee80211 phy0: brcmf_fw_crashed: Firmware has halted or crashed Dec 19 02:40:15 localhost kernel: [3919908.004319] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have nothing to do. Dec 19 02:40:15 localhost kernel: [3919908.004360] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have nothing to do. Dec 19 02:40:15 localhost kernel: [3919908.004372] ieee80211 phy0: brcmf_cfg80211_stop_ap: SET SSID error (-5) Dec 19 02:40:15 localhost kernel: [3919908.004388] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have nothing to do. Dec 19 02:40:15 localhost kernel: [3919908.004399] ieee80211 phy0: brcmf_cfg80211_stop_ap: BRCMF_C_DOWN error -5 Dec 19 02:40:15 localhost kernel: [3919908.004411] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have nothing to do. Dec 19 02:40:15 localhost kernel: [3919908.004422] ieee80211 phy0: brcmf_cfg80211_stop_ap: setting AP mode failed -5 Dec 19 02:40:15 localhost kernel: [3919908.004435] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have nothing to do. Dec 19 02:40:15 localhost kernel: [3919908.004446] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have nothing to do. Dec 19 02:40:15 localhost kernel: [3919908.206422] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1 Dec 19 02:40:15 localhost kernel: [3919908.206849] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43362-sdio.lemaker,bananapro.bin failed with error -2 Dec 19 02:40:15 localhost kernel: [3919908.206883] brcmfmac mmc1:0001:1: Falling back to sysfs fallback for: brcm/brcmfmac43362-sdio.lemaker,bananapro.bin Dec 19 02:40:15 localhost kernel: [3919908.274976] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43362-sdio.clm_blob failed with error -2 Dec 19 02:40:15 localhost kernel: [3919908.275024] brcmfmac mmc1:0001:1: Falling back to sysfs fallback for: brcm/brcmfmac43362-sdio.clm_blob Dec 19 02:40:15 localhost kernel: [3919908.537722] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available Dec 19 02:40:15 localhost kernel: [3919908.537759] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2) Dec 19 02:40:15 localhost kernel: [3919908.538389] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43362/1 wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d Dec 19 02:40:15 localhost NetworkManager[1088]: <info> [1734572415.8104] rfkill1: found Wi-Fi radio killswitch (at /sys/devices/platform/soc/1c12000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/ieee80211/phy1/rfkill1) (driver brcmfmac) WiFi could be re-activated by restarting the system. I shall also note that there are at least once a day messages like this in the log: Dec 19 22:36:32 localhost kernel: [20143.706800] ieee80211 phy0: brcmf_psm_watchdog_notify: PSM's watchdog has fired! The system is: uname -a Linux bananapipro2 6.6.44-current-sunxi #1 SMP Sat Aug 3 06:54:42 UTC 2024 armv7l GNU/Linux Are there any hints how to proceed with this issue? Many thanks, Thomas