Buggered up zipl.conf file
All, Being a zLinux Newbie I'm following Chapter 7. (installing and configuring SLES10) in the 'z/VM and Linux on IBM System z The Virtualization Cookbook' Step 7.5.13 identifies modifications to make to the zipl.conf file. Well... Here's where the problem lies... I fat fingered the parameter line and went ahead and executed the zipl command. Now when I try to IPL I get the following message. Waiting for device /dev/dasd1 to appear: ..not found -- exiting to /bin/sh $ The device I should be looking for is /dev/dasda1not /dev/dasd1. Can anyone offer any insight on how I can save this install without starting all over again? This is just a sandbox system I'm playing with for the time being, I was hoping this was going to become my "Gold" system eventually. Thanks in advance for any assistance. And yes... I do have a backup of the zipl.conf file, I just have no idea on how to restore it and re-run the zipl command without the actual system. David Rakoczy Operating Systems Programmer Thermo Fisher Scientific "He who laughs last probably made a backup." -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Buggered up zipl.conf file
To all those who replied to my distress call on Friday... Thank You, Thank You, Thank You. I went to section 12.4.2 Entering a rescue environment as described by Mike MacIsaac, then followed the suggestions from Robert Nix and I was able to successfully execute mkinitrd and zipl after updating (correctly this time around) zipl.conf. What a learing experience this has been. Thanks again. David Rakoczy Operating Systems Programmer Thermo Fisher Scientific "He who laughs last probably made a backup." -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of RPN01 Sent: Friday, August 29, 2008 3:07 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Buggered up zipl.conf file Boot up your install system, and define the network. Get things up to the point that ssh is started. Then log in via ssh, mount your real Linux system's filesystem and once everything is in place beneath this mount point, do a chroot to the mountpoint. Then edit your zipl.conf file, and re-run mkinitrd and zipl. Shutdown and try to boot again. My assumption here is that this is your first linux image. If you have others, you could attach the necessary disks to a running image, mount them and chroot to there. -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 8/29/08 1:51 PM, "Rakoczy, Dave" <[EMAIL PROTECTED]> wrote: > > All, > > Being a zLinux Newbie I'm following Chapter 7. (installing and > configuring SLES10) in the 'z/VM and Linux on IBM System z The > Virtualization Cookbook' > > Step 7.5.13 identifies modifications to make to the zipl.conf file. > > Well... Here's where the problem lies... I fat fingered the parameter > line and went ahead and executed the zipl command. Now when I try to > IPL I get the following message. > > Waiting for device /dev/dasd1 to appear: > ..not found > -- exiting to /bin/sh > > $ > > > The device I should be looking for is /dev/dasda1not > /dev/dasd1. > > Can anyone offer any insight on how I can save this install without > starting all over again? > > This is just a sandbox system I'm playing with for the time being, I > was hoping this was going to become my "Gold" system eventually. > > Thanks in advance for any assistance. > > And yes... I do have a backup of the zipl.conf file, I just have no > idea on how to restore it and re-run the zipl command without the > actual system. > > David Rakoczy > Operating Systems Programmer > Thermo Fisher Scientific > > "He who laughs last probably made a backup." > > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, send > email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or > visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
HiperSocket Performance
Hello all, We are a longtime zOS shop taking the plunge into the zVM / zLinux (SUSE 10SP2) world. We had never implemented HiperSockets in our zOS environment so our experience with this technology is rather limited. HiperSockets were implemented specifically to support our desire to take advantage of FDR/Upstreams ability to interface with our zOS tape management tools. During the last week or so we've been testing the different FDR/Upstreams backup and restore processes (including the RMAN option). The backup and restore processes work as advertised, but we are looking for better throughput times for these processes. Currently the HiperSocket channel is defined in the I/O Gen as having a Maximum Frame Size of 16 KB, the MTU size on both the zOS and z/linux interfaces is set to 8192 (see Below). The backups are going to our VTS which is Ficon attached to the Mainframe. DevName: IUTIQDF4 DevType: MPCIPA DevStatus: Ready CfgRouter: Non ActRouter: Non LnkName: HIPR2 LnkType: IPAQIDIOLnkStatus: Ready NetNum: n/a QueSize: n/a IpBroadcastCapability: No ArpOffload: YesArpOffloadInfo: Yes ActMtu: 8192 ReadStorage: GLOBAL (2048K) SecClass: 255 MonSysplex: No IQDMultiWrite: Disabled BSD Routing Parameters: MTU Size: 8192 Metric: 00 DestAddr: 0.0.0.0 SubnetMask: 255.255.255.0 Multicast Specific: hsi0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.0.1.5 Bcast:192.0.1.255 Mask:255.255.255.0 inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link UP BROADCAST RUNNING NOARP MULTICAST MTU:8192 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:168 (168.0 b) With the above settings I'm seeing throughput in the area of 15-18 Mb per second. I've spent the past few days scouring these archives looking for what others have done. I found a few threads that addressed HiperSocket throughput speeds between zOS and zLinux, but were using FTP as the benchmark utility. I have a window this weekend where I can put in a I/O Gen change for the Maximum Frame Size on the HiperSocket channel define (hopefully I'm on the right track here). So, the question I'm posing is : If you are using HiperSockets to support FDR/Upstream, in your experience where did you find the performance throughput sweet spot? Thanks in advance for any input you may relay. David Rakoczy Operating Systems Programmer Thermo Fisher Scientific "He who laughs last probably made a backup." -- 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
Re: HiperSocket Performance
zLinux assigns the MTU size according to the IQD CHPID definition. For sake of discussion lets say I set the CHPID to a Max Frame Size of 64K, that would give me an MTU size of 56K according to the Doc. Where can I control the size of the packets I'll send across the interface? In the Tape Blocksize / Record length as alluded to in the Adam's previous note? Sorry for all the questions... But I've got to learn this stuff somewhere. David Rakoczy -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of David Boyes Sent: Thursday, January 15, 2009 10:07 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: HiperSocket Performance For bulk data transfer, make the MTU size as large as possible, and make your packet sizes at least 40 bytes smaller than the maximum MTU to avoid fragmentation of data packets. That allows space for the TCP header on each packet. Note that this will affect interactive response, so it's probably not a good idea to try to share the same connection for interactive access and bulk transfer like backups. -- 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 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
Re: HiperSocket Performance
Doing an inquiry on the tape from the tape management system shows me the following: General Data Volume Serial. . . : 163738 Alternate Volume . : Media type . . . : 3490-36X2 Record Format. . . : VB Record Length. . . : 32756 Block Size . . . : 229376 My next window to do a GEN change (management will not allow dynamic I/O Changes) is the 3rd weekend of Feb. I wish I had the downtime window to make the change, run some test, change to a different frame size, run additional test and so on, I'd do that. The change I'll implement this weekend I'll need to live with for the next month, that's why I'm looking for what others have experienced. Yes, this HiperSocket interface will be dedicated to Bulk Transfers, specifically our backups. -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Adam Thornton Sent: Thursday, January 15, 2009 9:56 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: HiperSocket Performance On Jan 15, 2009, at 8:40 AM, Rakoczy, Dave wrote: > > I've spent the past few days scouring these archives looking for what > others have done. I found a few threads that addressed HiperSocket > throughput speeds between zOS and zLinux, but were using FTP as the > benchmark utility. I have a window this weekend where I can put in a > I/O Gen change for the Maximum Frame Size on the HiperSocket channel > define (hopefully I'm on the right track here). > > So, the question I'm posing is : If you are using HiperSockets to > support FDR/Upstream, in your experience where did you find the > performance throughput sweet spot? What does FDR/Upstream use as a tape block size? Most of the backup software I'm familiar with uses 32k or 64k chunks, so if you can set your frame size to match, that's probably ideal (assuming that much or most of your Hipersocket traffic *is* backup blocks). If your traffic is dominated by bulk transfers (like backup blocks) rather than interactive traffic, then the larger frame and larger MTU the better (unless you're in a *really* memory starved environment, but if you are this probably isn't going to be your first bottleneck). How long till the next-but-one window? Try something different this weekend, and measure it, would be my advice. Go back to the other one if it's worse, or try a third one, at your next opportunity (it is unlikely, I think, to get enormously faster or slower, presuming you're not doing silly things with MTU or frame size; 576 byte MTUs, for instance, did make sense for interactive traffic in the days of 2400 baud modems, but not so much now). Adam -- 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 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
Defining an LPAR on a z box to run LINUX
We are researching the possibility of putting up a LINUX LPAR on our z/890 for a Proof of Concept. We currently have 3 general purpose CP's turned on in the box. All 3 of the general purpose CP's are available for use to the 3 z/OS LPAR's we run on the machine, none of the CP's are dedicated. I know on the HMC's Activation Profile you can select the LPAR mode ESA/390 or LINUX (and a few other options as well). What I'd like to do is Build a 4th LPAR to be a LINUX LPAR, assign that LPAR just a single processor, it's own Devices via IOCP along with a chunk of memory. This LPAR would just be for me to play around with and learn on. Now my question is the following. Since all three of my General Purpose CP's are shared across LPAR's that are EAS/390 Mode LPARS, can I use one of those same three General Purpose CP's for this LINUX Mode LPAR? Or must all LPAR's assigned to a CP be defined as the same mode type? i.e. EAS/390 or LINUX. -Thanks Dave. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Defining an LPAR on a z box to run LINUX
Yes... We are in working with our IBM Rep, only problem is our purchasing department moves nowhere near as quickly as out IT department would like them too. Thanks to all who cleared this question up for me. I have a feeling I'll be back with additional inquiries as time go on. Thanks again. -Dave -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of RPN01 Sent: Tuesday, July 31, 2007 8:57 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Defining an LPAR on a z box to run LINUX If you're doing a proof of concept, talk to your friendly IBM Sales Rep; you might just be able to talk him / her into turning on an IFL for POC purposes, and you won't have to impact your production workload at all. Just a thought -- .~.Robert P. Nix Mayo Foundation /V\RO-OE-5-55200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - "In theory, theory and practice are the same, but in practice, theory and practice are different." On 7/31/07 7:30 AM, "Peter Webb, Toronto Transit Commission" <[EMAIL PROTECTED]> wrote: > Just define your Linux LPAR as you would a z/OS LPAR. The CP type > 'LINUX' refers to an IFL engine (Integrated Facility for Linux), which > from your description you do not have. Yes, all LPARS assigned to a CP > must be the same type. > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
