>>> On 8/3/2009 at 5:29 PM, "Jones, Russell" wrote:
> Good idea.
>
> I get no hits on that address range. Looks like the addresses are not
> available to the LPAR.
Try it again and use the "-i" switch on grep, since lscss reports everything in
upper case:
lscss | grep -i 0.b70
Mark Post
Good idea.
I get no hits on that address range. Looks like the addresses are not available
to the LPAR.
Thanks. Now I know who to complain to.
Russell Jones
ANPAC
System Programmer Trainee
rjo...@anpac.com
(417)887-4990 x2193
-Original Message-
From: Linux on 390 Port [mailto:l
On 08/03/2009 11:08 PM, Jones, Russell wrote:
> Can I list a range of address with lscss? It is listing too many devices
> to see the range that I need.
Just a quick hack which should definitely work to reduce the result set:
lscss | fgrep 0.0.b70
Steffen
Linux on System z Development
IBM Deuts
On 08/03/2009 10:51 PM, Jones, Russell wrote:
> I am moving one of my SUSE 10 images to a different machine where the
> OSA has a different hardware address. We do not have VM (very sad, I
> know). The address will be changing from f840 to b708, the name will
> change from GIGPORT1 to OSAEGA0 and t
Can I list a range of address with lscss? It is listing too many devices
to see the range that I need. 'lsqeth' reports:
ls: /sys/bus/ccwgroup/drivers/qeth: No such file or directory
Russell Jones
ANPAC
System Programmer Trainee
rjo...@anpac.com
-Original Message-
From: Linux on 390 Port
>>> On 8/3/2009 at 4:51 PM, "Jones, Russell" wrote:
> I am moving one of my SUSE 10 images to a different machine where the
> OSA has a different hardware address. We do not have VM (very sad, I
> know). The address will be changing from f840 to b708, the name will
> change from GIGPORT1 to OSAE
I am moving one of my SUSE 10 images to a different machine where the
OSA has a different hardware address. We do not have VM (very sad, I
know). The address will be changing from f840 to b708, the name will
change from GIGPORT1 to OSAEGA0 and the IP will go from 10.5.100.31 to
10.50.40.121
I have
Right, which is why I prefer to install the base Linux image onto more
"conventional" disk, like 3390 DASD. Once the Linux kernel successfully
boots, it can then begin to exploit the more unconventional (at least in
a S/390 sense) disks like FCP.
Andrew Galewsky wrote:
The interesting thing of c
My impression is that its more efficient, and that you would build that
efficiency into your 'golden image' so that it can be leveraged with the
building of each new image. I agree that in normal conditions theres
negligible difference, but when the host system is being stressed and
you really NEED
