Re: mounting error in LVM install SLES 11 SP2
>>> On 5/23/2012 at 06:54 PM, Dave Jones wrote: > However, at the beginning of the install process I get the following > error from Yast: > > Failure occurred during the following action: > > Mounting /dev/system/swap to swap > System error code was: -3030 > > The DASD minidisk has been dasdfmt-ed as part of the Yast install. The > fdasd, create volume group, create logical volume, format logical volume > steps seem to have run successfully. If it makes any difference, this is > an SSH-based install and not an X11 or VNC one. The /var/log/YaST2/y2log file would be of interest to see if there are more details available. You say the mindisk had dasdfmt run against it. During this install, or a previous one? Are you doing the install manually, or using AutoYaST? I would also be curious to see what happens if you run CPFMTXA or CMS FORMAT against the minidisk before trying again. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: mounting error in LVM install SLES 11 SP2
Dave, I wonder if you have defined swap to be a crypto partition. If so, can you test the install without that option? Also, have you tried to change the fstab naming option from device name to UUID? HTH, Pedro Principeza From: Dave Jones To: LINUX-390@vm.marist.edu, Date: 23/05/2012 20:00 Subject:mounting error in LVM install SLES 11 SP2 Sent by:Linux on 390 Port Maybe someone here has seen this before, I haven't. I am trying to do a fresh install of SLES11 SP2 on z/VM 6.1. I let the install process suggest an LVM installation layout that has: /dev/dasda1 (150.38 MB) with ext3 logical volume /dev/system/root (10.00 GB) with ext3 logical volume /dev/system/swap (1.46 GB) with swap However, at the beginning of the install process I get the following error from Yast: Failure occurred during the following action: Mounting /dev/system/swap to swap System error code was: -3030 The DASD minidisk has been dasdfmt-ed as part of the Yast install. The fdasd, create volume group, create logical volume, format logical volume steps seem to have run successfully. If it makes any difference, this is an SSH-based install and not an X11 or VNC one. Thanks and have a good one. DJ -- Dave Jones V/Soft Software www.vsoft-software.com Houston, TX 281.578.7544 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: mounting error in LVM install SLES 11 SP2
So ... a lot of the "stuff" has been done. I'm not following the proposed layout. Where is that EXT3 partition mounted? /boot? What is the backing store for the "system" volume group? Is it online in a form YaST will recognize? (A bunch of DASD partitions? Were they also 'dasdfmt'?) SSH will tunnel X traffic, so is it still a graphical mode YaST? (should not matter w/r/t disk handling) -- R; Rick Troth Velocity Software http://www.velocitysoftware.com/ On Wed, May 23, 2012 at 6:54 PM, Dave Jones wrote: > Maybe someone here has seen this before, I haven't. > > I am trying to do a fresh install of SLES11 SP2 on z/VM 6.1. I let the > install process suggest an LVM installation layout that has: > > > /dev/dasda1 (150.38 MB) with ext3 > > logical volume /dev/system/root (10.00 GB) with ext3 > > logical volume /dev/system/swap (1.46 GB) with swap > > However, at the beginning of the install process I get the following > error from Yast: > > Failure occurred during the following action: > > Mounting /dev/system/swap to swap > System error code was: -3030 > > The DASD minidisk has been dasdfmt-ed as part of the Yast install. The > fdasd, create volume group, create logical volume, format logical volume > steps seem to have run successfully. If it makes any difference, this is > an SSH-based install and not an X11 or VNC one. > > Thanks and have a good one. > > DJ > -- > Dave Jones > V/Soft Software > www.vsoft-software.com > Houston, TX > 281.578.7544 > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ -- -- R; Rick Troth Velocity Software http://www.velocitysoftware.com/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
mounting error in LVM install SLES 11 SP2
Maybe someone here has seen this before, I haven't. I am trying to do a fresh install of SLES11 SP2 on z/VM 6.1. I let the install process suggest an LVM installation layout that has: /dev/dasda1 (150.38 MB) with ext3 logical volume /dev/system/root (10.00 GB) with ext3 logical volume /dev/system/swap (1.46 GB) with swap However, at the beginning of the install process I get the following error from Yast: Failure occurred during the following action: Mounting /dev/system/swap to swap System error code was: -3030 The DASD minidisk has been dasdfmt-ed as part of the Yast install. The fdasd, create volume group, create logical volume, format logical volume steps seem to have run successfully. If it makes any difference, this is an SSH-based install and not an X11 or VNC one. Thanks and have a good one. DJ -- Dave Jones V/Soft Software www.vsoft-software.com Houston, TX 281.578.7544 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: question migrating an LPAR full of guests to a new machine
Regarding machine replacement, if you get newer model OSA's you may change from one chpid per port to one chpid per port pair, which will force you to modify your definitions in z/VM to point to the correct OSA Port in addition to the correct memory range. Not a big deal, but an owie if you miss it. Roger Oakes -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Grzegorz Powiedziuk Sent: Tuesday, May 22, 2012 11:42 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: question migrating an LPAR full of guests to a new machine 2012/5/1 Bruce Lightsey > In the next two or three weeks we will have to move from our current z9 to > a z114 and are trying to look for all of the "gotchas" involved. > We recently did exactly the same jump. NPIV I guess was explained already (we actually implemented NPIV and SAN after we moved to z114). I would only suggest downloading and applying PTFs for z/vm. There were some pdfs from IBM which specify which PTFs you have to have in your z/vm 5.4 for z114. There aren't many but still, you should check this out. You will have to slightly adjust your IOCP because some chpids changed in z114. There are tools out there to remap those but for us, IBM guy did it before we plugged in new machine. Guys who were setting up z114, moved all LPARs configurations and uploaded new iocp. Generally in our case it all went smooth and after 2hours we were up again. Good luck Gregory Powiedziuk > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: mac address problem
David Boyes wrote on 05/23/2012 10:44:51 AM: > On 5/23/12 9:40 AM, "Dennis Musselwhite" wrote: > >When the VSWITCH is defined with the IP option, ARP responsibility > >is offloaded to the OSA hardware, so the Linux host should *not* be > >sending ARP frames on that interface. > > But the OSA simply swallows the unneeded ARP automagically if sent, so why > make people choose, particularly as these days more than 8 times out of 10 > they WANT the extra ARP, and it's clearly needed to make the device > function? It still seems that the proposed default of "no" is just wrong. > > Suggestion: have the device driver check the interface layer type (it > clearly knows how, since the driver can issue an error if there is a type > mismatch for L2 vs L3) and issue the ARP if needed. You shouldn't have to > set that kind of thing if the driver can figure it out, and clearly the > current solution is broken because it used to work and now it doesn't. > > Since IBM opened the case, I'd suggest telling SuSE that that's not an > acceptable solution. Their solution breaks a important network > self-defence mechanism that is an accepted RFC, and that shouldn't happen. Hi David, It turns out my concern was unnecessary. I know in the past we had to block outgoing ARP frames to avoid interfering with the OSA hardware ARP management (APAR VM64162) but I had forgotten how much time had passed. That fix is certainly in every z/VM system by now. Regards, Dennis Musselwhite -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: mac address problem
On 5/23/12 9:40 AM, "Dennis Musselwhite" wrote: > >When the VSWITCH is defined with the IP option, ARP responsibility >is offloaded to the OSA hardware, so the Linux host should *not* be >sending ARP frames on that interface. But the OSA simply swallows the unneeded ARP automagically if sent, so why make people choose, particularly as these days more than 8 times out of 10 they WANT the extra ARP, and it's clearly needed to make the device function? It still seems that the proposed default of "no" is just wrong. Suggestion: have the device driver check the interface layer type (it clearly knows how, since the driver can issue an error if there is a type mismatch for L2 vs L3) and issue the ARP if needed. You shouldn't have to set that kind of thing if the driver can figure it out, and clearly the current solution is broken because it used to work and now it doesn't. Since IBM opened the case, I'd suggest telling SuSE that that's not an acceptable solution. Their solution breaks a important network self-defence mechanism that is an accepted RFC, and that shouldn't happen. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: mac address problem
Ursula Braun wrote on 05/23/2012 04:20:43 AM: > On Mon, 2012-05-21 at 06:41 -0500, David Boyes wrote: > > On 5/21/12 4:11 AM, "Ursula Braun" wrote: > > > > > >we reported this problem in Novell bugzilla 617373. Solution has been to > > >introduce a SEND_GRATUITOUS_ARP config option. Its default is "no". > > >Changing it to "yes" should trigger the sending of gratuitous ARPs. The > > >config option is offered starting with sysconfig-0.71.30-0.10.1. > > > > When would this NOT be the correct behavior? Seems like the default should > > be yes, given that that's the way ARP has worked for decades. > > The solution with SEND_GRATUITOUS_ARP config option is provided by SUSE. > They would have to change the default to "yes". We have never asked for > this default change. I feel compelled to point out that this discussion has been about a Linux host using a Layer 2 interface. If I understand the scenario correctly, the virtual NIC is coupled to a VSWITCH which is defined with the ETHERNET (not IP) option, so it *is* appropriate to have this Linux host generating gratuitous ARP frames when the interface is ready (or perhaps when the server ports are open and ready to handle inbound requests). When the VSWITCH is defined with the IP option, ARP responsibility is offloaded to the OSA hardware, so the Linux host should *not* be sending ARP frames on that interface. This is just a reminder in case somebody using VSWITCH(IP) interfaces finds this thread and assumes SEND_GRATUITOUS_ARP is universally good. Regards, Dennis Musselwhite z/VM CP Development -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: mac address problem
On Mon, 2012-05-21 at 06:41 -0500, David Boyes wrote: > On 5/21/12 4:11 AM, "Ursula Braun" wrote: > > > >we reported this problem in Novell bugzilla 617373. Solution has been to > >introduce a SEND_GRATUITOUS_ARP config option. Its default is "no". > >Changing it to "yes" should trigger the sending of gratuitous ARPs. The > >config option is offered starting with sysconfig-0.71.30-0.10.1. > > When would this NOT be the correct behavior? Seems like the default should > be yes, given that that's the way ARP has worked for decades. The solution with SEND_GRATUITOUS_ARP config option is provided by SUSE. They would have to change the default to "yes". We have never asked for this default change. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
