Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[Mark Pace]

After a long process I have the filesystem converted to EXT3 and the new
kernel running.

On Thu, May 24, 2018 at 1:59 PM, Mike Walter  wrote:

> I'm just supposing here, that you put and it's on a test bed server first,
> at which point you would have found the problem with the xfs file system
> and been able to back it out. Only after maintenance has been thoroughly
> vetted on the test bed server wood shove it down the throats of the other
> servers.
>
> But, I never was responsible for Linux on Z systems servers, so I may have
> missed out on all the fun.
>
> Mike Walter
> -Retired-
> 
> From: Linux on 390 Port  on behalf of Marcy
> Cortes 
> Sent: Thursday, May 24, 2018 11:00:12 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-
> default
>
> Nice idea, but when you have a thousand servers, that isn't very
> practical.  And one your server has been up a few minutes its data has
> changed and regressing it that way may be a problem.   The multi kernel
> support works well for things like backing out the kernel.
>
>
>
>
> -Original Message-
> From: Linux on 390 Port  On Behalf Of John McKown
> Sent: Thursday, May 24, 2018 7:51 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: [LINUX-390] Bug with XFS and SLES 12SP3
> kernel-default-4.4.131-94.29-default
>
> On Thu, May 24, 2018 at 9:29 AM Mike Walter  com>
> wrote:
>
> > When I was a young man learning the art of systems programming sooo
> > long ago, I was taught that the first step of applying maintenance is
> > to make a physical backup of the target volumes.  That way you have a
> > validated source with which to return if/when the maintenance fails.
> Just sayin'.
> > :-)
> >
>
> ​Total agreement. I'm having a problem with a sandox system right now with
> some maintenance (but it's z/OS, not Linux). But that's what I did --
> physical back of all the volumes before doing _anything_. I do the same
> sort of thing when I install a never version of a product. I do a "tar"
> backup of the various files (it they're in /etc or /var or ...) &
> filesystems.​
>
>
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> https://eur03.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-
> 390=02%7C01%7C%7C74815a2d96a04a6abef508d5c18fc160%
> 7C84df9e7fe9f640afb435%7C1%7C0%7C636627745517533603=
> T6se4MfGCrQKhEoLAl1GSZdahtAXs2ZZd4gZiuAwgjU%3D=0
> --
> For more information on Linux on System z, visit
> https://eur03.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwiki.linuxvm.org%2F=02%7C01%7C%
> 7C74815a2d96a04a6abef508d5c18fc160%7C84df9e7fe9f640afb435
> %7C1%7C0%7C636627745517533603=84ePrZlYwZTFJpCrEaMBxk9u2g%
> 2FiN1kja9rARzKuHl0%3D=0
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>



-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[Marcy Cortes]

That is what we did and Ted found it on the first try, which is good because 
most of our servers don't have xfs.

We did have an issue with the kernel that came with SLES 11 SP4 initially.
It was a very intermittent problem with NFS client that only seemed to happen 
to us in production.   We never could recreate in a test environment.   And 
when it struck, the only way out was a reboot.  It didn't rear its head 
immediately but over a few weeks and then oddly got more frequent.
So Just Saying, you need to be able to back out only the broken pieces...   
Luckily the SUSE stuff with multiversion kernels makes it easy ( I have no idea 
if RH or other distros do that.



-Original Message-
From: Linux on 390 Port  On Behalf Of Mike Walter
Sent: Thursday, May 24, 2018 11:00 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Bug with XFS and SLES 12SP3 
kernel-default-4.4.131-94.29-default

I'm just supposing here, that you put and it's on a test bed server first, at 
which point you would have found the problem with the xfs file system and been 
able to back it out. Only after maintenance has been thoroughly vetted on the 
test bed server wood shove it down the throats of the other servers.

But, I never was responsible for Linux on Z systems servers, so I may have 
missed out on all the fun.

Mike Walter
-Retired-

From: Linux on 390 Port  on behalf of Marcy Cortes 

Sent: Thursday, May 24, 2018 11:00:12 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

Nice idea, but when you have a thousand servers, that isn't very practical.  
And one your server has been up a few minutes its data has changed and 
regressing it that way may be a problem.   The multi kernel support works well 
for things like backing out the kernel.




-Original Message-
From: Linux on 390 Port  On Behalf Of John McKown
Sent: Thursday, May 24, 2018 7:51 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Bug with XFS and SLES 12SP3 
kernel-default-4.4.131-94.29-default

On Thu, May 24, 2018 at 9:29 AM Mike Walter 
wrote:

> When I was a young man learning the art of systems programming sooo 
> long ago, I was taught that the first step of applying maintenance is 
> to make a physical backup of the target volumes.  That way you have a 
> validated source with which to return if/when the maintenance fails.  Just 
> sayin'.
> :-)
>

​Total agreement. I'm having a problem with a sandox system right now with some 
maintenance (but it's z/OS, not Linux). But that's what I did -- physical back 
of all the volumes before doing _anything_. I do the same sort of thing when I 
install a never version of a product. I do a "tar"
backup of the various files (it they're in /etc or /var or ...) & filesystems.​



--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390=02%7C01%7C%7C74815a2d96a04a6abef508d5c18fc160%7C84df9e7fe9f640afb435%7C1%7C0%7C636627745517533603=T6se4MfGCrQKhEoLAl1GSZdahtAXs2ZZd4gZiuAwgjU%3D=0
--
For more information on Linux on System z, visit
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.linuxvm.org%2F=02%7C01%7C%7C74815a2d96a04a6abef508d5c18fc160%7C84df9e7fe9f640afb435%7C1%7C0%7C636627745517533603=84ePrZlYwZTFJpCrEaMBxk9u2g%2FiN1kja9rARzKuHl0%3D=0

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[Mike Walter]

I'm just supposing here, that you put and it's on a test bed server first, at 
which point you would have found the problem with the xfs file system and been 
able to back it out. Only after maintenance has been thoroughly vetted on the 
test bed server wood shove it down the throats of the other servers.

But, I never was responsible for Linux on Z systems servers, so I may have 
missed out on all the fun.

Mike Walter
-Retired-

From: Linux on 390 Port  on behalf of Marcy Cortes 

Sent: Thursday, May 24, 2018 11:00:12 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

Nice idea, but when you have a thousand servers, that isn't very practical.  
And one your server has been up a few minutes its data has changed and 
regressing it that way may be a problem.   The multi kernel support works well 
for things like backing out the kernel.




-Original Message-
From: Linux on 390 Port  On Behalf Of John McKown
Sent: Thursday, May 24, 2018 7:51 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Bug with XFS and SLES 12SP3 
kernel-default-4.4.131-94.29-default

On Thu, May 24, 2018 at 9:29 AM Mike Walter 
wrote:

> When I was a young man learning the art of systems programming sooo
> long ago, I was taught that the first step of applying maintenance is
> to make a physical backup of the target volumes.  That way you have a
> validated source with which to return if/when the maintenance fails.  Just 
> sayin'.
> :-)
>

​Total agreement. I'm having a problem with a sandox system right now with some 
maintenance (but it's z/OS, not Linux). But that's what I did -- physical back 
of all the volumes before doing _anything_. I do the same sort of thing when I 
install a never version of a product. I do a "tar"
backup of the various files (it they're in /etc or /var or ...) & filesystems.​



--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390=02%7C01%7C%7C74815a2d96a04a6abef508d5c18fc160%7C84df9e7fe9f640afb435%7C1%7C0%7C636627745517533603=T6se4MfGCrQKhEoLAl1GSZdahtAXs2ZZd4gZiuAwgjU%3D=0
--
For more information on Linux on System z, visit
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.linuxvm.org%2F=02%7C01%7C%7C74815a2d96a04a6abef508d5c18fc160%7C84df9e7fe9f640afb435%7C1%7C0%7C636627745517533603=84ePrZlYwZTFJpCrEaMBxk9u2g%2FiN1kja9rARzKuHl0%3D=0

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[R P Herrold]

On Thu, 24 May 2018, Mike Walter wrote:

> When I was a young man learning the art of systems
> programming sooo long ago, I was taught that the first step
> of applying maintenance is to make a physical backup of the
> target volumes.  That way you have a validated source with
> which to return if/when the maintenance fails.  Just sayin'.
> :-)

hunh -0- I was taught to make and to TEST them, before letting
the SE touch the CPU

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[Marcy Cortes]

Nice idea, but when you have a thousand servers, that isn't very practical.  
And one your server has been up a few minutes its data has changed and 
regressing it that way may be a problem.   The multi kernel support works well 
for things like backing out the kernel.


 

-Original Message-
From: Linux on 390 Port  On Behalf Of John McKown
Sent: Thursday, May 24, 2018 7:51 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Bug with XFS and SLES 12SP3 
kernel-default-4.4.131-94.29-default

On Thu, May 24, 2018 at 9:29 AM Mike Walter 
wrote:

> When I was a young man learning the art of systems programming sooo 
> long ago, I was taught that the first step of applying maintenance is 
> to make a physical backup of the target volumes.  That way you have a 
> validated source with which to return if/when the maintenance fails.  Just 
> sayin'.
> :-)
>

​Total agreement. I'm having a problem with a sandox system right now with some 
maintenance (but it's z/OS, not Linux). But that's what I did -- physical back 
of all the volumes before doing _anything_. I do the same sort of thing when I 
install a never version of a product. I do a "tar"
backup of the various files (it they're in /etc or /var or ...) & filesystems.​



--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: 7.5 package levels

[R P Herrold]

On Thu, 24 May 2018, Timothy Sipples wrote:

> Russ Herrold wrote:
> > It may turn out that we (ClefOS) need to fork and offer two
> > variants
>
> I guess I'd call them "streams" rather than "forks."

One might, but in Red Hat parlance the 'Z' [a namespace
collision here, NOT referring to Arch] extended support tail
is called a 'stream ;)

> For what it's worth, Red Hat seems to offer at least 3 major
> streams now: Fedora (their "community" release), RHEL
> Structure A, and RHEL

The argument might be made, actually that there is a fourth:
CentOS
in light of their take-over and re-casting of that project a
few years back.  As one of its three founders, I was perfectly
happy to simply keep the community's source code resources
available in a binary form, simply replicating RHEL, deviation
for deviation, bug for bug.  Post acquisition, RHT added a
plethora of distractions, and started using CentOS as a second
'testing bench' but without so much of that pesky community
'hoots and hollars' which the Fedoraproject developed

> The RHEL Structure A/RHEL pair of streams is a unique
> offering for the s390x architecture branch, at least for
> now. (Is it a one-time aberration or the start of something
> new? I have no idea, so ask Red Hat, I guess.)

I spent some time researching this yesterday.  The kernel-alt
variant seems to be timed as to release mid RHEL 7, priced and
positioned to be a 'hard core' and high volume performance
engine for (particularly Z based) Docker / Open Shift / Atomic
transient / ephemeral common kernel instances [isolated by
Linux cgroups, and SElinux], rather than lots of 'each running
a potentially different kernel' KVM Open Stack instances,
which may be long-lived.  "Open Shift" vs "Open Stack" is
another of those unfortunately chosen nameings, as the
initials 'O.S.' here as to two differing virtualization
technologies, as well as the commonly used: Operating System
;)

> In RHEL 7.5, Red Hat decided to offer kernel 3.10 (only) for
> all POWER processors prior to POWER9, and (only) kernel 4.14
> for POWER9. For X86-64 it's only 3.10, and for ARM64 it's
> only 4.14.

Look again, but think about shared kernel spaces, and it makes
more sense.  This gets RHT an uplift on the kernel (and the
nice additions for Z in 4.14) and 'buys some time' as to the
fact that the 'long lived Enterprise maintainability' model
that RHEL offers, is really _too long_ for people wanting to
respond in a more _agile_ fashion, and to also provide a
platform capable of running the 'latest and greatest'

RHEL-next (externally, and for partially historical reasons,
RHT employees do not call formally call the next Major release
'8' yet, as it has not shipped yet / some 'leaks' by others
in bug trackers call it '8') has the longest ever interval
after its prior Major.  Up to 1600 days since the RHEL 7 drop
as of Apr 30 2018.  Previous intervals were:
574 days after RHL EE 6.2E
637 days after RHEL 2.1
476 days after RHEL 3
506 days after RHEL 4
1309 days after RHEL 5
1302 days after RHEL 6

> There are certain newer capabilities that RHEL 7.5 doesn't
> support on s390x that RHEL 7.5 Structure A does. Red Hat's
> release notes explain all that.

Lots of new nuggets in those Release Notes which were not in
the Beta copy.  I'll miss sendmail, but not XFS

Actually there was a lightly publicized 'stalking horse'
'testing candidate' as well:
RHEL 7.4 variant with an -alt kernel

I again use 'variant', as it varied, and will not use the
over-loaded word: fork here ;)

> But it's possible to mix RHEL and RHEL Structure A instances
> on the same machine and in a Red Hat supported way. (And,
> for that matter, other supported RHEL releases.)

You have the benefit of potential access in light of IBM's
long time and current collaboration with RHT, and I
hope so, but building a clean testing candidate has been
tricky

It turns out there is also a difference in how an 'El Torito'
capable [needed for one deployment method on Z] CD vs a DVD
image is spun, as there are s390x specific size requirements
that differ from other Arches, and some tooling changes were
needed

It's no big deal to have this kind of delay building a
community rebuild of sources.  The test 7.5 binary packages
will 'yum update' over a base install of an earlier ClefOS 7
variant just fine.  The ability to move the absolute
underlying base kernel back and forth between the 3.10 and the
4.14 series seems unlikely, and really, not something that
might not be better done with a fresh install.  There is the
open question, which I have not tested yet, about trying a
kernel-3 to kernel[-alt]-4 transition, but again, probably
better done with a fresh install.  It will probably end up
with a minimal installer image based on each

Thank you for your insights

> 
> Timothy Sipples
> IT Architect Executive, 

Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[Marcy Cortes]

Adding on, once you have the multiversion kernels set up, select 2) Advanced 
options at boot and then select the desired kernel.

Removing the new one will make the old one the default.


Marcy


-Original Message-
From: Linux on 390 Port  On Behalf Of Marcy Cortes
Sent: Thursday, May 24, 2018 8:07 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Bug with XFS and SLES 12SP3 
kernel-default-4.4.131-94.29-default

If your server is up, back out can be done easily

First make sure /etc/zypp/zypp.conf has
multiversion = provides:multiversion(kernel)
multiversion.kernels = latest,latest-1,running

Then simply install the old one 
zypper install kernel-default-4.4.126-94.22.1.s390x  --oldpackage

And remove the new one
zypper remove kernel-default-4.4.131-94.29-default

That should do it.
Reboot




--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[Marcy Cortes]

If your server is up, back out can be done easily

First make sure /etc/zypp/zypp.conf has
multiversion = provides:multiversion(kernel)
multiversion.kernels = latest,latest-1,running

Then simply install the old one 
zypper install kernel-default-4.4.126-94.22.1.s390x  --oldpackage

And remove the new one
zypper remove kernel-default-4.4.131-94.29-default

That should do it.
Reboot




--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: 7.5 package levels

[Neale Ferguson]

Out of curiosity what is in s390utils-2.x that wouldn't work on a 3.10 kernel?

On 5/24/18, 03:01, "Linux on 390 Port on behalf of Viktor VM Mihajlovski" 
 wrote:

On 24.05.2018 06:59, Timothy Sipples wrote:
Specifically, RHEL Structure A is required to run KVM guests on IBM Z.
Guests can be either RHEL and RHEL Structure A. Another thing to keep in
mind is that the s390utils-* releases are different. For RHEL it's
1.23.0 and for RHEL Structure A it's 2.1.0.
 


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[John McKown]

On Thu, May 24, 2018 at 9:29 AM Mike Walter 
wrote:

> When I was a young man learning the art of systems programming sooo long
> ago, I was taught that the first step of applying maintenance is to make a
> physical backup of the target volumes.  That way you have a validated
> source with which to return if/when the maintenance fails.  Just sayin'.
> :-)
>

​Total agreement. I'm having a problem with a sandox system right now with
some maintenance (but it's z/OS, not Linux). But that's what I did --
physical back of all the volumes before doing _anything_. I do the same
sort of thing when I install a never version of a product. I do a "tar"
backup of the various files (it they're in /etc or /var or ...) &
filesystems.​



>
> Mike Walter
> -Retired-
>
-- 
Once a government places vague notions of public safety and security above
the preservation of freedom, a general loss of liberty is sure to follow.

GCS Griffin -- Pelaran Alliance -- TFS Guardian (book)


Maranatha! <><
John McKown

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: 7.5 package levels

[Neale Ferguson]

The 3.10 works fine with Docker. There are a couple of things like criu that 
require things in the 4.1x kernel but this is not essential. I run OpenShift 
Origin 3.9 under docker 1.13 under the 3.10 kernel.

On 5/24/18, 09:19, "Linux on 390 Port on behalf of Terri C. Glowaniak" 
 wrote:

I found this in the RHEL7.5 release notes..

The 3.10 kernel version does not support KVM virtualization and containers 
on IBM z Systems. Both of these features are supported on the 4.14 kernel on 
IBM z Systems - this offerring is also referred to as Structure A.

I run z/VM as the hypervisor, so I am assuming I would need RHEL7 Structure 
A to do containers?


Thanks,
Terri Glowaniak

 

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of 
Viktor VM Mihajlovski
Sent: Thursday, May 24, 2018 2:01 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: 7.5 package levels

[External Content] Please use caution.

On 24.05.2018 06:59, Timothy Sipples wrote:
> Russ Herrold wrote:
>> It may turn out that we (ClefOS) need to fork and offer two variants
>
> I guess I'd call them "streams" rather than "forks."
>
> For what it's worth, Red Hat seems to offer at least 3 major streams now:
> Fedora (their "community" release), RHEL Structure A, and RHEL. The 
> RHEL Structure A/RHEL pair of streams is a unique offering for the 
> s390x architecture branch, at least for now. (Is it a one-time 
> aberration or the start of something new? I have no idea, so ask Red 
> Hat, I guess.) In RHEL 7.5, Red Hat decided to offer kernel 3.10 
> (only) for all POWER processors prior to POWER9, and (only) kernel 
> 4.14 for POWER9. For X86-64 it's only 3.10, and for ARM64 it's only 4.14.
>
> There are certain newer capabilities that RHEL 7.5 doesn't support on 
> s390x that RHEL 7.5 Structure A does. Red Hat's release notes explain all 
that.
> But it's possible to mix RHEL and RHEL Structure A instances on the 
> same machine and in a Red Hat supported way. (And, for that matter, 
> other supported RHEL releases.)
>
Specifically, RHEL Structure A is required to run KVM guests on IBM Z.
Guests can be either RHEL and RHEL Structure A. Another thing to keep in 
mind is that the s390utils-* releases are different. For RHEL it's
1.23.0 and for RHEL Structure A it's 2.1.0.
> It looks like the minimum RHEL 7.5/RHEL 7.5 Structure A machine model 
> requirement hasn't changed since RHEL 7.4, so it's z196/z114 
> processors or higher, which includes all LinuxONE machines.
>
> I don't have a strong view on the "right" approach for Linux release 
> streams. It really depends on end users and what they prefer, and they 
> might choose particular Linux distributors based on their different 
> release/service stream approaches. There are some important 
> principles, though. I'd say that maintaining security currency is 
> quite important, as a notable example. But that'll likely mean not 
> waiting too long to exploit new system features since many of those 
> new features are often security-related.
>
> --
> --
> Timothy Sipples
> IT Architect Executive, Industry Solutions, IBM Z & LinuxONE, 
> Multi-Geography
> E-Mail: sipp...@sg.ibm.com
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions, send 
> email to lists...@vm.marist.edu with the message: INFO LINUX-390 or 
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit 
> http://wiki.linuxvm.org/
>


--
Regards,
  Viktor Mihajlovski

--
For LINUX-390 subscribe / signoff / archive access instructions, send email 
to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or 
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[Mike Walter]

When I was a young man learning the art of systems programming sooo long ago, I 
was taught that the first step of applying maintenance is to make a physical 
backup of the target volumes.  That way you have a validated source with which 
to return if/when the maintenance fails.  Just sayin'.  :-)

Mike Walter
-Retired-

From: Linux on 390 Port  on behalf of Mark Pace 

Sent: Thursday, May 24, 2018 9:14:00 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

I found in yast a way to update the boot loader to point to the older
version of the kernel.  That allowed me to reboot and mount the XFS file
system. Yay.

But i still need to figure out if there is a way to remove the patches from
the new kernel.  As it is, it appears to me, that the maintenance(patches)
are now out of sync. Yast/zypper now think I am running the new kernel when
in fact I am using an older kernel.

On Thu, May 24, 2018 at 9:34 AM, Mark Pace  wrote:

> In /boot I still have the previous kernel files,  just not sure how to
> make them the kernel used at boot.
>
> .image-4.4.126-94.22-default.hmac  image-4.4.126-94.22-default
> symvers-4.4.126-94.22-default.gz
> .image-4.4.131-94.29-default.hmac  image-4.4.131-94.29-default
> symvers-4.4.131-94.29-default.gz
> System.map-4.4.126-94.22-default   initrd
> sysctl.conf-4.4.126-94.22-default
> System.map-4.4.131-94.29-default   initrd-4.4.126-94.22-default
> sysctl.conf-4.4.131-94.29-default
> boot.readmeinitrd-4.4.126-94.22-default-kdump
> vmlinux-4.4.126-94.22-default.gz
> config-4.4.126-94.22-default   initrd-4.4.131-94.29-default
> vmlinux-4.4.131-94.29-default.gz
> config-4.4.131-94.29-default   initrd-4.4.131-94.29-default-kdump
> zipl
> grub2  symtypes-4.4.126-94.22-default.gz
> image  symtypes-4.4.131-94.29-default.gz
>
>
> On Thu, May 24, 2018 at 9:27 AM, Alan Altmark 
> wrote:
>
>> On Thursday, 05/24/2018 at 12:45 GMT, Rick Troth  wrote:
>> > On 05/23/2018 07:25 PM, R P Herrold wrote:
>> > >> Suse just released a new kernel-default-4.4.131-94.29-1
>> > >> package for SLES 12SP3 with some kernel security fixes.  If
>> > >> you use XFS, don't install it!
>> > > My condolences
>> > >
>> > > There has been an (at least) four way finger pointing contest
>> > > raging for the last couple of months (on the Fedoraproject
>> > > front) between:
>> > > - xfs developers
>> > > - systemd developers
>> > > - dracut developers
>> > > - innocent victims of XFS
>> >
>> > - snip -
>> >
>> > Explain to me how a KERNEL update relates to a finger-pointing fest
>> > among three user-space packages and the users?
>> >
>> > I DO use XFS on some systems. I prolly fall into the fourth group, but
>> > was already pointing my digits at that second bullet.
>>
>> Explain to me why a distro would release an update that knowingly breaks
>> a
>> file system?  Unless they don't support xfs?
>>
>> Alan Altmark
>>
>> Senior Managing z/VM and Linux Consultant
>> IBM Systems Lab Services
>> IBM Z Delivery Practice
>> ibm.com/systems/services/labservices
>> office: 607.429.3323
>> mobile; 607.321.7556
>> alan_altm...@us.ibm.com
>> IBM Endicott
>>
>>
>> --
>> For LINUX-390 subscribe / signoff / archive access instructions,
>> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
>> visit
>> https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390=02%7C01%7C%7C729331ef1eaa416edd5308d5c1812d66%7C84df9e7fe9f640afb435%7C1%7C0%7C636627682905762564=pVFfsvoD%2Bo54c7gUfPfb2YUpxKaLoxVTxaSlLEpPzcg%3D=0
>> --
>> For more information on Linux on System z, visit
>> https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.linuxvm.org%2F=02%7C01%7C%7C729331ef1eaa416edd5308d5c1812d66%7C84df9e7fe9f640afb435%7C1%7C0%7C636627682905762564=prkeEQq3xbezoF0CXXrVjn7i7IocS3qwaJ75sOvc3W4%3D=0
>>
>
>
>
> --
> The postings on this site are my own and don’t necessarily represent
> Mainline’s positions or opinions
>
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
>
>
>
>


--
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit

Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[Mark Pace]

I found in yast a way to update the boot loader to point to the older
version of the kernel.  That allowed me to reboot and mount the XFS file
system. Yay.

But i still need to figure out if there is a way to remove the patches from
the new kernel.  As it is, it appears to me, that the maintenance(patches)
are now out of sync. Yast/zypper now think I am running the new kernel when
in fact I am using an older kernel.

On Thu, May 24, 2018 at 9:34 AM, Mark Pace  wrote:

> In /boot I still have the previous kernel files,  just not sure how to
> make them the kernel used at boot.
>
> .image-4.4.126-94.22-default.hmac  image-4.4.126-94.22-default
> symvers-4.4.126-94.22-default.gz
> .image-4.4.131-94.29-default.hmac  image-4.4.131-94.29-default
> symvers-4.4.131-94.29-default.gz
> System.map-4.4.126-94.22-default   initrd
> sysctl.conf-4.4.126-94.22-default
> System.map-4.4.131-94.29-default   initrd-4.4.126-94.22-default
> sysctl.conf-4.4.131-94.29-default
> boot.readmeinitrd-4.4.126-94.22-default-kdump
> vmlinux-4.4.126-94.22-default.gz
> config-4.4.126-94.22-default   initrd-4.4.131-94.29-default
> vmlinux-4.4.131-94.29-default.gz
> config-4.4.131-94.29-default   initrd-4.4.131-94.29-default-kdump
> zipl
> grub2  symtypes-4.4.126-94.22-default.gz
> image  symtypes-4.4.131-94.29-default.gz
>
>
> On Thu, May 24, 2018 at 9:27 AM, Alan Altmark 
> wrote:
>
>> On Thursday, 05/24/2018 at 12:45 GMT, Rick Troth  wrote:
>> > On 05/23/2018 07:25 PM, R P Herrold wrote:
>> > >> Suse just released a new kernel-default-4.4.131-94.29-1
>> > >> package for SLES 12SP3 with some kernel security fixes.  If
>> > >> you use XFS, don't install it!
>> > > My condolences
>> > >
>> > > There has been an (at least) four way finger pointing contest
>> > > raging for the last couple of months (on the Fedoraproject
>> > > front) between:
>> > > - xfs developers
>> > > - systemd developers
>> > > - dracut developers
>> > > - innocent victims of XFS
>> >
>> > - snip -
>> >
>> > Explain to me how a KERNEL update relates to a finger-pointing fest
>> > among three user-space packages and the users?
>> >
>> > I DO use XFS on some systems. I prolly fall into the fourth group, but
>> > was already pointing my digits at that second bullet.
>>
>> Explain to me why a distro would release an update that knowingly breaks
>> a
>> file system?  Unless they don't support xfs?
>>
>> Alan Altmark
>>
>> Senior Managing z/VM and Linux Consultant
>> IBM Systems Lab Services
>> IBM Z Delivery Practice
>> ibm.com/systems/services/labservices
>> office: 607.429.3323
>> mobile; 607.321.7556
>> alan_altm...@us.ibm.com
>> IBM Endicott
>>
>>
>> --
>> For LINUX-390 subscribe / signoff / archive access instructions,
>> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
>> visit
>> http://www.marist.edu/htbin/wlvindex?LINUX-390
>> --
>> For more information on Linux on System z, visit
>> http://wiki.linuxvm.org/
>>
>
>
>
> --
> The postings on this site are my own and don’t necessarily represent
> Mainline’s positions or opinions
>
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
>
>
>
>


-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[R P Herrold]

On Thu, 24 May 2018, Rick Troth wrote:

> Explain to me how a KERNEL update relates to a finger-pointing fest
> among three user-space packages and the users?
>
> I DO use XFS on some systems. I prolly fall into the fourth group, but
> was already pointing my digits at that second bullet.

The kernel needs to be reached, and at shutdown, left

Dracut, and early on, systemd acting as 'init' need to
transition out of an initrd into a (periodically updated)
kernel, and mount filesytems

At shutdown / reboot, filesystems need to be synced
and 'cleanly' umounted

XFS does not 'sync' as others do, and Dracut but
'plymouth' assert that it does to systemd (which does the
umounts ...)  So arbitrary FS may be left marked 'dirty' and
in need of recovery

But the new kernel does not have all the tools it needs to get
there

Read the (horrifying as to denials of accountability, and a
lack of 'taking ownership' and fixing stuff) thread

> Here is a trailhead to read back and forth from:
>http://tinyurl.com/y7d2a4he

As to Alan's later question, it was over on the Fedoraproject
'side of the house' [where breaking stuff is considered a
feature], and the RHEL 7.5 release notes indicate an intent to
no longer seek to 'mainstream' XFS going forward

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[Mark Pace]

In /boot I still have the previous kernel files,  just not sure how to make
them the kernel used at boot.

.image-4.4.126-94.22-default.hmac  image-4.4.126-94.22-default
symvers-4.4.126-94.22-default.gz
.image-4.4.131-94.29-default.hmac  image-4.4.131-94.29-default
symvers-4.4.131-94.29-default.gz
System.map-4.4.126-94.22-default   initrd
sysctl.conf-4.4.126-94.22-default
System.map-4.4.131-94.29-default   initrd-4.4.126-94.22-default
sysctl.conf-4.4.131-94.29-default
boot.readmeinitrd-4.4.126-94.22-default-kdump
vmlinux-4.4.126-94.22-default.gz
config-4.4.126-94.22-default   initrd-4.4.131-94.29-default
vmlinux-4.4.131-94.29-default.gz
config-4.4.131-94.29-default   initrd-4.4.131-94.29-default-kdump  zipl
grub2  symtypes-4.4.126-94.22-default.gz
image  symtypes-4.4.131-94.29-default.gz


On Thu, May 24, 2018 at 9:27 AM, Alan Altmark 
wrote:

> On Thursday, 05/24/2018 at 12:45 GMT, Rick Troth  wrote:
> > On 05/23/2018 07:25 PM, R P Herrold wrote:
> > >> Suse just released a new kernel-default-4.4.131-94.29-1
> > >> package for SLES 12SP3 with some kernel security fixes.  If
> > >> you use XFS, don't install it!
> > > My condolences
> > >
> > > There has been an (at least) four way finger pointing contest
> > > raging for the last couple of months (on the Fedoraproject
> > > front) between:
> > > - xfs developers
> > > - systemd developers
> > > - dracut developers
> > > - innocent victims of XFS
> >
> > - snip -
> >
> > Explain to me how a KERNEL update relates to a finger-pointing fest
> > among three user-space packages and the users?
> >
> > I DO use XFS on some systems. I prolly fall into the fourth group, but
> > was already pointing my digits at that second bullet.
>
> Explain to me why a distro would release an update that knowingly breaks a
> file system?  Unless they don't support xfs?
>
> Alan Altmark
>
> Senior Managing z/VM and Linux Consultant
> IBM Systems Lab Services
> IBM Z Delivery Practice
> ibm.com/systems/services/labservices
> office: 607.429.3323
> mobile; 607.321.7556
> alan_altm...@us.ibm.com
> IBM Endicott
>
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>



-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[Alan Altmark]

On Thursday, 05/24/2018 at 12:45 GMT, Rick Troth  wrote:
> On 05/23/2018 07:25 PM, R P Herrold wrote:
> >> Suse just released a new kernel-default-4.4.131-94.29-1
> >> package for SLES 12SP3 with some kernel security fixes.  If
> >> you use XFS, don't install it!
> > My condolences
> >
> > There has been an (at least) four way finger pointing contest
> > raging for the last couple of months (on the Fedoraproject
> > front) between:
> > - xfs developers
> > - systemd developers
> > - dracut developers
> > - innocent victims of XFS
>
> - snip -
>
> Explain to me how a KERNEL update relates to a finger-pointing fest
> among three user-space packages and the users?
>
> I DO use XFS on some systems. I prolly fall into the fourth group, but
> was already pointing my digits at that second bullet.

Explain to me why a distro would release an update that knowingly breaks a 
file system?  Unless they don't support xfs?

Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM Systems Lab Services
IBM Z Delivery Practice
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[Mark Pace]

I was able to edit my fstab and remove the mount for the XFS filesystem and
reboot the system.
Is there a way to roll back the maintenance for the kernel?  Still
struggling trying to figure out how to fix this.

On Thu, May 24, 2018 at 8:43 AM, Rick Troth  wrote:

> On 05/23/2018 07:25 PM, R P Herrold wrote:
> >> Suse just released a new kernel-default-4.4.131-94.29-1
> >> package for SLES 12SP3 with some kernel security fixes.  If
> >> you use XFS, don't install it!
> > My condolences
> >
> > There has been an (at least) four way finger pointing contest
> > raging for the last couple of months (on the Fedoraproject
> > front) between:
> >   - xfs developers
> >   - systemd developers
> >   - dracut developers
> >   - innocent victims of XFS
>
> - snip -
>
> Explain to me how a KERNEL update relates to a finger-pointing fest
> among three user-space packages and the users?
>
> I DO use XFS on some systems. I prolly fall into the fourth group, but
> was already pointing my digits at that second bullet.
>
> -- R; <><
>
>
>
>
>
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>



-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: 7.5 package levels

[Terri C. Glowaniak]

I found this in the RHEL7.5 release notes..

The 3.10 kernel version does not support KVM virtualization and containers on 
IBM z Systems. Both of these features are supported on the 4.14 kernel on IBM z 
Systems - this offerring is also referred to as Structure A.

I run z/VM as the hypervisor, so I am assuming I would need RHEL7 Structure A 
to do containers?


Thanks,
Terri Glowaniak

 

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Viktor VM 
Mihajlovski
Sent: Thursday, May 24, 2018 2:01 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: 7.5 package levels

[External Content] Please use caution.

On 24.05.2018 06:59, Timothy Sipples wrote:
> Russ Herrold wrote:
>> It may turn out that we (ClefOS) need to fork and offer two variants
>
> I guess I'd call them "streams" rather than "forks."
>
> For what it's worth, Red Hat seems to offer at least 3 major streams now:
> Fedora (their "community" release), RHEL Structure A, and RHEL. The 
> RHEL Structure A/RHEL pair of streams is a unique offering for the 
> s390x architecture branch, at least for now. (Is it a one-time 
> aberration or the start of something new? I have no idea, so ask Red 
> Hat, I guess.) In RHEL 7.5, Red Hat decided to offer kernel 3.10 
> (only) for all POWER processors prior to POWER9, and (only) kernel 
> 4.14 for POWER9. For X86-64 it's only 3.10, and for ARM64 it's only 4.14.
>
> There are certain newer capabilities that RHEL 7.5 doesn't support on 
> s390x that RHEL 7.5 Structure A does. Red Hat's release notes explain all 
> that.
> But it's possible to mix RHEL and RHEL Structure A instances on the 
> same machine and in a Red Hat supported way. (And, for that matter, 
> other supported RHEL releases.)
>
Specifically, RHEL Structure A is required to run KVM guests on IBM Z.
Guests can be either RHEL and RHEL Structure A. Another thing to keep in mind 
is that the s390utils-* releases are different. For RHEL it's
1.23.0 and for RHEL Structure A it's 2.1.0.
> It looks like the minimum RHEL 7.5/RHEL 7.5 Structure A machine model 
> requirement hasn't changed since RHEL 7.4, so it's z196/z114 
> processors or higher, which includes all LinuxONE machines.
>
> I don't have a strong view on the "right" approach for Linux release 
> streams. It really depends on end users and what they prefer, and they 
> might choose particular Linux distributors based on their different 
> release/service stream approaches. There are some important 
> principles, though. I'd say that maintaining security currency is 
> quite important, as a notable example. But that'll likely mean not 
> waiting too long to exploit new system features since many of those 
> new features are often security-related.
>
> --
> --
> Timothy Sipples
> IT Architect Executive, Industry Solutions, IBM Z & LinuxONE, 
> Multi-Geography
> E-Mail: sipp...@sg.ibm.com
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions, send 
> email to lists...@vm.marist.edu with the message: INFO LINUX-390 or 
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit 
> http://wiki.linuxvm.org/
>


--
Regards,
  Viktor Mihajlovski

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

unsubscribe

[Roger Shipman]

roger.ship...@daimler.com

If you are not the addressee, please inform us immediately that you have 
received this e-mail by mistake, and delete it. We thank you for your support.


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[Rick Troth]

On 05/23/2018 07:25 PM, R P Herrold wrote:
>> Suse just released a new kernel-default-4.4.131-94.29-1
>> package for SLES 12SP3 with some kernel security fixes.  If
>> you use XFS, don't install it!
> My condolences
>
> There has been an (at least) four way finger pointing contest
> raging for the last couple of months (on the Fedoraproject
> front) between:
>   - xfs developers
>   - systemd developers
>   - dracut developers
>   - innocent victims of XFS

- snip -

Explain to me how a KERNEL update relates to a finger-pointing fest
among three user-space packages and the users?

I DO use XFS on some systems. I prolly fall into the fourth group, but
was already pointing my digits at that second bullet.

-- R; <><






--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[Mark Pace]

I just got hit by this, this morning.  Updated SLES12 SP3 and now my XFS
filesystem will not mount.  I truly have no idea how to fix this.  I tried
xfs_repair on the device.  It ran to completion, but I get the same error
when I reboot.
Any suggestions?

Ý  OK  ¨ Found device
/dev/mapper/36005076307ffd4da003c-part1.

 Starting File System Check on
/dev/...7ffd4da003c-part1...
Ý  OK  ¨ Started File System Check on
/dev/m...307ffd4da003c-part1.
 Mounting
/srv/ftp/pub...

SGI XFS with ACLs, security attributes, realtime, no debug
enabled
XFS (dm-4): Mounting V5
Filesystem

XFS (dm-4): Torn write (CRC failure) detected at log block 0x231d3.
Truncating head block from 0x231d7.
XFS (dm-4): failed to locate log
tail
XFS (dm-4): log mount/recovery failed: error
-74
XFS (dm-4): log mount
failed

ÝFAILED¨ Failed to mount
/srv/ftp/pub.

See 'systemctl status srv-ftp-pub.mount' for
details.

On Wed, May 23, 2018 at 7:25 PM, R P Herrold  wrote:

> On Wed, 23 May 2018, Ted Rodriguez-Bell wrote:
>
> > Suse just released a new kernel-default-4.4.131-94.29-1
> > package for SLES 12SP3 with some kernel security fixes.  If
> > you use XFS, don't install it!
>
> My condolences
>
> There has been an (at least) four way finger pointing contest
> raging for the last couple of months (on the Fedoraproject
> front) between:
> - xfs developers
> - systemd developers
> - dracut developers
> - innocent victims of XFS
>
> Here is a trailhead to read back and forth from:
> http://tinyurl.com/y7d2a4he
>
> I have a number of Red Hat Bugzilla reports I track, I have
> corresponded twice privately with the Fedoraproject lead about
> applying dynamite to at least get the innocent victims out of
> XFS' harm's way, and ... bupkis.  I have to say the problem
> looks well and truly wedged, and XFS and data I care about
> will never meet
>
> In response, I went into our local deployment SOP's and added
> a general prohibition on using XFS, absent explicit prior
> approval from an admin or greater level authority.  The ONLY
> exception I can see being sought relates to extremely large
> filesystems
>
> -- Russ herrold
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>



-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

unsubscribe

[Richard Truett]

Richard Truett
retru...@verizon.net


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: 7.5 package levels

[Viktor VM Mihajlovski]

On 24.05.2018 06:59, Timothy Sipples wrote:
> Russ Herrold wrote:
>> It may turn out that we (ClefOS) need to fork and offer two
>> variants
>
> I guess I'd call them "streams" rather than "forks."
>
> For what it's worth, Red Hat seems to offer at least 3 major streams now:
> Fedora (their "community" release), RHEL Structure A, and RHEL. The RHEL
> Structure A/RHEL pair of streams is a unique offering for the s390x
> architecture branch, at least for now. (Is it a one-time aberration or the
> start of something new? I have no idea, so ask Red Hat, I guess.) In RHEL
> 7.5, Red Hat decided to offer kernel 3.10 (only) for all POWER processors
> prior to POWER9, and (only) kernel 4.14 for POWER9. For X86-64 it's only
> 3.10, and for ARM64 it's only 4.14.
>
> There are certain newer capabilities that RHEL 7.5 doesn't support on s390x
> that RHEL 7.5 Structure A does. Red Hat's release notes explain all that.
> But it's possible to mix RHEL and RHEL Structure A instances on the same
> machine and in a Red Hat supported way. (And, for that matter, other
> supported RHEL releases.)
>
Specifically, RHEL Structure A is required to run KVM guests on IBM Z.
Guests can be either RHEL and RHEL Structure A. Another thing to keep in
mind is that the s390utils-* releases are different. For RHEL it's
1.23.0 and for RHEL Structure A it's 2.1.0.
> It looks like the minimum RHEL 7.5/RHEL 7.5 Structure A machine model
> requirement hasn't changed since RHEL 7.4, so it's z196/z114 processors or
> higher, which includes all LinuxONE machines.
>
> I don't have a strong view on the "right" approach for Linux release
> streams. It really depends on end users and what they prefer, and they
> might choose particular Linux distributors based on their different
> release/service stream approaches. There are some important principles,
> though. I'd say that maintaining security currency is quite important, as a
> notable example. But that'll likely mean not waiting too long to exploit
> new system features since many of those new features are often
> security-related.
>
> 
> Timothy Sipples
> IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
> Multi-Geography
> E-Mail: sipp...@sg.ibm.com
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>


--
Regards,
  Viktor Mihajlovski

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/