OSR5.0.7 LSIL BTLD problem


    Sponsored Links


  • 1. hyperthreading - is it only supported by 5.0.7?
    Hi, I know the new P4 xeons all support hyper-threading and we have several of them in our production systems. However as nothing has ever been tested on 5.0.7, is it possible to enable hyper-threading on 5.0.6? If so, does it make any difference. (on 5.0.7 even?) I don't think there is any chance of an upgrade to 5.0.7 (even if we are buying the licenses) as testing have moved away from SCO. Steve
  • 2. named error
    Hi all, I have an error appearing in my SCO Openserver 5.0.6 syslog file that I am hoping someone has experienced. The error message is: named: sysquery: findns error (NXDOMAIN) on machinename I have checked all files for errors in /etc/named.d and can find nothing apparent. TIA
  • 3. cannot open tar file.
    Good Da: this will be reaching back for some. I'm a newbie at linux. We have a SCO UnixWare 2.1.3. A tar was created (( tar -cvfhn tarball /dal )), this is the instruction given to me. I moved over to a redhat 6.0 box and did a (( tar xvf tarball /dal )). the file opened and created a directory /dal and created 2 sub directors /w0,/w1 with full data included. I am tryed to move the dirctory /dal to another sco computer also running SCO UnixWare 2.1.3. The dirs are from a Intel 360 box Xenix OS. On the new sco box I have tryed tar -xvfnp tarball /dal UX:tar INFO: 1 file not extracted tar -xvf tarball /dal UX:tar: INFO blocksize = 20 UX:tar: INFO: 1 file not extracted tar xvAf tarball /dal UX:tar: INFO: Suppressing absolute pathnames UX:tar: INFO 1 file not extracted Nothing seems to work. The file size is 54Meg. 1: trying to move this tarfile to another machine. 2: Can still go back to the other machine and create a new tar file of directory with new instruction with help :-). Please help to untar the file or create a new tar and open this tar on other computer. Thanks for any help.

OSR5.0.7 LSIL BTLD problem

Postby rlwcons » Sun, 20 Nov 2005 09:42:20 GMT


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

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, 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?

Has anyone EVER gotten lsil to work?

I had the same problem a year and a half ago with an IBM X-Series
server with an on-board LSI controller that required "lsil".  We ended
up disabling the on-board controller and installing an Adaptec
controller (ad320).

Thanks in advance for any help on this...


Re: OSR5.0.7 LSIL BTLD problem

Postby Brian K. White » Sun, 20 Nov 2005 11:43:01 GMT

----- Original Message -----
Newsgroups: comp.unix.sco.misc
Sent: Friday, November 18, 2005 7:42 PM
Subject: OSR5.0.7 LSIL BTLD problem

Makes no difference what block size was used to write.

All my LSI U320 cards need amird not lsil. Some dinky 80 mhz cards with
symbios chips one them we use for tape drives use lsil.

Sounds like sco doesn't like the usb floppy. The bios must not be making it
look like a legacy floppy well enough.
There may be a boot string that can tell the kernel how to read the floppy
where "fd(65)" will be something else.
I've never even tried to use a usb floppy on sco, especially during boot or
isl. A client shipped me a DL380-G4 with no floppy and I simply told him to
order the $50 floppy kit from wherever he got the server and ship it to me.
He did. It dropped into place in less time than it takes to say "proprietary
parts are stupid". That machine uses the ciss driver btw.

I was extremely agrevated by HP for the absolutely impossible proprietary
plugs on the motherboard such that I couldn't even temporarily plug in a
normal floppy. That's just stupid. 4 years from now when he needs to do
something and for whatever reason the bootable backupedge cd doesn't work
and we need the floppy to rinstall from scratch, and his dust-choked floppy
doesn't work and there is no way to proceed and he has to wait for another
stupid proprietary one to ship while about 100 users are down... actually,
in that event he'll be fine but only because he'll run on the copy we rsync
twice daily to _my_ server, and _my_ servers do not have very much in them
that can hold me up in an emergency like that. Whatever breaks, I can plug
in any of the 50 other units laying around at hand, I can rob things from
any desktop in a pinch, etc... In truth, now that that box has the special
little cable that came attached to the floppy drive, I could probably get
any random laptop drive to work in a pinch, ...if the box wasn't a few
thousand miles from me like it is.

Good luck :)

Brian K. White -- XXXX@XXXXX.COM -- http://www.aljex.com/bkw/
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

Re: OSR5.0.7 LSIL BTLD problem

Postby Bela Lubkin » Sun, 20 Nov 2005 19:07:05 GMT


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

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.

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

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 t

Re: OSR5.0.7 LSIL BTLD problem

Postby rlwcons » Wed, 23 Nov 2005 00:43:23 GMT

Bela, Brian, Tom,

Thanks for the suggestions.  By the way, "Bob" *is* my name -- I
usually stay no less anonymous than that when I post to public forums
-- I get enough spam as it is.

I tried your suggestion of booting a system with a traditional floppy
drive and you were correct -- "Boot: dir fd(65)" got me a directory
listing (README.TXT, lsil, yadda, yadda, yadda), so the diskette is OK.
 When I tried it on the HP with the USB floppy, I got an error message
to the effect that it couldn't see the drive.  The problem is that SCO
can't correctly see the USB floppy (your "subtle BIOS problem").

To Brian: It looks like this HP system ALSO has a proprietary connector
on the mainboard -- so (short of ordering the HP floppy kit) it will be
impossible to connect a legacy floppy drive to the system.

To Tom:  As I recall, we got the Adaptec from IBM (after 5 months of
wrangling and {*filter*} emails).  It came with a cable I used to connect it
to the backplane.

This morning I spoke to the vendor's tech support, and they are going
to find me a controller that's supported "out of the box" by SCO
OSR5.0.7, and doesn't require a BTLD floppy.

Also, Bela, I read your suggestion to try copying the BTLD image to the
HD using the live Linux CD.  That's all well and good, but since the
system requires the BTLD driver to see the HD, I don't quite understand
how I'd be able to get the boot process to see it, since the driver
we're trying to load is needed to read the device holding it.  Kind of
a chicken-and-the-egg problem.  Am I missing something here?

What about the possibility of writing the 1.4 MB LSIL BTLD to the front
end of a CD?  Has anyone tried that trick?  Can Nero Burning ROM (or a
Linux equivalent) do the functional equivalent of a RAWRITE?  Can
anyone point me to a procedure (maybe on SCO's site) to do that?  If
it's possible, what "hd(x)" device does one use to access a CDROM
connected as "Master" to IDE0?  I searched C.U.S.M, google,
APLawrence.com, and the SCO site for "CDROM BTLD" but only found
references to using a BTLD to get the system to SEE a CDROM, nothing
about using a CD to hold the BTLD during the ISL.

Also, I've been working with SCO systems since Xenix days (early to mid
80's), but wasn't aware of the "Boot: dir fd(x)" trick.  I've probably
only done 25 or 30 installs over those years.  Are there other
bootstring commands?  When I did Bela's test of the floppy, I tried
typing a question mark (?) at the Boot: prompt -- it gave me 4 devices
(fd, hd, net, and one other).  Any pointers to info on Boot: tricks
would be appreciated.

Thanks to all for replying, at least I can quit beating my head against
the wall.


Re: OSR5.0.7 LSIL BTLD problem

Postby Bela Lubkin » Wed, 23 Nov 2005 05:45:18 GMT


Were you mistaken in saying that when the boot process tried to read the
BTLD, the floppy light went on and the drive made noises?

If the light goes on and all, but access still fails, then I would
characterize it as a "subtle BIOS problem". Access is happening, but
apparently the wrong data is being transferred.

If the light doesn't go on, if you get an immediate error message,
that's not so subtle. Many BIOSes just don't hook the USB floppy up to
the BIOS floppy calls. That's more of a "blatant problem".

You are. The BTLD image is (as I mentioned) accessed twice by the boot

First, the /boot program reads it and links it into the kernel it's
loading. /boot is a pure BIOS client: it doesn't use its own hardware
device drivers. It should succeed in reading the BTLD off the hard disk
because essentially all PC SCSI controllers provide BIOS access.

Second, the OSR5 ISL process eventually wants to copy the BTLD into the
link kit on the hard disk it's installing. This will work since the
BTLD driver was stitched into the kernel you're running (by /boot).

That's a good idea, but I doubt it will work. Nero or pretty much any
CD burning software can do a "rawrite" equivalent -- just tell it to
burn a pre-made ISO (and lie that the floppy image is an ISO).

The problem is, you need OSR5 /boot to read that CD. It has _no_ device
by which to refer to a raw CD. OSR5 CD booting uses the "floppy
emulation" mode of the El Torito CD boot spec. There is an image of a
floppy somewhere on the OSR5 install CD. When you boot the CD, the BIOS
pretends it is reading the image's sectors from a floppy drive "A:".
That's why BTLDs are read from "fd(65)" when booting from a CD. 65 is
the minor number for "_2nd_ floppy drive".

It is totally possible to do this (I've tested it): read the floppy
image in from an OSR5 install CD. Mount it as a filesystem. Also mount
the BTLD image as a filesystem. Copy the contents of the BTLD onto the
boot floppy (root directory to root directory -- there won't be any file
conflicts). If the boot floppy's going to run out of room, delete the
file /unix.notebook (or /unix.small or something like that -- the
smaller of two Unix kernels on the image -- it will be obvious).

Then burn a new copy of the OSR5 boot CD, using the modified floppy
image as its boot image. Boot it. Use "defbootstr link=fd(64)lsil".
Notice how you have to specify "fd(64)", overriding the default.

This works, but requires you to perform several moderately difficult
operations. You would need an OSR5 system to be able to successfully
mount the boot floppy and BTLD images. Finding and surgically replacing
the boot image on the CD require special tools.

Using a hard disk partition as your BTLD is a much better bet (I think).

Replacing the HBA seems like a big overreaction...

There's a "debug" command at the boot prompt; activates a simple hex
de{*filter*}. You can also add "prompt" to the bootstring ("defbootstr
prompt"). This gets you a prompt right before the kernel starts. "v"
at that prompt gives you an interesting memory map. Similar maps from
"mem=/p" and "mem=/v" at the main boot prompt (similar but not identical
-- they show you memory /boot is _going to_ use, while "v" shows what it
actually used.) "debug" also works at that final prompt. You can
easily get /boot into a crazed state where it's trying to add the sam

Re: OSR5.0.7 LSIL BTLD problem

Postby rlwcons » Wed, 23 Nov 2005 10:12:40 GMT


Thanks for the reply.

The light comes on, the floppy drive spins, the head makes ticking
noises.  All this takes a good 15 to 20 seconds.  Then the "dir"
command comes back with:

    . not found
    Can't open fd(65)

Sounds like it's more of the "subtle BIOS problem" variety.

I knew that the BTLD needs to be seen twice, but didn't realize that
/boot could "see" the SCSI drive.  I guess that brings up another
question, if there's a low level SCSI BIOS mechanism that lets /boot
see the drive, why doesn't the install process go ahead and install
using that process, then, once the OS is up and running on the drive,
install the correct driver and re-link the kernel?

If I have time, I may give that a shot (2MB partition, BTLD->HD, read
BTLD from hd(47)), but the customer has already ordered an Adaptec
39160.  According to SCO (I almost had to beat the answer out of them!
;^), that adapter is supported right off the CD.  I'd like to avoid
this whole BTLD mess if I can.  The system this one replaces was an old
Compaq P2-350 or so.  Even if we can't run the drive at a full transfer
speed of 320, 160 will still blow their hair back, compared to their
old system.

Thanks again for the help,


Re: OSR5.0.7 LSIL BTLD problem

Postby Bela Lubkin » Wed, 23 Nov 2005 12:18:59 GMT


Yep. It's transferring gibberish from the floppy, or offset a few
sectors, something like that.

That would be technically possible, but there are lots of problems. The
ISL process runs under the full Unix kernel, so a device driver would
have to be written to call the BIOS disk routines from within Unix.
Standards for calling BIOS disk I/O from 32-bit protected mode took a
long time to solidify. Since OSR5 never tried to use them, I'm not sure
how much they stabilized in the end. Windows has hardware-specific
drivers for everything, so it has little or no reason to use the 32-bit
BIOS interfaces; who knows how much those interfaces have been tested?
Then, even if they worked, Unix would probably drive them harder than
Windows, flushing out bugs that wouldn't have been seen before.

In the end, such a driver _could_ and probably _should_ have been
written (even if it was problematic on some machines, it would probably
have worked in many cases, making ISL possible in many situations where
it is currently difficult). But it wasn't.

Most drives aren't really fast enough to light up a 160 bus, nevermind
320. The faster I/O bus becomes much more important if they have many
drives on the system (either as separate drives or as RAID -- an
external RAID should offer read transfer rates close to #drives times
the speed of a single drive).

If they're moving from a P2-350-era drive to a modern one, the drive
itself will probably be enough faster to notice. But they'd have
noticed that even through the klunky old controller.

Similar Threads:

1.OSR5.0.7 LSIL BTLD problem Reply-To: scomsc@xenitec.on.ca

 XXXX@XXXXX.COM  enscribed:
| Has anyone EVER gotten lsil to work?
| I had the same problem a year and a half ago with an IBM X-Series
| server with an on-board LSI controller that required "lsil".  We ended
| up disabling the on-board controller and installing an Adaptec
| controller (ad320).

I've an IBM x225 happily running on 5.0.7 with the lsil driver and
mirrored 73 gig hard drives.  I left my installation notes with
the machine but I'm pretty sure the driver version ended in .27

After giving up on 5.0.6 and smaller hard drives, the installation
wasn't difficult except IBM had to send me 4 additional hard drives before
I got a pair to work but that wasn't an OS/driver issue.

Would I do it again, no.  I'd insist on spending the additional money
for the IBM ServerRAID bits (which would have been overkill on this

If you stuck an Adaptec host adapter in an x225 I'd be interested in
where you found the cable/adapter to connect it to the backplane.
 Tom Parsons                    XXXX@XXXXX.COM    

2.Tape verify/restore problem (OSR5.06)


running SCO Unix OSR5.06a on PIV 2.8, 256Mb ram, U160 Adaptec 29160 SCSI 
controler, 36gb hdd on 68pin port (external terminator on cable), SLR5 
tandberg data tape drive on 50pins port (internal default tandberg 

making backups with cpio, or tar, or Lone-Tar, when trying to 
verify/restore tape, I always get errors at anywhere on then tape. 
(telling that "lone tar, directory not in proper format", "cpio bad 
So I put the SLR5 on another machine, it works fine.
I tried another scsi cable, same results ==> errors.
I tried another tape drive (SLR4), same results ==> errors.

So could it be the SCSI controler, or an SCO bug, or any chipset or 
motherboard ?


3.Form feed problem with Xerox PE120i (SCO Unix OSR5.0x)


running SCO Unix OSR5.05 and 5.06 boxes, Progress V8.3C11 sgbdr.
we recently install on some of our distant sites, Xerox PE120i 
multi-function printers (including ethernet port with LPD server)
I configure it as remote printers.
If I send from Unix a file, it works well.
Now from Progress, if I send a file where I put a "page-size" command in 
program code, the file prints, and then a blank form feed page is 
printed at the end of job.
(the "page-size size-number" command puts ^L in file when line number is 
equal to size-number, and puts one ^L at the end of the file).
We've got a Xerox DC535 running under SCO Unix OSR5.06 in BSD remote 
format, and this problem doesn't appear.
Is the problem coming from the LPD server on Xerox PE120i ?


Enlever ".remove-me" dans l'adresse.
Remove ".remove-me" from e-mail.

4.iknt panic OSR5.0.4 - telnetd problem?

    We are running OSR5.0.4 on a Compaq Proliant 3000 dual PII (w/ SMP), ECC
memory, RAID and Netelligent NIC.  We recently started migrating our dumb
serial terminals (on a Digi Xem multiport board) to Ethernet NCD X-terminals
so the Netelligent is under increasingly heavy telnet load.  An intermittent
kernel panic has started to become a once-a-day occurrence and practically
crippled us after we added a Sonicwall appliance with VPN access to the
    Running _fst and crash, it appears that ikntrput (iknt) - telnetd - is
being fingered as the culprit.  The panic screen shows an eip value of

        # echo ts F01948ED | crash
        dumpfile = /dev/mem, namelist = /unix, outfile = stdout
        ikntrput + 0x12d

        # _fst /unix -
        * main?
        main:            0x8b55    = push    ebp
        * f01948ed
        ikntrput+0x12d: 0x8b66    = mov    ax,Word Ptr [eax+0x40]

    Required patches were installed long ago - rs504c supplement, oss469c
(Networking & SMP), oss469d (Networking & Core OS), oss471c (PII microcode),
oss481a (SNMP suppl), oss485a (memory suppl), oss480a (HTFS) & oss601(Y2k).
oss605a (Netbios drivers) was not installed, but nb is not found (or used)
on the system.

    I found an old thread in Google groups referring to exactly this panic
source (from 2002-12-20 to 2002-12-23) and the last post was from Bela
Lubkin who said:

> iknt does character I/O on behalf of rlogind and/or telnetd, avoiding
> the need to wake up a user process for every character of I/O.  The
> panic you're seeing has been seen before; I will see if a fix is
> available.

> >Bela<

Bela - or anyone - if this panic "has been seen before", was there ever a
fix or cause determined related to telnet, OS, drivers or NIC hardware?  I
can try replacing the NIC, upgrading the OS, Compaq EFS (5.46a currently),
replacing the power supply, memory or machine, but if we suffer through
daily system crashes on this production system while I try to guess what's
wrong, I'll probably end up looking for a new job!  Any more info or hints
would be greatly appreciated!

-Keith Temby

5.More info (was Tape verify/restore problem (OSR5.06))

I put the scsi controler on another machine and it works fine.
I put from another machine another U160 29160 scsi controler, and I 
always get errors;

the motherboard is an Asus P4PE-X/TE, could it be the cpu speed?, the 
hyper-threading ?



Frederic STOCK a rit :
> Hello,
> running SCO Unix OSR5.06a on PIV 2.8, 256Mb ram, U160 Adaptec 29160 SCSI 
> controler, 36gb hdd on 68pin port (external terminator on cable), SLR5 
> tandberg data tape drive on 50pins port (internal default tandberg 
> terminator).
> making backups with cpio, or tar, or Lone-Tar, when trying to 
> verify/restore tape, I always get errors at anywhere on then tape. 
> (telling that "lone tar, directory not in proper format", "cpio bad 
> header",).
> So I put the SLR5 on another machine, it works fine.
> I tried another scsi cable, same results ==> errors.
> I tried another tape drive (SLR4), same results ==> errors.
> So could it be the SCSI controler, or an SCO bug, or any chipset or 
> motherboard ?
> Thank's.

6. BTLD Floppy disk for Cristie CD1600

7. DOS Disk for BTLD

8. Fresh install with BTLD and no floppy drive

Return to unix


Who is online

Users browsing this forum: No registered users and 95 guest