Trillien

Hi, I've got the same behavior using OpenMediaVault 6.0.21 on an Helios64 using Linux 5.15.25-rockchip64. I tried to extend /dev/zram1 size from 50M to 150M. # configuration values for the armbian-ram-logging service # # enable the armbian-ram-logging service? ENABLED=true # # size of the tmpfs mount -- please keep in mind to adjust /etc/default/armbian> SIZE=150M # # use rsync instead of cp -r # requires rsync installed, may provide better performance # due to copying only new and changed files USE_RSYNC=true kobol@helios64:~$ sudo zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram1 zstd 150M 16.4M 1.4M 3M 6 /var/log /dev/zram0 lzo-rle 1.9G 4K 74B 12K 6 [SWAP] After rebooting, /var/log size actually increased and the email flow stopped for a while. Until it reached a critical threshold I guess. So far, I've got one email per day saying the logs are truncated. However as I checked /var/log, it has plenty of room still. kobol@helios64:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 1.9G 0 1.9G 0% /dev tmpfs 387M 13M 374M 4% /run /dev/mmcblk1p1 15G 2.1G 12G 15% / tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 1.9G 0 1.9G 0% /tmp /dev/zram1 146M 17M 119M 13% /var/log /dev/md0 1.8T 772G 1.1T 43% /srv/dev-disk-by-uuid-835fd1cc-3d15-41e4-a782-d4a4b66a415a tmpfs 387M 0 387M 0% /run/user/1000 For info, please have below memory consumption of /var/log.hdd: kobol@helios64:~$ sudo du -h /var/log.hdd 12K /var/log.hdd/unattended-upgrades 180K /var/log.hdd/nginx 32K /var/log.hdd/salt 4.0K /var/log.hdd/samba/cores/nmbd 4.0K /var/log.hdd/samba/cores/smbd 12K /var/log.hdd/samba/cores 6.4M /var/log.hdd/samba 4.0K /var/log.hdd/watchdog 24K /var/log.hdd/cron-apt 32K /var/log.hdd/proftpd 4.0K /var/log.hdd/private 4.0K /var/log.hdd/chrony 4.0K /var/log.hdd/openmediavault 4.0K /var/log.hdd/sysstat 124K /var/log.hdd/apt 136M /var/log.hdd/journal/736dbda275634e9d985f9e5ae956b2a2 136M /var/log.hdd/journal 4.0K /var/log.hdd/runit/ssh 8.0K /var/log.hdd/runit 153M /var/log.hdd

Hi, as I read this post, I'm not certain whether this rk808 regulator issue is solved yet. For info, I'm currently running: kobol@helios64:~$ uname -a Linux helios64 5.10.63-rockchip64 #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021 aarch64 GNU/Linux and I have these logs (similar than @prahal for bad): kobol@helios64:~$ journalctl -b | grep regulator Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc1v8-sys-s0: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc0v9-s3: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage avdd-0v9-s0: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage avdd-1v8-s0: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage pcie-power: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc3v3-sys-s3: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc3v0-sd: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc5v0-usb: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage usblan-power: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: vdd_log: supplied by regulator-dummy Oct 30 14:47:58 helios64 kernel: rk808-regulator rk808-regulator: there is no dvs0 gpio Oct 30 14:47:58 helios64 kernel: rk808-regulator rk808-regulator: there is no dvs1 gpio Oct 30 14:47:58 helios64 kernel: rk808-regulator rk808-regulator: max buck steps per change: 4 Oct 30 14:47:58 helios64 kernel: rk808 0-001b: failed to register 12 regulator Oct 30 14:47:58 helios64 kernel: fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected! Oct 30 14:47:58 helios64 kernel: fan53555-regulator 0-0041: FAN53555 Option[8] Rev[1] Detected! Oct 30 14:47:58 helios64 kernel: rockchip-saradc ff100000.saradc: failed to get regulator, -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc1v8-sys-s0: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc0v9-s3: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage avdd-0v9-s0: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage avdd-1v8-s0: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: rk808-regulator rk808-regulator: there is no dvs0 gpio Oct 30 14:47:58 helios64 kernel: rk808-regulator rk808-regulator: there is no dvs1 gpio Oct 30 14:47:58 helios64 kernel: rk808-regulator rk808-regulator: max buck steps per change: 4 Oct 30 14:47:58 helios64 kernel: lm75 2-004c: supply vs not found, using dummy regulator Oct 30 14:47:58 helios64 systemd[1]: Starting fan speed regulator... Oct 30 14:47:59 helios64 systemd[1]: Started fan speed regulator. Does there already exist a fix for such up-to-date kernel? Regards,

For info, my MMC device includes 2 partitions. mmcblk2p1 includes /boot, and mmcblk2p2 contains linux folders. As I performed the steps above by mounting mmcblk2p2 on /mnt/system, new linux image 5.10.43 was actually available in /mnt/system/boot. However, I had to copy the files to mmcblk2p1 partition. Otherwise, my system starts on MMC without any change in linux version. After generated the image, I apply the instructions below: root@helios64:~# mkdir -p /mnt/boot root@helios64:~# mount /dev/mmcblk1p2 /mnt/boot root@helios64:~# cp -r /mnt/system/boot/* /mnt/boot/boot root@helios64:~# reboot