As near as I can tell, S/390 still uses partconf, and it and m68k are the only architectures to do so.
Something I think we should think about--although not for the d-i or sarge releases, probably--is to get S/390 moved over to partman (if I understand correctly that partman's functionality is a superset of partconf's). We should also get better handling for FBA disks into the S/390 installer. (For those of you unfamiliar with S/390: most disks, and the only disks that MVS/OS390/zOS support, are ECKD (Extended Count Key Data); FBA (Fixed Block Architecture) is much more like disk everywhere else in the world, in that it's just a range of 512-byte blocks. It doesn't get much attention because S/390 disk is almost always presented as ECKD disk (even though these days all the ECKD stuff is emulated and it's really sitting on a big array of SCSI disks, which are FBA devices)) It's not a big deal right now, because the only use most people have for FBA is swap on VDISK (virtual DASD which comes out of VM's page space--this has the advantage that if there's physical memory available on the box, it's in memory and thus swap to it isn't a lot slower than real memory access, and if memory is tight, VM handles paging it out to disk automatically), and it's not too much hassle to do this manually. However, with z/VM 5.1, due out soon, z/VM will be able to transparently present Fibre-Channel attached SCSI devices as FBA devices. That's going to make life a lot easier for Linux guests (using FCP SCSI is possible, but very painful, right now) because some annoying size restrictions on ECKD disks are greatly ameliorated with the emulated FBA in z/VM 5.1 (the largest ECKD disk is currently a 3390-27, which is 32760 cylinders, which comes out to about 28GB--z/VM 5.1 will support emulated FBA up to 384GB). Also, the ECKD scheme wastes an awful lot of disk space on architectures that like 4K blocks. The capacity of a Model 3 (3339 cylinders), which is still the standard DASD size and what most shops have all their volumes formatted as, is about 2.8 GB, but Linux only sees 2.3 GB of that because of space wasted on each track (which implies LVM if you need more than 2.3GB in a single filesystem, which is *really* annoying). There's a third disk access method, DIAG, which is also supported in the kernel but not in the installer, and it should be. That's a feature that only works under VM, with disks that you have specially RESERVEd under CMS, and it involves basically letting VM manage disk resources and I/O access for its guests via a VM interface rather than worrying about passing I/O channel commands. This generally lets it get slightly better performance on FBA devices, although usually not for CKD devices. It's the best way to implement swap-on-VDISK, which is the primary use for it. The Linux DASD driver, when you hand it a disk, assuming it's got all three methods built into it (the stock Debian kernel does), knows which kind of access to use. So I don't think that from an application perspective anything would need to change much to support all three. However, partconf currently refuses to touch anything that isn't CKD. The reason why is fairly simple: the native S/390 partitioning tool, fdasd, which partconf uses, only works with ECKD. But that's OK. If you have a plain old FBA device, you should use the raw disk device: /dev/dasdd (or, in devfs terms, /dev/dasd/0153/disc). If you have a RESERVEd minidisk (i.e. DIAG-accessed), the RESERVEd space will show up as part1 (i.e., /dev/dasdd1 or /dev/dasd/0153/part1). So although you cannot partition a disk of either sort, you don't need to in order to use it. The point of this rather rambling note is just that Debian on S/390 and S/390x needs better handling of FBA and DIAG disks at install time to be ready for z/VM 5.1 (which would also let us support swap-on-VDISK natively, without having to do any manual steps, which would be a plus). I think this should be accompanied by a transition entirely to partman but I don't understand the various pieces of disk management well enough to be sure. Before I open this up as a "wishlist" bug I want to be sure that I'm opening it in the right package. Should this be a partman wishlist bug? Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]