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

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

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

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

On Sat, April 30, 2016 12:56 pm, 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.
>
As I said, I feel I hear MS Widows admins on this list. There are only two
things that require reboot in UNIX and Linux Worlds. Kernel patches or
rather installation of patched kernel (and again, no splice or similar on
my servers), and libc or glibc (as all and everything is linked to
libc/glibc, so it is virtually impossible to swap over to patched
libc/glibc in RAM).

All other updates/patches do not require reboot (at least for those who
know what they are doing).

Just my $0.02.

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

++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++