>>> On 1/12/2015 at 02:48 PM, Linker Harley - hlinke
wrote:
> Until you get around to disabling cio_ignore you can run the following
> command to update the blacklist when you add a volume to Linux to enable it
> to be seen:
> cio_ignore -r 0.0.vdev
Better yes, just
cio_ignore -R
which
Mike,
Until you get around to disabling cio_ignore you can run the following command
to update the blacklist when you add a volume to Linux to enable it to be seen:
cio_ignore -r 0.0.vdev
Harley Linker
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU]
Thanks, Sam, Jay, Jim, Harley, and Mark (and anyone else who may have replied
since I looked at the log),
There are no LPAR-only Linux servers running here, only those running (RHEL)
under z/VM. I suspected that cio_ignore was something related to security
(perhaps an auditor fearing that an e
>>> On 1/12/2015 at 12:13 PM, "Cohen, Sam" wrote:
> Mike,
>
> This is a RedHat "feature"; it isn't an issue with SuSE. It is an
SUSE, please. (It's been 11 years now.)
> implementation choice by the distributor.
Beginning with SLES12, a feature request from IBM means that (by _changeable_
Mike,
I don't have this problem with my SLES 11 SP3 systems on System z as cio-ignore
was not enabled, by default, at installation time. I encountered this problem
with SLES 12 on System z as cio-ignore is enabled by default. I was just
playing with SLES 12 to make note of the changes from SL
On Monday, 01/12/2015 at 10:58 EST, Rick Troth
wrote:
> Exception to Mother's rule #1:
> At a previous site, we had a small (read that as "easy to maintain") mod
> to SYSPROF EXEC to conditionally drive LCLPROF EXEC. The latter then did
> as little as possible, but arranged for our local stuff to
It's also about efficiency. Recall that there aren't many other processors
out there whose I/O architecture is built on (sub)channels. If the
cio_ignore data indicates that signals arriving from certain channels
needn't be processed, then that's less work the kernel has to engage in. In
cases where
It's there for when you bring Linux up in an LPAR with bajillions of
devices defined, like an old z/OS LPAR for example. The IPL takes forever
as udev enumerates all those devices in /sys and /dev, and then you're
running a system that can touch all the devices which it should not have
access to.
Mike,
This is a RedHat "feature"; it isn't an issue with SuSE. It is an
implementation choice by the distributor.
Thanks,
Sam Cohen
Levi, Ray & Shoup, Inc.
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mike
Walter
Sent: Monday, January 12,
The cio_ignore table within Linux (at least in RHEL6.5) is used to restrict
access devices, both real and virtual. Being new the Linux on System z, this
has become an occasional stumbling block for our Linux admins; when we z/VM
sysprogs attach a new virtual or real device and the guest cannot
On 01/12/2015 09:20 AM, Robert J Brenneman wrote:
> Mother's rule of z/VM Service number 1: Never change anything IBM sends you
> Mother's rule of z/VM Service number 2: Never mix your stuff with IBM's stuff.
Amen! But see below for an exception.
> In my shop we create a user in the directory na
On Monday, 01/12/2015 at 09:46 EST, "Cohen, Sam"
wrote:
> As you can tell, it's more art than science. My tendency matches Jay's;
I
> create a NOLOG user called LCLTOOLS and place all my tools on its 191
disk. I
> then create a nickname called TOOLS and use VMLINK TOOLS to access that
disk.
> To
Keith,
As you can tell, it's more art than science. My tendency matches Jay's; I
create a NOLOG user called LCLTOOLS and place all my tools on its 191 disk. I
then create a nickname called TOOLS and use VMLINK TOOLS to access that disk.
To create a nickname file, see the NAMES command (with
Mother's rule of z/VM Service number 1: Never change anything IBM sends you
Mother's rule of z/VM Service number 2: Never mix your stuff with IBM's
stuff.
In my shop we create a user in the directory named after our department and
set the PW to NOLOG. We give that new user a 191 disk and control a
Hi Keith,
Usually the VM tools, as well as your local tools, can be put on a general
tools disk. For instance, we have a shared minidisk that contains a lot of
tools from various sources. Our sysprog users have this disk as 192 so that it
will be attached as filemode D during logon.
So I would
I have a small z/vm system which is used to run linux and z/os test systems (I
work for an ISV). My z/vm knowledge is mainly limited to what I have picked up
from the z/linux Redbooks and the "Getting Started" guide.
I now want to install some tools from the VM downloads web pages. Is there a
s
16 matches
Mail list logo
