Re: OSR5.0.7 LSIL BTLD problem

• Previous message: Brian K. White: "Re: OSR5.0.7 LSIL BTLD problem"
• In reply to: rlwcons_at_gmail.com: "OSR5.0.7 LSIL BTLD problem"
• Next in thread: rlwcons_at_gmail.com: "Re: OSR5.0.7 LSIL BTLD problem"
• Reply: rlwcons_at_gmail.com: "Re: OSR5.0.7 LSIL BTLD problem"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: 19 Nov 2005 05:07:05 -0500

rlwcons@gmail.com wrote:

> It's been years since I posted a question to Usenet, so if my
> netiquette is rusty, please accept my apologies...

Looks fine, except your mailer didn't include a real name. It's more
pleasant to respond to someone with an actual name.

> This is the second time I've been bitten by the "Ultra-320/lsil" gator
> -- when I was just trying to drain the swamp ;^)
>
> A client of mine is moving off an old Compaq server, running OSR5.0.4.
> They ordered an HP ProLiant ML110G3. The server has an LSI Logic SCSI
> controller -- called an "HP Single Channel Ultra320 SCSI" adapter by
> HP. On the back of the card, the part # is LSI20320-HP. After
> searching the SCO website, talking for an hour to HP Unix/Linux tech
> support, and even talking to a helpful LSI Logic tech support guy, I'm
> still where I was when I started this morning.
>
> I've downloaded 3 different packages with files purported to be the
> BTLD for "lsil".
>
> Since modern laptops and servers DON'T come with floppy drives, I used
> a USB floppy drive to both generate the BTLD disk, and to attempt to
> use it at system installation.
>
> To generate the disk, I used RAWRITE.EXE from a WinXP laptop. The
> light turned on, the motor whirred, and the heads tick-tick-ticked
> across the diskette. SCO's instructions say to use dd(1), but since I
> don't have an SCO system available locally, I used RAWRITE.
>
> The first time I tried to install, I typed "defbootstr link=lsil" at
> the Boot: prompt. The CD booted, I got a couple of pages of dots
> (......), and it came up to the prompt to insert the BTLD disk. The
> USB floppy drive was connected to a USB port on the server. The BTLD
> diskette was inserted, the light came on, the drive whirred, and the
> head tick-tick-ticked across the diskette. The next thing I saw was:
>
> Sorry, that volume does not contain the lsil package
> Please insert the fd(65)lsil .....

Ok, stop right there...

Take the CD and floppy you are using to a more normal machine with a
"legacy" floppy drive. Boot the CD. Use "defbootstr link=lsil" and see
if it likes the floppy. (You can do this on any machine you're willing
to reboot. Booting the install to this point won't do anything to the
hard disk(s).)

If the test machine doesn't like the floppy, there is something wrong
with your copying methods (as you suspected).

If the test machine _does_ like it, there's a problem reading the USB
floppy at boot time on the HP ProLiant ML110G3 (as Brian White
suspected). In this case, boot the test machine a second time. At the
boot prompt, enter "dir fd(65)". This gives you a crude directory
listing (names only) of the floppy. Now do the same thing on the
ML110G3. Do you get a directory listing at all? Show us the output.

> OK, maybe there's a problem with RAWRITE.EXE, or the USB diskette
> drive. I rebooted the server with a live Feather Linux CD, which,
> incidentally, saw the U320 controller without a hiccup. I su'ed to
> root, and dd'ed from /dev/sda the contents of the diskette. I then ran
> sum(1) and got the same checksum as the SCO documentation said I
> should. The only difference was that it was 1440 blocks instead of
> 2880 blocks, since Linux uses a 1024 byte block and SCO uses 512.
>
> I've tried the other two so-called "lsil" BTLDs with the same result.
>
> Here are my questions (sorry for the long-winded tale of woe):
>
> Could the use of RAWRITE be my problem?
> Could the fact that SCO is looking for 512 byte blocks, but RAWRITE
> (and Linux) use 1024 byte blocks be the problem?
> Could the use of a USB diskette drive be the problem?

Since you got a correct sum from Linux, the image on the floppy is
probably fine. Which means it is almost certainly a problem with
accessing the USB floppy at boot time.

You were very clear about the fact that when you enter "link=lsil", the
OSR5 boot _does_ spin the floppy and make noises. Usually if there are
going to be problems with USB floppies at boot time, it doesn't get that
far. The most usual problem is that the BIOS doesn't make a USB floppy
respond to BIOS floppy calls.

So this is some sort of more subtle BIOS problem.

We could beat our brains out on this, but let me propose a crazy
workaround.

Boot your live Linux CD. Make a very small partition on the hard disk
(1440K, rounded up to whatever the `fdisk` UI wants -- 2MB or 1GB or
whatever). Make sure this is a _primary_ partition, not an extended
partition. Now copy the floppy image onto the partition:
`dd if=/dev/floppy of=/dev/hda2` -- replacing "hda2" with whatever
device node points to your newly created partition.

Boot the OSR5 CD and try "dir hd(15)". 15 is the minor number meaning
"the first partition, as a whole". If that doesn't work, try "dir
hd(23)", then 31, 39. These are the minor numbers for partitions 2, 3,
4. You need to try all 4 (until one works) because OSR5 and other OSes
sometimes disagree about partition ordering.

If one of the numbers works, you'll see a directory listing similar to
what you saw on the test machine, you're home free. Now you can enter
"defbootstr link=hd(15)lsil" -- substituting your successful minor
number. (BTW, on an already installed OSR5 system, "dir hd(40)" should
show the files on the /stand filesystem.)

If none of the numbers work, it'll be due to an issue that relates
strongly to the issue I mentioned with USB floppy access in the BIOS.
Non-IDE hard disk controllers have to jerk around with the system BIOS
in order to make hard disks accessible at the BIOS level. Some don't do
this at all, some do a poor job, some do a great job. Many also have a
controller setup option that controls whether drives are accessible from
BIOS. You might need to hit "control-L" (or whatever the LSI controller
uses for setup) and turn on the "drives accessible from BIOS" option.
But my guess is it'll just work.

I first wrote this recommending that you make the small partition the
active (bootable) partition from Linux `fdisk`. Then you would be able
to use "hd(47)" at the boot prompt. 47 is the minor number for "active
partition on the first drive". The problem with this is, OSR5 install
will want to refer back to the BTLD a second time during install, after
the kernel link kit has been written to the hard disk, in order to copy
the "lsil" driver into the link kit. By then the active partition will
be your new OSR5 install, so it won't be able to find the BTLD. Using
an absolute partition minor number avoids this pitfall.

This also means you shouldn't tell the OSR5 install "use entire disk for
Unix". Tell it "use rest of disk". You'll lose the use of a small
amount of space (probably 1440K or 2MB, practically invisible on modern
drives). After the install is all done, you could choose to delete the
BTLD partition, freeing up its space (which isn't significant) and also
its partition table slot (which might be important, depending how you
intend to use the system).

> Has anyone EVER gotten lsil to work?

People have posted here with problems farther down the line (old
versions of "lsil" saw disks larger than 64GB as [actual size mod
64GB]), so yes...

I've never tried this BTLD-on-partition concept, but it really ought to
work. If you try it, please follow up with your results -- success or
failure, with details. If my procedure is a bit off, correct me.

Thanks,

>Bela<

2005-11-19: I am looking for an interesting job that takes advantage of
            my skills. Resume at <http://lubkin.com/bela/resume.html>.

• Previous message: Brian K. White: "Re: OSR5.0.7 LSIL BTLD problem"
• In reply to: rlwcons_at_gmail.com: "OSR5.0.7 LSIL BTLD problem"
• Next in thread: rlwcons_at_gmail.com: "Re: OSR5.0.7 LSIL BTLD problem"
• Reply: rlwcons_at_gmail.com: "Re: OSR5.0.7 LSIL BTLD problem"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]