This was the last attempt on installing from this script which resides
on another Linux guest under a production z/VM 5.4 system on a layer 3
network.
My thought is to try a different method of install but the Linux folks
won't hear of it.
The first phase to runs, but still failing on the second phase.
Below are the console messages leading up to the failure and the VNC
connection error.
Enabling syn flood protection..done
Disabling IP forwarding..done
Disabling IPv6 forwarding..done
Enabling IPv6 autoconfig..done
Disabling IPv6 privacy..done
..done
System Boot Control: The system has been set up
System Boot Control: Running /etc/init.d/boot.local
[1A..doneStarting syslog services..done
Starting D-BUS daemon..done
Starting HAL daemon..done
Setting up network interfaces:
lo
lo IP address: 127.0.0.1/8
Checking for network time protocol daemon (NTPD): ..unused
Can't determine current runlevel
[1A..doneWaiting for mandatory devices: eth-id-02:00:51:50:00:00
__NSC__
19 18 17 16 15 14 13 12 11 10 9 8 7 6 4 3 2 1 0
eth-id-02:00:51:50:00:00 No interface found
[1A..failedSetting up service network . . . . . . . . . . .
. . .
. ...failed
ip_tables: (C) 2000-2006 Netfilter Core Team
MORE...
SANDBOX
Jul 1 16:46:08 linux kernel: ip_tables: (C) 2000-2006 Netfilter Core
Team
***
*** Please return to your X-Server screen to finish installation
***
starting VNC server...
A log file will be written to: /var/log/YaST2/vncserver.log ...
***
*** You can connect to , display :1 now with vncviewer
*** Or use a Java capable browser on http://:5801/
***
(When YaST2 is finished, close your VNC viewer and return to this
window.)
*** Fatal Error occured, process stopped ***
- Commandline available at <Alt-F2>
- Further information written to:
/var/log/YaST2/y2start.log
Russell Gendreau
Time Customer Service, Inc.
813-554-2064
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[email protected]] On
Behalf Of Tom Duerbusch
Sent: Friday, June 26, 2009 4:22 PM
To: [email protected]
Subject: Re: Linux install on a z/VM 1st level with an OSA defined as
layer 2 network
No real trick to it.
First, make sure you have everything setup properly on the FTP server.
On the same VM as your FTP server, log on to CMS, and try a FTP.
This makes sure your FTP server is setup properly.
Then, on the same VM as you are doing the Linux install, logon to CMS
and try the FTP.
If successful, you have a good server and good communications.
As installed, the FTP server is not configured for what you want to
do.
The following is a snipit of the changes I have to make:
Install vsFTPd ftp server
Must be done to be an install server.
When done, don't need winscp for FTP transfers, but it will
still work.
yast
Network Services
Network Services (xinetd)
Enable
ftp: edit
vsftpd: continue (to install vsftpd)
ok (installed successfully)
(enable) service is active
accept
finish
quit
joe /etc/vsftpd.conf
comment out: Listen=YES
eliminates 500 OOPS: count not bind listening IPv4 sockets
uncomment:
local_enable=yes
write_enable =yes
save and exit
Tom Duerbusch
THD Consulting
>>> <[email protected]> 6/26/2009 2:44 PM >>>
Greetings
We have successfully setup an OSA as a layer 2 network with the
defined
vswitch and vlan.
We are having an issue with the build of a Linux guest defined for a
layer 2 network.
While the Linux build is starting it goes out to another Linux guest
on
another z/VM LPAR to download the binaries.
*** Error while accessing the FTP server:
Failed to connect to FTP server
*** Could not find the SUSE Linux Enterprise Server 10 Installation
Source.
Activating manual setup program.
>>> Linuxrc v2.0.79 (Kernel 2.6.16.60-0.21-default) <<<
Has anyone ever successfully built a Linux guest under z/VM on a layer
2
network?
Are there any tricks to get the installs to work?
The theory is that with the layer 2 network in place we will be able
to
move Linux guest from one z/VM to another and potentially move from
one
box to another box as long as the OSA's on them are connected to the
same layer 2 network and that the OSA's are defined the same so that
the
Linux guest can retain their IP address's no matter which box they are
running.
Supposedly for load balancing and when maintenance is required on the
z/VM systems there will be minimal outages on the Linux guests.
Hopefully I have made some sense.
