Nabble - debian-s390

Re: Custom Kernel Building in Debian

2009-11-17T12:23:31Z

> first of all you shall build your linux-2.6 in ~/src/
> no compellent reason to do it in /usr/src

> second you shall use make deb-pkg no need to use kernel-package
> on a recent linux-2.6 tarball (>= 2.6.31). it will just produce
> the linux-image.

Thank you for your feedback. In response to your feedback I have created a new
section in my document called "Alternatives". It's at the end. If you visit the
site and don't see it, be sure to manually reload the page to make sure you are
not looking at an obsolete cached version of the page. Here's the link again.

http://www.wowway.com/~zlinuxman/Kernel.htm

Regards,
Steve

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Custom Kernel Building in Debian

2009-11-17T08:14:09Z

On Tue, Nov 17 2009, maximilian attems wrote:

> second you shall use make deb-pkg no need to use kernel-package
> on a recent linux-2.6 tarball (>= 2.6.31). it will just produce
> the linux-image.

Not if you want to produce headers, doc, or debug packages from
your custom sources. The upstream deb-pkg is nice and all, but does not
offer the same functionality as kernel-package does.

--
Most people prefer certainty to truth.
Manoj Srivastava <srivasta@...> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Custom Kernel Building in Debian

2009-11-17T00:51:14Z

On Mon, Nov 16, 2009 at 02:24:52PM -0500, Stephen Powell wrote:
> Maybe I'm re-inventing the wheel here, but I have recently collected and organized
> my notes on custom kernel building in Debian and have put them on the web at the
> following URL: http://www.wowway.com/~zlinuxman/Kernel.htm

first of all you shall build your linux-2.6 in ~/src/
no compellent reason to do it in /usr/src

second you shall use make deb-pkg no need to use kernel-package
on a recent linux-2.6 tarball (>= 2.6.31). it will just produce
the linux-image.

>
> Commence firing. Fire at will.

hehe, see above :)

kind regards

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Custom Kernel Building in Debian

2009-11-16T12:24:16Z

On Mon, Nov 16 2009, Manoj Srivastava wrote:

> I like that, and would like to be able to incorporate this HOWTO
> in the kernel-package package. What license are you distributing the
> document under? If it is a free license, I would like it to be in the
> kernel-package docs for Squeeze.

I'm glad you like it.
As stated in the disclaimer section, the license is public domain.
Use whatever you want. A little blurb of attribution would be nice though.

Regards,
Steve

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Custom Kernel Building in Debian

2009-11-16T12:05:07Z

Hi,

On Mon, Nov 16 2009, Stephen Powell wrote:

> Maybe I'm re-inventing the wheel here, but I have recently collected
> and organized my notes on custom kernel building in Debian and have
> put them on the web at the following URL:
> http://www.wowway.com/~zlinuxman/Kernel.htm

> Commence firing. Fire at will.

I like that, and would like to be able to incorporate this HOWTO
in the kernel-package package. What license are you distributing the
document under? If it is a free license, I would like it to be in the
kernel-package docs for Squeeze.

manoj
--
If graphics hackers are so smart, why can't they get the bugs out of
fresh paint?
Manoj Srivastava <srivasta@...> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Custom Kernel Building in Debian

2009-11-16T11:24:52Z

Maybe I'm re-inventing the wheel here, but I have recently collected and organized
my notes on custom kernel building in Debian and have put them on the web at the
following URL: http://www.wowway.com/~zlinuxman/Kernel.htm

Maybe it will be useful to somebody. If there is anything incorrect on this page,
regardless of how small or inconsequential, please tell me. If it's out-of-date,
please tell me. If it's redundant, or if there's better documentation somewhere
else, please tell me. I welcome all feedback. I am subscribed to debian-s390,
but not to debian-kernel; so if you post to debian-kernel please cc me. I
welcome any and all feedback.

Commence firing. Fire at will.

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

s390 machines available (portland, or, usa)

2009-11-06T14:19:51Z

greetings. i work at freegeek (http://freegeek.org), and we recently got two
s390 machines in, if they would be helpful to debian's s390 port.

don't know what model they are, or much of anything about s390 in general, or
the condition of the hardware.

let me know off-list if you're interested and would be able to pick them up.

live well,
vagrant

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

ч ? ζ品ζ信ζ息Ｑ�

2009-10-29T22:20:45Z

仲孙顾问： ★您好！★ 我司現有多種【發*f *票】可向外優惠代開，代開範圍：廣告、運輸、服務、租憑、餐飲、醫療、商品銷售、建築安裝、機動車銷售及增*值*稅等【發*９ *票】，貴司如有需要，請與我司聯系！聯系人：于先生電.話:⑴-⑶-⑹ - ⑼-⑴-⑻-⑹ - ⑼-⑴-⑶-⑹ 順頌商祺！打擾之處請見諒！Ｅ

GyaO! - Anime, Dramas, Movies, and Music videos [FREE]

Implementing the DASD DIAG Driver for Debian GNU/Linux on the S390 Architecture

2009-10-22T14:14:27Z

As promised in an earlier post (or as threatened, depending on your
point of view :-) ), I have completed my "How To" document for using
the DASD DIAG driver with Debian for S390. Here is a link to the
web page for it: http://www.wowway.com/~zlinuxman/diag250.htm.
I hope it proves useful to someone. I welcome all comments,
suggestions, complaints, etc.

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#550898: DASD DIAG driver doesn't work for read-only minidisks (s390, s390x only)

2009-10-16T06:03:39Z

>
> However ...
>
> This fix also creates (or more likely exposes) another problem. When this fix
> is on, devices which are manually taken offline immediately come online again!
> I had this problem once before in an earlier kernel, but the problem eventually
> went away with maintenance.
>

False alarm. I can now reproduce this error in kernels without the patch too.
It just doesn't happen all the time (with or without the patch). Further research
is needed on this problem. In any case, I am convinced that these two problems
are totally unrelated.

>
> FYI: The DASD device driver maintainers are aware of this problem and will
> provide a fix for the upstream version of the Linux kernel with the next merge
> window (2.6.33). Should you need the fix for an earlier version, someone at
> Debian will need to port that fix back to the respective levels.
>
> Regards,
> Peter Oberparleiter
>

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.
Here is my version of the patch:

----------

*** dasd_diag.c 2008-07-13 17:51:29.000000000 -0400
--- /usr/src/linux-source-2.6.26/drivers/s390/block/dasd_diag.c 2009-10-14 09:30:26.000000000 -0400
***************
*** 111,116 ****
--- 111,120 ----

rc = dia250(iib, INIT_BIO);

+ /* Fix for read-only minidisk */
+ if (rc == 4) rc = 0;
+ /* End fix for read-only minidisk */
+
if ((rc & 3) == 0 && end_block)
*end_block = iib->end_block;

----------

This is a "context diff" with three lines of context. I don't know if this is the standard way
of producing patch files or not. Forgive me; I'm new at this.

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bug#550898: DASD DIAG driver doesn't work for read-only minidisks (s390, s390x only)

2009-10-16T03:31:31Z

Stephen Powell wrote:
> When using the DASD DIAG driver with a read-only minidisk, the
> initialize function of DIAG X'250' fails. The error message produced
> goes something like this:
>
> dasd(diag) 0.0.0404: DIAG initialization failed (rc=4)
> dasd_generic couldn't online device 0.0.0404 with discipline DIAG rc=-5

FYI: The DASD device driver maintainers are aware of this problem and
will provide a fix for the upstream version of the Linux kernel with the
next merge window (2.6.33). Should you need the fix for an earlier
version, someone at Debian will need to port that fix back to the
respective levels.

Regards,
Peter Oberparleiter

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

AUTO: Fernando Gieseler is out of the office (returning 23/10/2009)

2009-10-15T12:02:17Z

I am out of the office until 23/10/2009.

Estarei de férias de 13/10 a 23/10. Para assuntos urgentes, favor contatar minha gerente, Andrea Rhors R. 2440 (TU) - arohrs@....
Be on vacation from 13/oct to 23/oct. For urgent matters, please contact my manager, Andrea Rhors R, 2440 (TU) - arohrs@....

Note: This is an automated response to your message "Re: Another problem in lenny installation (Debian for S390 )" sent on 15/10/09 10:41:18.

This is the only notification you will receive while this person is away.

Re: Another problem in lenny installation (Debian for S390 )

2009-10-15T06:41:18Z

Mike Kirjanov wrote:
> dasd: 0.0.0adf: default ERP in fastpath (4 retries left)
> dasd: 0.0.0adf: default ERP in fastpath (3 retries left)
> dasd: 0.0.0adf: default ERP in fastpath (2 retries left)
> dasd: 0.0.0adf: default ERP in fastpath (1 retries left)
> dasd_generic couldn't online device 0.0.0adf with discipline ECKD rc=-5

I have never seen these errors, so I can't really help her.

> # uname -a
> Linux debian503 2.6.26-2-s390 #1 SMP Fri Aug 21 16:47:41 UTC 2009 s390
> unknown "
>
> We have some explanation of this problem (maybe ) :
>
http://www.nabble.com/Bug-497843:-linux-2.6:--s390--2.6.26-does-not-boot-in-Hercules-emulator-td19318251.html

No. That issue has long been fixed. The current Lenny kernel works
perfectly in Hercules (at least for me).

Maybe this thread can help you (found through google):
http://www.mail-archive.com/linux-390%40vm.marist.edu/msg54335.html

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Another problem in lenny installation (Debian for S390 )

2009-10-15T01:48:32Z

Thank you, Frans Pop!

We have some progress in Debian for S390 (lenny ) installation: (after the question at the http://lists.debian.org/debian-s390/2009/10/msg00017.html )

When we used the remote repositaries (on the mirror.yandex.ru ) the installation process was progressed and now we are stopping at the dasd (eckd - 3390-3 model) preparing...
We have this message (see below ):

" Oct 15 11:57:27 kernel: [17182651.179251] dasd: 0.0.0adf: default ERP in fastpath (4 retries left)
Oct 15 11:57:27 kernel: [17182651.180728] dasd: 0.0.0adf: default ERP in fastpath (3 retries left)
Oct 15 11:57:27 kernel: [17182651.182214] dasd: 0.0.0adf: default ERP in fastpath (2 retries left)
Oct 15 11:57:27 kernel: [17182651.183677] dasd: 0.0.0adf: default ERP in fastpath (1 retries left)
Oct 15 11:57:27 kernel: [17182651.185183] dasd_generic couldn't online device 0.0.0adf with discipline ECKD rc=-5

# uname -a
Linux debian503 2.6.26-2-s390 #1 SMP Fri Aug 21 16:47:41 UTC 2009 s390 unknown "

We have some explanation of this problem (maybe ) :

http://www.nabble.com/Bug-497843:-linux-2.6:--s390--2.6.26-does-not-boot-in-Hercules-emulator-td19318251.html

What do you think about?

Thanks

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#550898: DASD DIAG driver doesn't work for read-only minidisks (s390, s390x only)

2009-10-14T11:10:58Z

I have come up with a patch that seems to solve my problem.

The mdsk_init_io internal subroutine of drivers/s390/block/dasd_diag.c
currently looks like this:

----------

/* Initialize block I/O to DIAG device using the specified blocksize and
* block offset. On success, return zero and set end_block to contain the
* number of blocks on the device minus the specified offset. Return non-zero
* otherwise. */
static inline int
mdsk_init_io(struct dasd_device *device, unsigned int blocksize,
blocknum_t offset, blocknum_t *end_block)
{
struct dasd_diag_private *private;
struct dasd_diag_init_io *iib;
int rc;

private = (struct dasd_diag_private *) device->private;
iib = &private->iib;
memset(iib, 0, sizeof (struct dasd_diag_init_io));

iib->dev_nr = private->dev_id.devno;
iib->block_size = blocksize;
iib->offset = offset;
iib->flaga = DASD_DIAG_FLAGA_DEFAULT;

rc = dia250(iib, INIT_BIO);

if ((rc & 3) == 0 && end_block)
*end_block = iib->end_block;

return rc;
}

----------

After the "rc = dia250(iib, INIT_BIO);" statement I add a
statement that sets rc to zero if it is 4. The resulting code
looks like this:

----------

/* Initialize block I/O to DIAG device using the specified blocksize and
* block offset. On success, return zero and set end_block to contain the
* number of blocks on the device minus the specified offset. Return non-zero
* otherwise. */
static inline int
mdsk_init_io(struct dasd_device *device, unsigned int blocksize,
blocknum_t offset, blocknum_t *end_block)
{
struct dasd_diag_private *private;
struct dasd_diag_init_io *iib;
int rc;

private = (struct dasd_diag_private *) device->private;
iib = &private->iib;
memset(iib, 0, sizeof (struct dasd_diag_init_io));

iib->dev_nr = private->dev_id.devno;
iib->block_size = blocksize;
iib->offset = offset;
iib->flaga = DASD_DIAG_FLAGA_DEFAULT;

rc = dia250(iib, INIT_BIO);

/* Fix for read-only minidisk */
if (rc == 4) rc = 0;
/* End fix for read-only minidisk */

if ((rc & 3) == 0 && end_block)
*end_block = iib->end_block;

return rc;
}

----------

This fix solves the problem. I can now get read-only minidisks to come online.

However ...

This fix also creates (or more likely exposes) another problem. When this fix
is on, devices which are manually taken offline immediately come online again!
I had this problem once before in an earlier kernel, but the problem eventually
went away with maintenance. But with this fix on, the original problem of
getting disks offline is back. The only way I can get around it is to
immediately detach the disk with CP. For example:

# echo 0 > /sys/bus/ccw/devices/0.0.0404/online;vmcp DETACH VIRTUAL 0404

If the device isn't there, it can't be brought online! But I shouldn't have
to resort to something like this. Someone really needs to take a closer
look at this.

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#550898: DASD DIAG driver doesn't work for read-only minidisks (s390, s390x only)

2009-10-13T15:04:57Z

Package: linux-image-2.6.26-2-s390x
Version: 2.6.26-19
X-Debbugs-CC: debian-s390@...

This bug report applies to the s390 and s390x Linux kernel architectures only.
I am reasonably certain that this is not a Debian-specific bug but
applies to all distributions. Nevertheless, since I am using Debian
I will report it to Debian. Please call this bug report to the
attention of the appropriate upstream kernel development team.

When using the DASD DIAG driver with a read-only minidisk, the
initialize function of DIAG X'250' fails. The error message produced
goes something like this:

dasd(diag) 0.0.0404: DIAG initialization failed (rc=4)
dasd_generic couldn't online device 0.0.0404 with discipline DIAG rc=-5

Consulting the IBM manual "CP Programming Services" for DIAG X'250',
I find the following explanation for return code 4 for the initialize
function:

Initialization for DIAGNOSE code X'250'
to the specified virtual device is
complete. The virtual device is
read-only. The starting block number and
the ending block number have been stored
in the BIOPL.

In other words, this is a normal condition, not an error. It is
simply a warning that this minidisk is read-only. The correct
response by the program should be to treat a return code of 4
the same as a return code of 0, provided that the device really
is read-only. A return code of 4 for a device that is supposedly
read-write is a sanity-check error that you might want to check
for. Otherwise, a return code of 4 is a normal and expected
condition.

I don't claim to be a C programmer, but it appears to me that
the mdsk_init_io internal subroutine of /drivers/s390/block/dasd_diag.c
is the culprit.

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Debian for S390 (lenny ) installation problem

2009-10-13T10:32:33Z

Mike Kirjanov wrote:
> 1. We are trying to install Debian for S390 (lenny ) distribution on the
> virtual machine (via z/VM 5.4 on the real mainframe ) and via Hercules
> 3.05 on the Linux Intel box. All our attempts is ended with the "WARNING
> **: bad d-i Packages file " message. We are using local repositories of
> the 5.0.3, 5.0.2 (stable ) and unstable verion (12.10.09 ) via http/ftp
> protocols. We are doubt what is wrong ? All our attempts to install the
> previous version of the Debian for S390 (etch ) were successful and we
> hadn't any installation problems at all.

As far as I know installing Lenny with current images should work fine.

It sounds as if your local repository is invalid, incomplete or corrupt in
some way. Have you tried installing using official mirrors?

Can you send us the system log (/var/log/syslog) for the installation?
Maybe we can get additional info from that.
Please make sure you gzip the syslog.

Cheers,
FJP

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

RE: Future of the s390 port

2009-10-13T05:35:43Z

You download the ISO file for the S390 distribution and burn the CD. You then use the the CD in the HMC and use the "Load from CD-ROM or Server method" (specify the directory as "/boot".

When I did this a few weeks ago I got a "kernel panic" as I reported on this list.

The tape files can be written to a tape and then IPL directly from that tape drive; however, that drive must be offline to ALL other LPARs on the system.

Thanks, .........Larry

-----Original Message-----
From: Stephen Powell [mailto:zlinuxman@...]
Sent: Friday, October 09, 2009 3:23 PM
To: debian-s390@...
Subject: Re: Future of the s390 port

>
> That would be great. Please see [1] for details. If you need additional
> info, just ask.
>
> Cheers,
> FJP
>
> [1] http://lists.debian.org/debian-s390/2009/09/msg00027.html
>
It sounds to me like you are asking for information on how to create a
mainframe-bootable CD. I'm afraid I don't know the answer. If you
have a specific .iso image that you want me to download and try to
see if it will boot, I can do that for you. But I don't pretend
to know how to create one.

I can see, though, from the link above, that you are using the
"generic" sub-architecture files. Have you tried using the "tape"
files? The reason I ask is that, on the Multiprise 3000, the CD-ROM
could be used as an emulated tape or via the "Load from CD-ROM or
Server" method. I just wonder if the tape files are what you
should use in that .ins file. Hey it's just a guess, but it's
worth a try.

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

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.

Debian for S390 (lenny ) installation problem

2009-10-13T02:21:02Z

Hi!

1. We are trying to install Debian for S390 (lenny ) distribution on the virtual machine (via z/VM 5.4 on the real mainframe ) and via Hercules 3.05 on the Linux Intel box.
All our attempts is ended with the "WARNING **: bad d-i Packages file " message. We are using local repositories of the
5.0.3, 5.0.2 (stable ) and unstable verion (12.10.09 ) via http/ftp protocols. We are doubt what is wrong ? All our attempts to install the previous version of the Debian for S390 (etch ) were successful and we hadn't any installation problems at all.

2. We have a great interest to the OpenOffice package on the Debian for S390 but as we understand it was not included into the etch distribution so we are need with the lenny distribution that contains full OpenOffice package (with Writer,Base,Draw and so on ).

Thanks.

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Future of the s390 port

2009-10-11T09:35:26Z

>
> Thanks a lot Bastian.
> I received basically the same info in a private mail from Adam (private
> probably because he forwarded it from a contact at SuSE). So thanks to
> them too.
>
> And with the help of google to fill in the missing bits I now have it
> working in Hercules again.
>

Well, I'm sorry I couldn't be of much help on this one. I'm afraid I'm
spoiled by z/VM. Since I have access to z/VM, I don't mess with LPARs much.
Perhaps my main contribution this time was to demonstrate that there are
people out there in the user community who care passionately about
the continued viability of the Debian s390 port. And perhaps that motivated
others who had the requisite knowledge to come forth. My next suggestion
was going to be "look at the install CD for another distribution and see
how they do it". But unfortunately I don't have access to such a CD myself.
And apparently neither did you. Fortunately, someone out there did.

:soapbox.
Documentation for IBM hardware really stinks these days. In the "old days",
when they were still operating under the consent decree, you could get
documentation for just about anything. But since the consent decree has been
canceled, they have been really tight with everything. For example, I can't
get documentation on the channel commands or sense bytes for 3590 tape control
units. I can't get documentation on the SERVC interface to the processor
controller (for things like I/O to the integrated system console, integrated
3270 console, obtaining the LOADPARM, etc.). And I'd be willing to bet that
you can't get documentation on the internals of "LOAD from a CD ROM or FTP
Server" either. All of that came out after the consent decree was canceled.
How ironic that the world's best server consolidation platform for open source
servers is so tight with its own documentation!
:esoapbox.

I might suggest that you modify the s390 install script to put in a plug
for this mailing list. I have been using Debian on s390 for years but only
joined this list last week. Perhaps there are others out there like me
who could be of service in some way if they were connected.

As I mentioned in an earlier post, I am working on a "how to" document for
getting the high-performance DASD DIAG driver to work for Debian on s390.
Perhaps that will be useful to someone. If I can be useful in some other
way, please let me know.

Regards,
Steve

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Future of the s390 port

2009-10-11T07:39:34Z

On Sun, Oct 11, 2009 at 04:20:28PM +0200, Frans Pop wrote:
> diff --git a/data/squeeze/s390/d390oco.ins b/data/squeeze/s390/d390oco.ins

This file can be removed.

If I can find the repo, I will do some cleanup in a few days.

Bastian

--
Warp 7 -- It's a law we can live with.

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Future of the s390 port

2009-10-11T07:20:28Z

Bastian Blank wrote:
> On Sat, Oct 10, 2009 at 08:00:13PM +0200, Frans Pop wrote:
>> Right, so who has a *recent* SuSE CD he/she can disect? I personally
>> don't feel like registering with Novell just for this.
>
> Well, I have an account and got an image.

Thanks a lot Bastian.
I received basically the same info in a private mail from Adam (private
probably because he forwarded it from a contact at SuSE). So thanks to
them too.

And with the help of google to fill in the missing bits I now have it
working in Hercules again.

Attached the patch for debian-cd (for squeeze). I've tested it for both
Lenny and Squeeze (the latter using current daily D-I images), so the same
changes work for both 31-bit and 64-bit kernels.

>> Main questions are:
>> - what does the .ins file they use look like?
>
> | * SuSE Linux for zSeries Installation/Rescue System
> | boot/s390x/vmrdr.ikr 0x00000000
> | boot/s390x/initrd.off 0x0001040c
> | boot/s390x/initrd.siz 0x00010414
> | boot/s390x/initrd 0x00800000
> | boot/s390x/parmfile 0x00010480

We did not yet specify initrd offset and size.

>> - what kind of initrd do they use: initramfs or "oldfashioned" initrd?
>> - if oldfashioned, then what filesystem do they use?
>> - if initramfs, then how do they manage to boot it?
>
> This are just memory loads, so this should work regardless of the type.
> The kernel handles both types in the same way.

Well, it worked without the size and offset for ext2 initrds. And at least
that defines block you quoted has been unchanged since the start of git
(2.6.12). Maybe there has been a change in the kernel, or maybe the
autodetection differs between initramfs and a "real" file system.

>> - what is the kernel config they use in their installer?
>
> The VM reader kernel.

Same as us then.

So with this weekly built CDs should work again very soon if you boot using
d390.ins. And Lenny CDs should work again with the next point release.

Note that I have not modified d390.tdf, which I assume is tape emulation.
I have no idea if that is supposed to be possible from CD. If someone knows
and wants to test that, please do.

Cheers,
FJP

diff --git a/data/squeeze/s390/d390.ins b/data/squeeze/s390/d390.ins
index 5e82599..78c5f11 100644
--- a/data/squeeze/s390/d390.ins
+++ b/data/squeeze/s390/d390.ins
@@ -1,4 +1,6 @@
* Debian GNU/Linux for S/390 (boot from CD-ROM or FTP-Server)
linux_vm 0x00000000
+root.off 0x0001040c
+root.siz 0x00010414
parmfile 0x00010480
root.bin 0x00800000
diff --git a/data/squeeze/s390/d390oco.ins b/data/squeeze/s390/d390oco.ins
index 03da8f6..b3f11dd 100644
--- a/data/squeeze/s390/d390oco.ins
+++ b/data/squeeze/s390/d390oco.ins
@@ -1,5 +1,7 @@
* Debian GNU/Linux for S/390 (boot from CD-ROM or FTP-Server with
OCO-Modules)
linux_vm 0x00000000
+root.off 0x0001040c
+root.siz 0x00010414
parmfile 0x00010480
root.bin 0x00800000
oco.bin 0x00c00000
diff --git a/tools/boot/squeeze/boot-s390 b/tools/boot/squeeze/boot-s390
index 6b3796f..34b8351 100755
--- a/tools/boot/squeeze/boot-s390
+++ b/tools/boot/squeeze/boot-s390
@@ -87,6 +87,10 @@ done
# - d390oco.tdf : same, using object-code-only-modules-ramdisk (example)
cp $BASEDIR/data/$CODENAME/s390/d390* "$imagedir/"

+# Create the files specifying offset and size of the initrd
+perl -e "print pack('N', 0x800000)" >"$imagedir/root.off"
+perl -e "print pack('N', -s '$imagedir/root.bin')" >"$imagedir/root.siz"
+
# Copy the README file
cp $BASEDIR/data/$CODENAME/s390/README.boot "boot$N/"

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Future of the s390 port

2009-10-11T05:40:32Z

On Sun, Oct 11, 2009 at 02:24:50PM +0200, Bastian Blank wrote:

> The addresses are specified this way:
> | #ifndef __s390x__
> | #define IPL_DEVICE (*(unsigned long *) (0x10404))
> | #define INITRD_START (*(unsigned long *) (0x1040C))
> | #define INITRD_SIZE (*(unsigned long *) (0x10414))
> | #else /* __s390x__ */
> | #define IPL_DEVICE (*(unsigned long *) (0x10400))
> | #define INITRD_START (*(unsigned long *) (0x10408))
> | #define INITRD_SIZE (*(unsigned long *) (0x10410))
> | #endif /* __s390x__ */
> | #define COMMAND_LINE ((char *) (0x10480))
>
> So the addresses for the initrd differs between the 31 and 64bit kernel.

Flawed observation. This way you can load the 32bit long addresses
always at the same location, regardless of the type.

Bastian

--
Only a fool fights in a burning house.
-- Kank the Klingon, "Day of the Dove", stardate unknown

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Future of the s390 port

2009-10-11T05:24:34Z

On Sat, Oct 10, 2009 at 08:00:13PM +0200, Frans Pop wrote:
> Right, so who has a *recent* SuSE CD he/she can disect? I personally don't
> feel like registering with Novell just for this.

Well, I have an account and got an image.

> Main questions are:
> - what does the .ins file they use look like?

| * SuSE Linux for zSeries Installation/Rescue System
| boot/s390x/vmrdr.ikr 0x00000000
| boot/s390x/initrd.off 0x0001040c
| boot/s390x/initrd.siz 0x00010414
| boot/s390x/initrd 0x00800000
| boot/s390x/parmfile 0x00010480

This looks like absolute addresses, so the contents of the initrd.off,
initrd.siz and parmfile files are written into the kernel image.

> - what kind of initrd do they use: initramfs or "oldfashioned" initrd?
> - if oldfashioned, then what filesystem do they use?
> - if initramfs, then how do they manage to boot it?

This are just memory loads, so this should work regardless of the type.
The kernel handles both types in the same way.

> - what is the kernel config they use in their installer?

The VM reader kernel.

More informations:

| $ l boot/s390x/{vmrdr.ikr,initrd*,parmfile*}
| -r--r--r-- 1 root root 12897335 8. Mär 2009 boot/s390x/initrd
| -r--r--r-- 1 root root 4 8. Mär 2009 boot/s390x/initrd.off
| -r--r--r-- 1 root root 4 8. Mär 2009 boot/s390x/initrd.siz
| -r--r--r-- 1 root root 71 8. Mär 2009 boot/s390x/parmfile
| -r--r--r-- 1 root root 102 8. Mär 2009 boot/s390x/parmfile.cd
| -r--r--r-- 1 root root 6761472 8. Mär 2009 boot/s390x/vmrdr.ikr
| $ hexdump -C boot/s390x/initrd.off
| 00000000 00 80 00 00 |....|
| 00000004
| $ hexdump -C boot/s390x/initrd.siz
| 00000000 00 c4 cc 37 |...7|
| 00000004
| $ cat boot/s390x/parmfile
| ramdisk_size=65536 root=/dev/ram1 ro init=/linuxrc TERM=dumb
| manual=1
|
| $ cat suse.ins
| * SuSE Linux for zSeries Installation/Rescue System
| boot/s390x/vmrdr.ikr 0x00000000
| boot/s390x/initrd.off 0x0001040c
| boot/s390x/initrd.siz 0x00010414
| boot/s390x/initrd 0x00800000
| boot/s390x/parmfile 0x00010480
| $ cat boot/s390x/suse.ins
| * SuSE Linux for zSeries Installation/Rescue System
| vmrdr.ikr 0x00000000
| initrd.off 0x0001040c
| initrd.siz 0x00010414
| initrd 0x00800000
| parmfile 0x00010480

The addresses are specified this way:
| #ifndef __s390x__
| #define IPL_DEVICE (*(unsigned long *) (0x10404))
| #define INITRD_START (*(unsigned long *) (0x1040C))
| #define INITRD_SIZE (*(unsigned long *) (0x10414))
| #else /* __s390x__ */
| #define IPL_DEVICE (*(unsigned long *) (0x10400))
| #define INITRD_START (*(unsigned long *) (0x10408))
| #define INITRD_SIZE (*(unsigned long *) (0x10410))
| #endif /* __s390x__ */
| #define COMMAND_LINE ((char *) (0x10480))

So the addresses for the initrd differs between the 31 and 64bit kernel.

Bastian

--
Murder is contrary to the laws of man and God.
-- M-5 Computer, "The Ultimate Computer", stardate 4731.3

signature.asc (204 bytes) Download Attachment

Re: Future of the s390 port

2009-10-10T18:13:00Z

On Oct 10, 2009, at 1:00 PM, Frans Pop wrote:

> Adam Thornton wrote:
>> Does the .ins file specify load addresses?
>
> Yes, it does.
> See: http://lists.debian.org/debian-s390/2009/09/msg00027.html
>
>> The short version I would suggest is "see how SuSE does it" and do
>> that.
>
> Right, so who has a *recent* SuSE CD he/she can disect? I personally
> don't
> feel like registering with Novell just for this.
>
> Main questions are:
> - what does the .ins file they use look like?
> - what kind of initrd do they use: initramfs or "oldfashioned" initrd?
> - if oldfashioned, then what filesystem do they use?
> - if initramfs, then how do they manage to boot it?
> - what is the kernel config they use in their installer?
>
> I've had CD boot working with an ext2 initrd and I suspect that
> would still
> work (and testing that would be fairly straightforward). But the
> Debian
> kernels have all moved away from that. So we really want to find out
> how
> to boot from CD using an initramfs initrd.
>
> If we can't I'd have to try to convince Bastian to compile ext2 into
> the
> s390 kernels again.

I have a recentish (SLES 10, not SLES 11) SuSE image I can get to
fairly easily, I think. I think their initrds were old-style, though.

I'll see what I can do with the rest of the weekend.

Adam

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Future of the s390 port

2009-10-10T11:00:13Z

Adam Thornton wrote:
> Does the .ins file specify load addresses?

Yes, it does.
See: http://lists.debian.org/debian-s390/2009/09/msg00027.html

> The short version I would suggest is "see how SuSE does it" and do that.

Right, so who has a *recent* SuSE CD he/she can disect? I personally don't
feel like registering with Novell just for this.

Main questions are:
- what does the .ins file they use look like?
- what kind of initrd do they use: initramfs or "oldfashioned" initrd?
- if oldfashioned, then what filesystem do they use?
- if initramfs, then how do they manage to boot it?
- what is the kernel config they use in their installer?

I've had CD boot working with an ext2 initrd and I suspect that would still
work (and testing that would be fairly straightforward). But the Debian
kernels have all moved away from that. So we really want to find out how
to boot from CD using an initramfs initrd.

If we can't I'd have to try to convince Bastian to compile ext2 into the
s390 kernels again.

Cheers,
FJP

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Future of the s390 port

2009-10-10T08:58:43Z

On Oct 10, 2009, at 6:10 AM, Frans Pop wrote:

> Stephen Powell wrote:
>> It sounds to me like you are asking for information on how to
>> create a
>> mainframe-bootable CD. I'm afraid I don't know the answer.
>
> That's a pity. Because that is *exactly* the information we need.
> And I'm
> very surprised that nobody in the community is able (or willing) to
> provide that info.
>
>> If you have a specific .iso image that you want me to download and
>> try to
>> see if it will boot, I can do that for you. But I don't pretend
>> to know how to create one.
>
> I can do that myself on Hercules (using the method described in the
> README
> file on current CD images).
>
>> I can see, though, from the link above, that you are using the
>> "generic" sub-architecture files. Have you tried using the "tape"
>> files? The reason I ask is that, on the Multiprise 3000, the CD-ROM
>> could be used as an emulated tape or via the "Load from CD-ROM or
>> Server" method. I just wonder if the tape files are what you
>> should use in that .ins file. Hey it's just a guess, but it's
>> worth a try.
>
> I doubt it will make a difference as the problem is not in the
> kernel, but
> in loading the initrd.
>
> But maybe I'm wrong and the method you describe really is different
> from
> what I can do in hercules. If you think it may help, please give it a
> shot. It should be trivial to create a CD image yourself as all you
> need
> is the D-I images and boot files. You don't need any packages on the
> CD to
> do an installation on s390.
>
> Besides, you have the hardware, I don't. So you can play around with
> different options, I can't.

Does the .ins file specify load addresses? The short version I would
suggest is "see how SuSE does it" and do that.

I don't have access to s390(x) hardware anymore either, I'm afraid.

Adam

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Future of the s390 port

2009-10-10T04:10:18Z

Stephen Powell wrote:
> It sounds to me like you are asking for information on how to create a
> mainframe-bootable CD. I'm afraid I don't know the answer.

That's a pity. Because that is *exactly* the information we need. And I'm
very surprised that nobody in the community is able (or willing) to
provide that info.

> If you have a specific .iso image that you want me to download and try to
> see if it will boot, I can do that for you. But I don't pretend
> to know how to create one.

I can do that myself on Hercules (using the method described in the README
file on current CD images).

> I can see, though, from the link above, that you are using the
> "generic" sub-architecture files. Have you tried using the "tape"
> files? The reason I ask is that, on the Multiprise 3000, the CD-ROM
> could be used as an emulated tape or via the "Load from CD-ROM or
> Server" method. I just wonder if the tape files are what you
> should use in that .ins file. Hey it's just a guess, but it's
> worth a try.

I doubt it will make a difference as the problem is not in the kernel, but
in loading the initrd.

But maybe I'm wrong and the method you describe really is different from
what I can do in hercules. If you think it may help, please give it a
shot. It should be trivial to create a CD image yourself as all you need
is the D-I images and boot files. You don't need any packages on the CD to
do an installation on s390.

Besides, you have the hardware, I don't. So you can play around with
different options, I can't.

Cheers,
FJP

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Future of the s390 port

2009-10-09T12:23:05Z

>
> That would be great. Please see [1] for details. If you need additional
> info, just ask.
>
> Cheers,
> FJP
>
> [1] http://lists.debian.org/debian-s390/2009/09/msg00027.html
>
It sounds to me like you are asking for information on how to create a
mainframe-bootable CD. I'm afraid I don't know the answer. If you
have a specific .iso image that you want me to download and try to
see if it will boot, I can do that for you. But I don't pretend
to know how to create one.

I can see, though, from the link above, that you are using the
"generic" sub-architecture files. Have you tried using the "tape"
files? The reason I ask is that, on the Multiprise 3000, the CD-ROM
could be used as an emulated tape or via the "Load from CD-ROM or
Server" method. I just wonder if the tape files are what you
should use in that .ins file. Hey it's just a guess, but it's
worth a try.

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Future of the s390 port

2009-10-09T10:14:21Z

Stephen Powell wrote:
> I shall be happy to do all of the above. I do have access to a real
> mainframe. It's a z/890 (2086). It's not one of the newest machines.
> It's not a z9 or z10. But it is 64-bit. And I do have a spare LPAR I
> can test with. And yes, I do know how to IPL Linux in an LPAR from CD.
> I don't know how to create an ISO image that the mainframe considers
> bootable; but if you point me to an ISO image I can burn a copy onto CD
> and IPL the thing and let you know if it came up OK.

That would be great. Please see [1] for details. If you need additional
info, just ask.

Cheers,
FJP

[1] http://lists.debian.org/debian-s390/2009/09/msg00027.html

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Future of the s390 port

2009-10-09T09:11:38Z

>
> Run it, try the different installation methods, especially with testing
> and unstable. Report the findings either as bugs or on the mailing-list.
> Show things that can be made easier to understand/use for the mainframe
> people.
>
> Maybe you know how to properly IPL systems from CD/DVD and can even test
> that. Maybe you have the possibility to run it on a LPAR instead of VM.
>
> Bastian
>

I shall be happy to do all of the above. I do have access to a real
mainframe. It's a z/890 (2086). It's not one of the newest machines.
It's not a z9 or z10. But it is 64-bit. And I do have a spare LPAR I
can test with. And yes, I do know how to IPL Linux in an LPAR from CD.
I don't know how to create an ISO image that the mainframe considers
bootable; but if you point me to an ISO image I can burn a copy onto CD
and IPL the thing and let you know if it came up OK. I also have z/VM
5.4.0 and can install in a virtual machine under z/VM. That's how I
normally do it. z/VM's LPAR has a dedicated IFL processor, and that is
it's only processor. The other LPARs, including my test LPAR,
share a standard processor.

I'm currently working on a "how to" document that explains how to get
the high-performance DASD DIAG driver to work under Debian. I'll post
a link to it on this list when I'm done.

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Future of the s390 port

2009-10-09T06:19:59Z

On Wed, Oct 07, 2009 at 04:37:07PM -0400, STEPHEN POWELL wrote:
> That would be awful! As you mentioned, Debian is the only remaining
> viable, non-commercial distribution of Linux for s390. And it would be
> a blow to Debian's goal of being "The Universal Operating System", as
> they advertise on their home page. I'd like to help. What can I do?
> I'm not a Debian developer or package maintainer. I'm an IBM mainframe
> system programmer, with both MVS and VM responsibilities.

Run it, try the different installation methods, especially with testing
and unstable. Report the findings either as bugs or on the mailing-list.
Show things that can be made easier to understand/use for the mainframe
people.

Maybe you know how to properly IPL systems from CD/DVD and can even test
that. Maybe you have the possibility to run it on a LPAR instead of VM.

Bastian

--
"We have the right to survive!"
"Not by killing others."
-- Deela and Kirk, "Wink of An Eye", stardate 5710.5

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Future of the s390 port

2009-10-08T13:03:03Z

I just joined this list server yesterday; so I apologize for
the un-timeliness of my replies to earlier posts.

> Is this really an important problem?
> Does a significant number of people actually use Debian/s390 on
> production servers? And if they exist, why they are not helping?

> --
> ciao,
> Marco

This logic makes an unwarranted assumption. It assumes that
those who use Linux on S/390 don't want to help. In most cases,
the problem is not a willingness to help but a lack of the requisite
skills to help. I have been using IBM mainframes for 34 years
as end user, application programmer, and system programmer. I know
a number of traditional mainframe programming languages, such as
PL/I, FORTRAN, and S/390 assembler language. And I know the
primary mainframe scripting language (REXX). But Linux is a
different animal. Linux is written in things like C, shell scripts,
perl scripts, etc. Those are not skill sets that a typical
mainframe developer would have. Similarly, the Linux gurus typically
know very little about the mainframe. The number of people with
advanced technical skills in both arenas is a very limited talent
pool. And many of them work for IBM, Suse, or Red Hat and may be
restricted by employment contract from helping with Debian.

I am willing to help. But I lack the requisite skills. I think
I have basic computer programming aptitudes, but I will need to
learn new skill sets before I can be useful. That probably won't
be in time for getting Squeeze into production. But I'm willing to
do whatever I can.

> One simple way to help a bit which will make it more visible to the
> Debian community at large that the s390 port is used, is to install
> and activate popularity-contest on these machines and thus make sure
> 236 machines show up on <URL: http://popcon.debian.org/ > as running
> the s390 port. :)

> At the moment, only 8 machines are reporting to popularity-contest,
> which put s390 in line with hurd-i386, kfreebsd-amd64 and m68k as
> ports with very small user groups. That number made me and probably
> others believe that very few are using the s390 port - at least until
> your email came along. :)

As a number of other responders have already said, this is a security
problem in the eyes of most network managers. There are a lot of
Debian s390 host images out there. But most of them are either
internal-use-only servers with no access to the internet or are
restricted by policy from participating in popcon.

We cannot allow the s390 port of Debian to die. That would be a
great tragedy. I've been extolling the virtues of free and open source
software for a long time and management is finally beginning to listen.
I just got approval this week for a new Debian s390 server for an in-house
pilot project. One of the reasons I got the approval is Debian's
"Universal Operating System" appeal. If the s390 port dies, management
is likely to either switch their focus back to Windows or else choose
another Linux distribution to work with, not just on the mainframe,
but on Intel boxes as well. Either way, Debian loses on all platforms.

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Problem on Instalation of Debian Lenny

2009-10-07T22:00:17Z

STEPHEN POWELL wrote:
> Hmm. These are the same symptoms as Debian bug report number 523942.
> Does that mean that stock kernel image linux-image-2.6.26-2-s390
> version 2.6.26-19 will work for me?

Current stable kernels should work fine.

> Don't ask me why the version created by
> make-kpkg works but the stock kernel image doesn't work, but that's how
> I've been circumventing the problem. I'd really like to get back to
> a stock kernel if I can.

Probably because you use a different compiler version.

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Problem on Instalation of Debian Lenny

2009-10-07T14:19:30Z

>> Well, I trying install Debian Lenny on System z behavior z/VM.
>> The first attempt was: I downloaded the essentials files from the
>> official mirror ftp server
>> (ftp://ftp.debian.org/debian/dists/lenny/main/installer-s390/current/im
>>ages/generic/) but, the message "[17179570.468526] Kernel panic - not
>> syncing: Attempted to kill init!" was displayed and the installation
>> stop.
>
> With the stable point release that's now available from the mirrors, s390
> should be installable again for Lenny.
>
> Note that new CD images with the fixed version will only become available
> sometime in the next few days.
>
> Cheers,
> FJP

Hmm. These are the same symptoms as Debian bug report number 523942.
Does that mean that stock kernel image linux-image-2.6.26-2-s390
version 2.6.26-19 will work for me? I've been continuing to build a
custom kernel with make-kpkg every time there's an update to the kernel
as my only circumvention. Don't ask me why the version created by
make-kpkg works but the stock kernel image doesn't work, but that's how
I've been circumventing the problem. I'd really like to get back to
a stock kernel if I can.

--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...