Re: but is it right?

[Mike Grundy]

/lib64 was mentioned in the Linux Filesystem Standard as an example in
footnote 12 from section 3.10 /lib. Here's a link:

http://www.pathname.com/fhs/pub/fhs-2.2.pdf

Hope that helps

Mike

but is it right?

[Rick Troth]

A good friend
from a community shared by many on this list
often signs his e-mail  "WIRDI",  whatever is right,  do it.

I'm trying to get a handle on the /lib and /lib64 mess.
At first,  I was put off by SuSE's use of /lib64,  but it may be
"the right thing".   What do y'all think?   What precedent is there?
(IS there precedent?)

Clearly,  having both /lib for 31-bit and /lib64 for 64-bit
facilitates the kernels ability to run either 31-bit or 64-bit
executables.   Having just one /lib would make that more difficult.
But mixed-mode workloads alone would not seem to justify
branching the standard directory suite in such a way.
Is there something more?

Re: zVM/linux performance

[Kurt Acker]

General information:
http://www.vm.ibm.com
http://www.vm.ibm.com/perf/
http://www.vm.ibm.com/perf/tips/

Linux Performance when running under VM:
http://www.vm.ibm.com/perf/tips/linuxper.html

The performance book:
http://www.vm.ibm.com/pubs/pdf/hcsi1a50.pdf
And for the ability to manage workloads see the Chapter 17, Virtual Machine
Resource Manager (VMRM)


Kurt Acker
[EMAIL PROTECTED]





  Chris Little
  cc:
  Sent by: Linux onSubject:  zVM/linux performance
  390 Port
  <[EMAIL PROTECTED]
  IST.EDU>


  08/27/02 11:50 AM
  Please respond to
  Linux on 390 Port





Any links for tuning vm and linux for specific workloads?

Re: Linux/390 on Hercules on Mandrake Linux

[Jim Pierson]

Forgive me, I've not followed this thread and don't keep
a running log of this list like I do with Hercules-390 but
I happened to see the subject line.  What kind of troubles
are you running into?  I've not tested Hercules on the
Mandrake distro's and if there is problem, I'd like to find
it now as I'm about to release a major update to CTCI and
LCS.  (I'd rather fix it now before 2.17 than after.)

Regards,

Jim

> -Original Message-
> From: Yoon-suk Cho [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 27, 2002 10:30 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Linux/390 on Hercules on Mandrake Linux
>
>
> On Tue, Aug 27, 2002 at 06:22:31PM -0700, [EMAIL PROTECTED] wrote:
> > Here is what my Herc conf file looks like"
> >
> > 0E203088CTCI/dev/net/tun1500192.168.1.9
> 192.168.1.7
> > 255.255.255.255
> > 0E213088CTCI/dev/net/tun1500192.168.1.9
> 192.168.1.7
> > 255.255.255.255
> >
> > The address of : 192.168.1.9 "will be my new Suse
> (guest/lpar/instance)" or
> > what ever you want to call it under hercules.
> > And the address of 192.168.1.7 is my7 "Hosting" system that
> I am doing the
> > installation on !  In my case RH 7.3
> >
>
> 1. Check the TUN/TAP device in your kernel.
># cat /usr/src/linux/.config | grep TUN
>(maybe you can see CONFIG_TUN=y)
>If you can't see above option in .config file, you should recompile
>your RH7.3 Kernel with 'CONFIG_TUN=y' option.
>
>or
>
>In my experience, RH 7.3 is provides TUN module under /lib/modules/
>in basically.(find /lib/modules -name tun*)
>Just you can find the module as follwing.
>
># modprobe tun
># /sbin/lsmod (for checking)
>
>
>
> 2. verify the tun device under /dev/net/tun in your RH 7.3.
>If you can't found the tun device, you make the device as shown
>below.
>
># mkdir /dev/net
># mknod /dev/net/tun c 10 200
>
>
> Good Luck~
>
>
>
> > I did NOT have to configure any tuntap stuff, it came with
> Valhalla 7.3 RH
> > and fired up right away...not so with RH 7.1
> >
> > So, I hope this helps...
> > Ken Dreger
>
> --
> Yoon-suk Cho <[EMAIL PROTECTED]> Linux for S/390 team at
> 3atec, Inc.
> GnuPG Key fingerprint = 7754 A7D5 9802 0E8D EC40  43C8 DAC5
> B375 BA91 F780
>

Re: Linux/390 on Hercules on Mandrake Linux

[Yoon-suk Cho]

On Tue, Aug 27, 2002 at 06:22:31PM -0700, [EMAIL PROTECTED] wrote:
> Here is what my Herc conf file looks like"
>
> 0E203088CTCI/dev/net/tun1500192.168.1.9 192.168.1.7
> 255.255.255.255
> 0E213088CTCI/dev/net/tun1500192.168.1.9 192.168.1.7
> 255.255.255.255
>
> The address of : 192.168.1.9 "will be my new Suse (guest/lpar/instance)" or
> what ever you want to call it under hercules.
> And the address of 192.168.1.7 is my7 "Hosting" system that I am doing the
> installation on !  In my case RH 7.3
>

1. Check the TUN/TAP device in your kernel.
   # cat /usr/src/linux/.config | grep TUN
   (maybe you can see CONFIG_TUN=y)
   If you can't see above option in .config file, you should recompile
   your RH7.3 Kernel with 'CONFIG_TUN=y' option.

   or

   In my experience, RH 7.3 is provides TUN module under /lib/modules/
   in basically.(find /lib/modules -name tun*)
   Just you can find the module as follwing.

   # modprobe tun
   # /sbin/lsmod (for checking)



2. verify the tun device under /dev/net/tun in your RH 7.3.
   If you can't found the tun device, you make the device as shown
   below.

   # mkdir /dev/net
   # mknod /dev/net/tun c 10 200


Good Luck~



> I did NOT have to configure any tuntap stuff, it came with Valhalla 7.3 RH
> and fired up right away...not so with RH 7.1
>
> So, I hope this helps...
> Ken Dreger

--
Yoon-suk Cho <[EMAIL PROTECTED]> Linux for S/390 team at 3atec, Inc.
GnuPG Key fingerprint = 7754 A7D5 9802 0E8D EC40  43C8 DAC5 B375 BA91 F780

Re: Enlarging Root File System

[Post, Mark K]

Of course.  In no way do I want to be the only person contributing to those
HOWTOs.  I don't have the time or opportunity to do that.  I had been hoping
that more people would have contributed more of them than have already.  I
recognize that most of us have pretty busy jobs, but I was still hoping.  :)

Mark Post

-Original Message-
From: Scully, William [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 27, 2002 3:52 PM
To: [EMAIL PROTECTED]
Subject: Re: Enlarging Root File System


Mark,

No offense taken.  Years ago kind people helped me learn VM... and now
Linux.  I try to help people learn VM when I have the chance to do so.
Turnabout is fair play, I think!

What I'd like to do is pass on to you an updated how-to which can help
others avoid this in the future.  Sound fair?

Re: but is it right?

[Post, Mark K]

Rick,

I would have to say that there is precedent.  In working on porting the SAP
database to Linux/390, I've come across numerous instances of files checking
for 64-bit and using /lib64, or /lib otherwise.

Mark Post

-Original Message-
From: Rick Troth [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 27, 2002 7:58 PM
To: [EMAIL PROTECTED]
Subject: but is it right?


A good friend
from a community shared by many on this list
often signs his e-mail  "WIRDI",  whatever is right,  do it.

I'm trying to get a handle on the /lib and /lib64 mess.
At first,  I was put off by SuSE's use of /lib64,  but it may be
"the right thing".   What do y'all think?   What precedent is there?
(IS there precedent?)

Clearly,  having both /lib for 31-bit and /lib64 for 64-bit
facilitates the kernels ability to run either 31-bit or 64-bit
executables.   Having just one /lib would make that more difficult.
But mixed-mode workloads alone would not seem to justify
branching the standard directory suite in such a way.
Is there something more?

Re: Linux/390 on Hercules on Mandrake Linux

[[EMAIL PROTECTED]]

Here is what my Herc conf file looks like"

0E203088CTCI/dev/net/tun1500192.168.1.9 192.168.1.7
 255.255.255.255
0E213088CTCI/dev/net/tun1500192.168.1.9 192.168.1.7
 255.255.255.255

The address of : 192.168.1.9 "will be my new Suse (guest/lpar/instance)" or
what ever you want to call it under hercules.
And the address of 192.168.1.7 is my7 "Hosting" system that I am doing the
installation on !  In my case RH 7.3

I did NOT have to configure any tuntap stuff, it came with Valhalla 7.3 RH
and fired up right away...not so with RH 7.1

So, I hope this helps...
Ken Dreger

Re: Enlarging Root File System

[John Summerfield]

On Tue, 27 Aug 2002 22:55, you wrote:
> he's not likely to repeat the mistake.

If he's like me, he will just find another creative way to stuff things up;-)


-- 
Cheers
John Summerfield


Microsoft's most solid OS: http://www.geocities.com/rcwoolley/

Re: Enlarging Root File System

[Scully, William]

Mark,

No offense taken.  Years ago kind people helped me learn VM... and now Linux.  I try 
to help people learn VM when I have the chance to do so.  Turnabout is fair play, I 
think!

What I'd like to do is pass on to you an updated how-to which can help others avoid 
this in the future.  Sound fair?

-Original Message-
From: Post, Mark K [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 27, 2002 10:56 AM
To: [EMAIL PROTECTED]
Subject: Re: Enlarging Root File System


You're both right.  Willem is right in pointing out when and where the
various system components are executed, and when their outputs are used, and
how that led to the failure.  It's helpful for people to understand the
details in that manner.  You're right in that essentially William was trying
to outsmart the system, and wound up outsmarting himself.  :)  (Please don't
think I'm beating up on William, I'm not.  I have a tendency towards those
kinds of mistakes myself, so if anything I empathize with him.)  Now that
William knows more about the details, he's not likely to repeat the mistake.
(Hopefully, new people that read the archives won't either.)

I'm just glad that people are willing to post their problems and ask for
help.  Every one of them is taking the chance of being told they did
themselves in, and post the question anyway.

Mark Post

-Original Message-
From: Ihno Krumreich [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 27, 2002 3:41 AM
To: [EMAIL PROTECTED]
Subject: Re: Enlarging Root File System


-snip-
No, thats not true.

The dasd-driver is called with a range of numbers (200-21f). So these
numbers
are reserved and assigned to the corresponding letters (200 -> a, 201 -> b
...).
This is independent from the fact that only 201 and 20E are currently
present.

The problem from my point of view was, that the dasds where exchanged
two times. one time in the zipl.conf and the second in the
dasd-configuration.

Ihno

--
Ihno Krumreich[EMAIL PROTECTED]
SuSE Linux AG S390 & zSeries
Deutschherrnstr. 15-19+49-911-74053-439
90429 N|rnberghttp://www.suse.de

9/6 NYC IBM and Droplets Seminar Customer Invitation

[Leonard Santalucia]

IBM and Droplets Invite You to Come See the Next Generation of Web Services
and Internet Applications

Where:  Room 952 @ IBM Briefing Center, 590 Madison Ave, New York, NY

When:   Friday, September 6, 2002.
Morning Session 9:00 to 11:00 a.m.
or
Afternoon Session 2:00 to 4:00 p.m.

Why:  The web's ubiquity with the functionality and performance of a
desktop GUI. Next generation web services and the internet applications
offer rich interactive GUI's that extend legacy applications without adding
complexity.

These new GUI enabled applications work seamlessly with legacy code bases
and modern architectures, plus offer significant operational and
development cost advantages over current WEB and WIRELESS architectures.

What: The Internet introduced us to the world of thin clients, wireless,
distributed Web Applications and Web Services.  The browser gave us a
standard mechanism to reach applications outside the firewall without
installing new software, or so we thought.  In the process, users lost rich
functionality, information density, and an easy to use real time interface.
At the same time, developers were burdened with a number of new
technologies to duplicate the former desktop software.  The web
architectures, consisting of HTML, servlets, client side scripting,
countless applets and plug-ins, shows no sign of effectively returning the
functionality of desktop software.  According to usability research firm
Nielsen Norman Group, "Billions of dollars are wasted yearly in lost
productivity as people wait for Web pages to perform duties that could be
better handled by a 1984 Macintosh-style GUI application.  Next time you
find yourself traveling, think about the amount of time you personally
waste on simply due to web-page refresh...now multiply that times the
number of employees in your company and the number of working days per
year. The need for easy-to-create Web Services and Internet applications
with the interactivity of desktop applications is now being met by
Droplets, Inc. The Droplets software  development platform, with its
Droplets User Interface ServerTM and Software Development Kit, enables
developers to create software that combines the convenient, instant
deployment benefits of the Web's thin client and wireless architectures
with the high usability and rich GUI of fat clients. Usability of desktop
software, centralized maintenance, order of magnitude performance and
security increase, Droplets delivers the next generation of interactive
applications over the Internet.

To confirm to your attendance to this event, please call Cam Reed at
214-540-2519

Info provided by
Steven K. Morse
Vice President, Sales
Central Region
Droplets, Inc.
(214) 540-2515  office
(214) 906-9399  mobile
(214) 540-2521  fax
[EMAIL PROTECTED]

droplets.com 


Len Santalucia
Senior Consulting Sales Specialist & Certified Professional
IBM Americas eServer Linux Impact Team
Tieline 340-5957 <> Outside 212-493-5957
Cell 917-856-4493 <> Fax 607-757-6260
Internal: Leonard Santalucia/New York/IBM
email: mailto:[EMAIL PROTECTED]
Visit: http://www.ibm.com/linux

Re: ZIPL...IPL from CMS reserved minidisks not supported

[Rob van der Heij]

At 17:21 27-08-02, Gary A. Ernst wrote:

>I Have installed kernel 2.4.17 and IBM patches as well as the s390-tools. Run
>zipl and rebooted When I run zipl again I get IPL form CMS reserved minidisks
>not supported cannot continue. Am I missing something or has this support
>actually been dropped ?

While this is not really an answer, I believe it never worked or
has been broken very long time ago. ;-) My apologies for the
long explanation, but maybe this explains both things you see.

The way Linux deals with writing the IPL records is by insisting
that the architectured IPL records R1 & R2 are part of the payload
of the disk (and skip the first tracks when data is written to disk).
With the CMS Reserved mini disk the payload portion does not include
the first few blocks, but only the blocks within that single file.
Thus Linux cannot reach the IPL record through that mechanism.

Unfortunately the zipl code was such that it got confused by a CMS
reserved mini disk such that it corrupted the data on the disk
instead. Otherwise it would be trivial to make a CMS program that
puts an IPL record on disk that will pick up the IPL record that
Linux puts in the payload portion of the disk.

The PFAULT support then broken the external interrupt handler such
that a Linux kernel hangs when trying to initialize a CMS reserved
mini disk. From what I have seen SuSE have configured their kernel
not to include the diagnose driver (only as a module so you can
hang yourself on demand). A patch for this problem was published
but I was unable to put it on yet since it bites the demand timer
code.

The net result is that currently the non-CDL discipline of the
Linux dasd driver picks up the CMS reserved disk as plain CMS
formatted, and will write data blocks from R4 or R5. In some
cases this corrupts what's left of CMS FST's so that ACCESS of
the disk will hang your backup programs or scanning software.

The moral of this is probably right now to use CDL format until
we sorted out all issues with the diagnose driver and then see
whether we need to convert.

Rob

ZIPL and CMS reserved mini-disks

[Gary . Ernst]

I have applied the IBM patches to kernel 2.4.17 and re-built the s390
tools, run zipl rebooted and re-run zipl.
Now when I run zipl I get  IPL for CMS reserved minidisks not supported
cannot continue. Am I missing something
or has support actually been dropped?

Gary Ernst
MainLine

Two More New Presentations on linuxvm.org

[Post, Mark K]

Gordon Wolfe has graciously (after being nagged a little :) ) contributed
copies of his two SHARE 99 presentations:

Sess.PresenterTitle
9108  Gordon W. Wolfe, Ph.D.  A Linux and/or VM Solution for Analyzing any
Web Server Log
9341  Gordon W. Wolfe, Ph.D.  Managing a Penguin Farm on the VM Prairie

Thanks Gordon!  Those of you who haven't volunteered yet, _will_ be hearing
from me!

Thanks to all for helping spread much-needed information.


Mark Post

zVM/linux performance

[Chris Little]

Any links for tuning vm and linux for specific workloads?

Re: Enlarging Root File System

[Post, Mark K]

You're both right.  Willem is right in pointing out when and where the
various system components are executed, and when their outputs are used, and
how that led to the failure.  It's helpful for people to understand the
details in that manner.  You're right in that essentially William was trying
to outsmart the system, and wound up outsmarting himself.  :)  (Please don't
think I'm beating up on William, I'm not.  I have a tendency towards those
kinds of mistakes myself, so if anything I empathize with him.)  Now that
William knows more about the details, he's not likely to repeat the mistake.
(Hopefully, new people that read the archives won't either.)

I'm just glad that people are willing to post their problems and ask for
help.  Every one of them is taking the chance of being told they did
themselves in, and post the question anyway.

Mark Post

-Original Message-
From: Ihno Krumreich [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 27, 2002 3:41 AM
To: [EMAIL PROTECTED]
Subject: Re: Enlarging Root File System


-snip-
No, thats not true.

The dasd-driver is called with a range of numbers (200-21f). So these
numbers
are reserved and assigned to the corresponding letters (200 -> a, 201 -> b
...).
This is independent from the fact that only 201 and 20E are currently
present.

The problem from my point of view was, that the dasds where exchanged
two times. one time in the zipl.conf and the second in the
dasd-configuration.

Ihno

--
Ihno Krumreich[EMAIL PROTECTED]
SuSE Linux AG S390 & zSeries
Deutschherrnstr. 15-19+49-911-74053-439
90429 N|rnberghttp://www.suse.de

Re: Two More New Presentations on linuxvm.org

[Wolfe, Gordon W]

Hey, you call being asked once "nagged a little"?  ;>)

So I wasn't very awake yesterday.  It was Monday after all, with SHARE last
week and house guests over the weekend.  And I had 454 e-mails to go
through.  Mostly from this list.

"Only two things are infinite:  the Universe and human stupidity, and I'm
not so sure about the Universe."  - Albert Einstein
Gordon Wolfe, Ph.D. (425)865-5940
VM Technical Services, The Boeing Company

> --
> From: Post, Mark K
> Reply To: Linux on 390 Port
> Sent: Tuesday, August 27, 2002 9:17 AM
> To:   [EMAIL PROTECTED]
> Subject:  Two More New Presentations on linuxvm.org
>
> Gordon Wolfe has graciously (after being nagged a little :) ) contributed
> copies of his two SHARE 99 presentations:
>
> Sess.PresenterTitle
> 9108  Gordon W. Wolfe, Ph.D.  A Linux and/or VM Solution for Analyzing any
> Web Server Log
> 9341  Gordon W. Wolfe, Ph.D.  Managing a Penguin Farm on the VM Prairie
>
> Thanks Gordon!  Those of you who haven't volunteered yet, _will_ be
> hearing
> from me!
>
> Thanks to all for helping spread much-needed information.
>
>
> Mark Post
>
>

ZIPL...IPL from CMS reserved minidisks not supported

[Gary A. Ernst]

Greetings list

I Have installed kernel 2.4.17 and IBM patches as well as the s390-tools. Run 
zipl and rebooted When I run zipl again I get IPL form CMS reserved minidisks 
not supported cannot continue. Am I missing something or has this support 
actually been dropped ?

Thanks

Gary Ernst
MainLine

Re: Enlarging Root File System

[James Melin]

The corollary to that is that the only dumb question is the one that goes
unasked, because it will probably go unanswered. There is a wealth of
talent and experience connected to this list that far outstrips the talents
contained within any one company, or any one discipline. You guys have
saved my sorry butt so many times I'm probably never going to be able to
foot the bill.


|-+>
| |   "Post, Mark K"   |
| |   <[EMAIL PROTECTED]|
| |   m>   |
| |   Sent by: Linux on|
| |   390 Port |
| |   <[EMAIL PROTECTED]|
| |   IST.EDU> |
| ||
| ||
| |   08/27/2002 09:55 |
| |   AM   |
| |   Please respond to|
| |   Linux on 390 Port|
| ||
|-+>
  
>--|
  |
  |
  |   To:   [EMAIL PROTECTED]
  |
  |   cc:  
  |
  |   Subject:  Re: Enlarging Root File System 
  |
  
>--|




You're both right.  Willem is right in pointing out when and where the
various system components are executed, and when their outputs are used,
and
how that led to the failure.  It's helpful for people to understand the
details in that manner.  You're right in that essentially William was
trying
to outsmart the system, and wound up outsmarting himself.  :)  (Please
don't
think I'm beating up on William, I'm not.  I have a tendency towards those
kinds of mistakes myself, so if anything I empathize with him.)  Now that
William knows more about the details, he's not likely to repeat the
mistake.
(Hopefully, new people that read the archives won't either.)

I'm just glad that people are willing to post their problems and ask for
help.  Every one of them is taking the chance of being told they did
themselves in, and post the question anyway.

Mark Post

-Original Message-
From: Ihno Krumreich [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 27, 2002 3:41 AM
To: [EMAIL PROTECTED]
Subject: Re: Enlarging Root File System


-snip-
No, thats not true.

The dasd-driver is called with a range of numbers (200-21f). So these
numbers
are reserved and assigned to the corresponding letters (200 -> a, 201 -> b
...).
This is independent from the fact that only 201 and 20E are currently
present.

The problem from my point of view was, that the dasds where exchanged
two times. one time in the zipl.conf and the second in the
dasd-configuration.

Ihno

--
Ihno Krumreich[EMAIL PROTECTED]
SuSE Linux AG S390 & zSeries
Deutschherrnstr. 15-19+49-911-74053-439
90429 N|rnberghttp://www.suse.de

Re: HiperSockets

[Dennis Musselwhite]

Hi...

You mention 'routed' in your network, but I believe the routed application
uses multicast or broadcast to exchange routing information.  If you are
running z/VM 4.2.0 HiperSockets it will not support multicast.

If you are using z/VM 4.3.0 the HiperSockets simulation supports multicast
or you have the option of defining a QDIO adapter which supports multicast
and broadcast within the QDIO Guest LAN.

If you were depending on routed to install the SUSE7 IP Address in
your TCPIP routing table, that might cause ping to fail.  I am not skilled
with the configuration options, but if you describe the way you have
configured the HiperSockets DEVICE/LINK on the TCPIP side, perhaps
other readers can offer suggestions that will help.

Regards,
Dennis Musselwhite ([EMAIL PROTECTED])
IBM Corporation -- z/VM Development -- CP Network Simulation

getting the SHARE CD

[Peticolas, Anne]

>Dave Jones made some mention about a checkbox on the registration form.  I
>don't know if that's going to work for him or not.  I do know that when the
>CDs are ready, I get an email from them, and I can request one from the
>SHARE web site.  I did that for Minneapolis, and got the CD not too long
>afterwards.  I did the same for Nashville, but haven't gotten the CD yet.
>Mark Post

When I was at Nashville, I went and signed a *physical list* in the SHARE
office
requesting a CD.  And I *have* gotten it in the mail without doing anything
else.
FWIW.
Regards,
   Anne Peticolas
   Dept. of Veterans Affairs
   Austin, Texas

Re: dasdfmt: Unsupported disk type

[Jae-hwa Park]

On Tue, Aug 27, 2002 at 10:04:20AM +0200, Rob van der Heij wrote:
> At 15:07 27-08-02 +0900, Jae-hwa Park wrote:
>
> >What should I do for this problem?
>
> Just run 'mkswap' - depending on your kernel (and on
> whether you made it CMS reserved) either the FBA or
> the diag code in the dasd driver will pick it up and
> treat it as a disk with just one partition for the
> entire disk.
>
> Rob

Thank you, Rob.

It works for me. Just run mkswap and swapon.

Thanks again. :-)

Jae-hwa

--
Jae-hwa Park <[EMAIL PROTECTED]>
IBM Korea, Inc. Sa-Rang means LOVE!
For more information on me, visit http://php.sarang.net

Re: dasdfmt: Unsupported disk type

[Rob van der Heij]

At 15:07 27-08-02 +0900, Jae-hwa Park wrote:

>What should I do for this problem?

Just run 'mkswap' - depending on your kernel (and on
whether you made it CMS reserved) either the FBA or
the diag code in the dasd driver will pick it up and
treat it as a disk with just one partition for the
entire disk.

Rob

Re: Enlarging Root File System

[Ihno Krumreich]

On Mon, Aug 26, 2002 at 06:28:20PM +0200, Willem Konynenberg wrote:
> "Post, Mark K" wrote:
> > From: Scully, William [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, August 26, 2002 9:52 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Enlarging Root File System
> >
> >
> > Here's my zipl configuration file.  Note that we normally boot off the 201
> > (/dev/dasda1) device, and the new larger disk was added at address 20E
> > (/dev/dasd01).  To put the new disk into production I swapped 201 and 20E
> > via the VM Directory.
> >
> >
> > [defaultboot]
> > default=ipl
> >
> > [ipl]
> > target=/mnt/boot/zipl
> > image=/mnt/boot/kernel/image
> > #ramdisk=/boot/initrd
> > parameters="dasd=0200-21f root=/dev/dasdo1 noinitrd"
> >
> > [dumptape]
> > target=/boot
> > dumpto=/dev/rtibm0
> >
> >
> > It was placed into production using the command:  zipl -c /etc/zipl.new.root
> > On further investigation (and from a suggestion off-list from Willem
> > Konynenberg) I suspect that I have the "parameters" value incorrect, as this
> > seems to be the only explaination of what's gone wrong here.  Since I'm
> > working with a production server I can't bounce and test at will.  (The
> > changes must be scheduled.)  If someone can confirm this suspicion that
> > would be very helpful to me.
>
> Yes, confirmed.
>
> Some of the data in the zipl config file are being used at the
> time you run the zipl utility, and they must reflect the situation
> at the time the zipl utility runs.  Other data (e.g. the kernel
> command line) is being used at the time the kernel boots, and they
> must reflect the situation at the time the kernel boots.
> Normally, both situations are the same, and thus there is no
> confusion, but in this particular case, you change the configuration
> between these two steps, and you have to take that into account.
>
> By the time the kernel boots and interprets that command line,
> the root filesystem you want it to mount is located at /dev/dasda1,
> not /dev/dasdo1.
>
No, thats not true.

The dasd-driver is called with a range of numbers (200-21f). So these numbers
are reserved and assigned to the corresponding letters (200 -> a, 201 -> b ...).
This is independent from the fact that only 201 and 20E are currently
present.

The problem from my point of view was, that the dasds where exchanged
two times. one time in the zipl.conf and the second in the dasd-configuration.

Ihno

--
Ihno Krumreich[EMAIL PROTECTED]
SuSE Linux AG S390 & zSeries
Deutschherrnstr. 15-19+49-911-74053-439
90429 N|rnberghttp://www.suse.de

Re: [PATCH RFC] s390x sys32 (remove duplicated code)

[Martin Schwidefsky]

Hi Tim,

> I am working on a patch that removes the old limit of NGROUPS.
>
> In doing so, I am checking everything that references NGROUPS.  One
> such place is in arch/s390x/kernel/linux32.c.
>
> I notice these things:
> * s390x defines __kernel_old_gid_t to __kernel_gid_t (unsigned int)
> * s390x has a sys32_getgroups16() which looks JUST LIKE uid16.c
> sys_getgroups16
> * s390x does not define CONFIG_UID16, but seems to need it
The early versions of 64 bit s390x did not have the 31 bit emulation
layer. As long as only 64 bit code is executed you don't need the
16 bit uids/gids. Thats why is isn't defined.

> It seems to me that if we do:
> * s390x defines CONFIG_UID16
> * typedef __kernel_old_gid_t to u16
> * get rid of all the sys32_*16 stuff and just call the uid16.c function
I checked the code and didn't find any reason why this shouldn't work.
In fact with the 31 bit emulation layer the 64 bit kernel does need the
16 bit uid/gid system calls although only for the emulation. To make it
really perfect you could define CONFIG_UID16 dependent on
CONFIG_S390_SUPPORT. This saves a few bytes in the image if the emulation
support is not enabled.

> We could save a bit of duplicated code.  Patches that remove code are
> good, right?
Definitly.

blue skies,
   Martin

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: [EMAIL PROTECTED]