Re: VOL1
Here is a little more info about VOL1 capabilities. The official IBM standard only requires 80 bytes, far less than the 512 bytes reserved for MBR. The MBR reservation is common for many filesystems (EXT2/3/4 and others). You can have a VOL1 label while keeping the FS at the front of the disk. It fits. Things continue to work. This is really useful for systems like zPDT because you can 'mount -o loop' the file defining the disk on the host system. Similarly, a PV could be "attached" to Linux on zPDT, happily with VOL1 label. (Same for an LV, of course.) "But wait, there's more!" A physical disk could be attached to Linux on zPDT. (Though not partitioned if stamped VOL1.) Alan said, "Linux could obtain, via IBM channels, an official VOL1 standard version ID." IPL text for FBA DASD also fits in "MBR space". So why CDL? Because it provides a VTOC and flattens the learning curve for MVS shops. (Hence the comment "MVS needs to grow up.") Then what's wrong with CDL? It truncates records at the front of the disk rendering all other uses void. (filesystems, partitioning, PV) The VOL1 standard does not require this; it doesn't mandate end-of-record at 80 bytes. Think about interoperability. VM shops might prefer a CMS reserved file where MVS wants a DS. (The label would be "CMS1". Holy minidisks, Bat Man!) Going extreme ... ISO-9660 (CD-ROM) reserves a whopping 32K. I recall putting a traditional PC partition table at the front of a minidisk with a boot partition following the ISO-9660 FS. -- R; <>< -- 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/
Network Problem installing SLES12 SP1
We are running VM 6.3 and I am attempting to install SLES12 SP1 from the VM reader using NFS like I have done with all other versions. I have copied the needed files into the RDR and execute the SLES12 EXEC I start the installation, enter the required info when it goes to setup the network connection: (Layer2) (Port 0) qeth.5cb8a3: 0.0.0600: The qeth device is not configured for the OSI layer requi red by z/VM qeth.5cb8a3: 0.0.0600: The qeth device is not configured for the OSI layer requi red by z/VM qeth.3acf0c: 0.0.0600: The qeth device driver failed to recover an error on the device qeth: irb : 00 c2 60 17 3f 0c c0 38 0e 00 10 00 00 80 00 00 ..`.?..8... . qeth: irb 0010: 01 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... . qeth: sense data : 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 qeth: sense data 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 qeth.3acf0c: 0.0.0600: The qeth device driver failed to recover an error on the device Could not set device 0.0.0600 online *** network configuration script failed (error code 2560) *** No network device found. Any ideas? Gene Walters System Programmer WV Office of Technology Data Center 1900 Kanawha Blvd East Bldg 6, Room B-110 Charleston, WV 25305 (304)957-8284 (304)558-1441 fax Work Hours: 6AM-2PM EST -- 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: Curious about crash.
Why these LINUX machines are setup the way they are is a mystery to me. As part of the lab exercise I used XCAT to provision the machines.. Following what Rick said I was able to boot the failing machine.. I don't know what to do next, but it is booted. On Mon, Dec 21, 2015 at 6:45 PM, Rick Troth wrote: > On 12/16/2015 09:45 AM, Tom Huegel wrote: > > VFS: Cannot open root device "disk/by-path/ccw-0.0.0100-part2" or > > unknown-block(0,0) > > Please append a correct "root=" boot option; here are the available > > partitions: > > Nothin. > No partitions. (More significantly, no disks at all.) > > I didn't see it mentioned, but if the two systems use the same device > addresses then you might be able to boot from the good system. > Guessing that the INITRD is shot. So ... > > #cp link good 100 500 rr > #cp ipl 500 clear > > ... and the INITRD there will have the needed modules and startup magic > to "see" your 100 disk. You do not need R/W access to the link. It > should not try to mount that disk (or a partition thereof) as root. > You're only using the bootstrap, the IPL text. > > -- R; <>< > > -- > 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: Network Problem installing SLES12 SP1
Looks like you configured your nic with the wrong layer. Is your vswitch configured in layer2? If so, then you need to specify it is layer2 on the layer2 prompt... Hope this helps Offer Baruch On Dec 22, 2015 5:47 PM, "Walters, Gene P" wrote: > We are running VM 6.3 and I am attempting to install SLES12 SP1 from the > VM reader using NFS like I have done with all other versions. > > I have copied the needed files into the RDR and execute the SLES12 EXEC > > I start the installation, enter the required info when it goes to setup > the network connection: > > (Layer2) > (Port 0) > qeth.5cb8a3: 0.0.0600: The qeth device is not configured for the OSI layer > requi > red by z/VM > qeth.5cb8a3: 0.0.0600: The qeth device is not configured for the OSI layer > requi > red by z/VM > qeth.3acf0c: 0.0.0600: The qeth device driver failed to recover an error > on the > device > qeth: irb : 00 c2 60 17 3f 0c c0 38 0e 00 10 00 00 80 00 00 > ..`.?..8... > . > qeth: irb 0010: 01 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ... > . > qeth: sense data : 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > qeth: sense data 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > qeth.3acf0c: 0.0.0600: The qeth device driver failed to recover an error > on the > device > Could not set device 0.0.0600 online > > *** network configuration script failed (error code 2560) > > *** No network device found. > > Any ideas? > > > Gene Walters > System Programmer > WV Office of Technology Data Center > 1900 Kanawha Blvd East > Bldg 6, Room B-110 > Charleston, WV 25305 > (304)957-8284 > (304)558-1441 fax > Work Hours: 6AM-2PM EST > > > -- > 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: Curious about crash.
On 12/22/2015 11:55 AM, Tom Huegel wrote: > Why these LINUX machines are setup the way they are is a mystery to me. As > part of the lab exercise I used XCAT to provision the machines.. So we're all learning from your experience. Kind of you to walk point with XCAT for the rest of us. :-) > Following what Rick said I was able to boot the failing machine.. I don't > know what to do next, but it is booted. Fab! Now you can try to run that 'diff' which Russ asked for. mv grub.cfg grub.cfg-BAK grub2-mkconfig -o /boot/grub2/grub.cfg diff grub.cfg-BAK grub.cfg I don't know what to tell you about stamping a now-good bootstrap (with GRUB). In times past it would be 'mkinitrd' followed by 'zipl'. Can someone say if that's viable here? -- R; <>< -- 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: Network Problem installing SLES12 SP1
>>> On 12/22/2015 at 10:45 AM, "Walters, Gene P" wrote: > We are running VM 6.3 and I am attempting to install SLES12 SP1 from the VM > reader using NFS like I have done with all other versions. > > I have copied the needed files into the RDR and execute the SLES12 EXEC > > I start the installation, enter the required info when it goes to setup the > network connection: > > (Layer2) > (Port 0) > qeth.5cb8a3: 0.0.0600: The qeth device is not configured for the OSI layer > requi > red by z/VM -snip- > Any ideas? Add "layer2=0" to your parmfile. 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: Curious about crash.
My ignorance overflows.. When I look on my INTEL LINUX I can find grub.cfg in boot/grub2 but I cannot find it in the zLINUX. ls /boot bootmap symvers-2.6.32-573.8.1.el6.s390x.gz config-2.6.32-431.el6.s390x System.map-2.6.32-431.el6.s390x config-2.6.32-573.8.1.el6.s390x System.map-2.6.32-573.8.1.el6.s390x grubtape0 initramfs-2.6.32-431.el6.s390x.img vmlinuz-2.6.32-431.el6.s390x symvers-2.6.32-431.el6.s390x.gz vmlinuz-2.6.32-573.8.1.el6.s390x [root@tom129 /]# ls /boot/grub ls /boot/grub splash.xpm.gz Two additional points: 1) I'll post my XCAT experience as best I can remember, but probably not until I return from the holiday break in January. 2) I wrote up the little exec (pipe trackread) I had mentioned to compare raw dasd tracks but I couldn't determine the problem because there were too many differences.. But if anyone would like the exec I can post it here.. Someone may have a use for it. On Tue, Dec 22, 2015 at 9:37 AM, Rick Troth wrote: > On 12/22/2015 11:55 AM, Tom Huegel wrote: > > Why these LINUX machines are setup the way they are is a mystery to me. > As > > part of the lab exercise I used XCAT to provision the machines.. > > So we're all learning from your experience. > Kind of you to walk point with XCAT for the rest of us. :-) > > > > Following what Rick said I was able to boot the failing machine.. I don't > > know what to do next, but it is booted. > > Fab! > > Now you can try to run that 'diff' which Russ asked for. > > > mv grub.cfg grub.cfg-BAK > grub2-mkconfig -o /boot/grub2/grub.cfg > diff grub.cfg-BAK grub.cfg > > > I don't know what to tell you about stamping a now-good bootstrap (with > GRUB). > In times past it would be 'mkinitrd' followed by 'zipl'. Can someone say > if that's viable here? > > -- R; <>< > > -- > 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: Curious about crash.
On 12/22/2015 04:16 PM, Tom Huegel wrote: > My ignorance overflows.. > When I look on my INTEL LINUX I can find grub.cfg in boot/grub2 but I > cannot find it in the zLINUX. Probably me making ASSumptions. GRUB recently learned how to play in z land, and the distros have picked that up. There are some advantages. [edited] > # ls /boot > bootmap symvers-2.6.32-573.8.1.el6.s390x.gz > config-2.6.32-431.el6.s390x System.map-2.6.32-431.el6.s390x > config-2.6.32-573.8.1.el6.s390x System.map-2.6.32-573.8.1.el6.s390x > grubtape0 > initramfs-2.6.32-431.el6.s390x.img vmlinuz-2.6.32-431.el6.s390x > symvers-2.6.32-431.el6.s390x.gz vmlinuz-2.6.32-573.8.1.el6.s390x > > # ls /boot/grub > ls /boot/grub > splash.xpm.gz Look under /etc too. And compare the dead system to the good system. It's all new to me too. I believe /boot/grub2/grub.cfg gets built using the "helper scripts" found under /etc/grub.d. In any case, the fact that /boot/grub exists suggests that we do want to go the GRUB route and not traditional ZIPL. Since the system has booted, can you [re]run a 'yum update'? > Two additional points: 1) I'll post my XCAT experience as best I can > remember, but probably not until I return from the holiday break in > January. 2) I wrote up the little exec (pipe trackread) I had mentioned to > compare raw dasd tracks but I couldn't determine the problem because there > were too many differences.. But if anyone would like the exec I can post it > here.. Someone may have a use for it. > > I for one would be interested in the tool, but the task of track-by-track analysis of a Linux filesystem would be mind numbing at best. Hang in there, Tom. Oh, and, of course, ... Mey Christmaaas! -- Sir Santa; <>< -- 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: Curious about crash.
>>> On 12/22/2015 at 05:40 PM, Rick Troth wrote: > On 12/22/2015 04:16 PM, Tom Huegel wrote: >> My ignorance overflows.. >> When I look on my INTEL LINUX I can find grub.cfg in boot/grub2 but I >> cannot find it in the zLINUX. Most likely because it doesn't exist on your system(s). > Probably me making ASSumptions. > GRUB recently learned how to play in z land, Not really. GRUB still doesn't understand DASD or SCSI over FCP (as implemented by z Systems). GRUB only knows how to read the file systems Linux uses to find the various kernels and initrds specified in /boot/grub2/grub.cfg. > and the distros have picked > that up. To my knowledge, only SUSE Linux Enterprise Server 12 and 12 SP1 offer this. -snip- > In any case, the fact that /boot/grub exists suggests that we do want to > go the GRUB route and not traditional ZIPL. The zipl command is still needed on z Systems. It's just not as front-and-center as it used to be in the past. In particular, SUSE doesn't provide an /etc/zipl.conf any more, since there's no real need for customer modifications there. The way things work is that: 1. A Linux kernel needs to be booted from DASD or SCSI over FCP. That means that zipl has to write out the pointers to the kernel and initrd so that the boot loader can find them. 2. Once the Linux system gets up to a point where GRUB can be invoked, it then tries to find both grub.cfg and then the Linux kernels and initrds that it references. 3. After the user specifies a specific kernel/initrd combination, possibly adding parameters to what is in /boot/grub2/grub.cfg, or the timeout happens, GRUB then boots the "real" system. 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/
