Re: Kernel patch to add VM IPL PARM support
First off I gotta say 2 things...
Don't ever install Unreal Tournament on your home (or work) machine. You'll
never get anything productive done. If you have and see Cyball running
around gettin' his arse blown off, show me some mercy. Putting a few slugs
in the dude blastin' me would hurt either :-)
Secondly, VM is bloody cool!!! I haven't had this much fun in a while and
would never have been able to figure out something like this on bare metal.
(Unless I used Hercules...)
I don't know if it will be of interest to anyone, but it'll help me remember
later on if'n I "write" it down.
When you save the Linux segment you tell CP where to interrupt the IPL (I R
1). But, the breakpoint occurs AFTER the instruction at 1 executes.
That's the point where CP takes a snapshot of the registers that get saved
in the segment. It is also the location that CP reloads the registers, so
anything that the instruction at 1 does to the registers, is effectively
nullified when the reload occurs. Normally, this is okay since CP reloads
what was just set.
But, it causes us a problem when we use the PARMREGS=0-15 in the DEFSYS
command since the instruction (BASR R13,0) at 1 is setting up a base
register and when CP loads the PARM registers it winds up killing the base.
This is what was causing the loop when PARMREGS=0-15 was specified. The
easiest solution around that was simply to put a "NOP 0" as the instruction
at 1. This allows CP to load the registers with whatever it bloody well
pleases as the base setup will occur after the load.
But, that doesn't help us with PARMs on the IPL command. And whatever
change is made, must be usable when a kernel compiled with the SHARED option
is IPLed directly from disk, reader, tape, an NSS, or when the SHARED option
isn't used.
It wound up being almost as easy as the NOP. Since zipl and my original
patch save the IPL registers at location 0x180, all that is necessary to get
this to work with NSSes is to include an LM and STM of all registers as the
first 2 instructions at 1. This is only necessary when the SHARED
option is used, so the instructions are left out for a normal compile.
Anyway, enough rambling. If you want the updated patch, head over to:
http://www.homerow.net/projects/zlinux/vmparms.htm
to grab a copy. It also includes the change that allows you to specify (or
not) what keyword will be looked for when examining the IPL regs to
determine if parameters were supplied or not. Currently, it is set to
require "LINE " as in:
IPL 4000 PARM line dasd=0x4000-0x5000 single
If it doesn't find "LINE " at the beginning, it doesn't include any
additional parameters.
You may change what it looks for by modifying the the PARMEYEC define at the
start of the /usr/src/linux/arch/s390/kernel/setup.c file to whatever you
like. Setting it to the null string ("") will disable the feature and the
patch will blindly attempt to use whatever the registers contained at IPL.
(Well, upto the first hex zero.)
I decided against the allowing prefix and postfix parameters. It seesm that
"most" parameter processing uses the last option found, thus allowing
overrides. Let me know if you folks think it necessary.
Leland
NOT disabled wait
I have a question about shutdown linux. I use Red Hat 7.2 under z/VM 4.3. After i shutdown linux, CP does not become "disabled wait". Why? And when using multiple cpu and 'SET RUN ON', after shutdown linux and #cp disconnect, cpu 0 is running forever... What is running? What is a reason that cpu is running after shutdown and disconnect? Naoshi Kubo E-Mail : [EMAIL PROTECTED]
Re: Kernel patch to add VM IPL PARM support
Got around the loop (my guesser was working okay tonight). Now to figure out how to get the parms accepted. Leland -Original Message- From: Lucius, Leland To: 'Adam Thornton ' '; ''[EMAIL PROTECTED] ' ' Sent: 3/4/03 9:30 PM Subject: RE: Kernel patch to add VM IPL PARM support Welp, don't bother with the PARMREGS parm. It taint a gonna work. (As you've already noticed.) The ZIPL boot code is bypassed as the IPL starts at 0x1. This means that the IPL PARMs never get a chance to be saved in storage. As you found out, a loop results if you use the PARMREGS parm. I'm still looking, but I believe this has to do when CP loads (or doesn't) the IPL PARMs into the registers. If my guessing works out this time round, then there will be an easy solution to the loop and the lack of IPL PARMs with a saved segment. Give me a bit... Leland -Original Message- From: Lucius, Leland To: 'Adam Thornton '; '[EMAIL PROTECTED] ' Sent: 3/4/03 8:06 PM Subject: RE: Kernel patch to add VM IPL PARM support Okay, adding PARMREGS=0-15 to the DEFSYS command "might" work. I'm gonna try it, bit I'm not too confident... Leland -Original Message- From: Adam Thornton To: [EMAIL PROTECTED] Sent: 3/4/03 8:45 PM Subject: Re: Kernel patch to add VM IPL PARM support This may be a silly question based on my deeply imperfect understanding of the VM IPL process, but... Why does the PARM patch not work with a kernel in an NSS? That is, if I define the kernel in an NSS (let's call it DEB24M), and then I do an IPL DEB24M PARM mem=32M I don't actually get the mem=32M appended to my parmline. Works fine when I IPL from DASD, though. Adam
Re: Kernel patch to add VM IPL PARM support
Welp, don't bother with the PARMREGS parm. It taint a gonna work. (As you've already noticed.) The ZIPL boot code is bypassed as the IPL starts at 0x1. This means that the IPL PARMs never get a chance to be saved in storage. As you found out, a loop results if you use the PARMREGS parm. I'm still looking, but I believe this has to do when CP loads (or doesn't) the IPL PARMs into the registers. If my guessing works out this time round, then there will be an easy solution to the loop and the lack of IPL PARMs with a saved segment. Give me a bit... Leland -Original Message- From: Lucius, Leland To: 'Adam Thornton '; '[EMAIL PROTECTED] ' Sent: 3/4/03 8:06 PM Subject: RE: Kernel patch to add VM IPL PARM support Okay, adding PARMREGS=0-15 to the DEFSYS command "might" work. I'm gonna try it, bit I'm not too confident... Leland -Original Message- From: Adam Thornton To: [EMAIL PROTECTED] Sent: 3/4/03 8:45 PM Subject: Re: Kernel patch to add VM IPL PARM support This may be a silly question based on my deeply imperfect understanding of the VM IPL process, but... Why does the PARM patch not work with a kernel in an NSS? That is, if I define the kernel in an NSS (let's call it DEB24M), and then I do an IPL DEB24M PARM mem=32M I don't actually get the mem=32M appended to my parmline. Works fine when I IPL from DASD, though. Adam
Re: DB2 Connect Enterprise Edition for Linux/Zseries
In number 4, you do NOT need KDE (or XFree86) installed in order to run these programs. It is just a waste of disk space since the zSeries is not a graphical environment. The export of the display variable, the xhost command and a X Server on a Windows machine (or a Linux Intel system) will work just fine. On Tuesday 04 March 2003 01:19 pm, you wrote: > James, > > I went through a similar thing with WebSphere. Here's what I did: > > 1) Download and install on your desktop the Cygwin/XFree86 X-Server from > www.cygwin.com. > > 2) Launch Cygwin on your desktop and in the window type: cd /usr/X11R6/bin > && startx > > 3) A few xterm sessions will start in another window; in one of them do: > ps -a > > kill > xhost +your-linux-hostname > > 4) On Linux do: > export DISPLAY=ip.address.of.desktop:0 > startkde & (this starts the Windows Manager KDE) > cd /your.db2.install.directory > ./install.sh & (or whatever it's called) > > The DB2 install window should appear in you Cygwin window. > > Thanks, > Hank Calzaretta > > > > -Original Message- > From: James Melin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 04, 2003 12:48 PM > To: [EMAIL PROTECTED] > Subject: DB2 Connect Enterprise Edition for Linux/Zseries > > > I just got shipped the DB2 Connect EE for Z/Linux version 8.1. The manual > doesn't have a specific Linux 390 section, however I get teh following > error when I try to run the db2setup process. > > DBI1190I db2setup is preparing the DB2 Setup Wizard which will > guide you through the program setup process. Please > wait. > > > > The DISPLAY variable is not set properly. Ensure that the DISPLAY variable > is set properly and that permissions are set properly to open windows on > the display specified, then rerun the command. > nokomis:/opt/DB2_V81_CONEE_LNX390_NLV # > > It appears that it's gonna do something with x windows, for a gui client to > do the actual setup. The documentation I have doesn't mention doing an > export display etc. sort of thing. > > Anyone been here? The 7.2 Db2 Connect EE was shell based. -- Rich Smrcina Sr. Systems Engineer Sytek Services, A Division of DSG Milwaukee, WI [EMAIL PROTECTED] [EMAIL PROTECTED] Catch the WAVV! Stay for Requirements and the Free for All! Update your S/390 skills in 4 days for a very reasonable price. WAVV 2003 in Winston-Salem, NC. April 25-29, 2003 For details see http://www.wavv.org
Re: Kernel patch to add VM IPL PARM support
Okay, adding PARMREGS=0-15 to the DEFSYS command "might" work. I'm gonna try it, bit I'm not too confident... Leland -Original Message- From: Adam Thornton To: [EMAIL PROTECTED] Sent: 3/4/03 8:45 PM Subject: Re: Kernel patch to add VM IPL PARM support This may be a silly question based on my deeply imperfect understanding of the VM IPL process, but... Why does the PARM patch not work with a kernel in an NSS? That is, if I define the kernel in an NSS (let's call it DEB24M), and then I do an IPL DEB24M PARM mem=32M I don't actually get the mem=32M appended to my parmline. Works fine when I IPL from DASD, though. Adam
Re: Kernel patch to add VM IPL PARM support
Now remember, I'm still new to VM and barely know what a shared segment is, so I'm just guessing, but... It probably has to do with the ZIPL boot code not being executed when you IPL the NSS. The boot code stores the PARMs into lowcore at 0x180 for 64 bytes. I recall seeing some NSS specific code in the kernel. I'll see if'n I can get devine the problem. Leland -Original Message- From: Adam Thornton To: [EMAIL PROTECTED] Sent: 3/4/03 8:45 PM Subject: Re: Kernel patch to add VM IPL PARM support This may be a silly question based on my deeply imperfect understanding of the VM IPL process, but... Why does the PARM patch not work with a kernel in an NSS? That is, if I define the kernel in an NSS (let's call it DEB24M), and then I do an IPL DEB24M PARM mem=32M I don't actually get the mem=32M appended to my parmline. Works fine when I IPL from DASD, though. Adam
Re: Red Hat 7.2 S/390
Hello again from Gregg C Levine Personally I have androids running my computer centers, in all the shops that I setup. Now can we revert to a more appropriate level in our discussions? --- Gregg C Levine [EMAIL PROTECTED] "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of > Ferguson, Neale > Sent: Tuesday, March 04, 2003 5:26 PM > To: [EMAIL PROTECTED] > Subject: Re: [LINUX-390] Red Hat 7.2 S/390 > > It's not a problem when you're running Eunuchs! > > -Original Message- > FIn the S/390 case its perhaps less of an > issue to a customer because you already assigned IBM control of your left > testicle when you bought into the S/390 platform.
Re: Kernel patch to add VM IPL PARM support
This may be a silly question based on my deeply imperfect understanding of the VM IPL process, but... Why does the PARM patch not work with a kernel in an NSS? That is, if I define the kernel in an NSS (let's call it DEB24M), and then I do an IPL DEB24M PARM mem=32M I don't actually get the mem=32M appended to my parmline. Works fine when I IPL from DASD, though. Adam
Two More SHARE Presentations
Mike MacIsaac of IBM donated his two presentations from SHARE 100: 9321Mike MacIsaac File Solutions Using Samba 9325Mike MacIsaac Print Solutions Using Samba Thanks, Mike. Mark Post
Re: Gnome
On Tue, 4 Mar 2003, Ryan Ware wrote: > > -Original Message- > > From: Tzafrir Cohen [SMTP:[EMAIL PROTECTED] > > Sent: Tuesday, March 04, 2003 2:47 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Gnome [ snip ] > > Repeast until all dependencies are satisfied (in that case the rpm command > > will succeed) > > > My, what fun. > This is when you don't want to use up2date, don't want to setup apt, and can't figure things out manually. -- Tzafrir Cohen mailto:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir
Re: Linux question re: kernel update
The output from the "uname -r" command was: 2.4.7-SuSE-SMP I have installed SuSE Linux Enterprise Server 7 for S/390 (31 bit-mode). -Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 3:00 PM To: [EMAIL PROTECTED] Subject: Re: Linux question re: kernel update Doug, The configure scripts normally do not look at environment variables to figure things out. They normally use other methods. If it can't find the kernel source, then perhaps you don't have the kernel source RPM installed. Do you want to know what version of the Linux distribution you're running, or do you want to know what version of the kernel you're running? For the latter, "uname -r" will tell you that. For the first, that is distribution-specific. Which one are you running? Mark Post -Original Message- From: Doug Clark [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 5:47 PM To: [EMAIL PROTECTED] Subject: Linux question re: kernel update I received an error message trying to run a configure script for LVM. One message I saw stated that I should "Consider using the --with-kernel_dir flag" and I have seen the "use with-kernel_dir flag" comment is other documentation. I assume that this is an environment variable but I don't know what steps I need to perform so that this is set. Also, what command can I execute to determine the version of Linux I am running? Thanks in advance for your help.
Re: Linux question re: kernel update
Doug, The configure scripts normally do not look at environment variables to figure things out. They normally use other methods. If it can't find the kernel source, then perhaps you don't have the kernel source RPM installed. Do you want to know what version of the Linux distribution you're running, or do you want to know what version of the kernel you're running? For the latter, "uname -r" will tell you that. For the first, that is distribution-specific. Which one are you running? Mark Post -Original Message- From: Doug Clark [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 5:47 PM To: [EMAIL PROTECTED] Subject: Linux question re: kernel update I received an error message trying to run a configure script for LVM. One message I saw stated that I should "Consider using the --with-kernel_dir flag" and I have seen the "use with-kernel_dir flag" comment is other documentation. I assume that this is an environment variable but I don't know what steps I need to perform so that this is set. Also, what command can I execute to determine the version of Linux I am running? Thanks in advance for your help.
Linux question re: kernel update
I received an error message trying to run a configure script for LVM. One message I saw stated that I should "Consider using the --with-kernel_dir flag" and I have seen the "use with-kernel_dir flag" comment is other documentation. I assume that this is an environment variable but I don't know what steps I need to perform so that this is set. Also, what command can I execute to determine the version of Linux I am running? Thanks in advance for your help.
Re: Red Hat 7.2 S/390
It's not a problem when you're running Eunuchs! -Original Message- FIn the S/390 case its perhaps less of an issue to a customer because you already assigned IBM control of your left testicle when you bought into the S/390 platform.
Re: Red Hat 7.2 S/390
Ouch. I was wondering what that doctor with the IBM badge was doing in our computer room when they installed our z900. -Original Message- From: Alan Cox [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 2:49 PM To: [EMAIL PROTECTED] Subject: Re: Red Hat 7.2 S/390 On Tue, 2003-03-04 at 19:49, James Melin wrote: > Mark, any conjecture as to why Red Hat would do what I feel is a customer > Disservice by not including the OCO modules where SuSE does include them? See the release notes. It would actually be pretty wrong to claim to support any code you don't have source and reasonable control over. In the S/390 case its perhaps less of an issue to a customer because you already assigned IBM control of your left testicle when you bought into the S/390 platform. There are ways of building that kind of support as a multi-way partnership with all the relevant code authors. Thankfully you can play nethack/390 without OCO modules ;) Alan
Re: SNMP response
Neale, Is 10.20.45.1 VM and 10.20.45.159. linux? And are you using port 1024 as you snmp port in the esatcp?? |+---> || "Ferguson, Neale"| || <[EMAIL PROTECTED]| || G-USA.com> | || Sent by: Linux on 390| || Port | || <[EMAIL PROTECTED]>| || | || | || 03/04/2003 04:29 PM | || Please respond to Linux | || on 390 Port | || | |+---> >---| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: SNMP response | >---| I am attempting to get ESATCP on zVM to retrieve SNMP information from a Linux guest. ESATCP complains that there is no response from the guest. A TCPDUMP shows the following: 17:11:20.317614 10.20.45.1.1024 > 10.20.45.159.snmp: C=velocity GetRequest(29) 25.1.1.0 4500 004a 30a1 3c11 df3a 0a14 2d01 0a14 2d9f 0400 00a1 0036 26e6 302c 0201 0004 0876 656c 6f63 6974 79a0 1d02 0401 020d 0002 0100 0201 0030 0f30 0d06 092b 0601 0201 1901 0100 0500 17:11:20.318741 10.20.45.159.snmp > 10.20.45.1.1024: C=velocity GetResponse(33) 25.1.1.0=76121297 (DF) 4500 004e f72e 4000 4011 d4a8 0a14 2d9f 0a14 2d01 00a1 0400 003a 5379 3030 0201 0004 0876 656c 6f63 6974 79a2 2102 0401 020d 0002 0100 0201 0030 1330 1106 092b 0601 0201 1901 0100 4304 0489 84d1 17:11:20.319258 10.20.45.1 > 10.20.45.159: icmp: 10.20.45.1 udp port 1024 unreachable 4500 0038 f72e 3c01 18cf 0a14 2d01 0a14 2d9f 0303 f821 4500 004e f72e 4000 4011 d4a8 0a14 2d9f 0a14 2d01 00a1 0400 003a What is causing the "port 1024 unreachable" error? - This message and its attachments may contain privileged and confidential information. If you are not the intended recipient(s), you are prohibited from printing, forwarding, saving or copying this email. If you have received this e-mail in error, please immediately notify the sender and delete this e-mail and its attachments from your computer.
Re: Red Hat 7.2 S/390
On Tue, Mar 04, 2003 at 10:48:55PM +, Alan Cox wrote: > you already assigned IBM control of your left > testicle when you bought into the S/390 platform. I *knew* I should have read the T&Cs more carefully. Adam
Re: Red Hat 7.2 S/390
On 05.03.2003 at 07:47:06, Alan Cox <[EMAIL PROTECTED]> wrote: > Thankfully you can play nethack/390 without OCO modules ;) Unless your system is network attached via an OSA-Express ;-( Cheers, Vic Cross
Re: DB2 Connect Enterprise Edition for Linux/Zseries
Ditto ... on the x-term and used Cygwin and grumbled about the rubbish documentation. The IBM documentation is rubbish, or perhaps it is the best they can do. -Original Message- From: James Melin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 2:40 PM To: [EMAIL PROTECTED] Subject: Re: DB2 Connect Enterprise Edition for Linux/Zseries Thanks for the info/refresher. If this amount of information was ANYWHERE in the IBM Quick Beginnings for SB2 Connect Enterprise Edition version 8 book, I'd be done now. (GC09-4833-00 - note manual number provided for anyone at IBM that wants to run out and add a specific Linux/390 install section for version 01 of this book) |-+> | | Hank Calzaretta | | | <[EMAIL PROTECTED]| | | ace.com> | | | Sent by: Linux on| | | 390 Port | | | <[EMAIL PROTECTED]| | | IST.EDU> | | || | || | | 03/04/2003 01:19 | | | PM | | | Please respond to| | | Linux on 390 Port| | || |-+> >--- ---| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: DB2 Connect Enterprise Edition for Linux/Zseries | >--- ---| James, I went through a similar thing with WebSphere. Here's what I did: 1) Download and install on your desktop the Cygwin/XFree86 X-Server from www.cygwin.com. 2) Launch Cygwin on your desktop and in the window type: cd /usr/X11R6/bin && startx 3) A few xterm sessions will start in another window; in one of them do: ps -a kill xhost +your-linux-hostname 4) On Linux do: export DISPLAY=ip.address.of.desktop:0 startkde & (this starts the Windows Manager KDE) cd /your.db2.install.directory ./install.sh & (or whatever it's called) The DB2 install window should appear in you Cygwin window. Thanks, Hank Calzaretta -Original Message- From: James Melin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 12:48 PM To: [EMAIL PROTECTED] Subject: DB2 Connect Enterprise Edition for Linux/Zseries I just got shipped the DB2 Connect EE for Z/Linux version 8.1. The manual doesn't have a specific Linux 390 section, however I get teh following error when I try to run the db2setup process. DBI1190I db2setup is preparing the DB2 Setup Wizard which will guide you through the program setup process. Please wait. The DISPLAY variable is not set properly. Ensure that the DISPLAY variable is set properly and that permissions are set properly to open windows on the display specified, then rerun the command. nokomis:/opt/DB2_V81_CONEE_LNX390_NLV # It appears that it's gonna do something with x windows, for a gui client to do the actual setup. The documentation I have doesn't mention doing an export display etc. sort of thing. Anyone been here? The 7.2 Db2 Connect EE was shell based.
Re: Gnome
On Tue, 2003-03-04 at 18:08, Post, Mark K wrote: > Welcome to RPM. > > You could try this: > cd /to/directory/with/RPMs > rpm -Uvh --test gnome-* up2date is your friend, or apt 8) If I remember rightly the basic order is glib gtk+ imlib ORBit audiofile libxml gnome-libs gdk-pixbuf libghttp libglade libgtop gnome-print control-center gnome-core but thats offhand
Re: Upgrading QDIO, QETH on SuSE Linux 2.4.7 SMP
Alan, Take a look at http://linuxvm.org/Info/HOWTOs/guestlan.html to see if that helps. I suspect your problem is that you are _not_ specifying a portname at all, on either the z/VM side, or the Linux/390 side. You need to specify something, and the name has to match, including case, so most people usually specify it in all upper case. All IBM patches and OCO modules are at http://www10.software.ibm.com/developerworks/opensource/linux390/index.shtml Mark Post -Original Message- From: Alan Schilla [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 3:54 PM To: [EMAIL PROTECTED] Subject: Upgrading QDIO, QETH on SuSE Linux 2.4.7 SMP I am trying to activate a virtual QDIO, QETH link between zVM 4.3 TCPIP guest and a SuSE guest version: Linux Version 2.4.7-timer-SMP, Compiled #1 SMP Tue Nov 26 23:25:11 GMT 2002 When I try activating the QDIO, QETH modules that were on the system with this version I received: insmod qdio Using /lib/modules/2.4.7-timer-SMP/misc/qdio.o qdio: loading QDIO base support version 2 ($Revision: 1.78.2.9 $/$Revision: 1.44 .2.3 $) debug: qdio_setup: new level 2 debug: qdio_labs: new level 2 debug: qdio_sense: new level 2 debug: qdio_trace: new level 2 lxisdn01:~ # insmod qeth Using /lib/modules/2.4.7-timer-SMP/net/qeth.o qeth: loading qeth S/390 OSA-Express driver ($Revision: 1.136.2.7 $/$Revision: 1 .53.2.3 $/$Revision: 1.18 $) qeth: allocated 0 spare buffers debug: qeth_setup: new level 3 debug: qeth_misc: new level 2 debug: qeth_data: new level 2 debug: qeth_control: new level 2 debug: qeth_sense: new level 2 debug: qeth_qerr: new level 2 debug: qeth_trace: new level 2 qeth: Trying to use card with devnos 0x700/0x701/0x702 qeth: received an IDX TERMINATE on irq 0x8/0x9 with cause code 0x22 -- try anot her portname qeth: received an IDX TERMINATE on irq 0x8/0x9 with cause code 0x22 -- try anot her portname qeth: There were problems in hard-setting up the card. debug: unregistering qeth_setup debug: unregistering qeth_qerr debug: unregistering qeth_sense debug: unregistering qeth_misc debug: unregistering qeth_data debug: unregistering qeth_control debug: unregistering qeth_trace /lib/modules/2.4.7-timer-SMP/net/qeth.o: init_module: No such device Hint: insmod errors can be caused by incorrect module parameters, including inva lid IO or IRQ parameters I get this TRY ANOTHER PORT NAME no matter what I use for portname even though a Q NIC DETAILS and Q V for the QDIO device numbers 700-702 show: CP Q NIC DETAILS Adapter 0700 Type: QDIO Name: UNASSIGNED Devices: 3 Port 0 MAC: 00-04-AC-00-00-02 LAN: SYSTEM LNXLAN MFS: 8192 RX Packets: 0 Discarded: 0 Errors: 0 TX Packets: 0 Discarded: 0 Errors: 0 RX Bytes: 0TX Bytes: 0 Connection Name: HALLOLE State: CM_CONNECT Device: 0700 Unit: 000 Role: CTL-READ Device: 0701 Unit: 001 Role: CTL-WRITE Device: 0702 Unit: 002 Role: DATA Q V 700-702 OSA 0700 ON NIC 0700 UNIT 000 SUBCHANNEL = 0008 0700 QDIO-ELIGIBLE OSA 0701 ON NIC 0700 UNIT 001 SUBCHANNEL = 0009 0701 QDIO-ELIGIBLE OSA 0702 ON NIC 0700 UNIT 002 SUBCHANNEL = 000A 0702 QDIO-ELIGIBLE I have also tried downloading the latest 2.4.7 qdio, qeth drivers and activating these and recieve: lxisdn01:~ # modprobe qeth modprobe qeth /lib/modules/2.4.7-timer-SMP/misc/qdio.o: kernel-module version mismatch /lib/modules/2.4.7-timer-SMP/misc/qdio.o was compiled for kernel version 2.4.7-timer while this kernel is version 2.4.7-timer-SMP. /lib/modules/2.4.7-timer-SMP/misc/qdio.o: insmod /lib/modules/2.4.7-timer-SMP/mi sc/qdio.o failed /lib/modules/2.4.7-timer-SMP/misc/qdio.o: insmod qeth failed lxisdn01:~ # Does anyone know how I can get this to work or where I may find the latest QDIO, QETH drivers for SuSE-2.4.7-SMP kernel? Thanks, Al Schilla State of Minnesota
Re: Installing Red Hat 7.2 on an LPAR?
Bill wrote: >Plan B: install from CD-ROM. But the doc refers to a "Load from CDROM or >Server" icon on the HMC - and there is no such thing. Groups defined cpc cpc you want Single Objects Operations cpc cpc you want - there should be a load from cdrom at this level If load from the HMC doesn't work, then you're stuck with plan C: >Plan C: ? tape? files are on the redhat CD 3480 or 3490 attached to the LPAR 1 OSA card (preferably OSA/LCS as RH has some trouble with QDIO) connection from the OSA to a network to a machine where you can mount the CD's as NFS or FTP. I found the OSA/LCS and FTP options worked the best for me for redhat. Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens ***
Re: Red Hat 7.2 S/390
On Tue, 2003-03-04 at 19:49, James Melin wrote: > Mark, any conjecture as to why Red Hat would do what I feel is a customer > Disservice by not including the OCO modules where SuSE does include them? See the release notes. It would actually be pretty wrong to claim to support any code you don't have source and reasonable control over. In the S/390 case its perhaps less of an issue to a customer because you already assigned IBM control of your left testicle when you bought into the S/390 platform. There are ways of building that kind of support as a multi-way partnership with all the relevant code authors. Thankfully you can play nethack/390 without OCO modules ;) Alan
Re: Installing Red Hat 7.2 on an LPAR?
Bill, The fact that your HMC is on an isolated network doesn't mean that the LPAR can't get to your PC. Two different considerations. Tom Butler already told you how to find the HMC icon you're looking for. If that still isn't an option, then unlabeled tape will work. Rob van der Heij wrote a document on how to write the 3 starter files to disk so that you can IPL without using a tape, though. Take a look at http://linuxvm.org/Info/l390link.html Mark Post -Original Message- From: Beinert, William [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 4:20 PM To: [EMAIL PROTECTED] Subject: Installing Red Hat 7.2 on an LPAR? After downloading Redhat 7.2 onto my workstation and reading the doc, I decided to to an FTP install. At the HMC, I discover it is on an isolated network segment, and cannot (and will never) see my PC. Plan B: install from CD-ROM. But the doc refers to a "Load from CDROM or Server" icon on the HMC - and there is no such thing. Plan C: ? tape? Any other alternatives? TIA Bill Beinert Systems Programming Con Edison (212) 460-4853 When they took the fourth amendment, I was quiet because I didn't deal drugs! When they took the sixth amendment, I was quiet because, I was innocent. When they took the second amendment, I was quiet because I didn't own a gun! Now they've taken the first amendment, and I can say (or do) nothing about it. The Second Amendment is in place in case they ignore the others. MODWN DAbE
Re: Installing Red Hat 7.2 on an LPAR?
Yes, there is You have to go to Single Object Mode (CPC Recovery)Try it, you'll like it !! -Original Message- From: Beinert, William [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 2:20 PM To: [EMAIL PROTECTED] Subject: Installing Red Hat 7.2 on an LPAR? After downloading Redhat 7.2 onto my workstation and reading the doc, I decided to to an FTP install. At the HMC, I discover it is on an isolated network segment, and cannot (and will never) see my PC. Plan B: install from CD-ROM. But the doc refers to a "Load from CDROM or Server" icon on the HMC - and there is no such thing. Plan C: ? tape? Any other alternatives? TIA Bill Beinert Systems Programming Con Edison (212) 460-4853 When they took the fourth amendment, I was quiet because I didn't deal drugs! When they took the sixth amendment, I was quiet because, I was innocent. When they took the second amendment, I was quiet because I didn't own a gun! Now they've taken the first amendment, and I can say (or do) nothing about it. The Second Amendment is in place in case they ignore the others. MODWN DAbE
Installing Red Hat 7.2 on an LPAR?
After downloading Redhat 7.2 onto my workstation and reading the doc, I decided to to an FTP install. At the HMC, I discover it is on an isolated network segment, and cannot (and will never) see my PC. Plan B: install from CD-ROM. But the doc refers to a "Load from CDROM or Server" icon on the HMC - and there is no such thing. Plan C: ? tape? Any other alternatives? TIA Bill Beinert Systems Programming Con Edison (212) 460-4853 When they took the fourth amendment, I was quiet because I didn't deal drugs! When they took the sixth amendment, I was quiet because, I was innocent. When they took the second amendment, I was quiet because I didn't own a gun! Now they've taken the first amendment, and I can say (or do) nothing about it. The Second Amendment is in place in case they ignore the others. MODWN DAbE
Re: Red Hat 7.2 S/390
Thanks for the feedback, James ... Our team was aware of this risk when making the decision to support/not support the OCO modules ... :) Regards, Brock On Tue, 2003-03-04 at 15:39, James Melin wrote: > The ONLY reason we went with SuSE over RedHat was the OCO module issue. -- Brock Organ <[EMAIL PROTECTED]>
Re: DB2 Connect Enterprise Edition for Linux/Zseries
Two comments: On Tue, 4 Mar 2003, Hank Calzaretta wrote: > James, > > I went through a similar thing with WebSphere. Here's what I did: > > 1) Download and install on your desktop the Cygwin/XFree86 X-Server from > www.cygwin.com. > > 2) Launch Cygwin on your desktop and in the window type: cd /usr/X11R6/bin > && startx If you want a smaller (and still free) X server: http://www.jcraft.com/weirdx/ Use putty with X11 forwarding, and run weirdx as a java application. > > 3) A few xterm sessions will start in another window; in one of them do: > ps -a > > kill > xhost +your-linux-hostname > > 4) On Linux do: > export DISPLAY=ip.address.of.desktop:0 > startkde & (this starts the Windows Manager KDE) > cd /your.db2.install.directory > ./install.sh & (or whatever it's called) Wow! you run a complete desktop on the remote computer? Wouldn't VNC been simpler? Anyway: have you tried: ssh your-linux-host '(cd /your.db2.install.directory; ./install.sh)' (from an xterm) > > The DB2 install window should appear in you Cygwin window. -- Tzafrir Cohen mailto:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir
Re: Gnome
> -Original Message- > From: Tzafrir Cohen [SMTP:[EMAIL PROTECTED] > Sent: Tuesday, March 04, 2003 2:47 PM > To: [EMAIL PROTECTED] > Subject: Re: Gnome > > On Tue, 4 Mar 2003, Kenneth Illingsworth wrote: > > > I am running RH Linux v7.2 with one PHP/MySQL test application that has > > performed well. I was interested in installing the Gnome desktop. I > > elected to try and duplicate past success and tried to utilize Webmin to > > install the RPM files. However, I ran into a lot of dependency problems. > > Is there more of a cookbook approach to installing a desktop on this > > virtual server? > > > > What dependency is not satisfied? > > If you can't figure it out yourself, then search for it in rpmfind.net: > > Suppose it is "libbarbi.so.2" > > go to http://rpmfind.net/ > > type in the search box: > > libbarbi.so.2 > > From the answers select *only* one from "RedHat 7.2" or "RedHat 7.2 > Updates": this is the package you need to install. Add it to the 'rpm -Uv' > command-line that failed due to missing dependencies. > > Repeast until all dependencies are satisfied (in that case the rpm command > will succeed) > My, what fun.
Upgrading QDIO, QETH on SuSE Linux 2.4.7 SMP
I am trying to activate a virtual QDIO, QETH link between zVM 4.3 TCPIP guest and a SuSE guest version: Linux Version 2.4.7-timer-SMP, Compiled #1 SMP Tue Nov 26 23:25:11 GMT 2002 When I try activating the QDIO, QETH modules that were on the system with this version I received: insmod qdio Using /lib/modules/2.4.7-timer-SMP/misc/qdio.o qdio: loading QDIO base support version 2 ($Revision: 1.78.2.9 $/$Revision: 1.44 .2.3 $) debug: qdio_setup: new level 2 debug: qdio_labs: new level 2 debug: qdio_sense: new level 2 debug: qdio_trace: new level 2 lxisdn01:~ # insmod qeth Using /lib/modules/2.4.7-timer-SMP/net/qeth.o qeth: loading qeth S/390 OSA-Express driver ($Revision: 1.136.2.7 $/$Revision: 1 .53.2.3 $/$Revision: 1.18 $) qeth: allocated 0 spare buffers debug: qeth_setup: new level 3 debug: qeth_misc: new level 2 debug: qeth_data: new level 2 debug: qeth_control: new level 2 debug: qeth_sense: new level 2 debug: qeth_qerr: new level 2 debug: qeth_trace: new level 2 qeth: Trying to use card with devnos 0x700/0x701/0x702 qeth: received an IDX TERMINATE on irq 0x8/0x9 with cause code 0x22 -- try anot her portname qeth: received an IDX TERMINATE on irq 0x8/0x9 with cause code 0x22 -- try anot her portname qeth: There were problems in hard-setting up the card. debug: unregistering qeth_setup debug: unregistering qeth_qerr debug: unregistering qeth_sense debug: unregistering qeth_misc debug: unregistering qeth_data debug: unregistering qeth_control debug: unregistering qeth_trace /lib/modules/2.4.7-timer-SMP/net/qeth.o: init_module: No such device Hint: insmod errors can be caused by incorrect module parameters, including inva lid IO or IRQ parameters I get this TRY ANOTHER PORT NAME no matter what I use for portname even though a Q NIC DETAILS and Q V for the QDIO device numbers 700-702 show: CP Q NIC DETAILS Adapter 0700 Type: QDIO Name: UNASSIGNED Devices: 3 Port 0 MAC: 00-04-AC-00-00-02 LAN: SYSTEM LNXLAN MFS: 8192 RX Packets: 0 Discarded: 0 Errors: 0 TX Packets: 0 Discarded: 0 Errors: 0 RX Bytes: 0TX Bytes: 0 Connection Name: HALLOLE State: CM_CONNECT Device: 0700 Unit: 000 Role: CTL-READ Device: 0701 Unit: 001 Role: CTL-WRITE Device: 0702 Unit: 002 Role: DATA Q V 700-702 OSA 0700 ON NIC 0700 UNIT 000 SUBCHANNEL = 0008 0700 QDIO-ELIGIBLE OSA 0701 ON NIC 0700 UNIT 001 SUBCHANNEL = 0009 0701 QDIO-ELIGIBLE OSA 0702 ON NIC 0700 UNIT 002 SUBCHANNEL = 000A 0702 QDIO-ELIGIBLE I have also tried downloading the latest 2.4.7 qdio, qeth drivers and activating these and recieve: lxisdn01:~ # modprobe qeth modprobe qeth /lib/modules/2.4.7-timer-SMP/misc/qdio.o: kernel-module version mismatch /lib/modules/2.4.7-timer-SMP/misc/qdio.o was compiled for kernel version 2.4.7-timer while this kernel is version 2.4.7-timer-SMP. /lib/modules/2.4.7-timer-SMP/misc/qdio.o: insmod /lib/modules/2.4.7-timer-SMP/mi sc/qdio.o failed /lib/modules/2.4.7-timer-SMP/misc/qdio.o: insmod qeth failed lxisdn01:~ # Does anyone know how I can get this to work or where I may find the latest QDIO, QETH drivers for SuSE-2.4.7-SMP kernel? Thanks, Al Schilla State of Minnesota
Re: Gnome
On Tue, 4 Mar 2003, Kenneth Illingsworth wrote: > I am running RH Linux v7.2 with one PHP/MySQL test application that has > performed well. I was interested in installing the Gnome desktop. I > elected to try and duplicate past success and tried to utilize Webmin to > install the RPM files. However, I ran into a lot of dependency problems. > Is there more of a cookbook approach to installing a desktop on this > virtual server? > What dependency is not satisfied? If you can't figure it out yourself, then search for it in rpmfind.net: Suppose it is "libbarbi.so.2" go to http://rpmfind.net/ type in the search box: libbarbi.so.2 >From the answers select *only* one from "RedHat 7.2" or "RedHat 7.2 Updates": this is the package you need to install. Add it to the 'rpm -Uv' command-line that failed due to missing dependencies. Repeast until all dependencies are satisfied (in that case the rpm command will succeed) -- Tzafrir Cohen mailto:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir
Re: Send mail alert - is this old? Are there L/390 patches out yet?
Just a small correction: On Tue, 4 Mar 2003, James Melin wrote: [ quoting the advisory ] > > On February 14th a TruSecure Radar posting indicated that we were > aware of a potential vulnerability in Sendmail. Today, a coordinated > announcement was made regarding a Sendmail header buffer overflow > vulnerability. It is expected that code exploiting this > vulnerability is already in circulation and attacks will be likely in > the near future. > > Most installations of Unix include Sendmail by default and are > therefore probably vulnerable. * SuSE uses postfix by default, (right?) * Debian uses exim by default * RedHat: RH7.2 uses sendmail by default. But RH7.3 and above (and the Advanced server as well?) uses postfix by default Note that all three distros have a sendmail package. > > This may impact an organization's infrastructure because many > firewalls and content filtering products contain Sendmail. Wow! show me such a firewall! It should be exterminated! > > It is recommended that customers who are using a firewall that > proxies mail, using Sendmail, implement packet filtering rules to > redirect mail through patched or non-Sendmail systems while > propagating fixes from their vendors. non-Sendmail systems is probably the better option. qmail has a very "clean" security history. Postfix and Exim also have a ratheer "clean" track record (and postfix shares most of the paranoid design decisions of qmail) Meanwhile not a year goes by without a new hole in sendmail... (I personally use postfix) -- Tzafrir Cohen mailto:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir
Re: Red Hat 7.2 S/390
Knowing full well that people who give feedback DIRECTLY to the execs at redhat, I will say this on the OCO subject: The ONLY reason we went with SuSE over RedHat was the OCO module issue. Once we solved the problem with our switch that made me go mad trying to figure out why Linux was broken (wasn't was switch) SuSE installed just fine. We did not feel that having to roll your own each time a proven stable maintenance release of the Kernel was out was a good way to do things. That was the deciding factor as to which vendor we currently are going with. |-+> | | "Post, Mark K" | | | <[EMAIL PROTECTED]| | | m> | | | Sent by: Linux on| | | 390 Port | | | <[EMAIL PROTECTED]| | | IST.EDU> | | || | || | | 03/04/2003 02:21 | | | PM | | | Please respond to| | | Linux on 390 Port| | || |-+> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Red Hat 7.2 S/390 | >--| Vic, One can only hope. It's made life miserable for a number of people, myself included, over time. Mark Post -Original Message- From: Vic Cross [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 3:14 PM To: [EMAIL PROTECTED] Subject: Re: Red Hat 7.2 S/390 On 05.03.2003 at 06:02:06, "Post, Mark K" <[EMAIL PROTECTED]> wrote: > No conjecture needed. They have both business and philosophical issues with > distributing OCO code, and hence being responsible for supporting them when > source code is not available. With IBM and Red Hat reaching an agreement on 'co-operative support' (the exact wording escapes me now), I wonder if we will see a change to this with future Red Hat releases... Cheers, Vic Cross
Re: DB2 Connect Enterprise Edition for Linux/Zseries
Thanks for the info/refresher. If this amount of information was ANYWHERE in the IBM Quick Beginnings for SB2 Connect Enterprise Edition version 8 book, I'd be done now. (GC09-4833-00 - note manual number provided for anyone at IBM that wants to run out and add a specific Linux/390 install section for version 01 of this book) |-+> | | Hank Calzaretta | | | <[EMAIL PROTECTED]| | | ace.com> | | | Sent by: Linux on| | | 390 Port | | | <[EMAIL PROTECTED]| | | IST.EDU> | | || | || | | 03/04/2003 01:19 | | | PM | | | Please respond to| | | Linux on 390 Port| | || |-+> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: DB2 Connect Enterprise Edition for Linux/Zseries | >--| James, I went through a similar thing with WebSphere. Here's what I did: 1) Download and install on your desktop the Cygwin/XFree86 X-Server from www.cygwin.com. 2) Launch Cygwin on your desktop and in the window type: cd /usr/X11R6/bin && startx 3) A few xterm sessions will start in another window; in one of them do: ps -a kill xhost +your-linux-hostname 4) On Linux do: export DISPLAY=ip.address.of.desktop:0 startkde & (this starts the Windows Manager KDE) cd /your.db2.install.directory ./install.sh & (or whatever it's called) The DB2 install window should appear in you Cygwin window. Thanks, Hank Calzaretta -Original Message- From: James Melin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 12:48 PM To: [EMAIL PROTECTED] Subject: DB2 Connect Enterprise Edition for Linux/Zseries I just got shipped the DB2 Connect EE for Z/Linux version 8.1. The manual doesn't have a specific Linux 390 section, however I get teh following error when I try to run the db2setup process. DBI1190I db2setup is preparing the DB2 Setup Wizard which will guide you through the program setup process. Please wait. The DISPLAY variable is not set properly. Ensure that the DISPLAY variable is set properly and that permissions are set properly to open windows on the display specified, then rerun the command. nokomis:/opt/DB2_V81_CONEE_LNX390_NLV # It appears that it's gonna do something with x windows, for a gui client to do the actual setup. The documentation I have doesn't mention doing an export display etc. sort of thing. Anyone been here? The 7.2 Db2 Connect EE was shell based.
Re: SNMP response
On 05.03.2003 at 03:32:42, "Ferguson, Neale" <[EMAIL PROTECTED]> wrote: > No firewall between guest and VM system - direct vCTC connection. Remember that there doesn't have to be a firewall between the systems for firewall rules to be in effect... Double and triple check (if you haven't already) that there are no firewall rules on your Linux system that might be blocking this. Can't really think of anything else that might be a problem... Cheers, Vic Cross
Re: SNMP response
It was the client. I updated to the latest level and things started working. Thanks all
Re: Red Hat 7.2 S/390
On Tue, Mar 04, 2003 at 01:49:30PM -0600, James Melin wrote: > Mark, any conjecture as to why Red Hat would do what I feel is a customer > Disservice by not including the OCO modules where SuSE does include them? Red Hat does not, as a matter of policy, include *any* OCO drivers in its systems. When I worked at Compaq, they refused to even consider it for any Compaq hardware, period. OCO drivers violate the very spirit of Linux, to their way of thinking, and they refuse to support them. Period. It's arguable that, while Red Hat may be doing its customers a disservice, IBM is doing them a greater disservice by releasing the drivers as OCO in the first place. That would certainly be Red Hat's argument.
Re: Kernel patch to add VM IPL PARM support
I found that your patch applied cleanly after the IBM patches (to the 2.4.19 kernel source tree). My automation applies patches in order based on their timestamp (which thankfully is preserved because IBM delivers them in TAR). This is so clean that I would hate for IBM to miss the opportunity. Only addition that it needs is LOADPARM, but that is a very different mechanism. It just seems that it fits with the support of PARM operationally. > > We've argued also about the order of the parameters. ... > My guess is that appending would be quite satisfactory, > but it won't be difficult to allow both prefixing and suffixing. I don't know what pain Rob & co have gone through, but my experience is that you want *override* of on-disk defaults, which seems to be effected by appending the additional PARMs. That is, the on-disk parm says root=/dev/dasdb1 and you would override that with 'ipl 1234 clear parm root=/dev/dasdc1'. The appending of the VM PARMs gives the desired result. In PC land too, "append" seems to be what is happening. But I have not had occasion to dissect LILO or GRUB to know for sure. It is possible that a boot loader would try to replace on-disk tokens with interactively entered boot parms, but that seems like a lot of work if the kernel is already doing the Right Thing with override. -- RMT
Re: Red Hat 7.2 S/390
Vic, One can only hope. It's made life miserable for a number of people, myself included, over time. Mark Post -Original Message- From: Vic Cross [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 3:14 PM To: [EMAIL PROTECTED] Subject: Re: Red Hat 7.2 S/390 On 05.03.2003 at 06:02:06, "Post, Mark K" <[EMAIL PROTECTED]> wrote: > No conjecture needed. They have both business and philosophical issues with > distributing OCO code, and hence being responsible for supporting them when > source code is not available. With IBM and Red Hat reaching an agreement on 'co-operative support' (the exact wording escapes me now), I wonder if we will see a change to this with future Red Hat releases... Cheers, Vic Cross
Re: Red Hat 7.2 S/390
On 05.03.2003 at 06:02:06, "Post, Mark K" <[EMAIL PROTECTED]> wrote: > No conjecture needed. They have both business and philosophical issues with > distributing OCO code, and hence being responsible for supporting them when > source code is not available. With IBM and Red Hat reaching an agreement on 'co-operative support' (the exact wording escapes me now), I wonder if we will see a change to this with future Red Hat releases... Cheers, Vic Cross
Re: Red Hat 7.2 S/390
Hi James, Our RELEASE-NOTES (section "Adding OCO Modules to the Installation Program") tries to address why Red Hat does not include the OCO modules. :) Regards, Brock On Tue, 2003-03-04 at 14:49, James Melin wrote: > Mark, any conjecture as to why Red Hat would do what I feel is a customer > Disservice by not including the OCO modules where SuSE does include them? -- Brock Organ <[EMAIL PROTECTED]>
Re: Red Hat 7.2 S/390
Jim, No conjecture needed. They have both business and philosophical issues with distributing OCO code, and hence being responsible for supporting them when source code is not available. There's a fairly long thread in the archives about this that starts here: http://www2.marist.edu/htbin/wlvtype?LINUX-VM.18546 Mark Post -Original Message- From: James Melin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 2:50 PM To: [EMAIL PROTECTED] Subject: Re: Red Hat 7.2 S/390 Mark, any conjecture as to why Red Hat would do what I feel is a customer Disservice by not including the OCO modules where SuSE does include them? |-+> | | "Post, Mark K" | | | <[EMAIL PROTECTED]| | | m> | | | Sent by: Linux on| | | 390 Port | | | <[EMAIL PROTECTED]| | | IST.EDU> | | || | || | | 03/04/2003 01:12 | | | PM | | | Please respond to| | | Linux on 390 Port| | || |-+> >--- ---| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Red Hat 7.2 S/390 | >--- ---| Richard, A better description of Red Hat's install package is that it does not include any of IBM's OCO modules. As a result, people who want to do an install that requires one of the OCO modules to get a network connection have to go through some additional work to make that happen. The latest installation kernel on the Red Hat site is 2.4.9-37. There should be current OCO modules for that available on IBM's DeveloperWorks site: http://www10.software.ibm.com/developerworks/opensource/linux390/special_oco _rh_2.4.shtml The RELEASE-NOTES file from Red Hat's FTP server has instructions on how to get the OCO modules integrated into the installation files. Mark Post ---Snip-
Re: Kernel patch to add VM IPL PARM support
> -Original Message- > From: Rob van der Heij [mailto:[EMAIL PROTECTED] > Sent: Monday, March 03, 2003 12:48 PM > To: [EMAIL PROTECTED] > Subject: Re: Kernel patch to add VM IPL PARM support > > > Lucius, Leland wrote: > > So, which should it be? Append or prepend the PARMs to the > command line? I > > haven't looked too deeply, but it appears that processing > kernel parameters > > isn't too consistent and some rtns take the first parameter > encountered. As > > it is, appending PARMs wouldn't allow you to override in > those situations. > > A similar implementation was published in the ISP/ASP > redbook. So far I have > failed in trying to get our friends in Boeblingen to take the > code I offered. That's a bummer. A shame they aren't more open to "user contributed" patches. > I can justify spending some type in protoyping code, but if > it does not make > it into the official sources it is a burden to support it > My take on this is a tad different. Since we will be using the patch, I don't have a problem with maintaining it. Not much different than the usermods we maintain on our OS/390 LPARs. But, I will only maintain a version that fits our needs. Since the patch is/will be made available to anyone, then it would be a simple matter for "anyone" to modify it to suit their needs. > We've argued also about the order of the parameters. In our > case the rest of > the options is in the NSS, and in real life it turns out we > mainly needed it > to specify the root= (which takes the last one) and to > specify a few more disk > devices (takes them all in the order specified). Also the > option to suppress > the DEVFS mount came in handy (when you forget to disable it > in the kernel). > But the main thing remains the simplicity to save the NSS. > My guess is that appending would be quite satisfactory, but it won't be difficult to allow both prefixing and suffixing. Leland
Re: Red Hat 7.2 S/390
Mark, any conjecture as to why Red Hat would do what I feel is a customer Disservice by not including the OCO modules where SuSE does include them? |-+> | | "Post, Mark K" | | | <[EMAIL PROTECTED]| | | m> | | | Sent by: Linux on| | | 390 Port | | | <[EMAIL PROTECTED]| | | IST.EDU> | | || | || | | 03/04/2003 01:12 | | | PM | | | Please respond to| | | Linux on 390 Port| | || |-+> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Red Hat 7.2 S/390 | >--| Richard, A better description of Red Hat's install package is that it does not include any of IBM's OCO modules. As a result, people who want to do an install that requires one of the OCO modules to get a network connection have to go through some additional work to make that happen. The latest installation kernel on the Red Hat site is 2.4.9-37. There should be current OCO modules for that available on IBM's DeveloperWorks site: http://www10.software.ibm.com/developerworks/opensource/linux390/special_oco _rh_2.4.shtml The RELEASE-NOTES file from Red Hat's FTP server has instructions on how to get the OCO modules integrated into the installation files. Mark Post ---Snip-
Re: DB2 Connect Enterprise Edition for Linux/Zseries
The install is actually 2 phases. The 1st simply places the necessary RPMs where they need to go (/opt/...). The 2nd part is answering exactly the same type of questions you did in 7.2. -Original Message- I'd just like to see some documentation in the IBM supplied info that explains EXACTLY what to do to make this work on Linux/390, since it is a HUGE deviation from the 7.2 distribution. I know we bought service from IBM for this, but I'll be damned if I know where to do in install question. Sure as hell isn't IIN. I did some stuff similar to this with WAS 4.0 on linux. Now I just gotta remember where that doc went
Re: DB2 Connect Enterprise Edition for Linux/Zseries
I'd just like to see some documentation in the IBM supplied info that explains EXACTLY what to do to make this work on Linux/390, since it is a HUGE deviation from the 7.2 distribution. I know we bought service from IBM for this, but I'll be damned if I know where to do in install question. Sure as hell isn't IIN. I did some stuff similar to this with WAS 4.0 on linux. Now I just gotta remember where that doc went |-+> | | "Post, Mark K" | | | <[EMAIL PROTECTED]| | | m> | | | Sent by: Linux on| | | 390 Port | | | <[EMAIL PROTECTED]| | | IST.EDU> | | || | || | | 03/04/2003 12:58 | | | PM | | | Please respond to| | | Linux on 390 Port| | || |-+> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: DB2 Connect Enterprise Edition for Linux/Zseries | >--| Some things to check: - Your sshd_config parms allows for X forwarding X11Forwarding yes - You're using ssh to access the system - echo $DISPLAY should show something like: localhost:10.0 - You have an X server running on your desktop Mark Post -Original Message- From: James Melin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 1:48 PM To: [EMAIL PROTECTED] Subject: DB2 Connect Enterprise Edition for Linux/Zseries I just got shipped the DB2 Connect EE for Z/Linux version 8.1. The manual doesn't have a specific Linux 390 section, however I get teh following error when I try to run the db2setup process. DBI1190I db2setup is preparing the DB2 Setup Wizard which will guide you through the program setup process. Please wait. The DISPLAY variable is not set properly. Ensure that the DISPLAY variable is set properly and that permissions are set properly to open windows on the display specified, then rerun the command. nokomis:/opt/DB2_V81_CONEE_LNX390_NLV # It appears that it's gonna do something with x windows, for a gui client to do the actual setup. The documentation I have doesn't mention doing an export display etc. sort of thing. Anyone been here? The 7.2 Db2 Connect EE was shell based.
Re: DB2 Connect Enterprise Edition for Linux/Zseries
James, I went through a similar thing with WebSphere. Here's what I did: 1) Download and install on your desktop the Cygwin/XFree86 X-Server from www.cygwin.com. 2) Launch Cygwin on your desktop and in the window type: cd /usr/X11R6/bin && startx 3) A few xterm sessions will start in another window; in one of them do: ps -a kill xhost +your-linux-hostname 4) On Linux do: export DISPLAY=ip.address.of.desktop:0 startkde & (this starts the Windows Manager KDE) cd /your.db2.install.directory ./install.sh & (or whatever it's called) The DB2 install window should appear in you Cygwin window. Thanks, Hank Calzaretta -Original Message- From: James Melin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 12:48 PM To: [EMAIL PROTECTED] Subject: DB2 Connect Enterprise Edition for Linux/Zseries I just got shipped the DB2 Connect EE for Z/Linux version 8.1. The manual doesn't have a specific Linux 390 section, however I get teh following error when I try to run the db2setup process. DBI1190I db2setup is preparing the DB2 Setup Wizard which will guide you through the program setup process. Please wait. The DISPLAY variable is not set properly. Ensure that the DISPLAY variable is set properly and that permissions are set properly to open windows on the display specified, then rerun the command. nokomis:/opt/DB2_V81_CONEE_LNX390_NLV # It appears that it's gonna do something with x windows, for a gui client to do the actual setup. The documentation I have doesn't mention doing an export display etc. sort of thing. Anyone been here? The 7.2 Db2 Connect EE was shell based.
Re: DB2 Connect Enterprise Edition for Linux/Zseries
Ugh. Are they trying to make themselves look more like Oracle?!? Why do these vendors insist on having a GUI to install a server software package?? Do they think UDB, Websphere, and Oracle administrators can't type? Craziness I say! Scott Chapman One who types Dave Jones <[EMAIL PROTECTED]To: [EMAIL PROTECTED] e.net> cc: Sent by: Linux onSubject: Re: DB2 Connect Enterprise Edition for Linux/Zseries 390 Port <[EMAIL PROTECTED] IST.EDU> 03/04/03 01:58 PM Please respond to Linux on 390 Port Yes, the new DB2 8.1 code requires you to use a gui install "widget" on all platforms. On S/390, that means that you must have X-Windows code installed on your image, have the client running, and have an X-Windows server available on a PC or workstation. Of course a lot of workstation and PC based Linux distributions have this feature installed and enabled by default, so it's no big deal to have it as a requirement.on S/390 it's another matter. Dave Jones Sine Nomine Associates Houston - Original Message - From: "James Melin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, March 04, 2003 12:47 PM Subject: DB2 Connect Enterprise Edition for Linux/Zseries > I just got shipped the DB2 Connect EE for Z/Linux version 8.1. The manual > doesn't have a specific Linux 390 section, however I get teh following > error when I try to run the db2setup process. > > DBI1190I db2setup is preparing the DB2 Setup Wizard which will > guide you through the program setup process. Please > wait. > > > > The DISPLAY variable is not set properly. Ensure that the DISPLAY variable > is set properly and that permissions are set properly to open windows on > the display specified, then rerun the command. > nokomis:/opt/DB2_V81_CONEE_LNX390_NLV # > > It appears that it's gonna do something with x windows, for a gui client to > do the actual setup. The documentation I have doesn't mention doing an > export display etc. sort of thing. > > Anyone been here? The 7.2 Db2 Connect EE was shell based. >
Re: Red Hat 7.2 S/390
Richard, A better description of Red Hat's install package is that it does not include any of IBM's OCO modules. As a result, people who want to do an install that requires one of the OCO modules to get a network connection have to go through some additional work to make that happen. The latest installation kernel on the Red Hat site is 2.4.9-37. There should be current OCO modules for that available on IBM's DeveloperWorks site: http://www10.software.ibm.com/developerworks/opensource/linux390/special_oco _rh_2.4.shtml The RELEASE-NOTES file from Red Hat's FTP server has instructions on how to get the OCO modules integrated into the installation files. Mark Post -Original Message- From: Richard W. Lauck, Cornerstone Systems, Inc. [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 1:55 PM To: [EMAIL PROTECTED] Subject: Red Hat 7.2 S/390 Hello Ken, I wanted to run something past you.I heard RH 7.2 31 bit did not recognize the OSA card when going through the installation process.Is this your understanding. If so, you can't telnet into it for a console. I guess IBM has patches for this? I need 2.4.9-13.4 Kernel OSA patches. These look a bit old as IBM only appears to have back to 2.4.9-17. Any info appreciated. Richard W. Lauck Cornerstone Systems, Inc. Sr. Systems Programmer IBM Certified S/390 Parallel Sysplex Systems Programmer IBM Certified S/390 Parallel Sysplex Operator IBM Parallel Sysplex Top Gun (425)489-4579 Direct - Home Office (425)453-5166 x9024Voice Mail (425)486-4501 Home (888)505-4534 Pager
Re: DB2 Connect Enterprise Edition for Linux/Zseries
Dig into the distro a bit ... it may be nothing more than a bunch of RPMs. > -Original Message- > From: James Melin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 04, 2003 1:48 PM > To: [EMAIL PROTECTED] > Subject: DB2 Connect Enterprise Edition for Linux/Zseries > > > I just got shipped the DB2 Connect EE for Z/Linux version > 8.1. The manual > doesn't have a specific Linux 390 section, however I get teh following > error when I try to run the db2setup process. > > DBI1190I db2setup is preparing the DB2 Setup Wizard which will > guide you through the program setup process. Please > wait. > > > > The DISPLAY variable is not set properly. Ensure that the > DISPLAY variable > is set properly and that permissions are set properly to open > windows on > the display specified, then rerun the command. > nokomis:/opt/DB2_V81_CONEE_LNX390_NLV # > > It appears that it's gonna do something with x windows, for a > gui client to > do the actual setup. The documentation I have doesn't mention doing an > export display etc. sort of thing. > > Anyone been here? The 7.2 Db2 Connect EE was shell based. >
Re: DB2 Connect Enterprise Edition for Linux/Zseries
Some things to check: - Your sshd_config parms allows for X forwarding X11Forwarding yes - You're using ssh to access the system - echo $DISPLAY should show something like: localhost:10.0 - You have an X server running on your desktop Mark Post -Original Message- From: James Melin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 1:48 PM To: [EMAIL PROTECTED] Subject: DB2 Connect Enterprise Edition for Linux/Zseries I just got shipped the DB2 Connect EE for Z/Linux version 8.1. The manual doesn't have a specific Linux 390 section, however I get teh following error when I try to run the db2setup process. DBI1190I db2setup is preparing the DB2 Setup Wizard which will guide you through the program setup process. Please wait. The DISPLAY variable is not set properly. Ensure that the DISPLAY variable is set properly and that permissions are set properly to open windows on the display specified, then rerun the command. nokomis:/opt/DB2_V81_CONEE_LNX390_NLV # It appears that it's gonna do something with x windows, for a gui client to do the actual setup. The documentation I have doesn't mention doing an export display etc. sort of thing. Anyone been here? The 7.2 Db2 Connect EE was shell based.
Re: DB2 Connect Enterprise Edition for Linux/Zseries
Yes, the new DB2 8.1 code requires you to use a gui install "widget" on all platforms. On S/390, that means that you must have X-Windows code installed on your image, have the client running, and have an X-Windows server available on a PC or workstation. Of course a lot of workstation and PC based Linux distributions have this feature installed and enabled by default, so it's no big deal to have it as a requirement.on S/390 it's another matter. Dave Jones Sine Nomine Associates Houston - Original Message - From: "James Melin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, March 04, 2003 12:47 PM Subject: DB2 Connect Enterprise Edition for Linux/Zseries > I just got shipped the DB2 Connect EE for Z/Linux version 8.1. The manual > doesn't have a specific Linux 390 section, however I get teh following > error when I try to run the db2setup process. > > DBI1190I db2setup is preparing the DB2 Setup Wizard which will > guide you through the program setup process. Please > wait. > > > > The DISPLAY variable is not set properly. Ensure that the DISPLAY variable > is set properly and that permissions are set properly to open windows on > the display specified, then rerun the command. > nokomis:/opt/DB2_V81_CONEE_LNX390_NLV # > > It appears that it's gonna do something with x windows, for a gui client to > do the actual setup. The documentation I have doesn't mention doing an > export display etc. sort of thing. > > Anyone been here? The 7.2 Db2 Connect EE was shell based. >
Red Hat 7.2 S/390
Hello Ken, I wanted to run something past you.I heard RH 7.2 31 bit did not recognize the OSA card when going through the installation process.Is this your understanding. If so, you can't telnet into it for a console. I guess IBM has patches for this? I need 2.4.9-13.4 Kernel OSA patches. These look a bit old as IBM only appears to have back to 2.4.9-17. Any info appreciated. Richard W. Lauck Cornerstone Systems, Inc. Sr. Systems Programmer IBM Certified S/390 Parallel Sysplex Systems Programmer IBM Certified S/390 Parallel Sysplex Operator IBM Parallel Sysplex Top Gun (425)489-4579 Direct - Home Office (425)453-5166 x9024Voice Mail (425)486-4501 Home (888)505-4534 Pager
DB2 Connect Enterprise Edition for Linux/Zseries
I just got shipped the DB2 Connect EE for Z/Linux version 8.1. The manual doesn't have a specific Linux 390 section, however I get teh following error when I try to run the db2setup process. DBI1190I db2setup is preparing the DB2 Setup Wizard which will guide you through the program setup process. Please wait. The DISPLAY variable is not set properly. Ensure that the DISPLAY variable is set properly and that permissions are set properly to open windows on the display specified, then rerun the command. nokomis:/opt/DB2_V81_CONEE_LNX390_NLV # It appears that it's gonna do something with x windows, for a gui client to do the actual setup. The documentation I have doesn't mention doing an export display etc. sort of thing. Anyone been here? The 7.2 Db2 Connect EE was shell based.
Re: SNMP response
Neale, Type 3 Code 3, no one listening on that port. Port 1024 is not the usual SNMP port. Are you sure about the port number being used? I normally use 161. Regards, Jeff -- Jeffrey C Barnard Barnard Software, Inc. http://www.bsiopti.com Phone 407-323-4773 Fax 407-323-4775
Re: Gnome
Welcome to RPM. You could try this: cd /to/directory/with/RPMs rpm -Uvh --test gnome-* and see what's left over to be specified. :) Mark Post -Original Message- From: Kenneth Illingsworth [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 9:33 AM To: [EMAIL PROTECTED] Subject: Gnome I am running RH Linux v7.2 with one PHP/MySQL test application that has performed well. I was interested in installing the Gnome desktop. I elected to try and duplicate past success and tried to utilize Webmin to install the RPM files. However, I ran into a lot of dependency problems. Is there more of a cookbook approach to installing a desktop on this virtual server?
Re: SNMP response
On the linux side (port got closed) ... timeout ??? "Post, Mark K" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] com> cc: Sent by: Linux Subject: Re: SNMP response on 390 Port <[EMAIL PROTECTED] arist.edu> 03/04/2003 05:29 PM Please respond to Linux on 390 Port Neale, Firewall rules? Mark Post -Original Message- From: Ferguson, Neale [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 11:29 AM To: [EMAIL PROTECTED] Subject: SNMP response I am attempting to get ESATCP on zVM to retrieve SNMP information from a Linux guest. ESATCP complains that there is no response from the guest. A TCPDUMP shows the following: 17:11:20.317614 10.20.45.1.1024 > 10.20.45.159.snmp: C=velocity GetRequest(29) 25.1.1.0 4500 004a 30a1 3c11 df3a 0a14 2d01 0a14 2d9f 0400 00a1 0036 26e6 302c 0201 0004 0876 656c 6f63 6974 79a0 1d02 0401 020d 0002 0100 0201 0030 0f30 0d06 092b 0601 0201 1901 0100 0500 17:11:20.318741 10.20.45.159.snmp > 10.20.45.1.1024: C=velocity GetResponse(33) 25.1.1.0=76121297 (DF) 4500 004e f72e 4000 4011 d4a8 0a14 2d9f 0a14 2d01 00a1 0400 003a 5379 3030 0201 0004 0876 656c 6f63 6974 79a2 2102 0401 020d 0002 0100 0201 0030 1330 1106 092b 0601 0201 1901 0100 4304 0489 84d1 17:11:20.319258 10.20.45.1 > 10.20.45.159: icmp: 10.20.45.1 udp port 1024 unreachable 4500 0038 f72e 3c01 18cf 0a14 2d01 0a14 2d9f 0303 f821 4500 004e f72e 4000 4011 d4a8 0a14 2d9f 0a14 2d01 00a1 0400 003a What is causing the "port 1024 unreachable" error? - This message and its attachments may contain privileged and confidential information. If you are not the intended recipient(s), you are prohibited from printing, forwarding, saving or copying this email. If you have received this e-mail in error, please immediately notify the sender and delete this e-mail and its attachments from your computer.
Re: SNMP response
No firewall between guest and VM system - direct vCTC connection. -Original Message- Firewall rules?
Re: SNMP response
Neale, Firewall rules? Mark Post -Original Message- From: Ferguson, Neale [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 11:29 AM To: [EMAIL PROTECTED] Subject: SNMP response I am attempting to get ESATCP on zVM to retrieve SNMP information from a Linux guest. ESATCP complains that there is no response from the guest. A TCPDUMP shows the following: 17:11:20.317614 10.20.45.1.1024 > 10.20.45.159.snmp: C=velocity GetRequest(29) 25.1.1.0 4500 004a 30a1 3c11 df3a 0a14 2d01 0a14 2d9f 0400 00a1 0036 26e6 302c 0201 0004 0876 656c 6f63 6974 79a0 1d02 0401 020d 0002 0100 0201 0030 0f30 0d06 092b 0601 0201 1901 0100 0500 17:11:20.318741 10.20.45.159.snmp > 10.20.45.1.1024: C=velocity GetResponse(33) 25.1.1.0=76121297 (DF) 4500 004e f72e 4000 4011 d4a8 0a14 2d9f 0a14 2d01 00a1 0400 003a 5379 3030 0201 0004 0876 656c 6f63 6974 79a2 2102 0401 020d 0002 0100 0201 0030 1330 1106 092b 0601 0201 1901 0100 4304 0489 84d1 17:11:20.319258 10.20.45.1 > 10.20.45.159: icmp: 10.20.45.1 udp port 1024 unreachable 4500 0038 f72e 3c01 18cf 0a14 2d01 0a14 2d9f 0303 f821 4500 004e f72e 4000 4011 d4a8 0a14 2d9f 0a14 2d01 00a1 0400 003a What is causing the "port 1024 unreachable" error?
Re: I/O Error on Readonly Filesystem
Thanks Mark/Gordon. Hank -Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 11:20 AM To: [EMAIL PROTECTED] Subject: Re: I/O Error on Readonly Filesystem Hank, That should be lower case. I'll fix it. Mark -Original Message- From: Hank Calzaretta [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 12:10 PM To: [EMAIL PROTECTED] Subject: Re: I/O Error on Readonly Filesystem Gordon, Thanks for the response; the procedure reads: mount /usr -o ro,remount Sync;sync shutdown Can you explain the command "Sync;sync". I don't find a "Sync" (capitol) command. Thanks, Hank -Original Message- From: Wolfe, Gordon W [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 10:51 AM To: [EMAIL PROTECTED] Subject: Re: I/O Error on Readonly Filesystem This is a well-known problem in sharing r/o disks among VM linux images. The cure is a fairly simple one. Go to Mark Post's Linuxvm.org site to the SHARE presentations at http://linuxvm.org/present/ and look down for the San Francisco SHARE last August. My paper number 9341 has the answer on slide 16. At least, it cures this exact error for us! Hope this helps! They say there are three signs of stress in your life. You eat too much junk food, you drive too fast and you veg out in front of the TV. Who are they kidding? That sounds like a perfect day to me! Gordon Wolfe, Ph.D. (425)865-5940 VM & Linux Servers and Storage, The Boeing Company > -- > From: Post, Mark K > Reply To: Linux on 390 Port > Sent: Tuesday, March 4, 2003 6:18 AM > To: [EMAIL PROTECTED] > Subject: Re: I/O Error on Readonly Filesystem > > Hank, > > Is the owning system up and running with this file system mounted? > > Mark Post > > -Original Message- > From: Hank Calzaretta [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 04, 2003 8:53 AM > To: [EMAIL PROTECTED] > Subject: I/O Error on Readonly Filesystem > > > Hello, > > I am sharing the "/usr" (reiserfs) filesystem across several zVM Linux > Guests. All Linuxes are SuSE 2.4.7. I am seeing the following error > messages in "/var/log/messages": > > Mar 4 07:36:02 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev > 5e:09 (dasd), sector 1435352 Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: > end_request: I/O error, dev 5e:09 (dasd), sector 1444728 > Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1434880 > Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1435352 > Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1444728 > Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1434880 > Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1435352 > > > I interpret the 5e:09 as Major 94, Minor 9, which in my case is > "/dev/dasdc1". The contents of "/proc/dev/dasd/devices" follows: > > 0200(FBA ) at ( 94: 0) is dasda:active at blocksize: 512, 262144 > blocks, 128 MB > 0201(ECKD) at ( 94: 4) is dasdb:active at blocksize: 4096, 504000 > blocks, 1968 MB > 0202(ECKD) at ( 94: 8) is dasdc:active at blocksize: 4096, 256500 > blocks, 1001 MB(ro) > 0203(ECKD) at ( 94: 12) is dasdd:active at blocksize: 4096, 95040 > blocks, 371 MB > 0204(ECKD) at ( 94: 16) is dasde:active at blocksize: 4096, 600840 > blocks, 2347 MB > 0205(ECKD) at ( 94: 20) is dasdf:active at blocksize: 4096, 600840 > blocks, 2347 MB > 0206(ECKD) at ( 94: 24) is dasdg:active at blocksize: 4096, 600840 > blocks, 2347 MB > > > The contents of "/etc/fstab" follows: > > /dev/dasda1 swap swapdefaults 0 0 > /dev/dasdb1 / reiserfsdefaults 1 1 > /dev/dasdc1 /usr reiserfsro 0 0 > /dev/dasdd1 /usr/localreiserfsdefaults 1 2 > /dev/irgdatax/irv_datax /db/invret/data ext2defaults > 1 2 > /dev/irglogs/irv_logs /db/invret/logs ext2defaults > 1 2 > > > The contents of "zipl.conf" follows: > > parameters="dasd=0200,0201,0202(ro),0203-027F,0301-0303 > root=/dev/dasdb1 noinitrd" > > > The VM directory MDISK entry for the owning user follows: > > MDISK 202 3390 1426 1425 LN1516 RR ALL SOME FEW > > > The VM directory LINK entry for sharing users follows: > > LINK SYSSOFT2 202 202 RR > > > I ran "fsck" on the filesystem, the output follows: > > wcs-mf-winxs-db2p:~ # fsck /dev/dasdc1 > Parallelizing fsck version 1.19a (13-Jul-2000) > > <-reiserfsck, 2001-> > reiserfsprogs 3.x.0k-pre8> > > Will read-only check consistency of the partition > Will put log info to 'stdout' > Do you want to run this program?[N/Yes] (note need to type Yes):Yes > 12799k will be used ### reiserfsck --check started at Tue Mar > 4 07:48:07 2003 ### > Files
Re: I/O Error on Readonly Filesystem
Hank, Whoops, I spoke too soon. I was thinking of the HOWTO page, not the presentations. Gordon, If you want to update that slide and send me a new copy, I'll upload it. Mark Post -Original Message- From: Hank Calzaretta [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 12:10 PM To: [EMAIL PROTECTED] Subject: Re: I/O Error on Readonly Filesystem Gordon, Thanks for the response; the procedure reads: mount /usr -o ro,remount Sync;sync shutdown Can you explain the command "Sync;sync". I don't find a "Sync" (capitol) command. Thanks, Hank -Original Message- From: Wolfe, Gordon W [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 10:51 AM To: [EMAIL PROTECTED] Subject: Re: I/O Error on Readonly Filesystem This is a well-known problem in sharing r/o disks among VM linux images. The cure is a fairly simple one. Go to Mark Post's Linuxvm.org site to the SHARE presentations at http://linuxvm.org/present/ and look down for the San Francisco SHARE last August. My paper number 9341 has the answer on slide 16. At least, it cures this exact error for us! Hope this helps! They say there are three signs of stress in your life. You eat too much junk food, you drive too fast and you veg out in front of the TV. Who are they kidding? That sounds like a perfect day to me! Gordon Wolfe, Ph.D. (425)865-5940 VM & Linux Servers and Storage, The Boeing Company > -- > From: Post, Mark K > Reply To: Linux on 390 Port > Sent: Tuesday, March 4, 2003 6:18 AM > To: [EMAIL PROTECTED] > Subject: Re: I/O Error on Readonly Filesystem > > Hank, > > Is the owning system up and running with this file system mounted? > > Mark Post > > -Original Message- > From: Hank Calzaretta [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 04, 2003 8:53 AM > To: [EMAIL PROTECTED] > Subject: I/O Error on Readonly Filesystem > > > Hello, > > I am sharing the "/usr" (reiserfs) filesystem across several zVM Linux > Guests. All Linuxes are SuSE 2.4.7. I am seeing the following error > messages in "/var/log/messages": > > Mar 4 07:36:02 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev > 5e:09 (dasd), sector 1435352 Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: > end_request: I/O error, dev 5e:09 (dasd), sector 1444728 > Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1434880 > Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1435352 > Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1444728 > Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1434880 > Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1435352 > > > I interpret the 5e:09 as Major 94, Minor 9, which in my case is > "/dev/dasdc1". The contents of "/proc/dev/dasd/devices" follows: > > 0200(FBA ) at ( 94: 0) is dasda:active at blocksize: 512, 262144 > blocks, 128 MB > 0201(ECKD) at ( 94: 4) is dasdb:active at blocksize: 4096, 504000 > blocks, 1968 MB > 0202(ECKD) at ( 94: 8) is dasdc:active at blocksize: 4096, 256500 > blocks, 1001 MB(ro) > 0203(ECKD) at ( 94: 12) is dasdd:active at blocksize: 4096, 95040 > blocks, 371 MB > 0204(ECKD) at ( 94: 16) is dasde:active at blocksize: 4096, 600840 > blocks, 2347 MB > 0205(ECKD) at ( 94: 20) is dasdf:active at blocksize: 4096, 600840 > blocks, 2347 MB > 0206(ECKD) at ( 94: 24) is dasdg:active at blocksize: 4096, 600840 > blocks, 2347 MB > > > The contents of "/etc/fstab" follows: > > /dev/dasda1 swap swapdefaults 0 0 > /dev/dasdb1 / reiserfsdefaults 1 1 > /dev/dasdc1 /usr reiserfsro 0 0 > /dev/dasdd1 /usr/localreiserfsdefaults 1 2 > /dev/irgdatax/irv_datax /db/invret/data ext2defaults > 1 2 > /dev/irglogs/irv_logs /db/invret/logs ext2defaults > 1 2 > > > The contents of "zipl.conf" follows: > > parameters="dasd=0200,0201,0202(ro),0203-027F,0301-0303 > root=/dev/dasdb1 noinitrd" > > > The VM directory MDISK entry for the owning user follows: > > MDISK 202 3390 1426 1425 LN1516 RR ALL SOME FEW > > > The VM directory LINK entry for sharing users follows: > > LINK SYSSOFT2 202 202 RR > > > I ran "fsck" on the filesystem, the output follows: > > wcs-mf-winxs-db2p:~ # fsck /dev/dasdc1 > Parallelizing fsck version 1.19a (13-Jul-2000) > > <-reiserfsck, 2001-> > reiserfsprogs 3.x.0k-pre8> > > Will read-only check consistency of the partition > Will put log info to 'stdout' > Do you want to run this program?[N/Yes] (note need to type Yes):Yes > 12799k will be used ### > reiserfsck --check started at Tue Mar 4 07:48:07 2003 > ### > Filesystem seems mounted read-only. Skipping journal replay.. > Checking S+tree..
Re: I/O Error on Readonly Filesystem
Sorry. that's Powerpoint. It automatically capitalizes the first word of every line. It's all lowercase. sync just makes sure all the buffers have been written to disks. They say there are three signs of stress in your life. You eat too much junk food, you drive too fast and you veg out in front of the TV. Who are they kidding? That sounds like a perfect day to me! Gordon Wolfe, Ph.D. (425)865-5940 VM & Linux Servers and Storage, The Boeing Company > -- > From: Hank Calzaretta > Reply To: Linux on 390 Port > Sent: Tuesday, March 4, 2003 9:10 AM > To: [EMAIL PROTECTED] > Subject: Re: I/O Error on Readonly Filesystem > > Gordon, > > Thanks for the response; the procedure reads: > > mount /usr -o ro,remount > Sync;sync > shutdown > > Can you explain the command "Sync;sync". I don't find a "Sync" (capitol) > command. > > > Thanks, > Hank > > > > -Original Message- > From: Wolfe, Gordon W [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 04, 2003 10:51 AM > To: [EMAIL PROTECTED] > Subject: Re: I/O Error on Readonly Filesystem > > > This is a well-known problem in sharing r/o disks among VM linux images. > The cure is a fairly simple one. > > Go to Mark Post's Linuxvm.org site to the SHARE presentations at > http://linuxvm.org/present/ > > and look down for the San Francisco SHARE last August. My paper number 9341 > has the answer on slide 16. At least, it cures this exact error for us! > > Hope this helps! > > They say there are three signs of stress in your life. You eat too much > junk food, you drive too fast and you veg out in front of the TV. Who are > they kidding? That sounds like a perfect day to me! Gordon Wolfe, Ph.D. > (425)865-5940 VM & Linux Servers and Storage, The Boeing Company > > > -- > > From: Post, Mark K > > Reply To: Linux on 390 Port > > Sent: Tuesday, March 4, 2003 6:18 AM > > To: [EMAIL PROTECTED] > > Subject: Re: I/O Error on Readonly Filesystem > > > > Hank, > > > > Is the owning system up and running with this file system mounted? > > > > Mark Post > > > > -Original Message- > > From: Hank Calzaretta [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, March 04, 2003 8:53 AM > > To: [EMAIL PROTECTED] > > Subject: I/O Error on Readonly Filesystem > > > > > > Hello, > > > > I am sharing the "/usr" (reiserfs) filesystem across several zVM Linux > > Guests. All Linuxes are SuSE 2.4.7. I am seeing the following error > > messages in "/var/log/messages": > > > > Mar 4 07:36:02 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev > > 5e:09 (dasd), sector 1435352 Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: > > end_request: I/O error, dev 5e:09 (dasd), sector 1444728 > > Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev > 5e:09 > > (dasd), sector 1434880 > > Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev > 5e:09 > > (dasd), sector 1435352 > > Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev > 5e:09 > > (dasd), sector 1444728 > > Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev > 5e:09 > > (dasd), sector 1434880 > > Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev > 5e:09 > > (dasd), sector 1435352 > > > > > > I interpret the 5e:09 as Major 94, Minor 9, which in my case is > > "/dev/dasdc1". The contents of "/proc/dev/dasd/devices" follows: > > > > 0200(FBA ) at ( 94: 0) is dasda:active at blocksize: 512, 262144 > > blocks, 128 MB > > 0201(ECKD) at ( 94: 4) is dasdb:active at blocksize: 4096, 504000 > > blocks, 1968 MB > > 0202(ECKD) at ( 94: 8) is dasdc:active at blocksize: 4096, 256500 > > blocks, 1001 MB(ro) > > 0203(ECKD) at ( 94: 12) is dasdd:active at blocksize: 4096, 95040 > > blocks, 371 MB > > 0204(ECKD) at ( 94: 16) is dasde:active at blocksize: 4096, 600840 > > blocks, 2347 MB > > 0205(ECKD) at ( 94: 20) is dasdf:active at blocksize: 4096, 600840> > > blocks, 2347 MB > > 0206(ECKD) at ( 94: 24) is dasdg:active at blocksize: 4096, 600840 > > blocks, 2347 MB > > > > > > The contents of "/etc/fstab" follows: > > > > /dev/dasda1 swap swapdefaults 0 0 > > /dev/dasdb1 / reiserfsdefaults 1 1 > > /dev/dasdc1 /usr reiserfsro 0 0 > > /dev/dasdd1 /usr/localreiserfsdefaults 1 2 > > /dev/irgdatax/irv_datax /db/invret/data ext2defaults > > 1 2 > > /dev/irglogs/irv_logs /db/invret/logs ext2defaults > > 1 2 > > > > > > The contents of "zipl.conf" follows: > > > > parameters="dasd=0200,0201,0202(ro),0203-027F,0301-0303 > > root=/dev/dasdb1 noinitrd" > > > > > > The VM directory MDISK entry for the owning user follows: > > > > MDISK 202 3390 1426 1425 LN1516 RR ALL SOME FEW > > > > > > The VM directory LINK entry for sharing users follows: > > > > LINK SYSSOFT2 202 202 RR > > >
Re: I/O Error on Readonly Filesystem
Hank, That should be lower case. I'll fix it. Mark -Original Message- From: Hank Calzaretta [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 12:10 PM To: [EMAIL PROTECTED] Subject: Re: I/O Error on Readonly Filesystem Gordon, Thanks for the response; the procedure reads: mount /usr -o ro,remount Sync;sync shutdown Can you explain the command "Sync;sync". I don't find a "Sync" (capitol) command. Thanks, Hank -Original Message- From: Wolfe, Gordon W [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 10:51 AM To: [EMAIL PROTECTED] Subject: Re: I/O Error on Readonly Filesystem This is a well-known problem in sharing r/o disks among VM linux images. The cure is a fairly simple one. Go to Mark Post's Linuxvm.org site to the SHARE presentations at http://linuxvm.org/present/ and look down for the San Francisco SHARE last August. My paper number 9341 has the answer on slide 16. At least, it cures this exact error for us! Hope this helps! They say there are three signs of stress in your life. You eat too much junk food, you drive too fast and you veg out in front of the TV. Who are they kidding? That sounds like a perfect day to me! Gordon Wolfe, Ph.D. (425)865-5940 VM & Linux Servers and Storage, The Boeing Company > -- > From: Post, Mark K > Reply To: Linux on 390 Port > Sent: Tuesday, March 4, 2003 6:18 AM > To: [EMAIL PROTECTED] > Subject: Re: I/O Error on Readonly Filesystem > > Hank, > > Is the owning system up and running with this file system mounted? > > Mark Post > > -Original Message- > From: Hank Calzaretta [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 04, 2003 8:53 AM > To: [EMAIL PROTECTED] > Subject: I/O Error on Readonly Filesystem > > > Hello, > > I am sharing the "/usr" (reiserfs) filesystem across several zVM Linux > Guests. All Linuxes are SuSE 2.4.7. I am seeing the following error > messages in "/var/log/messages": > > Mar 4 07:36:02 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev > 5e:09 (dasd), sector 1435352 Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: > end_request: I/O error, dev 5e:09 (dasd), sector 1444728 > Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1434880 > Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1435352 > Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1444728 > Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1434880 > Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1435352 > > > I interpret the 5e:09 as Major 94, Minor 9, which in my case is > "/dev/dasdc1". The contents of "/proc/dev/dasd/devices" follows: > > 0200(FBA ) at ( 94: 0) is dasda:active at blocksize: 512, 262144 > blocks, 128 MB > 0201(ECKD) at ( 94: 4) is dasdb:active at blocksize: 4096, 504000 > blocks, 1968 MB > 0202(ECKD) at ( 94: 8) is dasdc:active at blocksize: 4096, 256500 > blocks, 1001 MB(ro) > 0203(ECKD) at ( 94: 12) is dasdd:active at blocksize: 4096, 95040 > blocks, 371 MB > 0204(ECKD) at ( 94: 16) is dasde:active at blocksize: 4096, 600840 > blocks, 2347 MB > 0205(ECKD) at ( 94: 20) is dasdf:active at blocksize: 4096, 600840 > blocks, 2347 MB > 0206(ECKD) at ( 94: 24) is dasdg:active at blocksize: 4096, 600840 > blocks, 2347 MB > > > The contents of "/etc/fstab" follows: > > /dev/dasda1 swap swapdefaults 0 0 > /dev/dasdb1 / reiserfsdefaults 1 1 > /dev/dasdc1 /usr reiserfsro 0 0 > /dev/dasdd1 /usr/localreiserfsdefaults 1 2 > /dev/irgdatax/irv_datax /db/invret/data ext2defaults > 1 2 > /dev/irglogs/irv_logs /db/invret/logs ext2defaults > 1 2 > > > The contents of "zipl.conf" follows: > > parameters="dasd=0200,0201,0202(ro),0203-027F,0301-0303 > root=/dev/dasdb1 noinitrd" > > > The VM directory MDISK entry for the owning user follows: > > MDISK 202 3390 1426 1425 LN1516 RR ALL SOME FEW > > > The VM directory LINK entry for sharing users follows: > > LINK SYSSOFT2 202 202 RR > > > I ran "fsck" on the filesystem, the output follows: > > wcs-mf-winxs-db2p:~ # fsck /dev/dasdc1 > Parallelizing fsck version 1.19a (13-Jul-2000) > > <-reiserfsck, 2001-> > reiserfsprogs 3.x.0k-pre8> > > Will read-only check consistency of the partition > Will put log info to 'stdout' > Do you want to run this program?[N/Yes] (note need to type Yes):Yes > 12799k will be used ### > reiserfsck --check started at Tue Mar 4 07:48:07 2003 > ### > Filesystem seems mounted read-only. Skipping journal replay.. > Checking S+tree..ok > Comparing bitmaps..ok > Checking Semantic tree...ok > No corruptions found > ### > reiserfsck finished at Tue Mar 4 0
Re: I/O Error on Readonly Filesystem
Gordon, Thanks for the response; the procedure reads: mount /usr -o ro,remount Sync;sync shutdown Can you explain the command "Sync;sync". I don't find a "Sync" (capitol) command. Thanks, Hank -Original Message- From: Wolfe, Gordon W [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 10:51 AM To: [EMAIL PROTECTED] Subject: Re: I/O Error on Readonly Filesystem This is a well-known problem in sharing r/o disks among VM linux images. The cure is a fairly simple one. Go to Mark Post's Linuxvm.org site to the SHARE presentations at http://linuxvm.org/present/ and look down for the San Francisco SHARE last August. My paper number 9341 has the answer on slide 16. At least, it cures this exact error for us! Hope this helps! They say there are three signs of stress in your life. You eat too much junk food, you drive too fast and you veg out in front of the TV. Who are they kidding? That sounds like a perfect day to me! Gordon Wolfe, Ph.D. (425)865-5940 VM & Linux Servers and Storage, The Boeing Company > -- > From: Post, Mark K > Reply To: Linux on 390 Port > Sent: Tuesday, March 4, 2003 6:18 AM > To: [EMAIL PROTECTED] > Subject: Re: I/O Error on Readonly Filesystem > > Hank, > > Is the owning system up and running with this file system mounted? > > Mark Post > > -Original Message- > From: Hank Calzaretta [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 04, 2003 8:53 AM > To: [EMAIL PROTECTED] > Subject: I/O Error on Readonly Filesystem > > > Hello, > > I am sharing the "/usr" (reiserfs) filesystem across several zVM Linux > Guests. All Linuxes are SuSE 2.4.7. I am seeing the following error > messages in "/var/log/messages": > > Mar 4 07:36:02 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev > 5e:09 (dasd), sector 1435352 Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: > end_request: I/O error, dev 5e:09 (dasd), sector 1444728 > Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1434880 > Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1435352 > Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1444728 > Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1434880 > Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1435352 > > > I interpret the 5e:09 as Major 94, Minor 9, which in my case is > "/dev/dasdc1". The contents of "/proc/dev/dasd/devices" follows: > > 0200(FBA ) at ( 94: 0) is dasda:active at blocksize: 512, 262144 > blocks, 128 MB > 0201(ECKD) at ( 94: 4) is dasdb:active at blocksize: 4096, 504000 > blocks, 1968 MB > 0202(ECKD) at ( 94: 8) is dasdc:active at blocksize: 4096, 256500 > blocks, 1001 MB(ro) > 0203(ECKD) at ( 94: 12) is dasdd:active at blocksize: 4096, 95040 > blocks, 371 MB > 0204(ECKD) at ( 94: 16) is dasde:active at blocksize: 4096, 600840 > blocks, 2347 MB > 0205(ECKD) at ( 94: 20) is dasdf:active at blocksize: 4096, 600840 > blocks, 2347 MB > 0206(ECKD) at ( 94: 24) is dasdg:active at blocksize: 4096, 600840 > blocks, 2347 MB > > > The contents of "/etc/fstab" follows: > > /dev/dasda1 swap swapdefaults 0 0 > /dev/dasdb1 / reiserfsdefaults 1 1 > /dev/dasdc1 /usr reiserfsro 0 0 > /dev/dasdd1 /usr/localreiserfsdefaults 1 2 > /dev/irgdatax/irv_datax /db/invret/data ext2defaults > 1 2 > /dev/irglogs/irv_logs /db/invret/logs ext2defaults > 1 2 > > > The contents of "zipl.conf" follows: > > parameters="dasd=0200,0201,0202(ro),0203-027F,0301-0303 > root=/dev/dasdb1 noinitrd" > > > The VM directory MDISK entry for the owning user follows: > > MDISK 202 3390 1426 1425 LN1516 RR ALL SOME FEW > > > The VM directory LINK entry for sharing users follows: > > LINK SYSSOFT2 202 202 RR > > > I ran "fsck" on the filesystem, the output follows: > > wcs-mf-winxs-db2p:~ # fsck /dev/dasdc1 > Parallelizing fsck version 1.19a (13-Jul-2000) > > <-reiserfsck, 2001-> > reiserfsprogs 3.x.0k-pre8> > > Will read-only check consistency of the partition > Will put log info to 'stdout' > Do you want to run this program?[N/Yes] (note need to type Yes):Yes > 12799k will be used ### > reiserfsck --check started at Tue Mar 4 07:48:07 2003 > ### > Filesystem seems mounted read-only. Skipping journal replay.. > Checking S+tree..ok > Comparing bitmaps..ok > Checking Semantic tree...ok > No corruptions found > ### > reiserfsck finished at Tue Mar 4 07:48:24 2003 > ### > > > Anyone have any ideas on how to resolve this? > > > Thanks, > > Hank Calzaretta > Wallace Computer Services, Inc. > >
Re: I/O Error on Readonly Filesystem
This is a well-known problem in sharing r/o disks among VM linux images. The cure is a fairly simple one. Go to Mark Post's Linuxvm.org site to the SHARE presentations at http://linuxvm.org/present/ and look down for the San Francisco SHARE last August. My paper number 9341 has the answer on slide 16. At least, it cures this exact error for us! Hope this helps! They say there are three signs of stress in your life. You eat too much junk food, you drive too fast and you veg out in front of the TV. Who are they kidding? That sounds like a perfect day to me! Gordon Wolfe, Ph.D. (425)865-5940 VM & Linux Servers and Storage, The Boeing Company > -- > From: Post, Mark K > Reply To: Linux on 390 Port > Sent: Tuesday, March 4, 2003 6:18 AM > To: [EMAIL PROTECTED] > Subject: Re: I/O Error on Readonly Filesystem > > Hank, > > Is the owning system up and running with this file system mounted? > > Mark Post > > -Original Message- > From: Hank Calzaretta [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 04, 2003 8:53 AM > To: [EMAIL PROTECTED] > Subject: I/O Error on Readonly Filesystem > > > Hello, > > I am sharing the "/usr" (reiserfs) filesystem across several zVM Linux > Guests. All Linuxes are SuSE 2.4.7. I am seeing the following error > messages in "/var/log/messages": > > Mar 4 07:36:02 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1435352 > Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1444728 > Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1434880 > Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1435352 > Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1444728 > Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1434880 > Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 > (dasd), sector 1435352 > > > I interpret the 5e:09 as Major 94, Minor 9, which in my case is > "/dev/dasdc1". The contents of "/proc/dev/dasd/devices" follows: > > 0200(FBA ) at ( 94: 0) is dasda:active at blocksize: 512, 262144 blocks, > 128 MB > 0201(ECKD) at ( 94: 4) is dasdb:active at blocksize: 4096, 504000 blocks, > 1968 MB > 0202(ECKD) at ( 94: 8) is dasdc:active at blocksize: 4096, 256500 blocks, > 1001 MB(ro) > 0203(ECKD) at ( 94: 12) is dasdd:active at blocksize: 4096, 95040 blocks, > 371 MB > 0204(ECKD) at ( 94: 16) is dasde:active at blocksize: 4096, 600840 blocks, > 2347 MB > 0205(ECKD) at ( 94: 20) is dasdf:active at blocksize: 4096, 600840 blocks, > 2347 MB > 0206(ECKD) at ( 94: 24) is dasdg:active at blocksize: 4096, 600840 blocks, > 2347 MB > > > The contents of "/etc/fstab" follows: > > /dev/dasda1 swap swapdefaults 0 0 > /dev/dasdb1 / reiserfsdefaults 1 1 > /dev/dasdc1 /usr reiserfsro 0 0 > /dev/dasdd1 /usr/localreiserfsdefaults 1 2 > /dev/irgdatax/irv_datax /db/invret/data ext2defaults > 1 2 > /dev/irglogs/irv_logs /db/invret/logs ext2defaults > 1 2 > > > The contents of "zipl.conf" follows: > > parameters="dasd=0200,0201,0202(ro),0203-027F,0301-0303 root=/dev/dasdb1 > noinitrd" > > > The VM directory MDISK entry for the owning user follows: > > MDISK 202 3390 1426 1425 LN1516 RR ALL SOME FEW > > > The VM directory LINK entry for sharing users follows: > > LINK SYSSOFT2 202 202 RR > > > I ran "fsck" on the filesystem, the output follows: > > wcs-mf-winxs-db2p:~ # fsck /dev/dasdc1 > Parallelizing fsck version 1.19a (13-Jul-2000) > > <-reiserfsck, 2001-> > reiserfsprogs 3.x.0k-pre8> > > Will read-only check consistency of the partition > Will put log info to 'stdout' > Do you want to run this program?[N/Yes] (note need to type Yes):Yes > 12799k will be used > ### > reiserfsck --check started at Tue Mar 4 07:48:07 2003 > ### > Filesystem seems mounted read-only. Skipping journal replay.. > Checking S+tree..ok > Comparing bitmaps..ok > Checking Semantic tree...ok > No corruptions found > ### > reiserfsck finished at Tue Mar 4 07:48:24 2003 > ### > > > Anyone have any ideas on how to resolve this? > > > Thanks, > > Hank Calzaretta > Wallace Computer Services, Inc. > >
Re: Send mail alert - is this old? Are there L/390 patches out yet?
sendmail.org Jon R. Doyle Sendmail Inc. 6425 Christie Ave Emeryville, Ca. 94608 (o_ (o_ (o_ //\ (/)_ (\)_ V_/_ On Tue, 4 Mar 2003, James Melin wrote: > |-+> > | | "Harrod, William"| > | | <[EMAIL PROTECTED]| > | | e.com> | > | || > | | 03/03/2003 02:17 | > | | PM | > | || > |-+> > > >--| > | > | > | To: "Harrod, William" <[EMAIL PROTECTED]> > | > | cc: > | > | Subject: TruSecure ALERT- TSA 03-002 - Sendmail Buffer Overflow -- ALERT > | > > >--| > > > > > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > TruSecure ALERT- TSA 03-002 - Sendmail Buffer Overflow -- ALERT > > Initial Assessment: Important > Date: February 14, 2003 > Time: 2000 UTC > Current Assessment: RED HOT > Date: March 3, 2003 > Time: 1700 UTC > > On February 14th a TruSecure Radar posting indicated that we were > aware of a potential vulnerability in Sendmail. Today, a coordinated > announcement was made regarding a Sendmail header buffer overflow > vulnerability. It is expected that code exploiting this > vulnerability is already in circulation and attacks will be likely in > the near future. > > Most installations of Unix include Sendmail by default and are > therefore probably vulnerable. > > This may impact an organization's infrastructure because many > firewalls and content filtering products contain Sendmail. > > It is recommended that customers who are using a firewall that > proxies mail, using Sendmail, implement packet filtering rules to > redirect mail through patched or non-Sendmail systems while > propagating fixes from their vendors. > > > RISK INDICIES: > > Current Assessment: RED HOT > > Threat: High - The vulnerability allows administrative access on an > exploited host. The exploit takes advantage of a fixed-sized buffer > used to process certain mail header fields, (To:, From:, CC:, Resent > From: and related comment fields.) > > Vulnerability Prevalence: High - Sendmail is installed by default on > most Unix systems and this exploit may impact critical infrastructure > devices as well as numerous devices without mail functionality, but > with Sendmail installed. > > TruSecure is aware that known malicious coders currently have exploit > code to work from. We expect simple exploits in the near term, and > more complex exploits including mail-based worms shortly thereafter. > > Cost: High - This exploit may provide administrative access on > vulnerable systems, including infrastructure devices. > > MITIGATIONS: > > 1. Re-routing mail from Sendmail devices to already patched > servers > or non-Sendmail systems while propagating patches. > > 2. Substitute other Message Transfer Agents for Sendmail in your > organization (Postfix, Qmail, Exim, Exchange...) > > 3. Patch vulnerable systems as quickly as possible. The > following > vendors have announced patch availability: Mandrake, SuSE, IBM, > FreeBSD, OpenBSD, SGI, Red Hat. > > NOTES: > 1. People using TruSecure Shadow Mail should be safe from this > attack > downstream. > > 2. There are reports that Sendmail servers downstream from > Patched > Sendmail systems may be protected from potential attacks. >
SNMP response
I am attempting to get ESATCP on zVM to retrieve SNMP information from a Linux guest. ESATCP complains that there is no response from the guest. A TCPDUMP shows the following: 17:11:20.317614 10.20.45.1.1024 > 10.20.45.159.snmp: C=velocity GetRequest(29) 25.1.1.0 4500 004a 30a1 3c11 df3a 0a14 2d01 0a14 2d9f 0400 00a1 0036 26e6 302c 0201 0004 0876 656c 6f63 6974 79a0 1d02 0401 020d 0002 0100 0201 0030 0f30 0d06 092b 0601 0201 1901 0100 0500 17:11:20.318741 10.20.45.159.snmp > 10.20.45.1.1024: C=velocity GetResponse(33) 25.1.1.0=76121297 (DF) 4500 004e f72e 4000 4011 d4a8 0a14 2d9f 0a14 2d01 00a1 0400 003a 5379 3030 0201 0004 0876 656c 6f63 6974 79a2 2102 0401 020d 0002 0100 0201 0030 1330 1106 092b 0601 0201 1901 0100 4304 0489 84d1 17:11:20.319258 10.20.45.1 > 10.20.45.159: icmp: 10.20.45.1 udp port 1024 unreachable 4500 0038 f72e 3c01 18cf 0a14 2d01 0a14 2d9f 0303 f821 4500 004e f72e 4000 4011 d4a8 0a14 2d9f 0a14 2d01 00a1 0400 003a What is causing the "port 1024 unreachable" error?
Gnome
I am running RH Linux v7.2 with one PHP/MySQL test application that has performed well. I was interested in installing the Gnome desktop. I elected to try and duplicate past success and tried to utilize Webmin to install the RPM files. However, I ran into a lot of dependency problems. Is there more of a cookbook approach to installing a desktop on this virtual server?
Re: Send mail alert - is this old? Are there L/390 patches out ye t?
I'm not running it either, however I can see some point at which a PHB type will ask me to run it and I'd rather fill the divot now. |-+> | | "Post, Mark K" | | | <[EMAIL PROTECTED]| | | m> | | | Sent by: Linux on| | | 390 Port | | | <[EMAIL PROTECTED]| | | IST.EDU> | | || | || | | 03/04/2003 08:49 | | | AM | | | Please respond to| | | Linux on 390 Port| | || |-+> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Send mail alert - is this old? Are there L/390 patches out ye t? | >--| Jim, No, this is not an old alert. If you're running sendmail, you should upgrade. I don't know if there are Linux/390 packages available yet or not, since I'm not running sendmail. Mark Post -Original Message- From: James Melin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 9:17 AM To: [EMAIL PROTECTED] Subject: Send mail alert - is this old? Are there L/390 patches out yet? |-+> | | "Harrod, William"| | | <[EMAIL PROTECTED]| | | e.com> | | || | | 03/03/2003 02:17 | | | PM | | || |-+> > --- ---| | | | To: "Harrod, William" <[EMAIL PROTECTED]> | | cc: | | Subject: TruSecure ALERT- TSA 03-002 - Sendmail Buffer Overflow -- ALERT | > --- ---| -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 TruSecure ALERT- TSA 03-002 - Sendmail Buffer Overflow -- ALERT Initial Assessment: Important Date: February 14, 2003 Time: 2000 UTC Current Assessment: RED HOT Date: March 3, 2003 Time: 1700 UTC On February 14th a TruSecure Radar posting indicated that we were aware of a potential vulnerability in Sendmail. Today, a coordinated announcement was made regarding a Sendmail header buffer overflow vulnerability. It is expected that code exploiting this vulnerability is already in circulation and attacks will be likely in the near future. Most installations of Unix include Sendmail by default and are therefore probably vulnerable. This may impact an organization's infrastructure because many firewalls and content filtering products contain Sendmail. It is recommended that customers who are using a firewall that proxies mail, using Sendmail, implement packet filtering rules to redirect mail through patched or non-Sendmail systems while propagating fixes from their vendors. RISK INDICIES: Current Assessment: RED HOT Threat: High - The vulnerability allows administrative access on an exploited host. The exploit takes advantage of a fixed-sized buffer used to process certain mail header fields, (To:, From:, CC:, Resent From: and related comment fields.) Vulnerability Prevalence: High - Sendmail is installed by default on most Unix systems and this exploit may impact critical infrastructure devices as well as numerous devices without mail functionality, but with Sendmail installed. TruSecure is aware that known malicious coders currently have exploit code to work from. We expect simple exploits in the near term, and more complex exploits including mail-based worms shortly thereafter. Cost: High - This exploit may provide administrative access on vulnerable systems, including infrastructure devices. MITIGATIONS: 1. Re-routing mail from Sendmail devices to already patched servers or non-Sendmail systems while propagating patches. 2. Substitute other Message Transfer Agents for Sendmail in your organization (Postfix, Qmail, Exim, Exchange...) 3
Re: Send mail alert - is this old? Are there L/390 patches out ye t?
Jim, No, this is not an old alert. If you're running sendmail, you should upgrade. I don't know if there are Linux/390 packages available yet or not, since I'm not running sendmail. Mark Post -Original Message- From: James Melin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 9:17 AM To: [EMAIL PROTECTED] Subject: Send mail alert - is this old? Are there L/390 patches out yet? |-+> | | "Harrod, William"| | | <[EMAIL PROTECTED]| | | e.com> | | || | | 03/03/2003 02:17 | | | PM | | || |-+> >--- ---| | | | To: "Harrod, William" <[EMAIL PROTECTED]> | | cc: | | Subject: TruSecure ALERT- TSA 03-002 - Sendmail Buffer Overflow -- ALERT | >--- ---| -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 TruSecure ALERT- TSA 03-002 - Sendmail Buffer Overflow -- ALERT Initial Assessment: Important Date: February 14, 2003 Time: 2000 UTC Current Assessment: RED HOT Date: March 3, 2003 Time: 1700 UTC On February 14th a TruSecure Radar posting indicated that we were aware of a potential vulnerability in Sendmail. Today, a coordinated announcement was made regarding a Sendmail header buffer overflow vulnerability. It is expected that code exploiting this vulnerability is already in circulation and attacks will be likely in the near future. Most installations of Unix include Sendmail by default and are therefore probably vulnerable. This may impact an organization's infrastructure because many firewalls and content filtering products contain Sendmail. It is recommended that customers who are using a firewall that proxies mail, using Sendmail, implement packet filtering rules to redirect mail through patched or non-Sendmail systems while propagating fixes from their vendors. RISK INDICIES: Current Assessment: RED HOT Threat: High - The vulnerability allows administrative access on an exploited host. The exploit takes advantage of a fixed-sized buffer used to process certain mail header fields, (To:, From:, CC:, Resent From: and related comment fields.) Vulnerability Prevalence: High - Sendmail is installed by default on most Unix systems and this exploit may impact critical infrastructure devices as well as numerous devices without mail functionality, but with Sendmail installed. TruSecure is aware that known malicious coders currently have exploit code to work from. We expect simple exploits in the near term, and more complex exploits including mail-based worms shortly thereafter. Cost: High - This exploit may provide administrative access on vulnerable systems, including infrastructure devices. MITIGATIONS: 1. Re-routing mail from Sendmail devices to already patched servers or non-Sendmail systems while propagating patches. 2. Substitute other Message Transfer Agents for Sendmail in your organization (Postfix, Qmail, Exim, Exchange...) 3. Patch vulnerable systems as quickly as possible. The following vendors have announced patch availability: Mandrake, SuSE, IBM, FreeBSD, OpenBSD, SGI, Red Hat. NOTES: 1. People using TruSecure Shadow Mail should be safe from this attack downstream. 2. There are reports that Sendmail servers downstream from Patched Sendmail systems may be protected from potential attacks.
Re: I/O Error on Readonly Filesystem
Hank, No, don't do that. I was going to tell you to take it down. Mark -Original Message- From: Hank Calzaretta [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 9:27 AM To: [EMAIL PROTECTED] Subject: Re: I/O Error on Readonly Filesystem Mark, No, it is not, but I can bring it up. Thanks, Hank -Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 8:19 AM To: [EMAIL PROTECTED] Subject: Re: I/O Error on Readonly Filesystem Hank, Is the owning system up and running with this file system mounted? Mark Post -Original Message- From: Hank Calzaretta [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 8:53 AM To: [EMAIL PROTECTED] Subject: I/O Error on Readonly Filesystem Hello, I am sharing the "/usr" (reiserfs) filesystem across several zVM Linux Guests. All Linuxes are SuSE 2.4.7. I am seeing the following error messages in "/var/log/messages": Mar 4 07:36:02 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1435352 Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1444728 Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1434880 Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1435352 Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1444728 Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1434880 Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1435352 I interpret the 5e:09 as Major 94, Minor 9, which in my case is "/dev/dasdc1". The contents of "/proc/dev/dasd/devices" follows: 0200(FBA ) at ( 94: 0) is dasda:active at blocksize: 512, 262144 blocks, 128 MB 0201(ECKD) at ( 94: 4) is dasdb:active at blocksize: 4096, 504000 blocks, 1968 MB 0202(ECKD) at ( 94: 8) is dasdc:active at blocksize: 4096, 256500 blocks, 1001 MB(ro) 0203(ECKD) at ( 94: 12) is dasdd:active at blocksize: 4096, 95040 blocks, 371 MB 0204(ECKD) at ( 94: 16) is dasde:active at blocksize: 4096, 600840 blocks, 2347 MB 0205(ECKD) at ( 94: 20) is dasdf:active at blocksize: 4096, 600840 blocks, 2347 MB 0206(ECKD) at ( 94: 24) is dasdg:active at blocksize: 4096, 600840 blocks, 2347 MB The contents of "/etc/fstab" follows: /dev/dasda1 swap swapdefaults 0 0 /dev/dasdb1 / reiserfsdefaults 1 1 /dev/dasdc1 /usr reiserfsro 0 0 /dev/dasdd1 /usr/localreiserfsdefaults 1 2 /dev/irgdatax/irv_datax /db/invret/data ext2defaults 1 2 /dev/irglogs/irv_logs /db/invret/logs ext2defaults 1 2 The contents of "zipl.conf" follows: parameters="dasd=0200,0201,0202(ro),0203-027F,0301-0303 root=/dev/dasdb1 noinitrd" The VM directory MDISK entry for the owning user follows: MDISK 202 3390 1426 1425 LN1516 RR ALL SOME FEW The VM directory LINK entry for sharing users follows: LINK SYSSOFT2 202 202 RR I ran "fsck" on the filesystem, the output follows: wcs-mf-winxs-db2p:~ # fsck /dev/dasdc1 Parallelizing fsck version 1.19a (13-Jul-2000) <-reiserfsck, 2001-> reiserfsprogs 3.x.0k-pre8 Will read-only check consistency of the partition Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes):Yes 12799k will be used ### reiserfsck --check started at Tue Mar 4 07:48:07 2003 ### Filesystem seems mounted read-only. Skipping journal replay.. Checking S+tree..ok Comparing bitmaps..ok Checking Semantic tree...ok No corruptions found ### reiserfsck finished at Tue Mar 4 07:48:24 2003 ### Anyone have any ideas on how to resolve this? Thanks, Hank Calzaretta Wallace Computer Services, Inc.
Re: I/O Error on Readonly Filesystem
Mark, No, it is not, but I can bring it up. Thanks, Hank -Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 8:19 AM To: [EMAIL PROTECTED] Subject: Re: I/O Error on Readonly Filesystem Hank, Is the owning system up and running with this file system mounted? Mark Post -Original Message- From: Hank Calzaretta [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 8:53 AM To: [EMAIL PROTECTED] Subject: I/O Error on Readonly Filesystem Hello, I am sharing the "/usr" (reiserfs) filesystem across several zVM Linux Guests. All Linuxes are SuSE 2.4.7. I am seeing the following error messages in "/var/log/messages": Mar 4 07:36:02 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1435352 Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1444728 Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1434880 Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1435352 Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1444728 Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1434880 Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1435352 I interpret the 5e:09 as Major 94, Minor 9, which in my case is "/dev/dasdc1". The contents of "/proc/dev/dasd/devices" follows: 0200(FBA ) at ( 94: 0) is dasda:active at blocksize: 512, 262144 blocks, 128 MB 0201(ECKD) at ( 94: 4) is dasdb:active at blocksize: 4096, 504000 blocks, 1968 MB 0202(ECKD) at ( 94: 8) is dasdc:active at blocksize: 4096, 256500 blocks, 1001 MB(ro) 0203(ECKD) at ( 94: 12) is dasdd:active at blocksize: 4096, 95040 blocks, 371 MB 0204(ECKD) at ( 94: 16) is dasde:active at blocksize: 4096, 600840 blocks, 2347 MB 0205(ECKD) at ( 94: 20) is dasdf:active at blocksize: 4096, 600840 blocks, 2347 MB 0206(ECKD) at ( 94: 24) is dasdg:active at blocksize: 4096, 600840 blocks, 2347 MB The contents of "/etc/fstab" follows: /dev/dasda1 swap swapdefaults 0 0 /dev/dasdb1 / reiserfsdefaults 1 1 /dev/dasdc1 /usr reiserfsro 0 0 /dev/dasdd1 /usr/localreiserfsdefaults 1 2 /dev/irgdatax/irv_datax /db/invret/data ext2defaults 1 2 /dev/irglogs/irv_logs /db/invret/logs ext2defaults 1 2 The contents of "zipl.conf" follows: parameters="dasd=0200,0201,0202(ro),0203-027F,0301-0303 root=/dev/dasdb1 noinitrd" The VM directory MDISK entry for the owning user follows: MDISK 202 3390 1426 1425 LN1516 RR ALL SOME FEW The VM directory LINK entry for sharing users follows: LINK SYSSOFT2 202 202 RR I ran "fsck" on the filesystem, the output follows: wcs-mf-winxs-db2p:~ # fsck /dev/dasdc1 Parallelizing fsck version 1.19a (13-Jul-2000) <-reiserfsck, 2001-> reiserfsprogs 3.x.0k-pre8 Will read-only check consistency of the partition Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes):Yes 12799k will be used ### reiserfsck --check started at Tue Mar 4 07:48:07 2003 ### Filesystem seems mounted read-only. Skipping journal replay.. Checking S+tree..ok Comparing bitmaps..ok Checking Semantic tree...ok No corruptions found ### reiserfsck finished at Tue Mar 4 07:48:24 2003 ### Anyone have any ideas on how to resolve this? Thanks, Hank Calzaretta Wallace Computer Services, Inc.
Re: I/O Error on Readonly Filesystem
Hank, Is the owning system up and running with this file system mounted? Mark Post -Original Message- From: Hank Calzaretta [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 8:53 AM To: [EMAIL PROTECTED] Subject: I/O Error on Readonly Filesystem Hello, I am sharing the "/usr" (reiserfs) filesystem across several zVM Linux Guests. All Linuxes are SuSE 2.4.7. I am seeing the following error messages in "/var/log/messages": Mar 4 07:36:02 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1435352 Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1444728 Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1434880 Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1435352 Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1444728 Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1434880 Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1435352 I interpret the 5e:09 as Major 94, Minor 9, which in my case is "/dev/dasdc1". The contents of "/proc/dev/dasd/devices" follows: 0200(FBA ) at ( 94: 0) is dasda:active at blocksize: 512, 262144 blocks, 128 MB 0201(ECKD) at ( 94: 4) is dasdb:active at blocksize: 4096, 504000 blocks, 1968 MB 0202(ECKD) at ( 94: 8) is dasdc:active at blocksize: 4096, 256500 blocks, 1001 MB(ro) 0203(ECKD) at ( 94: 12) is dasdd:active at blocksize: 4096, 95040 blocks, 371 MB 0204(ECKD) at ( 94: 16) is dasde:active at blocksize: 4096, 600840 blocks, 2347 MB 0205(ECKD) at ( 94: 20) is dasdf:active at blocksize: 4096, 600840 blocks, 2347 MB 0206(ECKD) at ( 94: 24) is dasdg:active at blocksize: 4096, 600840 blocks, 2347 MB The contents of "/etc/fstab" follows: /dev/dasda1 swap swapdefaults 0 0 /dev/dasdb1 / reiserfsdefaults 1 1 /dev/dasdc1 /usr reiserfsro 0 0 /dev/dasdd1 /usr/localreiserfsdefaults 1 2 /dev/irgdatax/irv_datax /db/invret/data ext2defaults 1 2 /dev/irglogs/irv_logs /db/invret/logs ext2defaults 1 2 The contents of "zipl.conf" follows: parameters="dasd=0200,0201,0202(ro),0203-027F,0301-0303 root=/dev/dasdb1 noinitrd" The VM directory MDISK entry for the owning user follows: MDISK 202 3390 1426 1425 LN1516 RR ALL SOME FEW The VM directory LINK entry for sharing users follows: LINK SYSSOFT2 202 202 RR I ran "fsck" on the filesystem, the output follows: wcs-mf-winxs-db2p:~ # fsck /dev/dasdc1 Parallelizing fsck version 1.19a (13-Jul-2000) <-reiserfsck, 2001-> reiserfsprogs 3.x.0k-pre8 Will read-only check consistency of the partition Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes):Yes 12799k will be used ### reiserfsck --check started at Tue Mar 4 07:48:07 2003 ### Filesystem seems mounted read-only. Skipping journal replay.. Checking S+tree..ok Comparing bitmaps..ok Checking Semantic tree...ok No corruptions found ### reiserfsck finished at Tue Mar 4 07:48:24 2003 ### Anyone have any ideas on how to resolve this? Thanks, Hank Calzaretta Wallace Computer Services, Inc.
Send mail alert - is this old? Are there L/390 patches out yet?
|-+> | | "Harrod, William"| | | <[EMAIL PROTECTED]| | | e.com> | | || | | 03/03/2003 02:17 | | | PM | | || |-+> >--| | | | To: "Harrod, William" <[EMAIL PROTECTED]> | | cc: | | Subject: TruSecure ALERT- TSA 03-002 - Sendmail Buffer Overflow -- ALERT | >--| -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 TruSecure ALERT- TSA 03-002 - Sendmail Buffer Overflow -- ALERT Initial Assessment: Important Date: February 14, 2003 Time: 2000 UTC Current Assessment: RED HOT Date: March 3, 2003 Time: 1700 UTC On February 14th a TruSecure Radar posting indicated that we were aware of a potential vulnerability in Sendmail. Today, a coordinated announcement was made regarding a Sendmail header buffer overflow vulnerability. It is expected that code exploiting this vulnerability is already in circulation and attacks will be likely in the near future. Most installations of Unix include Sendmail by default and are therefore probably vulnerable. This may impact an organization's infrastructure because many firewalls and content filtering products contain Sendmail. It is recommended that customers who are using a firewall that proxies mail, using Sendmail, implement packet filtering rules to redirect mail through patched or non-Sendmail systems while propagating fixes from their vendors. RISK INDICIES: Current Assessment: RED HOT Threat: High - The vulnerability allows administrative access on an exploited host. The exploit takes advantage of a fixed-sized buffer used to process certain mail header fields, (To:, From:, CC:, Resent From: and related comment fields.) Vulnerability Prevalence: High - Sendmail is installed by default on most Unix systems and this exploit may impact critical infrastructure devices as well as numerous devices without mail functionality, but with Sendmail installed. TruSecure is aware that known malicious coders currently have exploit code to work from. We expect simple exploits in the near term, and more complex exploits including mail-based worms shortly thereafter. Cost: High - This exploit may provide administrative access on vulnerable systems, including infrastructure devices. MITIGATIONS: 1. Re-routing mail from Sendmail devices to already patched servers or non-Sendmail systems while propagating patches. 2. Substitute other Message Transfer Agents for Sendmail in your organization (Postfix, Qmail, Exim, Exchange...) 3. Patch vulnerable systems as quickly as possible. The following vendors have announced patch availability: Mandrake, SuSE, IBM, FreeBSD, OpenBSD, SGI, Red Hat. NOTES: 1. People using TruSecure Shadow Mail should be safe from this attack downstream. 2. There are reports that Sendmail servers downstream from Patched Sendmail systems may be protected from potential attacks.
I/O Error on Readonly Filesystem
Hello, I am sharing the "/usr" (reiserfs) filesystem across several zVM Linux Guests. All Linuxes are SuSE 2.4.7. I am seeing the following error messages in "/var/log/messages": Mar 4 07:36:02 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1435352 Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1444728 Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1434880 Mar 4 07:36:07 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1435352 Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1444728 Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1434880 Mar 4 07:37:22 wcs-mf-winxs-db2p kernel: end_request: I/O error, dev 5e:09 (dasd), sector 1435352 I interpret the 5e:09 as Major 94, Minor 9, which in my case is "/dev/dasdc1". The contents of "/proc/dev/dasd/devices" follows: 0200(FBA ) at ( 94: 0) is dasda:active at blocksize: 512, 262144 blocks, 128 MB 0201(ECKD) at ( 94: 4) is dasdb:active at blocksize: 4096, 504000 blocks, 1968 MB 0202(ECKD) at ( 94: 8) is dasdc:active at blocksize: 4096, 256500 blocks, 1001 MB(ro) 0203(ECKD) at ( 94: 12) is dasdd:active at blocksize: 4096, 95040 blocks, 371 MB 0204(ECKD) at ( 94: 16) is dasde:active at blocksize: 4096, 600840 blocks, 2347 MB 0205(ECKD) at ( 94: 20) is dasdf:active at blocksize: 4096, 600840 blocks, 2347 MB 0206(ECKD) at ( 94: 24) is dasdg:active at blocksize: 4096, 600840 blocks, 2347 MB The contents of "/etc/fstab" follows: /dev/dasda1 swap swapdefaults 0 0 /dev/dasdb1 / reiserfsdefaults 1 1 /dev/dasdc1 /usr reiserfsro 0 0 /dev/dasdd1 /usr/localreiserfsdefaults 1 2 /dev/irgdatax/irv_datax /db/invret/data ext2defaults 1 2 /dev/irglogs/irv_logs /db/invret/logs ext2defaults 1 2 The contents of "zipl.conf" follows: parameters="dasd=0200,0201,0202(ro),0203-027F,0301-0303 root=/dev/dasdb1 noinitrd" The VM directory MDISK entry for the owning user follows: MDISK 202 3390 1426 1425 LN1516 RR ALL SOME FEW The VM directory LINK entry for sharing users follows: LINK SYSSOFT2 202 202 RR I ran "fsck" on the filesystem, the output follows: wcs-mf-winxs-db2p:~ # fsck /dev/dasdc1 Parallelizing fsck version 1.19a (13-Jul-2000) <-reiserfsck, 2001-> reiserfsprogs 3.x.0k-pre8 Will read-only check consistency of the partition Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes):Yes 12799k will be used ### reiserfsck --check started at Tue Mar 4 07:48:07 2003 ### Filesystem seems mounted read-only. Skipping journal replay.. Checking S+tree..ok Comparing bitmaps..ok Checking Semantic tree...ok No corruptions found ### reiserfsck finished at Tue Mar 4 07:48:24 2003 ### Anyone have any ideas on how to resolve this? Thanks, Hank Calzaretta Wallace Computer Services, Inc.
Re: FW: [slackware-security] Sendmail buffer overflow fixed
On Tue, 2003-03-04 at 03:16, John Summerfield wrote: > > Another security alert. Anyone running sendmail should upgrade or apply the > > patch from the URL below. The sendmail web page describes this as a > > "critical security problem." > > Yeah, can let your sytem get rooted in the least vulgar way. > > Red Hat also has fixed packages. They were built a few days ago, but there seems to > have been some delay in their getting to my preferred mirror;-(. Security organisations tend to keep stuff secret where it isnt publically known so that all the vendors can test/release packages at the same point.
Re: File system size limitations
On Tue, 2003-03-04 at 03:21, Ferguson, Neale wrote: > I could swear this came up recently, but of course I can find no reference > to > it. What are the file and file system size limitations for the 2.4 kernel? > Do dofferent levels of the 2.4 kernel change this? Does any of this change > based on the type of file system used (ext2, ext3, reiser)? The block layer has a 1 or 2Tb limit on Linux 2.4. The file systems have their own limits depending on block size/layout etc.
Re: File system size limitations
Rich Smrcina <[EMAIL PROTECTED]> writes: > I could swear this came up recently, but of course I can find no reference to > it. What are the file and file system size limitations for the 2.4 kernel? > Do dofferent levels of the 2.4 kernel change this? Does any of this change > based on the type of file system used (ext2, ext3, reiser)? from http://www.suse.de/~aj/linux_lfs.html: +-+ |Background LFS in Linux Background | |-| | | | Large File Support in Linux | | | ...[extensive information for Kernels back to 2.2 and glibc back to 2.1 and for all filesystems and many distributions] | Some Other Often Requested Data about Filesystems | | | | Maximum On-Disk Sizes of the Filesystems | | | | +-+ | | |Filesystem| File Size | Filesystem | | | | | Limit| Size Limit | | | |--++-| | | |ext2 with 1 KiB blocksize |16448 MiB (~|2048 GiB (= 2| | | | |16 GiB) |TiB) | | | |--++-| | | |ext2 with 2 KiB blocksize |256 GiB |8192 GiB (= 8| | | | ||TiB) | | | |--++-| | | |ext2 with 4 KiB blocksize |2048 GiB (= |16384 GiB (= | | | | |2 TiB) |16 TiB) | | | |--++-| | | |ext2 with 8 KiB blocksize (Systems with 8 |65568 GiB (~|32768 GiB (= | | | |KiB pages like Alpha only)|64 TiB) |32 TiB) | | | |--++-| | | |ReiserFS 3.5 |4 GiB |16384 GiB (= | | | | ||16 TiB) | | | |--++-| | | |ReiserFS 3.6 (as in Linux 2.4)|1 EiB |16384 GiB (= | | | | ||16 TiB) | | | |--++-| | | |XFS |8 EiB |8 EiB| | | |--++-| | | |JFS with 512 Bytes blocksize |8 EiB |512 TiB | | | |--++-| | | |JFS with 4KiB blocksize |8 EiB |4 PiB| | | |--++-| | | |NFSv2 (client side) |2 GiB |8 EiB| | | |--++-| | | |NFSv3 (client side) |8 EiB |8 EiB| | | +-+ | | | | Note Kernel Limitations: The table above describes limitations of the | | on-disk format. The following kernel limits exist:| | | | * On 32-bit systems with Kernel 2.4.x: The size of a file and a block | | device is limited to 2 TiB. By using LVM several block devices can| | be combined enabling the handling of larger file systems. | | * 32-bit systems starting with around 2.5.43: The size of a file is | | limited to 2 TiB. Note that the system call statfs64 does not give| | the correct information back for file systems using more than 2 TiB | | (df will display wrong results). | | * 64-bit systems: The sizes of a filesytem and of a file are limited| | by 263 (8 EiB). But there might be hardware driver limits that do | | not allow to access such large devices. | |
