[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

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.


Reply to: