OpiOne: /dev/zram0 = /var/log full while apt update

guidol · April 4, 2020

Armbianmonitor:

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

guidol · 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

Igor · April 4, 2020

I was fixed - how are your values in /etc/systemd/journald.conf

https://github.com/armbian/build/commit/2f389a6cb6944983bbbaba15ef2b3cba228e9a05

guidol · 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

guidol · 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/2lY7
NanoPi K1 Plus with bullseye:
http://ix.io/2lY8

Maybe there is to less output from armbianmonitor because of the vacuum?

guidol · 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)

Igor · 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

guidol · 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

Igor · 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

Dennboy · 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

Dennboy · 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

Dennboy · 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

Igor · 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.

Dennboy · 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

Willy Moto · 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.

Sign In

OpiOne: /dev/zram0 = /var/log full while apt update

Question

Link to comment

Share on other sites

14 answers to this question

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Important Information