[CentOS] tune2fs: Filesystem has unsupported feature(s) while trying to open

[Alice Wonder]

Not all patches require rebooting the kernel. Most do not.

On 04/30/2016 10:56 AM, William Warren wrote:
> ALL systems need patching so obsessing about uptime is insecurity on its
> face.  It doe not matter if it is windows or linux or anything else.
>
>
> On 4/30/2016 11:33 AM, Valeri Galtsev wrote:
>> On Sat, April 30, 2016 8:54 am, William Warren wrote:
>>> uptime=insecurity.
>> This sounds like MS Windows admin's statement. Are there any Unix admins
>> still left around who remember systems with kernel that doesn't need
>> [security] patching for few years? And libc that does not need security
>> patches often. I almost said glibc, but on those Unixes it was libc;
>> glibc, however, wasn't getting security patches too often some long time
>> ago as well. Because these are only kernel and libc/glibc that do require
>> reboot (no splice or similar for me on servers, thank you).
>>
>> It sounds to me like the system you are talking about, and us, sysadmins
>> administering it, is pretty much in MS Widows ballpark already. Right?
>>
>> Sorry about my rant. I still consider not well debugged code not well
>> debugged code...
>>
>> Valeri
>>
>>> Patches must be kept up these days or your uptime
>>> won't matter when your server gets compromised.
>>>
>>>
>>> On 4/22/2016 4:33 AM, Rob Townley wrote:
>>>> 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
>>>>>
>>>> _______________________________________________
>>>> CentOS mailing list
>>>> CentOS at centos.org
>>>> https://lists.centos.org/mailman/listinfo/centos
>>> _______________________________________________
>>> CentOS mailing list
>>> CentOS at centos.org
>>> https://lists.centos.org/mailman/listinfo/centos
>>>
>>
>> ++++++++++++++++++++++++++++++++++++++++
>> Valeri Galtsev
>> Sr System Administrator
>> Department of Astronomy and Astrophysics
>> Kavli Institute for Cosmological Physics
>> University of Chicago
>> Phone: 773-702-4247
>> ++++++++++++++++++++++++++++++++++++++++
>> _______________________________________________
>> CentOS mailing list
>> CentOS at centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos