Apparently the email I sent Jim on this crossed with this one.  In case
anyone else is interested, I decided to repeat myself here.

One way to make sure the IPL text is being written out is to print off the
first 2048 bytes of what you believe is your IPL volume.  You probably used
the ipleckd.boot file when you ran silo.  If you do "od -t x ipleckd.boot"
you should see something like this:
# od -t x ipleckd.boot
0000000 00080000 800000f0 06000000 00001000
0000020 00000000 00000000 00000000 00000000
*
0000120 00000000 00000000 000a0000 00000058
0000140 000a0000 00000060 00080000 00000100
0000160 000a0000 00000070 00080000 800002a0
0000200 00000000 00000000 00000000 00000000
*
0000360 581000b8 50100c6c b234031c 96840321
0000400 97010337 b232031c 97060068 58200308
0000420 d2072000 0312b766 03004160 07c85060
0000440 0300a7f5 00b59680 03b54850 03a2be53
0000460 07fabe53 03c25820 00e05830 02e4a748
0000500 0001a7e5 004e58a0 02e4a758 0004d507
0000520 0312a000 a7840031 5820a000 1f44bf41
0000540 a0071f33 bf3ea004 a75e0000 a784000f
0000560 1954a744 00051b54 a7f4001b a72a0001
0000600 06404a30 03a24650 017c1222 a7840006

If you do this:
od -tx -N 2048 /dev/dasda

The output should be _very_ similar (it won't be exact).

If you do that on a volume where there is _no_ IPL text written, it should
look like this:
od -N 2048 /dev/dasda -tx
0000000 00000000 00000000 00000000 00000000
*
0004000

That output says that bytes 0-2047 all have binary zeros in them.

So, if you can find out which of your two DASD volumes have the IPL text on
it, then you can cross-check that with "cat /proc/dasd/devices" to make sure
you know what unit address is associated with that volume, and try IPLing
from there.

Mark Post

-----Original Message-----
From: James Melin [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 12, 2002 4:49 PM
To: [EMAIL PROTECTED]
Subject: Re: Attempting first IPL after initial SuSE install


First off, thanks to all of you whom tried to help me here.

As far as I can tell, I have done everything to excruciating exactness. I
have evidence that Yast did everything it was supposed to do, as I found it
created a parmline file with the correct information in it. I have
attempted running silo with the root path changed to /mnt/ via chroot, with
the PWD set relative to that into /boot (which would have been /mnt/boot
before the chroot) and I've specified the options for silo properly. It
even appears to write the block properly.

Regardless of what I have attempted and all of your wonderful advice, I
still get a Dev status of 0C and subchannel status of 40.

This makes me beg the question, has anyone here installed suse linux 7.0,
native in an LPAR, without VM, in a setup using strictly ficon to go to a
ficon switch and from there to a shark dasd box?

I will further assume that the block silo says it write the boot map to is
relative to the number of inodes on the device, and will therefore vary?

Is there any tool that can examine the disk while it is mounted and SHOW
what the IPL record on disc contains and where it is? Where does the IPL
process expect the IPL record to be?


Thanks again everyone. This is just driving me nuts

-J

Reply via email to