linux-ext4 - Re: Reg: loical volume file system is getting corrupted after multiple reboots.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6549e42a-e1d3-c25d-9f9c-3b9b12a66a5d@redhat.com>
Date:   Tue, 1 May 2018 07:45:15 -0500
From:   Eric Sandeen <esandeen@...hat.com>
To:     RAJESH DASARI <raajeshdasari@...il.com>, linux-ext4@...r.kernel.org
Subject: Re: Reg: loical volume file system is getting corrupted after
 multiple reboots.

On 4/30/18 1:27 PM, RAJESH DASARI wrote:
> Hi ,
> 
> We are noticing an issue with logical volume file system is getting
> corrupted after restarting the machine for multiple times.

When you say restarting, are you talking about clean reboots, or
power fails etc that may replay the log?

(Also note that for a while at least on Fedora, systemd was preventing
the root filesystem from unmounting cleanly on reboot.)

So, were these log-replay-inducing machine restarts or "clean" reboots?

> This issue we have started noticing after upgrading the kernel to 4.4.121.

What was the previous kernel that did not seem to exhibit the problem?

If this happens again, capturing the primary super in some way (i.e.
e2image, or even simply using dd to copy it) might be interesting, to see
exactly what the corruption is.

-Eric

> while running tune2fs -c 1 /dev/VG_NEW/state to set the
> mmax_mounts_count we are noticing the error.
> 
> tune2fs -c 1 /dev/VG_NEW/state
> tune2fs 1.44.0 (7-Mar-2018)
> tune2fs: The ext2 superblock is corrupt while trying to open /dev/VG_NEW/state
> Couldn't find valid filesystem superblock.
> 
> lvs command output is below (there are other logical volumes and
> volume groups also along with state volume, I have not pasted them to
> minimize this post).
> Important thing to note here is always state volume only is getting
> corrupted and no file system corruption seen on other logical volumes.