guidol Posted April 4, 2020 Posted April 4, 2020 Armbianmonitor: http://ix.io/2gCO while updating my dev-OPiOne Welcome to Armbian bullseye with Linux 5.5.8-sunxi package bsp-kernel[20.05.0-trunk] u-boot[20.05.0-trunk] dtb [20.05.0-trunk] firmware [20.05.0-trunk] config[20.05.0-trunk] branch[dev] Linux opi-one 5.5.8-sunxi #trunk SMP Wed Mar 18 21:19:37 +03 2020 armv7l GNU/Linux via apt update I did get the follwing error-message: Trigger für mime-support (3.64) werden verarbeitet ... E: Schreibfehler - ~LZMAFILE (28: Auf dem Gerät ist kein Speicherplatz mehr verfügbar) I did found out via df that /dev/zram0 = /var/log is used up to 100% :( root@opi-one(192.168.6.114):~# df Dateisystem 1K-Blöcke Benutzt Verfügbar Verw Eingehängt auf /dev/zram0 49584 48560 0 100% /var/log but only zram0 seems to be full and not the complete memory: MiB Mem : 491,5 total, 124,5 free, 101,3 used, 265,8 buff/cache MiB Swap: 245,8 total, 242,8 free, 3,0 used. 360,8 avail Mem After a reboot there is also 64% of the /dev/zram0 used and I dont know why :( root@opi-one(192.168.6.114):~# df Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf /dev/zram0 49584 28996 17004 64% /var/log Spoiler root@opi-one(192.168.6.114):/var/log# ls -l insgesamt 264 -rw-r--r-- 1 root root 0 Apr 4 19:06 alternatives.log drwxr-xr-x 2 root root 4096 Apr 4 19:09 apt -rw-r--r-- 1 root root 36237 Apr 4 19:14 armbian-hardware-monitor.log -rw-r----- 1 root adm 2188 Apr 4 19:17 auth.log -rw-r--r-- 1 root root 0 Apr 4 19:00 bootstrap.log -rw-rw---- 1 root utmp 0 Apr 4 19:00 btmp drwxr-xr-x 2 _chrony _chrony 4096 Okt 26 09:47 chrony -rw-r----- 1 root adm 20547 Apr 4 19:15 daemon.log -rw-r----- 1 root adm 607 Apr 4 19:14 debug -rw-r--r-- 1 root root 0 Apr 4 19:09 dpkg.log -rw-r--r-- 1 root root 0 Apr 4 19:00 faillog drwxr-sr-x 3 root systemd-journal 4096 Feb 25 19:02 journal -rw-r----- 1 root adm 35489 Apr 4 19:14 kern.log -rw-rw-r-- 1 root utmp 292 Apr 4 19:15 lastlog drwxr-x--- 2 www-data www-data 4096 Mär 18 21:28 lighttpd drwx------ 2 root root 16384 Apr 4 19:14 lost+found -rw-r----- 1 root adm 34597 Apr 4 19:14 messages drwxr-xr-x 2 pihole pihole 4096 Feb 14 14:53 pihole -rw-r--r-- 1 pihole pihole 4052 Apr 4 19:14 pihole-FTL.log -rw-r--r-- 1 pihole pihole 706 Apr 4 19:14 pihole.log -rw-r--r-- 1 root root 0 Apr 4 19:00 pihole_updateGravity.log drwx------ 2 root root 4096 Dez 31 13:35 private drwxr-xr-x 3 root root 4096 Mär 18 21:28 runit -rw-r----- 1 root adm 57029 Apr 4 19:17 syslog drwxr-xr-x 2 root root 4096 Nov 2 13:55 sysstat drwxr-x--- 2 root adm 4096 Mär 18 21:28 unattended-upgrades -rw-rw-r-- 1 root utmp 2688 Apr 4 19:15 wtmp Is there any chance to gain some space in /dev/zram0 or to configure a little bigger /dev/zram0? (to use a part of the 265Mb remaining cache/buffer-ram) The complete update to newer packages/kernel seems also to work with the full /dev/zram = /var/log: Welcome to Armbian bullseye with Linux 5.5.15-sunxi package bsp-kernel[20.05.0-trunk] u-boot[20.05.0-trunk] dtb [20.05.0-trunk] firmware [20.05.0-trunk] config[20.05.0-trunk] branch[dev] Linux opi-one 5.5.15-sunxi #trunk SMP Sat Apr 4 17:39:03 +03 2020 armv7l GNU/Linux 0 Quote
guidol Posted April 4, 2020 Author Posted April 4, 2020 Now I have 90% in /var/log after a reboot df Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf /dev/zram0 49584 41296 4704 90% /var/log zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram1 lzo 245,8M 4K 78B 12K 4 [SWAP] /dev/zram0 zstd 50M 40,4M 1M 1,5M 4 /var/log root@opi-one(192.168.6.114):/var/log/journal/14bb32cb9a1c40b29c1696d4acec6931# ls -l insgesamt 40976 -rw-r----- 1 root systemd-journal 16777216 Apr 4 19:14 system@0005a27952ce7c96-f8789ed6a81b97f9.journal~ -rw-r----- 1 root systemd-journal 8388608 Apr 4 22:45 system@0005a27c483373ab-1b9f47dd2956de8e.journal~ -rw-r----- 1 root systemd-journal 8388608 Apr 4 22:56 system@0005a27c6cce90a5-1036e2f49bee28e6.journal~ -rw-r----- 1 root systemd-journal 8388608 Apr 4 23:18 system.journal but I can't read the content of the system.journal-files [EDIT] here are instructions for reading journal files: https://www.linux-magazin.de/ausgaben/2016/02/systemd-journal/2/ If I delete these files - they will be "restored" at the next boot 0 Quote
Igor Posted April 4, 2020 Posted April 4, 2020 I was fixed - how are your values in /etc/systemd/journald.conf https://github.com/armbian/build/commit/2f389a6cb6944983bbbaba15ef2b3cba228e9a05 1 Quote
guidol Posted April 4, 2020 Author Posted April 4, 2020 9 minutes ago, Igor said: I was fixed - how are your values in /etc/systemd/journald.conf https://github.com/armbian/build/commit/2f389a6cb6944983bbbaba15ef2b3cba228e9a05 There I only have the default-file-entrys: Spoiler [Journal] #Storage=auto #Compress=yes #Seal=yes #SplitMode=uid #SyncIntervalSec=5m #RateLimitIntervalSec=30s #RateLimitBurst=10000 #SystemMaxUse= #SystemKeepFree= #SystemMaxFileSize= #SystemMaxFiles=100 #RuntimeMaxUse= #RuntimeKeepFree= #RuntimeMaxFileSize= #RuntimeMaxFiles=100 #MaxRetentionSec= #MaxFileSec=1month #ForwardToSyslog=yes #ForwardToKMsg=no #ForwardToConsole=no #ForwardToWall=yes #TTYPath=/dev/console #MaxLevelStore=debug #MaxLevelSyslog=debug #MaxLevelKMsg=notice #MaxLevelConsole=info #MaxLevelWall=emerg I did now edit my /usr/lib/armbian/armbian-zram-config and inserted the lines from the fix at the right place (which were missing). The fix inserted/corrected the SystemMaxUse=20M in /etc/systemd/journald.conf Before a reboot I did enter a "journalctl --vacuum-size=5M" And after the reboot I have: root@opi-one(192.168.6.114):~# df Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf /dev/zram0 49584 19676 26324 43% /var/log Many thanks at @Igor 2 Quote
guidol Posted May 14, 2020 Author Posted May 14, 2020 On 4/4/2020 at 11:35 PM, Igor said: I was fixed - how are your values in /etc/systemd/journald.conf https://github.com/armbian/build/commit/2f389a6cb6944983bbbaba15ef2b3cba228e9a05 @Igor I have two bullseye testing sbcs which seem to ignore the setting SystemMaxUse=20M in /etc/systemd/journald.conf var/log get full to 100% only on these bullseye sbcs but not on the buster sbcs both show System diagnosis information will now be uploaded to gzip: /var/log/armbian-hardware-monitor.log.1.gz: No such file or directory while armbianmonitor -u (OK, I did a journalctl --vacuum-size=5M shortly ago) NPi Neo2 with bullseye:http://ix.io/2lY7NanoPi K1 Plus with bullseye:http://ix.io/2lY8 Maybe there is to less output from armbianmonitor because of the vacuum? 0 Quote
guidol Posted May 14, 2020 Author Posted May 14, 2020 This looks strange for me (here the "red" ones) - a short part from journalctl -b but sometimes there are messages which arent red: May 14 11:56:14 npi-neo2-24 rsyslogd[758]: file '/var/log/syslog'[7] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2002.0 try https://www.rsyslog.com/e/20> May 14 11:56:14 npi-neo2-24 rsyslogd[758]: action 'action-1-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2002.0 try https://www.rsyslog> May 14 11:56:14 npi-neo2-24 rsyslogd[758]: file '/var/log/syslog'[7] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2002.0 try https://www.rsyslog.com/e/20> May 14 11:56:14 npi-neo2-24 rsyslogd[758]: action 'action-1-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2002.0 try https://www.rsyslog> May 14 11:56:14 npi-neo2-24 rsyslogd[758]: file '/var/log/syslog'[7] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2002.0 try https://www.rsyslog.com/e/20> here are some "normal green" ones from the journal: May 14 11:45:06 npi-neo2-24 CRON[416455]: pam_unix(cron:session): session closed for user root May 14 11:55:01 npi-neo2-24 CRON[428664]: pam_unix(cron:session): session opened for user root by (uid=0) May 14 11:55:01 npi-neo2-24 CRON[428665]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) 0 Quote
Igor Posted May 14, 2020 Posted May 14, 2020 1 hour ago, guidol said: I have two bullseye testing sbcs which seem to ignore the setting Good to know, thanks. ... I also noticed some other problems related to haveged, which requires apparmor and when that is enabled it still doesn't work. Perhaps Bullseye is too fragile atm and since it will remain unsupported (at this release), this is low priority to fix atm 0 Quote
guidol Posted May 14, 2020 Author Posted May 14, 2020 2 hours ago, Igor said: Good to know, thanks. ... I also noticed some other problems related to haveged, which requires apparmor and when that is enabled it still doesn't work. I will have an (bulls)eye on it - because I had the kernel freezed to 5.6.8 and defreezed it today. Now - after the update - I have 5.6.12 and since 2 hours /var/lag % hasnt grown. Maybe ist has been solved in 5.6.12 or the newer packages since 5.6.8 0 Quote
Igor Posted May 14, 2020 Posted May 14, 2020 27 minutes ago, guidol said: Maybe ist has been solved in 5.6.12 or the newer packages since 5.6.8 Anything is possible when using bleeding edge stuff 1 Quote
Dennboy Posted September 9, 2021 Posted September 9, 2021 Dear all, I gave the new opi0 bullseye image a try, since It seems to be supported now. It may be worth to have a fresh look at the limits for systemd journald logging, and log rotation. My /var/log was loaded upto 45M some hours after booting, installing packages on the opi0, mainly due to /var/log/journal. I vacuumed it to 10M but after some reboots, package installations and hours it was full again although SystemMaxUse=20M by default. Additionally, the log rotation (fired every 15 minutes from /etc/cron.d/armbian-truncate-logs) does not seem to work properly due to an issue in the script that is started with /bin/sh (see script line 1, instead of a shell that performs the $() command expansion): % sudo /usr/lib/armbian/armbian-truncate-logs [sudo] password for dennis: /usr/lib/armbian/armbian-truncate-logs: 18: /etc/default/armbian-ramlog: Syntax error: "(" unexpected Running it with bash seems to work fine (sudo bash /usr/lib/armbian/armbian-truncate-logs, which also vacuums the journal). After deciphering the journald.conf manpage, I found that both runtime /run/log/journal, as persistent /var/log/journal are running, and /var/log/journal is not really persistent since it is actually mapped zram memory (journald does not care and treats it as disk). % egrep -i "(system|runtime)MaxUse" /etc/systemd/journald.conf SystemMaxUse=20M #RuntimeMaxUse= % sudo journalctl --vacuum-size=10M Vacuuming done, freed 0B of archived journals from /run/log/journal. Deleted empty archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0005cb79ce3b8f57-f277d6397cc77cac.journal~ (380.0K). Deleted empty archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/user-1000@0005cb7769ae3241-2385d20dac4738ae.journal~ (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@1c1a53e8b25d40f3b676b26240347188-0000000000000001-0005ca73fa192ab2.journal (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/user-1000@7268c35dcad84410bca267900c47dcf3-00000000000003de-0005cb76b53d43a7.journal (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0005cb77143d39ed-a0190e6a8b8f96ef.journal~ (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0005cb77ab234dfb-97d2013e1117189a.journal~ (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/user-1000@0005cb77ab294eee-86b91930cb2eb4a9.journal~ (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0368477b592e43fdbf9ffcfb6934d264-0000000000000001-0005cb77ab1c0c05.journal (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0368477b592e43fdbf9ffcfb6934d264-00000000000002be-0005cb77ab27dc7d.journal (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/user-1000@bd369698bf69432a8bc7ab495a90d103-00000000000002cd-0005cb77abdedbd0.journal (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0368477b592e43fdbf9ffcfb6934d264-0000000000000960-0005cb7805815938.journal (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0005cb787689a85a-c5fb08a0411e45bd.journal~ (2.5M). Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/user-1000@0005cb787781d2a7-d60e1ce6a19e246b.journal~ (2.5M). Vacuuming done, freed 30.4M of archived journals from /var/log/journal/078479a1b0a4459f80590dd571c3d6de. Vacuuming done, freed 0B of archived journals from /var/log/journal. Vacuuming done, freed 0B of archived journals from /run/log/journal/078479a1b0a4459f80590dd571c3d6de. % ls -lsa /run/log/journal/078479a1b0a4459f80590dd571c3d6de total 5056 0 drwxr-s---+ 2 root systemd-journal 200 Sep 8 11:58 . 0 drwxr-sr-x+ 3 root systemd-journal 60 Sep 8 11:01 .. 632 -rw-r-----+ 1 root systemd-journal 647168 Sep 8 11:51 system@6b593560fcd344f2910e96f6d1a94416-000000000000719c-0005cb7a7b871b5f.journal 632 -rw-r-----+ 1 root systemd-journal 647168 Sep 8 11:52 system@6b593560fcd344f2910e96f6d1a94416-0000000000007493-0005cb7a81dbae26.journal 632 -rw-r-----+ 1 root systemd-journal 647168 Sep 8 11:54 system@6b593560fcd344f2910e96f6d1a94416-0000000000007783-0005cb7a85740dde.journal 632 -rw-r-----+ 1 root systemd-journal 647168 Sep 8 11:55 system@6b593560fcd344f2910e96f6d1a94416-0000000000007a7a-0005cb7a8c94d731.journal 632 -rw-r-----+ 1 root systemd-journal 647168 Sep 8 11:56 system@6b593560fcd344f2910e96f6d1a94416-0000000000007d6f-0005cb7a8d656445.journal 632 -rw-r-----+ 1 root systemd-journal 647168 Sep 8 11:57 system@6b593560fcd344f2910e96f6d1a94416-0000000000008062-0005cb7a93bd9e11.journal 632 -rw-r-----+ 1 root systemd-journal 647168 Sep 8 11:58 system@6b593560fcd344f2910e96f6d1a94416-0000000000008352-0005cb7a9754eac1.journal 632 -rw-r-----+ 1 root systemd-journal 647168 Sep 8 12:32 system.journal % ls -lsa /var/log/journal/078479a1b0a4459f80590dd571c3d6de total 12740 4 drwxr-sr-x 2 root systemd-journal 4096 Sep 8 11:58 . 4 drwxr-sr-x 3 root systemd-journal 4096 Aug 26 10:39 .. 2564 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:37 system@0005cb78a256a261-d8ca0603791c37d6.journal~ 2564 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:26 system@1e380884930f4d539d6a0d93d2b03d39-0000000000000001-0005cb7876859703.journal 2476 -rw-r-----+ 1 root systemd-journal 2527232 Sep 8 11:01 system.journal 2564 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:26 user-1000@933777cd01ac4494a761849c2e955801-00000000000002ee-0005cb787781bf5f.journal 2564 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:36 user-1000.journal % ls -lsa /var/log.hdd/journal/078479a1b0a4459f80590dd571c3d6de total 43904 4 drwxr-sr-x 2 root systemd-journal 4096 Sep 8 09:56 . 4 drwxr-sr-x 3 root systemd-journal 4096 Aug 26 10:39 .. 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 07:46 system@0005cb77143d39ed-a0190e6a8b8f96ef.journal~ 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 08:28 system@0005cb77ab234dfb-97d2013e1117189a.journal~ 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:25 system@0005cb787689a85a-c5fb08a0411e45bd.journal~ 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:37 system@0005cb78a256a261-d8ca0603791c37d6.journal~ 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 08:28 system@0368477b592e43fdbf9ffcfb6934d264-0000000000000001-0005cb77ab1c0c05.journal 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 08:53 system@0368477b592e43fdbf9ffcfb6934d264-00000000000002be-0005cb77ab27dc7d.journal 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:18 system@0368477b592e43fdbf9ffcfb6934d264-0000000000000960-0005cb7805815938.journal 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 07:46 system@1c1a53e8b25d40f3b676b26240347188-0000000000000001-0005ca73fa192ab2.journal 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:26 system@1e380884930f4d539d6a0d93d2b03d39-0000000000000001-0005cb7876859703.journal 376 -rw-r----- 1 root systemd-journal 385024 Sep 8 09:37 system.journal 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 08:10 user-1000@0005cb7769ae3241-2385d20dac4738ae.journal~ 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 08:28 user-1000@0005cb77ab294eee-86b91930cb2eb4a9.journal~ 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:25 user-1000@0005cb787781d2a7-d60e1ce6a19e246b.journal~ 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 07:46 user-1000@7268c35dcad84410bca267900c47dcf3-00000000000003de-0005cb76b53d43a7.journal 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:26 user-1000@933777cd01ac4494a761849c2e955801-00000000000002ee-0005cb787781bf5f.journal 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 08:43 user-1000@bd369698bf69432a8bc7ab495a90d103-00000000000002cd-0005cb77abdedbd0.journal 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:18 user-1000@bd369698bf69432a8bc7ab495a90d103-0000000000000a2b-0005cb7811371fa6.journal 2560 -rw-r----- 1 root systemd-journal 2621440 Sep 8 09:36 user-1000.journal % sudo journalctl --disk-usage Archived and active journals take up 17.3M in the file system. Kind regards, Dennis 0 Quote
Dennboy Posted September 9, 2021 Posted September 9, 2021 Hi again, Just updated and rebooted bullseye on nanopi neo3 and now the journals take 50M, before the reboot it was 17.3M .... Fortunately, the log rotation seems to be working again has /bin/bash on first line now, so after 15 minutes /var/log was back to reasonable size. Could not yet reproduce this on opi0, it used 20M of journals after reboot. Welcome to Armbian 21.08.2 Bullseye with Linux 5.10.63-rockchip64 System load: 100% Up time: 0 min Memory usage: 12% of 978M IP: 192.168.0.13 CPU temp: 60�°C Usage of /: 29% of 15G # journalctl --disk-usage Archived and active journals take up 50.6M in the file system. npin3bullseye:~:% df -h /var/log Filesystem Size Used Avail Use% Mounted on /dev/zram1 49M 48M 0 100% /var/log Welcome to Armbian 21.08.2 Bullseye with Linux 5.10.60-sunxi System load: 48% Up time: 0 min Memory usage: 15% of 491M IP: 192.168.0.30 CPU temp: 57�°C Usage of /: 21% of 15G [ General system configuration (beta): armbian-config ] % journalctl --disk-usage Archived and active journals take up 20.0M in the file system. opi0bullseye:~:% df -h /var/log Filesystem Size Used Avail Use% Mounted on /dev/zram1 49M 27M 19M 60% /var/log Kind regards, Dennis 0 Quote
Dennboy Posted September 15, 2021 Posted September 15, 2021 Hi Again, The problem seems to be /var/log.hdd/journal which is copied back to /var/log/journal after reboot without cleaning. Directly after a reboot: % du /var/log/journal /var/log.hdd/journal 46560 /var/log/journal/50bea5a2341c40588d32c8103dea6e71 46568 /var/log/journal 46320 /var/log.hdd/journal/50bea5a2341c40588d32c8103dea6e71 46324 /var/log.hdd/journal % sudo diff -r /var/log/journal /var/log.hdd/journal [sudo] password for dennis: Only in /var/log/journal/50bea5a2341c40588d32c8103dea6e71: system@0005cc0672bea9a2-be31a0e4284cf010.journal~ Binary files /var/log/journal/50bea5a2341c40588d32c8103dea6e71/system.journal and /var/log.hdd/journal/50bea5a2341c40588d32c8103dea6e71/system.journal differ Kind regards, Dennis 0 Quote
Igor Posted September 15, 2021 Posted September 15, 2021 On 9/9/2021 at 8:48 AM, Dennboy said: Additionally, the log rotation (fired every 15 minutes from /etc/cron.d/armbian-truncate-logs) does not seem to work properly due to an issue in the script that is started with /bin/sh (see script line 1, instead of a shell that performs the $() command expansion): https://github.com/armbian/build/pull/3115 This should / will be fixed with an update when it will be issued. When there will be time for that. Try with self build image. On 9/9/2021 at 8:48 AM, Dennboy said: I gave the new opi0 bullseye image a try, since It seems to be supported now. Debian officially release Bullseye just two weeks prior to our release so it was a hard decision. We are expecting problems to happen, but there is little to be done, especially if bugs are coming somewhere from Debian packages, we don't maintain. Or changes in Debian changed our features into bugs. Hard to tell without research. 0 Quote
Dennboy Posted September 15, 2021 Posted September 15, 2021 Hi Igor, Thanks for your support! Bullseye already feels stable enough for my purposes (synchronized voltage/current sensors for green R&D projects). I temporarily fixed my /var/log/journal size issue at (every) boot by clearing /var/log.hdd/journal and copying over /var/log/journal after logrotate has run. Guess this could be automated somehow in the boot scripts. Kind regards, Dennis 0 Quote
Willy Moto Posted September 17, 2021 Posted September 17, 2021 On 5/14/2020 at 5:14 PM, guidol said: @Igor I have two bullseye testing sbcs which seem to ignore the setting SystemMaxUse=20M in /etc/systemd/journald.conf var/log get full to 100% only on these bullseye sbcs but not on the buster sbcs Thanks for this. Confirmed the same bug can also be found on Bulleseye image for Allwinner H6 TX box: [ Armbian_21.11.0-trunk_Aw-h6-tv_bullseye_current_5.10.62.img.xz ] by balbes150 ZRAM log was getting full again after device reboot & also due to Bulleseye image "ignore the setting SystemMaxUse=20M in /etc/systemd/journald.conf" For now I'll fallback to Buster image previously downloaded for the device. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.