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
Reply to: