RE: FW: Installation Question
-Original Message- From: Stephen Powell [mailto:zlinux...@wowway.com] Sent: Monday, January 11, 2010 9:59 AM To: debian-s390@lists.debian.org Subject: Re: FW: Installation Question On 2010-01-11 at 08:00:18 -0500, Larry D Martin wrote: Update: With no other changes Suse 10.1 recognizes the disk. What is the difference in the install processes - as it relates to disk discovery? Thanks, ..Larry As requested previously, (1) please don't top post but use the usenet style of quoting, and (2) please try to keep the maximum length of a line to 80 bytes or less. (See http://en.wikipedia.org/wiki/Posting_style and http://www.debian.org/MailingLists/index.html#codeofconduct.) I will let those who are more knowledgeable about the internals of Debian Installer answer your specific question, if they choose to do so; but did you try my suggestions? And if so, what were the results? I have not tried your suggestions (yet) I have kept them and will get back to that. I amjust trying to get some Linux running. Thanks for all of the help and suggestions.Larry -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org This E-mail and any of its attachments may contain Prince George’s County Government or Prince George's County 7th Judicial Circuit Court proprietary information, which is privileged and confidential. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
FW: Installation Question
Update: With no other changes Suse 10.1 recognizes the disk. What is the difference in the install processes - as it relates to disk discovery? Thanks, ..Larry -Original Message- From: Stephen Powell [mailto:zlinux...@wowway.com] Sent: Wednesday, December 23, 2009 1:17 PM To: debian-s390@lists.debian.org Subject: RE: Installation Question On 2009-12-23, Marry Martin wrote: Unfortunately the list is empty (recognizes none) and then prompts me to enter an address, which, of course fails. Thanks again, ..Larry When you get to the screen that is supposed to show the recognized dasd devices, and nothing shows up, open another SSH session in another window on your desktop. Login as installer using the password that you specified earlier, but don't run the installer menu. Instead, escape to a shell. First of all, make sure that the dasd drivers are loaded # lsmod You should see both dasd_mod and dasd_eckd_mod as loaded modules. If not, manually load them with modprobe. If that doesn't work, you've got serious problems. Did you mess with the installer components to be downloaded? Did you deselect some of them? If both modules are loaded, issue # cd /sys/bus/ccw/devices # ls -Al|more You should see a directory listed for each device number recognized, regardless of whether it is dasd or not. It will be of the form 0.0., where is a hexadecimal number. (Note that hex digits a-f are lower case!) See if the device is listed there. If it is, cd to that directory. For example, # cd 0.0.108e # ls -Al You can check the values of these variables with cat. For example, # cat online If it responds with 0, then the device was recognized, but it is offline. Check the use_diag and readonly variables to make sure they are zero as well, then try to set the device online with # echo 1 online Then verify that it came online with another # cat online This time, it should say 1, which means that it is online. If this works, do the same for your other volume: # cd ../0.0.108f . . . If that works, then come back to the original install session, select Back, then invoke that step again. With luck, it will find the dasd devices now. P.S. Please do not attach my entire original e-mail at the end of your next posting. Just quote the relevant portions with the character above your response. Also, please try to keep your input lines to a maximum of 80 characters. Thanks. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org This E-mail and any of its attachments may contain Prince George’s County Government or Prince George's County 7th Judicial Circuit Court proprietary information, which is privileged and confidential. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: FW: Installation Question
On 2010-01-11 at 08:00:18 -0500, Larry D Martin wrote: Update: With no other changes Suse 10.1 recognizes the disk. What is the difference in the install processes - as it relates to disk discovery? Thanks, ..Larry As requested previously, (1) please don't top post but use the usenet style of quoting, and (2) please try to keep the maximum length of a line to 80 bytes or less. (See http://en.wikipedia.org/wiki/Posting_style and http://www.debian.org/MailingLists/index.html#codeofconduct.) I will let those who are more knowledgeable about the internals of Debian Installer answer your specific question, if they choose to do so; but did you try my suggestions? And if so, what were the results? -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Minidisk support (was: Installation Question)
Stephen Powell wrote: OK, so if all three drivers support minidisks, then what is Debian bug report 447755 all about? The issue here is the *format* of the minidisk. A DASD device, be it a dedicated device or a minidisk, can have one of four formats under Linux for s390: cdl, ldl, CMS non-reserved, and CMS reserved. The FBA driver supports two of the four formats: CMS non-reserved and CMS reserved. The DIAG driver supports three of the four formats: ldl, CMS non-reserved, and CMS reserved. The ECKD driver supports all four formats. Debian installer includes 2 drivers: - dasd_fba_mod - dasd_eckd_mod The second one is the one that's normally loaded AFAIK, so that means all four formats should be supported. CMS non-reserved: Low-level formatting: CMS FORMAT command Partitioning: none (a single partition is implied) High-level formatting: mke2fs or mkswap CMS reserved: Low-level formatting: CMS FORMAT command Partitioning: CMS RESERVE command (a single partition is created) High-level formatting: mke2fs or mkswap Here's one of the reason why I cannot do anything about this: I only have access to Hercules running Linux, so I cannot create CMS formatted disks. The issue in 447755 is that the Debian installer only supports cdl format. Why? It has the eckd kernel driver which supports all four formats if I understand you correctly. The fact that you cannot do a low-level CMS format is IMO not relevant as the first thing should be to support pre-formatted disks anyway. High level formatting (partitioning and file system creation) is not an issue here. Once the basic device is recognized, that should be automatic (unless the device has a special naming convention that's not recognized by partman, but that is trivial to implement). The s390-dasd udeb takes care of identifying available channels. Are minidisks maybe not listed as ccw channels maybe, or are they of a special type? The s390-dasd C program is relatively simple: it's a state engine and all actual functionality is based in info from /sys/. So what exactly is missing there? At what point does it go wrong: is it in s390-dasd, or is it in partman? I still don't get it... And since this is the only format that the DIAG driver *doesn't* support, the DIAG driver cannot be used, even after installation, without migrating the data to other minidisks after the installation. The installer currently does not include the DIAG driver. I'm not sure why, but possibly to avoid having to choose between two different drivers supporting the same device. But if the ECKD driver really does support all formats, then shouldn't you be able to use that initially and then switch over to DIAG after the installation? If so, missing DIAG in the installer would be no huge issue. There is also another issue mentioned in 447755, and that is a problem with mounting devices in the wrong order. In hindsight, I should have created two separate bug reports: one for the lack of support for CMS minidisks and one for the mount order issue. You can still do that... I apologize for the long reply, but again; I don't know what you know and what you don't know. Well, the thing this has clarified most for me is that my original position is still correct: I cannot do anything about this as the problem is not clear. Especially without access to a CMS formatted minidisk I cannot even start to see what's missing. It also still seems to me that anybody who *does* have access to such devices should be able to implement basic support, even without much coding skills. And they could at least specify *in detail* what's missing by doing all the needed steps manually: - what kernel modules are involved? - what are the relevant files in /sys/ and what are their contents? - what must be done to activate a device? - does the kernel recognize the device (see dmesg)? - do device nodes get created for the device? - ... If a kernel module is missing, simply scp it from an installed system into the D-i environment, run 'depmod -a', modprobe it and it should work. Working on Debian Installer is not rocket science, really. As an official Debian developer, you carry more weight than I do. I can appeal to the kernel team, of course; but if you say I'm full of excrement, they'll believe you more than they will me. No really, I do not have *any* influence over this. Even the kernel team does not have that much influence over the release date. Things just slowly move towards the critical mass needed to release, and at that point only serious release critical issues can stop it. And this simply does not qualify. So what you should do is just work to get any pet issues fixed in time and not make a huge issue of things. That's exactly the same basis on which everybody works. There's *plenty* of time to get it done. You just have to make it happen. Cheers, FJP -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a
Re: Minidisk support (was: Installation Question)
On 2009-12-24, Frans Pop wrote: Here's one of the reason why I cannot do anything about this: I only have access to Hercules running Linux, so I cannot create CMS formatted disks. Well, there are copies of very old releases of VM out there, such as VM/370 Release 6. VM/370 Release 6 has passed into the public domain now. But it is useless for this purpose. VM/370 Release 6 does not support the modern EDF disk format, with blocksizes of 512, 1024, 2048, and 4096. It only supports the original CDF format, with a blocksize of 800. That format is now obsolete, and Linux does not support it. It is technologically possible to run modern releases of z/VM under Hercules. I have heard that some people have done a Disaster Recovery Test of a modern z/VM system under Hercules. The problem is licensing. z/VM is not free software: you have to license it from IBM. And IBM normally won't license z/VM to run under Hercules, except maybe by special bid. And if they do license it to you by special bid, they'll probably charge you enough that it will be cheaper to buy a real mainframe and run it there! But I think IBM has, or used to have, some mainframes that have been set up for Linux developers to use, and they give away time and space on the machines for those who qualify. You might check into that. It would be nice if someone were to write a program that runs under Linux that can format a DASD device in the CMS format. That would help. As far as I know, there's no such program today. On 2009-12-24, Frans Pop wrote: Why? It has the eckd kernel driver which supports all four formats if I understand you correctly. The fact that you cannot do a low-level CMS format is IMO not relevant as the first thing should be to support pre-formatted disks anyway. Yes, that's true. I'm not asking for support for doing a low-level format in CMS format while the Debian installer is running. That would be wonderful, but even Suse doesn't give me that. All I'm asking for right now is the capability to use pre-formatted CMS disks. On 2009-12-24, Frans Pop wrote: So what exactly is missing there? At what point does it go wrong: is it in s390-dasd, or is it in partman? I still don't get it... I'm going from memory here. I haven't done an install in quite a while. But if I recall correctly, there is an initial screen in which the dasd devices that it finds are listed, and you can pick which ones you want to use. That works fine. Then there is a second screen after that on which you can do things like create partitions and assign mount points. I think that's partman. The problem is that a disk in CMS FORMAT, reserved or non-reserved, is treated like an unformatted disk. Partman does not recognize that the disk already has a partition on it. Therefore, I cannot assign a mount point to it or designate it as swap space. It will not let me do anything with the disk unless it runs dasdfmt and fdasd on it first. Then, and only then, does it recognize a partition on the disk, which I can assign a mount point to or designate as swap space. But that destroys the pre-existing CMS format which I need to keep. If I were to boil the problem definition down to one sentence it would be: Partman does not recognize the pre-existing partition on disks which are pre-formatted in the CMS non-reserved format or the CMS reserved format. It also still seems to me that anybody who *does* have access to such devices should be able to implement basic support, even without much coding skills. Well, I'm working on it, but I'm not there yet. I am currently teaching myself bash scripting by reading online tutorials and man pages. After that, I'll probably tackle awk, perl, and sed. And then eventually, C. I'm heading in the right direction. Maybe someday I'll be useful to you. But Rome wasn't built in a day. I'm sorry if the problem description wasn't clear to you. It was clear to me. But understanding a problem is one thing. Being able to explain it to someone else who comes from a different background and a different perspective is another thing. That takes work. And apparently I'm not as good at that as I thought I was. What I have is a real mainframe, a legitimate z/VM license, and a willingness to help. What I lack but am working on is Linux programming skills. I think I will eventually have them, but I'm not there yet. What I don't have, and likely never will, is FBA DASD. Someone else will need to test that support. You might be able to create emulated FBA dasd devices under Hercules. But formatting them in CMS format (EDF CMS format) is another story. In the meantime, if there's anything I *can* do for you, let me know. Merry Christmas! -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Minidisk support (was: Installation Question)
Stephen Powell wrote: If I were to boil the problem definition down to one sentence it would be: Partman does not recognize the pre-existing partition on disks which are pre-formatted in the CMS non-reserved format or the CMS reserved format. Right. That narrows it down a lot. Partman is almost exclusively shell script, and is because of that relatively easy to play around with. Main problem is that it's a *HUGE* amount of shell script, so the main challenge is to find the correct place in the code. This should be fairly simple to solve. Well, I'm working on it, but I'm not there yet. I am currently teaching myself bash scripting by reading online tutorials and man pages. After that, I'll probably tackle awk, perl, and sed. For this issue shell scripting (plus basic sed, find, etc.) is all that's needed. What I have is a real mainframe, a legitimate z/VM license, and a willingness to help. If you can provide me with *exact* info I need and if you can reply quickly, I may be able to add support for this. If you could provide me with access to a system that has these disks mounted that might work as well. To start with: - What device name does such a partition have? - How could it be distinguished from a partitionable dasd? Please send the replies for these questions to the BR instead of the list! -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Minidisk support (was: Installation Question)
On Thursday 24 December 2009, Frans Pop wrote: Stephen Powell wrote: Partman does not recognize the pre-existing partition on disks which are pre-formatted in the CMS non-reserved format or the CMS reserved format. Right. That narrows it down a lot. Partman is almost exclusively shell script, and is because of that relatively easy to play around with. Main problem is that it's a *HUGE* amount of shell script, so the main challenge is to find the correct place in the code. This should be fairly simple to solve. Hmmm. Possibly that info should come from libparted instead of partman itself. That would make it rather more difficult and probably beyond my skills. But we can give it a try. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Minidisk support (was: Installation Question)
On Thursday 24 December 2009, Frans Pop wrote: To start with: - What device name does such a partition have? - How could it be distinguished from a partitionable dasd? The output of the following command would be useful as well: # parted /dev/device print Please send the replies for these questions to the BR instead of the list! -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RE: Installation Question
Thank you. I am now in the SSH session. I have made it to Configure Disks and am not sure what the format of the address is. I have two volumes 108E and 108F and I tried 0.0.108E but that failed. Any suggestions? On the first menu on SSH I chose Start Installation. Should I have chosen to Start a Shell? Thanks, Larry -Original Message- From: Frans Pop [mailto:elen...@planet.nl] Sent: Tuesday, December 22, 2009 5:47 PM To: debian-s390@lists.debian.org Subject: RE: Installation Question Martin, Larry D wrote: All goes well until the install asks which site I want to use. I chose ftp.us.debian.org (and a couple of others) and I get ...site either not available or does not contain a valid release... The ftp.us.debian.org mirror works perfectly for me (using the same CD). Sounds as if you don't have an internet connection because of incorrect networking setup. But that's hard to tell without knowing the actual errors. Did you already switch to using an SSH session to complete the installation, or are you still using the text interface from the console? If you're still on the console you can see them by choosing Execute a shell from the installer's main menu and typing 'cat /var/log/syslog'. If you're using SSH, you can see the syslog by starting a second session and choosing the Start shell option and then use either cat or nano to view the syslog. If you need help, please copy and paste the full syslog (if possible). -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org This E-mail and any of its attachments may contain Prince George’s County Government or Prince George's County 7th Judicial Circuit Court proprietary information, which is privileged and confidential. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
RE: Installation Question
It appears that Debian does not think the disks are usable because they are reachable from another partition. When I did the IOCDS for our machine I actually had the two volumes for Linux reachable from four LPARs. One of the four is linux, one is inactive, one has the volumes offline, and the last one is a coupling facility LPAR. Does anyone have an IOCDS that shows 3390's properly defined for Debian? Or any other suggestions? The disks are definitely reachable from the LPAR into which I am loading Linux. Thanks, .Larry -Original Message- From: Frans Pop [mailto:elen...@planet.nl] Sent: Wednesday, December 23, 2009 9:33 AM To: debian-s390@lists.debian.org Subject: Re: Installation Question hint how to reply correctly on mailing lists A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? /hint Martin, Larry D wrote: I am now in the SSH session. I have made it to Configure Disks and am not sure what the format of the address is. I have two volumes 108E and 108F and I tried 0.0.108E but that failed. Any suggestions? No idea. For me the available dasds have always been listed and I could just select them. AFAICT the last format should be correct. You may have to check that the devices really are available. I don't think I can help much with this. Maybe this walktrough of an installation in the Hercules s390 emulator will help for reference: http://www.josefsipek.net/docs/s390-linux/hercules-s390.html On the first menu on SSH I chose Start Installation. Should I have chosen to Start a Shell? I assume you mean Start menu, but that's correct. The shell is available mainly for troubleshooting. You can use it to enter commands manually, check the syslog, etc. You should only have *one* menu SSH session open, but you can have multiple shell sessions if you want. Cheers, FJP -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org This E-mail and any of its attachments may contain Prince George’s County Government or Prince George's County 7th Judicial Circuit Court proprietary information, which is privileged and confidential. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
RE: Installation Question
On 2009-12-23, Larry Martin wrote:
It appears that Debian does not think the disks are usable because
they are reachable from another partition.
When I did the IOCDS for our machine I actually had the two volumes
for Linux reachable from four LPARs. One of the four is linux, one
is inactive, one has the volumes offline, and the last one is a
coupling facility LPAR.
Does anyone have an IOCDS that shows 3390's properly defined for Debian?
Or any other suggestions? The disks are definitely reachable from the
LPAR into which I am loading Linux.
Thanks, .Larry
Larry,
I'm not sure what you mean by reachable. Do you mean shared? Here
are some excerpts from our IOCP statements for a z890 (2086) with an IBM
DS6800 1750-511 RAID box for our DASD, which is attached to the host via
four FICON chpids. The RAID box defines 512 devices: 6100-61FF and
6300-63FF. 6100-6112 and 6300-6312 (38 devices) are emulated 3390-9
devices. The rest are 3390-3 devices. None of these devices support
PVA. These are IOCP statements generated by HCD/HCM running under z/OS,
which are slightly different in format from the native IOCP format. But
you'll get the idea.
--
TITLE 'SYS1.IODF01 - 2006-10-10 12:08:22 '
*
ID NAME=DOLC01,UNIT=2086,MODEL=A04,MODE=LPAR,LEVEL=H040331, *
SCR='DOLC01 06-10-1012:08:22SYS*
1IODF01 '
RESOURCE PARTITION=((CSS(0),(MVSPROD,1),(MVSTECH,3),(MVSTEST,2*
),(ZOSPROD,4),(ZVMPROD,5))),MAXDEV=((CSS(0),64512)),*
DESCL=('MVS PRODUCTION LPAR','','MVS TES*
T LPAR','',''),USAGE=(OS,OS,OS,OS,OS)
.
.
.
CHPID PATH=(CSS(0),20),SHARED,*
PARTITION=((MVSPROD,MVSTECH,MVSTEST,ZOSPROD,ZVMPROD),(=)*
),DESC='IBM DS6800 DASD',TYPE=FC,PCHID=120
CHPID PATH=(CSS(0),21),SHARED,*
PARTITION=((MVSPROD,MVSTECH,MVSTEST,ZOSPROD,ZVMPROD),(=)*
),DESC='IBM DS6800 DASD',TYPE=FC,PCHID=121
.
.
.
CHPID PATH=(CSS(0),30),SHARED,*
PARTITION=((MVSPROD,MVSTECH,MVSTEST,ZOSPROD,ZVMPROD),(=)*
),DESC='IBM DS6800 DASD',TYPE=FC,PCHID=130
CHPID PATH=(CSS(0),31),SHARED,*
PARTITION=((MVSPROD,MVSTECH,MVSTEST,ZOSPROD,ZVMPROD),(=)*
),DESC='IBM DS6800 DASD',TYPE=FC,PCHID=131
.
.
.
CNTLUNIT CUNUMBR=6100,PATH=((CSS(0),20,30,21,31)),*
UNITADD=((00,256)),SHARED=N,CUADD=1,SERIAL='13-AFALA', *
DESC='DS6800 1750-511 Control Unit',UNIT=1750
IODEVICE ADDRESS=(6100,256),UNITADD=00,CUNUMBR=(6100),STADET=Y*
,SERIAL='13-AFALA', *
DESC='DS6800 1750-511 mod-9 mod-3s',UNIT=3390
CNTLUNIT CUNUMBR=6300,PATH=((CSS(0),21,31,20,30)),*
UNITADD=((00,256)),SHARED=N,CUADD=3,SERIAL='13-AFALA', *
DESC='DS6800 1750-511 Control Unit',UNIT=1750
IODEVICE ADDRESS=(6300,256),UNITADD=00,CUNUMBR=(6300),STADET=Y*
,SERIAL='13-AFALA',
DESC='DS6800 1750-511 mod-9 mod-3s',UNIT=3390
--
The above IOCP definitions use the ESCON Multi-Image Facility (EMIF)
to allow the DASD devices to be shared by all LPARs. (EMIF works for
FICON as well as ESCON.)
If a normal mainframe operating system, such as z/OS or z/VM, can see
the DASD, then Linux should be able to see it too. If not, then you're
probably doing something wrong in the installation. If I remember right,
there is an initial screen which displays all the DASD devices it
recognizes. You have to explicitly select all the devices you are going
to use on that screen, though some of them may be pre-selected. Then
there is another screen later on where you can create partitions,
assign mount points, etc. If you don't select the devices on the first
screen, they won't be available on the second screen.
Also, keep in mind that (a) the Debian installer supports only CKD DASD
devices and (b) the Debian installer supports only the cdl format
(compatible disk layout). You said that your devices were 3390s, which
are CKD devices; so that should be OK.
I do all of my Linux installs in a virtual machine under z/VM, not natively
in an LPAR as you are attempting to do; so I don't really know how much
more help I can be if you are running into an LPAR-environment-specific
problem.
Regards,
Steve
--
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RE: Installation Question
Steve,
Thanks.
If I remember right,
there is an initial screen which displays all the DASD devices it
recognizes.
Unfortunately the list is empty (recognizes none) and then prompts me to enter
an address, which, of course fails.
Thanks again, ..Larry
-Original Message-
From: Stephen Powell [mailto:zlinux...@wowway.com]
Sent: Wednesday, December 23, 2009 11:41 AM
To: debian-s390@lists.debian.org
Subject: RE: Installation Question
On 2009-12-23, Larry Martin wrote:
It appears that Debian does not think the disks are usable because
they are reachable from another partition.
When I did the IOCDS for our machine I actually had the two volumes
for Linux reachable from four LPARs. One of the four is linux, one
is inactive, one has the volumes offline, and the last one is a
coupling facility LPAR.
Does anyone have an IOCDS that shows 3390's properly defined for Debian?
Or any other suggestions? The disks are definitely reachable from the
LPAR into which I am loading Linux.
Thanks, .Larry
Larry,
I'm not sure what you mean by reachable. Do you mean shared? Here
are some excerpts from our IOCP statements for a z890 (2086) with an IBM
DS6800 1750-511 RAID box for our DASD, which is attached to the host via
four FICON chpids. The RAID box defines 512 devices: 6100-61FF and
6300-63FF. 6100-6112 and 6300-6312 (38 devices) are emulated 3390-9
devices. The rest are 3390-3 devices. None of these devices support
PVA. These are IOCP statements generated by HCD/HCM running under z/OS,
which are slightly different in format from the native IOCP format. But
you'll get the idea.
--
TITLE 'SYS1.IODF01 - 2006-10-10 12:08:22 '
*
ID NAME=DOLC01,UNIT=2086,MODEL=A04,MODE=LPAR,LEVEL=H040331, *
SCR='DOLC01 06-10-1012:08:22SYS*
1IODF01 '
RESOURCE PARTITION=((CSS(0),(MVSPROD,1),(MVSTECH,3),(MVSTEST,2*
),(ZOSPROD,4),(ZVMPROD,5))),MAXDEV=((CSS(0),64512)),*
DESCL=('MVS PRODUCTION LPAR','','MVS TES*
T LPAR','',''),USAGE=(OS,OS,OS,OS,OS)
.
.
.
CHPID PATH=(CSS(0),20),SHARED,*
PARTITION=((MVSPROD,MVSTECH,MVSTEST,ZOSPROD,ZVMPROD),(=)*
),DESC='IBM DS6800 DASD',TYPE=FC,PCHID=120
CHPID PATH=(CSS(0),21),SHARED,*
PARTITION=((MVSPROD,MVSTECH,MVSTEST,ZOSPROD,ZVMPROD),(=)*
),DESC='IBM DS6800 DASD',TYPE=FC,PCHID=121
.
.
.
CHPID PATH=(CSS(0),30),SHARED,*
PARTITION=((MVSPROD,MVSTECH,MVSTEST,ZOSPROD,ZVMPROD),(=)*
),DESC='IBM DS6800 DASD',TYPE=FC,PCHID=130
CHPID PATH=(CSS(0),31),SHARED,*
PARTITION=((MVSPROD,MVSTECH,MVSTEST,ZOSPROD,ZVMPROD),(=)*
),DESC='IBM DS6800 DASD',TYPE=FC,PCHID=131
.
.
.
CNTLUNIT CUNUMBR=6100,PATH=((CSS(0),20,30,21,31)),*
UNITADD=((00,256)),SHARED=N,CUADD=1,SERIAL='13-AFALA', *
DESC='DS6800 1750-511 Control Unit',UNIT=1750
IODEVICE ADDRESS=(6100,256),UNITADD=00,CUNUMBR=(6100),STADET=Y*
,SERIAL='13-AFALA', *
DESC='DS6800 1750-511 mod-9 mod-3s',UNIT=3390
CNTLUNIT CUNUMBR=6300,PATH=((CSS(0),21,31,20,30)),*
UNITADD=((00,256)),SHARED=N,CUADD=3,SERIAL='13-AFALA', *
DESC='DS6800 1750-511 Control Unit',UNIT=1750
IODEVICE ADDRESS=(6300,256),UNITADD=00,CUNUMBR=(6300),STADET=Y*
,SERIAL='13-AFALA',
DESC='DS6800 1750-511 mod-9 mod-3s',UNIT=3390
--
The above IOCP definitions use the ESCON Multi-Image Facility (EMIF)
to allow the DASD devices to be shared by all LPARs. (EMIF works for
FICON as well as ESCON.)
If a normal mainframe operating system, such as z/OS or z/VM, can see
the DASD, then Linux should be able to see it too. If not, then you're
probably doing something wrong in the installation. If I remember right,
there is an initial screen which displays all the DASD devices it
recognizes. You have to explicitly select all the devices you are going
to use on that screen, though some of them may be pre-selected. Then
there is another screen later on where you can create partitions,
assign mount points, etc. If you don't select the devices on the first
screen, they won't be available on the second screen.
Also, keep in mind that (a) the Debian installer supports only CKD DASD
devices and (b) the Debian installer supports only the cdl format
(compatible disk layout). You said that your devices were 3390s, which
are CKD devices; so that should be OK.
I do all of my Linux installs in a virtual machine under z/VM
RE: Installation Question
On 2009-12-23, Marry Martin wrote: Unfortunately the list is empty (recognizes none) and then prompts me to enter an address, which, of course fails. Thanks again, ..Larry When you get to the screen that is supposed to show the recognized dasd devices, and nothing shows up, open another SSH session in another window on your desktop. Login as installer using the password that you specified earlier, but don't run the installer menu. Instead, escape to a shell. First of all, make sure that the dasd drivers are loaded # lsmod You should see both dasd_mod and dasd_eckd_mod as loaded modules. If not, manually load them with modprobe. If that doesn't work, you've got serious problems. Did you mess with the installer components to be downloaded? Did you deselect some of them? If both modules are loaded, issue # cd /sys/bus/ccw/devices # ls -Al|more You should see a directory listed for each device number recognized, regardless of whether it is dasd or not. It will be of the form 0.0., where is a hexadecimal number. (Note that hex digits a-f are lower case!) See if the device is listed there. If it is, cd to that directory. For example, # cd 0.0.108e # ls -Al You can check the values of these variables with cat. For example, # cat online If it responds with 0, then the device was recognized, but it is offline. Check the use_diag and readonly variables to make sure they are zero as well, then try to set the device online with # echo 1 online Then verify that it came online with another # cat online This time, it should say 1, which means that it is online. If this works, do the same for your other volume: # cd ../0.0.108f . . . If that works, then come back to the original install session, select Back, then invoke that step again. With luck, it will find the dasd devices now. P.S. Please do not attach my entire original e-mail at the end of your next posting. Just quote the relevant portions with the character above your response. Also, please try to keep your input lines to a maximum of 80 characters. Thanks. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RE: Installation Question
Thank you. I downloaded and started the install. All goes well until the install asks which site I want to use. I chose ftp.us.debian.org (and a couple of others) and I get ...site either not available or does not contain a valid release... What site should I chose to complete the install? Thanks again, Larry -Original Message- From: Frans Pop [mailto:elen...@planet.nl] Sent: Monday, December 21, 2009 4:13 PM To: debian-s390@lists.debian.org Subject: Re: Installation Question On Monday 21 December 2009, Frans Pop wrote: Martin, Larry D wrote: The iso directory for s390 is empty (as far as I can tell) again this week. Unfortunately the server that hosts the Debian Installer images for s390 looks to be down today, which means that the server that builds the CD images could not download them and so the weekly CD build failed. There's nothing much I can do about that. Sorry for the inconvenience. I've just created a bootable s390 CD for Lenny. You can download it from: http://cdimage.debian.org/cdimage/unofficial/fjp/ Cheers, FJP -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org This E-mail and any of its attachments may contain Prince George’s County Government or Prince George's County 7th Judicial Circuit Court proprietary information, which is privileged and confidential. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
RE: Installation Question
Martin, Larry D wrote: All goes well until the install asks which site I want to use. I chose ftp.us.debian.org (and a couple of others) and I get ...site either not available or does not contain a valid release... The ftp.us.debian.org mirror works perfectly for me (using the same CD). Sounds as if you don't have an internet connection because of incorrect networking setup. But that's hard to tell without knowing the actual errors. Did you already switch to using an SSH session to complete the installation, or are you still using the text interface from the console? If you're still on the console you can see them by choosing Execute a shell from the installer's main menu and typing 'cat /var/log/syslog'. If you're using SSH, you can see the syslog by starting a second session and choosing the Start shell option and then use either cat or nano to view the syslog. If you need help, please copy and paste the full syslog (if possible). -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RE: Installation Question
The iso directory for s390 is empty (as far as I can tell) again this week. Thanks, .Larry -Original Message- From: Frans Pop [mailto:elen...@planet.nl] Sent: Wednesday, December 16, 2009 11:59 AM To: debian-s390@lists.debian.org Subject: Re: Installation Question Martin, Larry D wrote: The S390 directory appears to me to be empty this week. Yes, unfortunately there was a build error this week (which sometimes happens for daily and weekly builds). The images should be back next Monday. There was stuff there last week (can I point to that?). Afraid not. Full CD/DVD images just take too much space to keep multiple versions around. Cheers, FJP -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org This E-mail and any of its attachments may contain Prince George’s County Government or Prince George's County 7th Judicial Circuit Court proprietary information, which is privileged and confidential. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: Installation Question
Martin, Larry D wrote: The iso directory for s390 is empty (as far as I can tell) again this week. Unfortunately the server that hosts the Debian Installer images for s390 looks to be down today, which means that the server that builds the CD images could not download them and so the weekly CD build failed. There's nothing much I can do about that. Sorry for the inconvenience. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Installation Question
On Monday 21 December 2009, Frans Pop wrote: Martin, Larry D wrote: The iso directory for s390 is empty (as far as I can tell) again this week. Unfortunately the server that hosts the Debian Installer images for s390 looks to be down today, which means that the server that builds the CD images could not download them and so the weekly CD build failed. There's nothing much I can do about that. Sorry for the inconvenience. I've just created a bootable s390 CD for Lenny. You can download it from: http://cdimage.debian.org/cdimage/unofficial/fjp/ Cheers, FJP -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RE: Installation Question
On December 21, 2009, Larry Martin wrote: The iso directory for s390 is empty (as far as I can tell) again this week. Thanks, .Larry According to the web page http://cdimage.debian.org/cdimage/weekly-builds/, problems with the weekly builds should be reported on another list: debian...@lists.debian.org. I cannot find evidence in your original posting that this list was CC-ed; so you might want to put a posting on that list complaining that none of the s390 architecture weekly builds exist. Here is an excerpt from the above web page: -- Problems? If you encounter any problems with these images, please check the Debian CDs FAQ. The most common complaint at the moment is about wrongly-sized or corrupt DVD ISO images, which is normally a bug in your http download program. If your problem is not covered by the above FAQ, please report it to the debian...@lists.debian.org mailing list. -- (I checked the FAQ. The subject, all the files for architecture xyz are missing is not one of the topics covered in the FAQ.) I'd report the problem myself; but I use the VM reader images from generic, not the CD images, to do my installs. Therefore, you have a greater vested interest to make some noise on the other list than I do. So I'll let you do it. :-) Regards, Steve -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Minidisk support (was: Installation Question)
On 2009-12-14, Frans Pop wrote: By far the best way is to try to get *upstream* to include the patch in one of their stable updates for .32, so in 2.6.32.1 or 2.6.32.2. I would suggest proposing that on the linux-s390 mailing list. Pardon my ignorance, but would you mind giving me the full URL of the upstream linux-s390 mailing list, so that I can follow-up on your advise? A quick search of the internet yielded a number of hits, but nothing obviously the right place in the first few screens. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Minidisk support (was: Installation Question)
On 2009-12-15, Stephen Powell wrote: OK, so if all three drivers support minidisks, then what is Debian bug report 447755 all about? The issue here is the *format* of the minidisk. A DASD device, be it a dedicated device or a minidisk, can have one of four formats under Linux for s390: cdl, ldl, CMS non-reserved, and CMS reserved. The FBA driver supports two of the four formats: CMS non-reserved and CMS reserved. The DIAG driver supports three of the four formats: ldl, CMS non-reserved, and CMS reserved. The ECKD driver supports all four formats. I need to make one further clarification. The DIAG driver (dasd_diag_mod) really doesn't *take the place* of the basic driver for the underlying dasd type (dasd_fba_mod or dasd_eckd_mod, depending on whether the device is an FBA device or a CKD device). Rather it works *with* the basic driver for the underlying dasd type. The basic driver (dasd_fba_mod or dasd_eckd_mod) makes some initial tests of the device to see if it qualifies for use by the DIAG driver. For example: Are we running in a virtual machine under z/VM? Is it a supported device type? Is it a supported format? Does it have a valid block size? etc. Once the basic driver is satisfied that the device qualifies, it hands it off to the DIAG driver. That means two things: (1) the initial RAM file system must contain both drivers, and both drivers must be loaded from the initial RAM file system, and (2) the set of formats supported by the DIAG driver *for a particular device* is the intersection of sets of the set of formats supported by the DIAG driver and the set of formats supported by the basic driver for that type of device. For example, when using the DIAG driver with an FBA device, one can only use the CMS non-reserved or the CMS reserved format. The ldl format cannot be used by the DIAG driver for this type of device, even though the DIAG driver supports the ldl format, because the underlying basic driver, the FBA driver in this case, does not support the ldl format. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Minidisk support (was: Installation Question)
At the risk of flogging a dead horse, there's one more minor correction I need to make. On 2009-12-15, Stephen Powell wrote: cdl format: Low-level formatting: dasdfmt -d cdl (this is the default format for dasdfmt) Partitioning: fdasd (up to three partitions can be created) High-level formatting: mke2fs or mkswap ldl format: Low-level formatting: dasdfmt -d ldl Partitioning: none (a single partition is implied) High-level formatting: mke2fs or mkswap CMS non-reserved: Low-level formatting: CMS FORMAT command Partitioning: none (a single partition is implied) High-level formatting: mke2fs or mkswap CMS reserved: Low-level formatting: CMS FORMAT command Partitioning: CMS RESERVE command (a single partition is created) High-level formatting: mke2fs or mkswap In the above section I imply that high-level formatting must be done by either mke2fs or mkswap. This is not strictly true. Other file systems besides ext2 or ext3 may be used. It would be more accurate to say mkfs or mkswap for the high-level formatting part of each of the four disk formats. This allows any desired (and supported) filesystem to be used. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Installation Question
Martin, Larry D wrote: The S390 directory appears to me to be empty this week. Yes, unfortunately there was a build error this week (which sometimes happens for daily and weekly builds). The images should be back next Monday. There was stuff there last week (can I point to that?). Afraid not. Full CD/DVD images just take too much space to keep multiple versions around. Cheers, FJP -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RE: Installation Question
Thanks..Larry -Original Message- From: Frans Pop [mailto:elen...@planet.nl] Sent: Wednesday, December 16, 2009 11:59 AM To: debian-s390@lists.debian.org Subject: Re: Installation Question Martin, Larry D wrote: The S390 directory appears to me to be empty this week. Yes, unfortunately there was a build error this week (which sometimes happens for daily and weekly builds). The images should be back next Monday. There was stuff there last week (can I point to that?). Afraid not. Full CD/DVD images just take too much space to keep multiple versions around. Cheers, FJP -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org This E-mail and any of its attachments may contain Prince George’s County Government or Prince George's County 7th Judicial Circuit Court proprietary information, which is privileged and confidential. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: Minidisk support (was: Installation Question)
That's really the wrong way to look at it. Just look at the headers from the mail: they clearly show that the mail was sent to you by the mailing list software. It was delivered to you because *you* subscribed to the list, not because *I* sent it to you. Other mail clients (such as my own kmail) by default automatically reply to the mailing list only. Your client probably has a reply-to-list option. The e-mail client I normally use is the the browser-based basic webmail client of my ISP, which happens to be WOW! It is a cable TV company which also offers high speed internet connectivity via a cable modem. They give free e-mail accounts to their cable-modem customers. And they have a basic and an advanced browser-based webmail client. I don't use the e-mail client installed on my workstation. I prefer web-based e-mail for a number of reasons, but I won't go into it here because it's off-topic. The point is that, as seen by my e-mail client, the incoming e-mail says To: debian-s390@lists.debian.org From: (poster's e-mail address) When I click on reply, the To field is pre-filled-in with the poster's e-mail address. I have to remember to do a copy, while still on the page for the incoming e-mail, of the To field; then after clicking on reply I have to remember to do a paste on top of the To field to put the list address there. I'm not sure why it works that way, but it does. Anyway, the point is that I know how to work around it; I just have to remember to do it. And in fact, the patch that's now included upstream is rather different from your patch. Yes, they took a different approach than I did. My patch applies to the mdsk_init_io internal function. It sets the return code to zero inside the function; so that the caller never sees a return code of 4. The official patch took a different approach. They changed the logic in the two places in the code where the return code is checked; so that it correctly handles a return code of 4. Both approaches work. The official patch is better, in my opinion, because it automatically sets the read-only option on when it detects the return code of 4 and also adds some diagnostic and informational messages. The down side to the official patch is that it does not backport as easily to old releases due to changes in the way that kernel messages are issued between 2.6.26 and 2.6.33. But both patches solve the problem. More confusion. The reason that still points to the Lenny version is that there has not yet been a release (upload) of D-I for Squeeze [1]. The images linked there are completely unusable to build CD images for Squeeze (and even unusable to install Squeeze). The only images relevant for Squeeze ATM are the daily built images available from [2], and they use the 2.6.30 kernel udebs from unstable. That's good info. Thank you. I was just about to try an install of Squeeze for s390. You just saved yourself a bug report. No, they accepted it as a *bug*. They did not accept your *patch*. Oh, now I get it. Sure. But OTOH it adds support for a class of devices that is currently effectively not supported. So even though the from a technical PoV it is a bug, from a functional PoV it can be seen as an enhancement. I don't think I understand what you are trying to say. Every DASD device which is supported by the DIAG driver, with or without the patch, is also supported by either the ECKD driver or the FBA driver. The only thing that the DIAG driver buys you that's useful is a performance boost. It might also help you if you have a vested interest in driving I/O through CP diagnose codes for some reason. (i.e. local modifications to DIAG 250 support in z/VM for accounting, security, auditing, or whatever.) The DIAG driver, with or without the patch, does not add support for devices that otherwise are not supported by Linux. And the patch does not add support for new devices. What the patch gives you is safety. Without the patch, the only way to share minidisks between multiple servers, and still use the DIAG driver, is to LINK the minidisks with access mode MW. And that gives multiple servers potential read/write access to the minidisk, which can (and almost certainly will) corrupt the minidisk if two servers mount the file system read/write at the same time. If the minidisks are LINKed with access mode R, that can't happen. CP prevents you from accidentally shooting yourself in the foot. But if you LINK the minidisk with access mode R, and you use the DIAG driver, you can't get the device online unless one of the two DIAG patches is on. Without the patch, you must either LINK the minidisk with access mode MW or else stay with access mode R but switch to the ECKD or FBA driver, depending on device type. If you use access mode MW, you increase the risk of corruption. If you switch to the ECKD or FBA driver, you lose the performance boost of the DIAG driver. I think it *is* worth the effort to try to
Re: Minidisk support (was: Installation Question)
Stephen Powell wrote: When I click on reply, the To field is pre-filled-in with the poster's e-mail address. So, it's a limitation of *your* email client. The choice of client is up to you, but forcing its limitations on others is backwards. I don't think I understand what you are trying to say. Every DASD device which is supported by the DIAG driver, with or without the patch, is also supported by either the ECKD driver or the FBA driver. The only thing that the DIAG driver buys you that's useful is a performance boost. OK. My s390 knowledge is very limited. My understanding was that minidisks were not supported at all (as there's a longstanding BR open to add support for them in the installer). This might increase the chances of getting it accepted for Lenny, but someone will still need to do the work to prepare things cleanly for the kernel team. *If* things are presented correctly I see no reason why the kernel team would not accept it. OK, I'll try. But in exchange, I'll ask that you attempt to persuade Eh, what? Why would I have to do that? I have no special status here. the kernel team to hold off on freezing Squeeze until a kernel with this patch on it is adopted by Squeeze. There isn't much point in going through the effort to get the patch into 2.6.32 if Squeeze is going to be frozen at 2.6.30 or 2.6.31. As 2.6.32 is already in unstable and Squeeze will only freeze in March, there is zero risk of that. If that had been a realistic risk, I would have mentioned it in earlier mails. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Minidisk support (was: Installation Question)
On 2009-12-14, Adam Thornton wrote: On 2009-12-14, Stephen Powell wrote: Well, it's definitely a bug. But whether or not it affects a significant number of users is another story. This bug has been around since day 1 of the driver. And I'm apparently the first one to find it. So claiming that it affects a significant number of users would be a hard sell. Well, it bit me too, back when I was doing the diag250 driver for OpenSolaris, but I was too lazy to file a bug report on it, so, yeah, my bad. But two still isn't a lot, and I've changed jobs and don't work with s390x except for fun on Hercules these days. OK, I stand corrected. I'm not the first one to find it. But apparently, I'm the first one to report it. Others must have worked around it by linking the minidisks MW or by using another driver. Or maybe they wrote their own patches. But nobody reported it. That's one down side of having the source code. It's sometimes easier to fix it yourself and not report it. But then others don't benefit from your work. But since OpenSolaris is a competitor of Linux, I can see why, if they were paying you, that they didn't want you to spend your time filing Linux bug reports. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Minidisk support (was: Installation Question)
On 2009-12-15, Frans Pop wrote: OK. My s390 knowledge is very limited. My understanding was that minidisks were not supported at all (as there's a longstanding BR open to add support for them in the installer). OK, now I think I understand where the confusion lies. I'd start a new thread here; but since the subject line already says minidisk support, and since that's exactly what we're discussing now, I'll just continue with the current thread. If you want to split this off into another thread, be my guest. I assume that you are referring to bug report number 447755, which I opened. (That reminds me, I opened it under my old e-mail address. I've got to get the e-mail address updated.) Please forgive me if I insult your intelligence or give too much information. That is not my intent. I have a tendency to do that at times, but I don't do it on purpose. I do respect you. I just don't know what you do know and what you don't know. So I'll just explain the whole thing and please politely ignore what you already know. We'll start with the definition of DASD. DASD is an acronym which stands for Direct Access Storage Device. It's a general term for any storage device in which the records can be easily accessed in random order, such as a disk. This is in contrast with a sequential access storage device, in which the records must be accessed in sequential order, such as a magnetic tape. Historically, DASD was not necessarily a disk device. In the early days of mainframes, there were magnetic drum devices as well, and they were also classified as DASD. But those devices fell by the wayside long ago. In today's environment, DASD and disk are practically, though not technically, synonymous. Mainframe DASD comes in two basic types: FBA (Fixed Block Architecture) and CKD (Count Key Data). FBA DASD is similar to the type of disk devices used in the world of PCs. The physical blocks on disk are all of a fixed size: 512 bytes. Sometimes you will see FBA DASD described as an FB-512 device. In theory, an FBA device can use other blocksizes; but to the best of my knowledge every FBA device ever made for mainframe use has a physical blocksize of 512. CKD DASD is different. With CKD DASD, the physical blocks on disk can be of all different sizes, from a theoretical minimum of 1 to a theoretical maximum of 65535 (hex ). In order to keep track of things, there is a special little block in front of every main block called a count block which contains the size (length) of the following main block, or data block. In addition, some types of blocks, such as directory blocks for partitioned data sets, also contain keys. The key is typically a sort key that is significant to the type of data being stored. In the case of a partitioned data set directory block, it is the key (member name) of the highest-sorting member (in the EBCDIC collating sequence) of all the members described in that directory block. Thus, for a keyed block, there are actually three blocks on the disk: a count block, a key block, and a data block. Most blocks do not have keys, they have only a count block and a data block. But in the general case, a block on this type of DASD device may have keys. Hence the name count-key-data or CKD DASD. In Linux, the FBA driver (the dasd_fba_mod kernel module) supports FBA devices and the ECKD driver (the dasd_eckd_mod kernel module) supports CKD devices. The E in ECKD stands for Extended. This refers to some extra channel commands supported by the control unit which allow some high-performance options, such as reading a whole track at a time, etc. But the underlying data format is still CKD. When people speak of ECKD DASD, what they mean is CKD-format DASD which has a control unit which supports the extra ECKD channel commands. Different IBM DASD devices are identified by a four-digit device-type number. For example, 3370, 9336, 9332, and 9335 are four different device types of FBA DASD. 9345, 3390, 3380, and 3350 are four different device types of CKD DASD. These different device types differ from each other in things like track capacity, number of tracks per cylinder, average seek time, average rotational delay, channel speed, etc. In addition to the main four-digit number, there is often a suffix to distinguish different models. These different models most often differ from each other only in the number of cylinders they possess. For example, a 3390-3, the most popular model of 3390, has 3339 cylinders, numbered from 0-3338. The 3390-9 has 10017 cylinders, numbered 0-10016. IBM has two main historical operating systems: VSE and MVS. VSE added support for FBA DASD, but MVS never did. MVS can only use CKD DASD. And since MVS is IBM's most popular (and most lucrative) operating system, CKD DASD is far more popular with mainframe customers than FBA DASD is. Of course, these days, hardly anybody uses real mainframe DASD anymore, be it FBA or CKD. Most mainframe customers
Re: Installation Question
Frans Pop wrote: Hm. Except that for Lenny (stable) we haven't had any new CD builds since it was fixed. That will only happen at the next stable point release (which is overdue). The weekly built CD for Squeeze [1] should work though and should be usable to install Lenny too. You'll need to change the debconf priority to medium before the mirror selection step to get a choice of which release to install. Given the low frequency of stable release updates, perhaps I should ask if the fix for Debian bug #550898 is scheduled to be included in the next update, both in the Debian installer and in the regular stock kernels. This fix is an s390/s390x-specific fix. An upstream developer promised me that he would get this fix in the next kernel release, which at the time was going to be 2.6.33. But since stable Debian releases tend to go with even numbered kernel releases, the earliest upstream version which contains this fix that Debian actually uses is likely to be 2.6.34. That might not even be available in Squeeze. I'd really like to see this fix in production as soon as possible. Until that happens, I will have to build custom kernels. I requested this in bug report number 550898, but no-one responded. I have a patch for this available on my web site now: http://www.wowway.com/~zlinuxman/dasd_diag.diff If you cut and paste the version in the problem log you may have problems applying the patch due to tab versus space issues. The version on my web site applies just fine even without resorting to the -l option of patch. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Minidisk support (was: Installation Question)
(No need to CC me; I read the list; see the Debian mailing list policy.) Hello Stephen, A few misconceptions in your mail. Let me try to correct them and offer some advise on who to proceed. But first of all: please don't hijack an existing thread for an unrelated issue; next time, please just start a new thread instead. On Monday 14 December 2009, Stephen Powell wrote: Given the low frequency of stable release updates, You are mixing two different things in this mail: - the next stable release (Squeeze) - the next update (point release) for the existing stable release (Lenny) The rules, limitations and methods for getting changes included are completely different for them, and you should clearly separate between them. perhaps I should ask if the fix for Debian bug #550898 is scheduled to be The people to ask are the kernel team. And for inclusion in a stable update, you may need to specifically need to make the person within that team who takes care of preparing those updates (Dan Frazier) aware of the issue. Bastian Blank as kernel team member and s390 porter would be a logical person to drive this, but possibly he does not personally think the issue important enough to get involved. I don't know. included in the next update, both in the Debian installer and in the regular stock kernels. There is no difference between regular and D-I kernels, especially not for the next stable release. D-I merely repackages the regular kernel into udebs it does not build its own kernels. So, any change included in the regular kernels almost automatically gets included in the installer (except when it requires additional new kernel modules to be included, which is not the case here). For stable updates it is a bit different as not every point release includes an update of the Installer, and even if the installer is updated, it does not necessarily include a kernel update. This fix is an s390/s390x-specific fix. An upstream developer promised me that he would get this fix in the next kernel release, which at the time was going to be 2.6.33. Right. The fix (22825ab7) _is_ now in mainline, which means your chances of getting this included in Debian Squeeze has just increased from 10% to about 98%. And the chance to get it included in Lenny from 0% to 20%. Why? Simple. The kernel team policy is to only include patches that already have been accepted upstream or look certain to get included upstream very soon. For stable updates added criteria are: - it must fix an important *bug* (affecting a significant number of users), or - it must be an enhancement that is very important to a significant number of users *and* has no risk of introducing regressions. This patch is IMO more an enhancement than a bug fix, so I'm not certain it qualifies for a stable update. But since stable Debian releases tend to go with even numbered kernel releases, the earliest upstream That is a totally random deduction based on nothing else than coincidence for the last few releases. There is no difference between odd and even upstream releases, so no reason for Debian to prefer even ones. The choice of kernel version is mostly a timing issue (when is the upstream release relative to Debian's freeze date) and possibly what kernel other distributions use for their releases (so we can profit from long term maintenance of that kernel release). version which contains this fix that Debian actually uses is likely to be 2.6.34. So this is nonsense. That might not even be available in Squeeze. I'd really like to see this fix in production as soon as possible. I don't know what the kernel team are currently planning for Squeeze: .32 or .33. It depends a lot on when Debian actually freezes. I guess .32 is more likely than .33, but .33 is a possibility. Now, assuming that it will be .32, how can you get this fix that's been included upstream in .33 included in Debian? By far the best way is to try to get *upstream* to include the patch in one of their stable updates for .32, so in 2.6.32.1 or 2.6.32.2. I would suggest proposing that on the linux-s390 mailing list. If that does not happen, you can try asking the Debian kernel team to backport the fix to .32. The way to do that is: - follow up to the bug report - include a link to the upstream commit in .33 (this is essential!) - get the attention of the kernel team: keep following up regularly and ask (politely) if someone has had a chance to consider this To get the patch included in a Lenny point release you need to do the same, but with the following additional things: - provide a solid rationale why this is an important change for Lenny - check whether or not the upstream patch applies to the current Lenny kernel - if it does, test it thoroughly - if it does not, provide a backported patch after testing that thoroughly - make sure the maintainer for the stable kernel is aware of the issue As mentioned before, I'm not sure
Re: Minidisk support (was: Installation Question)
First of all, thank you very much for your lengthy reply. I am honored that you took the time to explain so many things. However, I believe that you have some misconceptions as well. (No need to CC me; I read the list; see the Debian mailing list policy.) Here is the exact wording from the mailing list policy: When replying to messages on the mailing list, do not send a carbon copy (CC) to the original poster unless they explicitly request to be copied. Strictly speaking, I did not do that. I am subscribed to the list; and whenever a post is made, I get a copy in my private e-mail. My private e-mail sees the e-mail as coming from the poster, not from the list. As viewed by my e-mail system, I was replying to a private e-mail from you. It was the list that I added to the CC, for the benefit of others. Nevertheless, I acknowledge that the net result is the same. In the future, I will try to remember to change the TO field from the poster's address to the list address instead of adding the list address to the CC list, unless I know that the poster is not subscribed to the list or he explicitly requested a CC. By the way, there's another item on the mailing list policy that may interest you: If you want to complain to someone who sent you a carbon copy when you did not ask for it, do it privately. please don't hijack an existing thread for an unrelated issue; next time, please just start a new thread instead. Well, to you it may seem unrelated; but to the way I was thinking at the time, it was related. User A was asking if fix X was going to be included in the next update and user B (me) was chiming in to ask if fix Y was going to be included as well. I defer to your judgment on this matter, but please keep things in perspective. This list has a very low posting rate. Here we are in the middle of December, and this is the first legitimate thread, not counting spam, that has been posted this month. I wouldn't be surprised if it's the only thread at the end of the month (except for the fact that you forced a new thread). I doubt that people are going to have trouble keeping everything straight. Hijack is a strong word. When I think of hijack, I think of the terrorists who hijacked those planes and flew them into the World Trade Center. Hijacking is criminal activity. If you think a reply belongs in a new thread, please just start one yourself in the reply. You are mixing two different things in this mail: - the next stable release (Squeeze) - the next update (point release) for the existing stable release (Lenny) The rules, limitations and methods for getting changes included are completely different for them, and you should clearly separate between them. OK, maybe I don't know all of the Debian-internal-use-only terminology. Apparently, what I should have said is stable point release instead of stable release update. By stable release update, I meant an update to the stable release, that is, an update to Lenny. I did not mean Squeeze becoming the stable release. Sorry for the confusion. The people to ask are the kernel team. I *did* ask the kernel team. Debian bug report 550898 was reported against package linux-image-2.6.26-2-s390x. The maintainer for package linux-image-2.6.26-2-s390x is Debian Kernel Team debian-ker...@lists.debian.org. Here is part of what I said in my last post: Since upstream development has accepted this as a bug and has agreed to provide a fix in the next merge window, I respectfully request that this patch be included in the next stable release of Debian for s390 (6.0.0 -- Squeeze). If you could include it in the next update of the stable release (5.0.4 -- Lenny), that would be good too. In the meantime I will need to build a custom kernel with every security update that hits the kernel, which I don't like to have to do. As I read over this again, I now realize that I used internally inconsistent terminology, which may have added to the confusion. Nevertheless, I did mention both Squeeze and Lenny as releases that I would like to see updated. But there was no response. There is no difference between regular and D-I kernels, especially not for the next stable release. D-I merely repackages the regular kernel into udebs it does not build its own kernels. So, any change included in the regular kernels almost automatically gets included in the installer (except when it requires additional new kernel modules to be included, which is not the case here) Hmm. Starting with the top directory of the Debian archive, dists/squeeze/main/installer-s390/current is a symbolic link to ../../../lenny/main/installer-s390/current so right now the boot-up files that I use to install, which are dists/squeeze/main/installer-s390/current/images/generic/kernel.debian dists/squeeze/main/installer-s390/current/images/generic/initrd.debian dists/squeeze/main/installer-s390/current/images/generic/parmfile.debian etc. are all
Re: Minidisk support (was: Installation Question)
On Monday 14 December 2009, Frans Pop wrote: Stephen Powell wrote: I *did* ask the kernel team. Yes, and I gave several reasons that could explain why they may not have replied. P.S. I never meant to imply that anything you did was wrong. I was just trying to explain why it was not effective. Obviously it would have been much better if the kernel team had replied to your bug report themselves. But things become much easier if you try to look at things from their PoV. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Minidisk support (was: Installation Question)
On Dec 14, 2009, at 3:44 PM, Stephen Powell wrote: Well, it's definitely a bug. But whether or not it affects a significant number of users is another story. This bug has been around since day 1 of the driver. And I'm apparently the first one to find it. So claiming that it affects a significant number of users would be a hard sell. Well, it bit me too, back when I was doing the diag250 driver for OpenSolaris, but I was too lazy to file a bug report on it, so, yeah, my bad. But two still isn't a lot, and I've changed jobs and don't work with s390x except for fun on Hercules these days. Adam
Installation Question
Does anyone know if the problem installing Debian on zSeries from CD-ROM has been corrected? Thanks, Larry Larry D. Martin Mainframe Systems Support Office of Information Technology and Communications 301.883.7335 This E-mail and any of its attachments may contain Prince George’s County Government or Prince George's County 7th Judicial Circuit Court proprietary information, which is privileged and confidential. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: Installation Question
Martin, Larry D wrote: Does anyone know if the problem installing Debian on zSeries from CD-ROM has been corrected? Yes, it has. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
