Description of problem: At times, anaconda program failed to establish the network connection to the VM TCPIP stack via ctc0. Sometimes we were able to free it up by stop and start the device from the VM TCPIP, and the install process continued. And sometimes, we experienced the same problem after we told the Anaconda program to use NFSserver for install. In this case, anaconda terminated immedidately after we stop and start the ctc0 link. We experienced this problem on both Beta one and two. We reported this problem to IBM that we found Unit Checks on this VIRTUAL ctca device from the console log of VM TCPIP. As per IBM, this is NOT possible for a VIRTUAL device and IBM would like to know what exactly is the anaconda program doing for the TX init handshake? I have NO problem with other Linux distributions. Below is the console log of the Linux guest: Starting the zSeries initrd to configure networking. Version is 1.01 CTC driver Version: 1.57 with CHANDEV support initialized divert: not allocating divert_blk for non-ethernet device ctc0 ctc0: read: ch 0a00 (irq 0000), write: ch 0a01 (irq 0001) proto: 0 ctc0 Link encap:Serial Line IP inet addr:171.177.29.9 P-t-P:171.177.29.1 Mask:255.255.255.255 UP POINTOPOINT NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 171.177.29.1 0.0.0.0 255.255.255.255 UH 0 0 0 ctc0 171.177.29.9 0.0.0.0 255.255.255.255 UH 0 0 0 ctc0 127.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 lo 0.0.0.0 171.177.29.1 0.0.0.0 UG 0 0 0 ctc0 Starting portmap. Journalled Block Device driver loaded Starting telnetd and sshd to allow login over the network. Connect now to 171.177.29.9 to start the installation. ctc0: Timeout during TX init handshake ctc0: TX channel restart ctc0: Timeout during TX init handshake ctc0: TX channel restart ctc0: Timeout during TX init handshake ctc0: TX channel restart ctc0: Timeout during TX init handshake ctc0: TX channel restart ctc0: Timeout during TX init handshake ctc0: TX channel restart ctc0: Timeout during TX init handshake ctc0: TX channel restart ctc0: Timeout during TX init handshake ctc0: TX channel restart ctc0: Timeout during TX init handshake ctc0: TX channel restart ctc0: Timeout during TX init handshake ctc0: TX channel restart ctc0: Timeout during TX init handshake ctc0: TX channel restart ch-0a01: Interface disc. or Sel. reset (remote) ctc0: Error during TX init handshake ch-0a00: Interface disc. or Sel. reset (remote) ctc0: Got remote disconnect, re-initializing ... ch-0a00: Interface disc. or Sel. reset (remote) ch-0a01: Interface disc. or Sel. reset (remote) ch-0a00: Interface disc. or Sel. reset (remote) ch-0a01: Interface disc. or Sel. reset (remote) ch-0a00: Interface disc. or Sel. reset (remote) ch-0a01: Interface disc. or Sel. reset (remote) ch-0a00: Interface disc. or Sel. reset (remote) ch-0a01: Interface disc. or Sel. reset (remote) ch-0a00: Interface disc. or Sel. reset (remote) ch-0a01: Interface disc. or Sel. reset (remote) ctc0: connected with remote side login(pam_unix)¬59|: session opened for user root by (uid=0)? -- root¬59|: ROOT LOGIN ON pts/0 FROM 171.184.32.205? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I think this should be fixed in 2.4.21-4.11.EL. We better poke Frank (the TAM) to get it to Emil for testing. Installation won't be tested until the U1 comes around with updated install images, but at least regression testing needs to happen.