Jump to content

EXT4-fs zram0 Checksum error


kevkkvek

Recommended Posts

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. 

IMG_20190626_030336.jpg

Link to comment
Share on other sites

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.
 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

######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?

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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 ???

Link to comment
Share on other sites

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.  :D

 

Has anyone else tried the proposed solution with 'zram-config' ?

@kevkkvek, could you please share how is your device running after that change?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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:

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.

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines