CentOS - Apr 2016 - tune2fs: Filesystem has unsupported feature(s) while trying to open

I have an ext4 filesystem for which I'm trying to use "tune2fs
-l".
Here is the listing of the filesystem from the "mount" command:

# mount | grep share
/dev/mapper/VolGroup_Share-LogVol_Share on /share type ext4
(rw,noatime,nodiratime,usrjquota=aquota.user,jqfmt=vfsv0,data=writeback,nobh,barrier=0)


When I try to run "tune2fs" on it, I get the following error:

# tune2fs -l /dev/mapper/VolGroup_Share-LogVol_Share
tune2fs 1.41.12 (17-May-2010)
tune2fs: Filesystem has unsupported feature(s) while trying to open
/dev/mapper/VolGroup_Share-LogVol_Share
Couldn't find valid filesystem superblock.


This filesystem was created on this system (i.e. not imported from
another system).  I have other ext4 filesystems on this server, and
they all work with "tune2fs -l".

Basic system info:

# rpm -qf `which tune2fs`
e2fsprogs-1.41.12-18.el6.x86_64

# cat /etc/redhat-release
CentOS release 6.5 (Final)

# uname -a
Linux lnxutil8 2.6.32-504.12.2.el6.x86_64 #1 SMP Wed Mar 11 22:03:14
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux


I did a little web searching on this, most of the hits were for much
older systems, where (for example) the e2fsprogs only supported up to
ext3, but the user had an ext4 filesystem.  Obviously that's not the
case here.  In other words, the filesystem was created with the
mkfs.ext4 binary from the same e2fsprogs package as the tune2fs binary
I'm trying to use.

Anyone ever seen anything like this?

Thanks!

On Tue, Apr 19, 2016 at 10:51 AM, Matt Garman <matthew.garman at
gmail.com> wrote:

># rpm -qf `which tune2fs`
>e2fsprogs-1.41.12-18.el6.x86_64
That's in the CentOS 6.4 repo, I don't see a newer one through 6.7 but
I didn't do a thorough check, just with google site: filter.

> # cat /etc/redhat-release
> CentOS release 6.5 (Final)
> # uname -a
> Linux lnxutil8 2.6.32-504.12.2.el6.x86_64 #1 SMP Wed Mar 11 22:03:14
> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
And that's a centosplus kernel in the 6.6 repo; while the regular
kernel for 6.7 is currently kernel-2.6.32-573.22.1.el6.src.rpm. So I'm
going to guess you'd have this problem even if you weren't using the
centosplus kernel.

I suggest you do a yum upgrade anyway, 6.7 is current, clean it up,
test it, and then while chances are it's still a problem, then it's
probably a legit bug worth filing. In the meantime you'll have to
upgrade your e2fsprogs yourself.

> I did a little web searching on this, most of the hits were for much
> older systems, where (for example) the e2fsprogs only supported up to
> ext3, but the user had an ext4 filesystem.  Obviously that's not the
> case here.  In other words, the filesystem was created with the
> mkfs.ext4 binary from the same e2fsprogs package as the tune2fs binary
> I'm trying to use.
>
> Anyone ever seen anything like this?
Well the date of the kernel doesn't tell the whole story, so you need
a secret decoder ring to figure out what's been backported into this
distro kernels. There's far far less backporting happening in user
space tools. So it's not difficult for them to get stale when the
kernel is providing new features. But I'd say the kernel has newer
features than the progs supports and the progs are too far behind.

And yes, this happens on the XFS list and the Btrfs list too where
people are using old progs with new kernels and it can be a problem.
Sometimes new progs and old kernels are a problem too but that's less
common.


-- 
Chris Murphy

tune2fs against a LVM (albeit formatted with ext4) is not the same as
tune2fs against ext4.

Could this possibly be a machine where uptime has outlived its usefulness?

On Thu, Apr 21, 2016 at 10:02 PM, Chris Murphy <lists at
colorremedies.com>
wrote:
> On Tue, Apr 19, 2016 at 10:51 AM, Matt Garman <matthew.garman at
gmail.com>
> wrote:
>
>
> ># rpm -qf `which tune2fs`
> >e2fsprogs-1.41.12-18.el6.x86_64
>
> That's in the CentOS 6.4 repo, I don't see a newer one through 6.7
but
> I didn't do a thorough check, just with google site: filter.
>
>
> > # cat /etc/redhat-release
> > CentOS release 6.5 (Final)
>
> > # uname -a
> > Linux lnxutil8 2.6.32-504.12.2.el6.x86_64 #1 SMP Wed Mar 11 22:03:14
> > UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> And that's a centosplus kernel in the 6.6 repo; while the regular
> kernel for 6.7 is currently kernel-2.6.32-573.22.1.el6.src.rpm. So I'm
> going to guess you'd have this problem even if you weren't using
the
> centosplus kernel.
>
> I suggest you do a yum upgrade anyway, 6.7 is current, clean it up,
> test it, and then while chances are it's still a problem, then it's
> probably a legit bug worth filing. In the meantime you'll have to
> upgrade your e2fsprogs yourself.
>
>
> > I did a little web searching on this, most of the hits were for much
> > older systems, where (for example) the e2fsprogs only supported up to
> > ext3, but the user had an ext4 filesystem.  Obviously that's not
the
> > case here.  In other words, the filesystem was created with the
> > mkfs.ext4 binary from the same e2fsprogs package as the tune2fs binary
> > I'm trying to use.
> >
> > Anyone ever seen anything like this?
>
> Well the date of the kernel doesn't tell the whole story, so you need
> a secret decoder ring to figure out what's been backported into this
> distro kernels. There's far far less backporting happening in user
> space tools. So it's not difficult for them to get stale when the
> kernel is providing new features. But I'd say the kernel has newer
> features than the progs supports and the progs are too far behind.
>
> And yes, this happens on the XFS list and the Btrfs list too where
> people are using old progs with new kernels and it can be a problem.
> Sometimes new progs and old kernels are a problem too but that's less
> common.
>
>
> --
> Chris Murphy
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>