kevkkvek Posted June 27, 2019 Posted June 27, 2019 I am getting a series of errors related to EXT4 zram checksum that look like this one: [3328.749555] EXT4-fs error (device zram0): ext4_readdir:189: inode #11 com find: path var/log/lost+found directory fails checksum at offset 4096 (and other offsets) I've seen a recommendation as a possible fix to the checksum error : disabling metadata_csum, using "tune2fs -O ^metadata_csum /dev/zram0", with the file system umounted (I don't know how to unmount zram) The error apparently is related to bad hardware (not the case) , old kernels that don't support new versions of programs capable of altering the fs. Like a newer checksum feature, or a new e2fsprogs. Would appreciate some help. Thx.
NicoD Posted June 27, 2019 Posted June 27, 2019 Hi. Maybe you could try to remove and reinstall zram-config. Open another terminal ALT-Fx sudo apt remove zram-config. Reboot and reinstall it. I have no clue why this happened. Please also provide the output of armbianmonitor -u if possible.
Igor Posted June 27, 2019 Posted June 27, 2019 3 hours ago, kevkkvek said: I am getting a series of errors armbianmonitor -u is mandatory if you want fact based help. Now I can only tell you that probably there is nothing wrong. Possible kernel config issue - I don't recall what exactly - but its most likely safe to ignore.
kevkkvek Posted June 27, 2019 Author Posted June 27, 2019 I think this should be it, hope you can take a look at my armbianmonitor -u: http://ix.io/1MXs
kevkkvek Posted June 27, 2019 Author Posted June 27, 2019 9 hours ago, NicoD said: Hi. Maybe you could try to remove and reinstall zram-config. Open another terminal ALT-Fx sudo apt remove zram-config. Reboot and reinstall it. I have no clue why this happened. Please also provide the output of armbianmonitor -u if possible. Sorry for asking but how do you reinstall zram-config? ~sudo apt install zram-config"? Is there any danger in doing that? I can't say i'm a linux guru by any means. I would also like to do something about the logging because nginx also gives me full zram messages all the time.
kevkkvek Posted June 27, 2019 Author Posted June 27, 2019 22 minutes ago, NicoD said: It's just : sudo apt install zram-config Yeah, did that. BTW, the zram-config tool wasn't installed by default on my system. is that normal or ...strange?
kevkkvek Posted June 27, 2019 Author Posted June 27, 2019 ######before zram-confing ~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk ├─sda1 8:1 0 24G 0 part / ├─sda2 8:2 0 16G 0 part [SWAP] └─sda3 8:3 0 891.5G 0 part /opt mtdblock0 31:0 0 4M 0 disk zram0 252:0 0 50M 0 disk /var/log zram1 252:1 0 2G 0 disk [SWAP] ######after zram-config ~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk ├─sda1 8:1 0 24G 0 part / ├─sda2 8:2 0 16G 0 part [SWAP] └─sda3 8:3 0 891.5G 0 part /opt mtdblock0 31:0 0 4M 0 disk zram0 252:0 0 498.6M 0 disk [SWAP] zram1 252:1 0 498.6M 0 disk [SWAP] zram2 252:2 0 498.6M 0 disk [SWAP] zram3 252:3 0 498.6M 0 disk [SWAP] how do i make it back as it was?
NicoD Posted June 28, 2019 Posted June 28, 2019 That's ok. It's the same, but a bit different configuration. It's 2GB zram. If it works, then let it. Unless you don't want zram. Then you can delete it.
kevkkvek Posted June 28, 2019 Author Posted June 28, 2019 3 minutes ago, NicoD said: That's ok. It's the same, but a bit different configuration. It's 2GB zram. If it works, then let it. Unless you don't want zram. Then you can delete it. I'm ok but I just don't want to have any performance problems. Before zram0 was mounted in /var/log. What happens with the logs now.? This box is mainly for servers.
c0decrow Posted January 24, 2020 Posted January 24, 2020 I had the same problem on my Rock64 board running Armbian, it fixes after reboot.
raidboy Posted February 4, 2020 Posted February 4, 2020 In my case the zram problem happens after every reboot. RockPi4A/1Gbyte/32GB emmc running Armbian_20.02.0-rc1_Rockpi-4b_bionic_legacy_4.4.210_desktop.7z root@rockpi:~# armbianmonitor -u System diagnosis information will now be uploaded to cat: /var/log/armbian-hardware-monitor.log: Input/output error gzip: /var/log/armbian-hardware-monitor.log.1.gz: No such file or directory server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. Please post the URL in the forum where you've been asked for. root@rockpi:~# df -k /var/log Filesystem 1K-blocks Used Available Use% Mounted on /dev/zram0 49584 4324 41676 10% /var/log Console: [35959.400713] EXT4-fs error (device zram0): ext4_find_extent:916: inode #25: comm rs:main Q:R) [35959.410268] EXT4-fs error (device zram0): ext4_find_extent:916: inode #25: comm rs:main Q:R) [35959.421957] EXT4-fs error (device zram0): ext4_ext_remove_space:2999: inode #25: comm rs:ma) [35959.432859] EXT4-fs error (device zram0) in ext4_ext_truncate:4688: Filesystem failed CRC ... 32GB eMMC with >> 50% unused should have a lot of spare cells to live long even if i was not using zram ???
nekelson Posted February 10, 2020 Posted February 10, 2020 On 1/25/2020 at 5:25 AM, c0decrow said: I had the same problem on my Rock64 board running Armbian, Liteblue it fixes after reboot. Yeah Its fixed after reboot.
c0decrow Posted April 15, 2020 Posted April 15, 2020 In my case, the problem occurs after prolonged periods of time - about 20-30days uptime. However, it's still annoying to reboot a Linux-based system like a Windows server. Has anyone else tried the proposed solution with 'zram-config' ? @kevkkvek, could you please share how is your device running after that change?
Igor Posted April 15, 2020 Posted April 15, 2020 1 hour ago, c0decrow said: it's still annoying to reboot a Linux-based system You are probably using some very cheap arm development board that is only supported by amateurs and its support is not matured, right? Most of them doesn't run (mainline) Linux, but "some sort of development version of Linux." on top of fishy boot loaders. The problem above is trivial and solved with disabling ext4 debug mode or/and moving away from smelly "Linux". If you have Rockchip*, this means going to "current" kernel.
paleozogt Posted May 14, 2020 Posted May 14, 2020 I have a cluster of Raspberry Pi 4's with various small differences in armbian version. I'm seeing this problem on several of the nodes. Here's some armbianmonitor outputs. In the log at the bottom you can see the ext4-fs errors: http://ix.io/2m0y http://ix.io/2m0r http://ix.io/2m0s One error that pops out at me is EXT4-fs warning (device zram0): ext4_dirent_csum_verify:353: inode #11: comm find: No space for directory leaf checksum. Please run e2fsck -D. Perhaps the logs are maxing out the space, which leads to subsequent corruption of the filesystem? Another pattern that pops out at me is that the nodes running 4.4.182-rockchip64 and 4.4.192-rockchip64 have the error, but those running 4.4.174-rockchip64 don't have it. btw, none of these distros have zram-config (zramctl is provided by "util-linux"), so I'm not sure why we're talking about removing/reinstalling that.
Igor Posted May 14, 2020 Posted May 14, 2020 The problem is not critical - just ext4 driver debug is on ... use most recent image or (do a backup since in some cases it might fail) and switch to more recent builds: 1
guidol Posted May 14, 2020 Posted May 14, 2020 3 hours ago, paleozogt said: I have a cluster of Raspberry Pi 4's with various small differences in armbian version. Another pattern that pops out at me is that the nodes running 4.4.182-rockchip64 and 4.4.192-rockchip64 have the error, but those running 4.4.174-rockchip64 don't have it. You dont have a Raspberry Pi 4 with armbian These are Rockchip64 SBCs because there is no armbian for the Raspberry Pi 2
c0decrow Posted June 8, 2020 Posted June 8, 2020 Actually I'm using Armbian running on Rock64 board. Today I successfully did the kernel upgrade and I hope this will resolve the problem. @Igor, thank you for the info and the detailed instructions how to upgrade the Armbian kernel!
c0decrow Posted July 14, 2020 Posted July 14, 2020 I would like to confirm that the issue for me is solved by the switch to the last kernel build. 35 days without any issues: ~ $ uptime 13:50:11 up 35 days, 19:27, 1 user, load average: 0.07, 0.18, 0.20 Thanks again to @Igor!
Recommended Posts