Merge Installation/Configuration Problem on OpenServer 5.0.7
Transpower
run /usr/bin/installwindows, I get the following messages:
Install Windows 9x from /usr/merge/dosroot/wincabs
Internal error - can't read configuration
Internal error - can't read configuration
Error 10: The personal drive directory in the win configuration is not valid
Cannot continue. Exiting ...
Whew. Anybody here know what to do?
Transpower
Transpower
I had to index the documentation....well, OK, I guess. I ran this program:
/usr/lib/docview/conf/rundig -i -v
It seemed to finish. But when I went back into Help I got the message "Unable
to read word database file '/usr/lib/docview/db/dbwords.db'". Did you run
htmerge? Well, no. If I try to run /usr/bin/htmerge, I get the message
"Unable to find configuration file '/opt/www/htdig/conf/htdig.conf'
Whew. I love 5.0.4's Help system. What the hell has SCO done now? The same
thing with the online version of TA. The old method was much, much better.
Has anyone on this list gotten Merge to work on 5.0.7?
Transpower
to...@aplawrence.com
>/usr/lib/docview/conf/rundig -i -v
I had similar problems; from http://aplawrence.com/Reviews/osr507.html
DocView
Docview is the new SCO help system. One of the first things you need to
do is run /usr/lib/docview/conf/rundig to build its indexes. Be prepared
for that to take a LONG time: on this admittedly weak machine, the
process took an amazing 5.5 hours! But then everything was painfully
slow with this. I finally got impatient and threw in some more memory,
which helped a lot. For the heck of it, I reindexed (using -i to make
it do the whole thing) after bumping the ram up to 384MB; that took just
about as long. Reindexing isn't particularly healthy for the rest of
your system either: my sar %idle was at 0 throughout this process.
But the indexing wasn't complete at all. For example, while there is a
"usb" man page, Docview search turned up absolutely nothing for "usb".
I did notice that at SCO's web site, a Docview search for "usb" did
turn up the appropriate pages, so it had to be something silly that
interfered with indexing on my machine. So, I did it a third time.
This took an incredible 10 hours, but when it finished, Docview could find
"usb" in a search.
You cannot index if you have used dhcp to get an address for this box.
The supposed reason is that the machine doesn't have a fixed ip address
(see /usr/lib/docview/conf/README). Pretty silly, I think.
You may recall that in previous versions, "man" wouldn't work if scohttp
wasn't running. In 5.0.7, "man" does not depend on Docview (/etc/docview
stop|start|restart if you care).
--
to...@aplawrence.com Unix/Linux/Mac OS X resources: http://aplawrence.com
Get paid for writing about tech: http://aplawrence.com/publish.html
Transpower
I still get a "configuration" error when I attempt to install a personal copy
of Windows 98. I believe there is a bug in the install script. I'm going to
wait until I get an updated CD.
Transpower
Jean-Pierre Radley
| I then attempted to go into the Help to find an answer. I got the message that
| I had to index the documentation....well, OK, I guess. I ran this program:
|
| /usr/lib/docview/conf/rundig -i -v
Don't try to second-guess the instructions, which are to run
/usr/lib/conf/rundig
without any options.
| It seemed to finish. But when I went back into Help I got the message "Unable
| to read word database file '/usr/lib/docview/db/dbwords.db'". Did you run
| htmerge? Well, no. If I try to run /usr/bin/htmerge, I get the message
| "Unable to find configuration file '/opt/www/htdig/conf/htdig.conf'
|
| Whew. I love 5.0.4's Help system. What the hell has SCO done now? The same
| thing with the online version of TA. The old method was much, much better.
|
| Has anyone on this list gotten Merge to work on 5.0.7?
Certainly.
--
JP
Jean-Pierre Radley
Please stop posting messages with absolutely no context -- you're just
wasting our time, we have no idea *what* you tried again...
--
JP
Transpower
I don't have /usr/lib/conf/rundig on my system. Maybe you mistyped?
As for the procedure to install Windows 98:
In root, I ran Merge Tools --> Merge Setup --> System-Wide Administration -->
Load Windows CD. This prompted for a Start Disk, which fortunately I had (but
really Merge should use a switch on Windows setup to avoid this, because it's
not appropriate in this environment). Then I logged in as a regular user and
ran Merge Tools --> Merge Setup --> Personal Windows Setup. This is where I
get the "configuration" problem. I believe there is a bug in the script
installwindows.sh. How's that for content?
Regards,
RWS
trans...@aol.com
Bob Bailin
"Transpower" <trans...@aol.com> wrote in message
news:20030801183130...@mb-m03.aol.com...
Better, but this new info would have helped if you related it sooner.
The installation program is asking you for a startup disk because you're
using
a Win98 CD that's not bootable. And if I remember correctly, you cannot use
the Win98 Update CD. You have to use either the Win98 Full Retail CD or the
Win98 OEM CD, both of which are bootable. And to save yourself a lot of
grief, you should be using Win98 2nd edition.
At this point, you may want to consider removing Merge 5.3.7 using custom,
then running the 'remove.sh' script in either /usr/lib/merge or /usr/merge
to
completely remove any remaining Merge-related files on your system, then
rebooting your machine before installing Merge 5.3.23 with custom.
This will clear out any problems that may be left from previous mis-attempts
to install Windows.
Bob
Transpower
I went to download Merge revision 23 and found that it was in CPIO format. On
AOL, this just displays as text on the screen--it doesn't FTP properly to a
file. Besides, why would this file be in CPIO format and not in VOL format?
What should I do now--call SCO on Monday?
Regards,
RWS
trans...@aol.com
to...@aplawrence.com
Many VOL. files are just cpio archives - there's nothing unusual about
that.
Why on earth would you use AOL???
But even if you have to, you can still use IE once AOL connects, and
then simply SHIFT-CLICK to download.
Jean-Pierre Radley
Instead of just clicking on that file (or on the release_notes files),
use Shift-Click instead.
The cpio archive conatins VOL files, as expected.
--
JP
Transpower
choice was HTML, which wouldn't do). I then attempted to extract the VOL files
using cpio -i. Didn't work. What command am I supposed to use? I thought
cpio was marked for obsolescense years ago.
Jean-Pierre Radley
Saved it as a "text" file? What stupid client are you using? It isn't a
text file, it's a binary.
--
JP
Transpower
Obviously it's a binary file. But AOL and Explorer just give the two choices
of HTML or text. OK, so now what? Can someone just send me a normal tar.Z
file of this patch?
Regards,
RWS
trans...@aol.com
Jean-Pierre Radley
| JP:
|
| Obviously it's a binary file. But AOL and Explorer just give the two choices
| of HTML or text. OK, so now what? Can someone just send me a normal tar.Z
| file of this patch?
Then install Netscape or Mozilla. Or don't use Windoze at all, use the
OSR 5 box itelf.
--
JP
to...@aplawrence.com
Huh??
What on earth gave you THAT idea?
Certtainly pax has started to replace it and tar, but I don't
think it will be "obsolete" for many a year.
Transpower
Just do a man on cpio.
Nachman Yaakov Ziskind
> Transpower <trans...@aol.com> wrote:
> >OK, JP, I downloaded the file and saved it as a "text" file (the only other
> >choice was HTML, which wouldn't do). I then attempted to extract the VOL
> > files using cpio -i. Didn't work. What command am I supposed to use? I
> > thought cpio was marked for obsolescense years ago.
Actually, you're supposed to tell custom where the VOL.* files live ("Media
Device: Media Images" option), and custom handles the heavy lifting.
--
_________________________________________
Nachman Yaakov Ziskind, EA, LLM aw...@egps.com
Attorney and Counselor-at-Law http://yankel.com
Economic Group Pension Services http://egps.com
Actuaries and Employee Benefit Consultants
Transpower
then installed the latest revision, 23. But, alas, to no avail. I still get
the same configuration errors (see below) when I attempt to create or use a
personal copy of Windows ME. The problem could be the Start Disk; I still
don't know why this is required. How does one go about creating this disk
without an ME machine available?
Exact statements of error messages:
CONFIGUNR: Win: Error: The configuation win is not readable.
CONFIG_READ_FAIL: dos: ERROR: Failed to read config <NIL>: 268870008 Error 4,5,
unable to continue
to...@aplawrence.com
>Tony:
>Just do a man on cpio.
Where? Are you talking about the references to the -H oldc/newc stuff??
That doesn't make cpio obsolete :-)
Transpower
me three Start Disks: ME, 98 SE, 98. Cost me $10.70. Came back and tried the
Merge install again. No luck. Still the same configuation error messages when
I go in as non-root to install/use Personal copy of Windows or DOS. Has anyone
here actually used this version of Merge (rev. 23) under OpenServer 5.0.7?
Jean-Pierre Radley
You asked this question two days ago, and I answered you: certainly. I
just now have Mozilla open under X Window, and another Mozilla under
W98SE under Merge in the same X Window session.
Custom says I've got:
NeTraverse Merge (ver 5.3.23a)
SCO OpenServer Enterprise System (ver 5.0.7Hw)
You have also been asked, more than once, to stop posting context-less
messages. Please pay attention.
--
JP
Transpower
See message #20 in this thread. I'm saying that I get the same error messages
with the correct Start Disks using both Windows ME and Windows 98. So that
rules out the Start Disks as being the problem. So, any other ideas to try?
to...@aplawrence.com
You don't understand Usenet. We can't necessarily refer back to previous
postings. Depending on how quickly our servers expire messages, your
older posts can be gone in a day. Even if it hasn't expired, few of
us are willing to make any extra effort to find information that is
your responsibility to supply.
That's why you need to quote context if you expect useful answers.
If you don't like it, fine. But you'll quickly find that people
will just start ignoring you. Usenet will become a black hole
that your posts spiral into, never to be acknowledged. Like
any social group, you either play by the groups rules or you
get shunned. JPR is nice enough to try to warn you. Most don't
care enough even to do that.
Unfortunately for us, though it may be percieved by some as an
encouragement, Microsoft intends to change all that:
http://aplawrence.com/Blog/B315.html
I am reminded of a long time radio talk show host here in Boston
who, for years before he finally did retire, would rail in
disgust against what his world was becoming, and would close
with "I'm getting out of the business". I'm nearing the time
when I'll be able to retire. It's only a few years away, but
I'm feeling like Jerry Williams of Boston.. the barbarians
truly are at the gates, and there is nothing to be done but
let them in.
As to your actual problem, I have nothing to offer. I run VPC
on my Mac laptop, but I wouldn't run Merge on an office server.
Unless you value your time far less dearly than I value mine,
you've already thrown away far more than the cost of a cheap
PC and a KVM switch, which is how I deal with this always.
Merge on SCO offers nothing of value that I can see.
Jean-Pierre Radley
Context, as I've invoked it here, has zilch to do with your error
messages. I am talking about having some minimal quoting of prior
messages in your new postings.
I happen to read this newsgroup as email, so I save just what I choose.
I have not found this particular thread so entrancing that I would have
saved each and every part of it,
Nor do I know how anyone else, using any newsreading method, would find
"No. 20". Newsgroups aren't numbered that way.
In any case, whatever help you get here is given freely by people who
care to do so. We are not required to be able to summon your No. 20.
If you want folks to follow the discussion, provide some context. We're
not at your beck and call to backtrack through some archive.
I'm done with this thread.
--
JP
Transpower
a list of all messages in a thread and so I get the entire context. I can go
to any message in the list.
Update on Attempting to Install/Configure Merge 5.23: I realized that there
must be a permission problem in a user, since the problem wasn't the Start
Disk. So I created a new user under 5.0.7 and this time the install of
Personal Windows went much further, proving that the in-place upgrade did not
upgrade certain user data/permissions. However, I now get this message:
"This version of Windows requires MS-DOS 7.1 and currently MS-DOS 6.x or older
is installed. If someone already has Windows 3.1 installed and this MS-DOS is
upgraded to MS-DOS 7.1, the Windows 3.1 will not work anymore. If this is the
situation it is best to install the upgrade version of Windows 95, because it
has MS-DOS 7.0 which works with Windows 3.1. If you really want to install the
Windows from this CD then you first need to log in as 'root' and install DOS
from this CD. Windows installation failed."
But I've completely removed the previous version of Merge (from the 5.0.4
installation), and I've installed DOS/Windows using the latest revision of
Merge. Is the previous version of DOS hiding somewhere? Any ideas?
Transpower
I ran DOSINSTALL (from root) to remove the current version of DOS and install
DOS 8, but then I got this message:
CONFIG_READ_FAIL : dos :ERROR: Failed to read config <NIL>: 268870008, Error 4,
5. Unable to continue.
This means there is some other permission problem, with root no less.
Bill Vermillion
Transpower <trans...@aol.com> wrote:
Context means putting some of the message to which you are replying
in the message you post.
How am I to know what message '#20 in this thread' is. I have
nothing that gives messages numbers in a thread - and knowing the
reading I'm using there are lots of others. The message
has a number on it - and in THIS system it is #24872 - sure to be
different on ever new server extant.
"message #20" also pre-supposes that all sites get all the messages
in a thread - and that is a false presumption. I see holes in
threads quite often.
And think how this message would look as a standalone - there is no
indication to what it is about.
Shortening messages too far is just as bad as including all the
text of a huge message only to comment on one paragraph or
sentence.
Bill
--
Bill Vermillion - bv @ wjv . com
Bela Lubkin
> OK, I see your problem, JP and Tony. With the AOL news group reader I can see
> a list of all messages in a thread and so I get the entire context. I can go
> to any message in the list.
Apparently you do not see, because you still do not comply.
> Update on Attempting to Install/Configure Merge 5.23: I realized that there
> must be a permission problem in a user, since the problem wasn't the Start
> Disk. So I created a new user under 5.0.7 and this time the install of
> Personal Windows went much further, proving that the in-place upgrade did not
> upgrade certain user data/permissions. However, I now get this message:
>
> "This version of Windows requires MS-DOS 7.1 and currently MS-DOS 6.x or older
> is installed. If someone already has Windows 3.1 installed and this MS-DOS is
> upgraded to MS-DOS 7.1, the Windows 3.1 will not work anymore. If this is the
> situation it is best to install the upgrade version of Windows 95, because it
> has MS-DOS 7.0 which works with Windows 3.1. If you really want to install the
> Windows from this CD then you first need to log in as 'root' and install DOS
> from this CD. Windows installation failed."
>
> But I've completely removed the previous version of Merge (from the 5.0.4
> installation), and I've installed DOS/Windows using the latest revision of
> Merge. Is the previous version of DOS hiding somewhere? Any ideas?
As far as I can tell from this context-free discussion, you are trying
to install some version of Windows (you don't say which -- you've
mentioned several along the way) -- using boot disks that were made for
you by a tech at some computer store. In order for this to have any
chance at all, the boot disk and Windows install media you're using will
have to exactly match. Since you've mentioned neither in this message,
every single reader is in the dark. You're just throwing words to the
wind.
Merge requires a boot disk because Windows installation requires a boot
disk. If you had a completely blank PC you would not be able to install
Windows from unbootable media, you would need a boot disk. Merge
_could_, technically, provide internal boot media. But this would
violate Microsoft's copyrights, and the authors of Merge would have been
put out of business more than 10 years ago. I suspect that with current
Windows media kits, they might even technically be able to install
without a boot disk; however, the software scrupulously follows the
original requirement so that there is no question at all of Merge
promoting piracy of Windows.
You could of course use your own pirated media, but you would be doing
that under your own power, neither encouraged nor abetted by Merge. In
fact, it sounds like this is pretty much what you _are_ doing, trying to
use Windows upgrade media whose salient differences from full product
media are (1) they aren't bootable, (2) they're cheaper. And hey,
you're paying the price in frustration and confusion. The system works.
>Bel<
to...@aplawrence.com
>OK, I see your problem, JP and Tony. With the AOL news group reader I can see
>a list of all messages in a thread and so I get the entire context. I can go
>to any message in the list.
No, it's not OUR problem. It's your problem because you assume that
the manner in which the morons at AOL present Usenet to you is
ubiquitous. They don't understand Usenet, you don't understand
Usenet, and the result is all this foolishness.
We'll have an avalanche of this sort of misunderstanding when Microsoft
gives the world their view of Usenet, again with no regard for the reality
of how it actually works. http://aplawrence.com/Blog/B315.html
for those who missed the earlier mention of that.
Dumbing things down for the masses actually does make things dumb.
Transpower
RE: Merge Installation/Configuration on 5.0.7
Here's the context--I've tried both Windows 98 and Windows ME with the
respective Start Disks and got the same error messages. I have the latest
version of Merge, 5.3.23. For some unknown reason, Merge seems to think there
is still a pre-existing version of DOS (from the previous 3.22t version of
Merge) installed on the system which prevents the installation of DOS 8 and a
Personal copy of Windows ME or 98. I have filed a Bug Report with SCO.
Transpower
>Context means putting some of the message to which you are replying
>in the message you post.
OK, I can use AOL's Quote option to put some of the message to which I'm
replying in the response message I'm posting, as above.
On the topic at hand, I filed a Bug Report with SCO.
Transpower
Windows
Thanks to an e-mail from Roger Cornelius (rac...@tenzing.org) we're getting
warm now. DOS is now working! His solution is to delete $HOME/win,
$HOME/.merge, and $HOME/mydata, which I did for one user. But when I attempt to
install Windows I get the same error messages, as before. The version of DOS
is the ME one, not 6.x, so I still don't know where the installer is getting
the idea that it is.
Bob Bailin
"Transpower" <trans...@aol.com> wrote in message
news:20030804101144...@mb-m10.aol.com...
I'm going to give this one last try:
In the course of installing/upgrading/re-installing Merge, you've clobbered
something,
somewhere. The easiest solution is to start from square 1. Using custom,
remove
SCO Merge. Reboot. Go to /usr/lib/merge and run the script final_remove.sh
which
will clean up the remaining merge stuff not removed by custom. Also remove
all
personal merge data using: rm -r /usr/*/.merge
and rm -r /usr/*/win
Reinstall SCO Merge 5.7.23 and reboot. Using X-Windows and logged in as
root, install DOS from your favorite version of Windows (98 or ME). Be
absolutely sure you're using a full retail or OEM version on CD. Upgrade
versions are simply not supported. If you're unsure of whether you have an
upgrade version, try to boot from the CD on another machine. Upgrade
versions of Win9x don't boot from CD.
Also as root, install an image of the same Windows CD to make user
installation simpler. Then, as an ordinary user, install Windows from that
CD image. If for some reason this step fails, install Windows directly from
the Windows CD instead.
Document every step. You should get no errors at any step above.
Bob
Bob Bailin
"Bob Bailin" <72027...@compuserve.com> wrote in message
news:aMxXa.16384$Vx2.8...@newssvr28.news.prodigy.com...
Additional note: Installing Windows ME *requires* a startup disk, which
comes with the full retail version of WinME, otherwise you have to make
one on an exisitng WinME system. WinME requires that MS-DOS 8.0
be the underlying OS, not an earlier version.
Jean-Pierre Radley
You were strongly advised NOT to do an In-Place Upgrade...
--
JP
Transpower
issue was the residual .merge and win directories. The script writer for Merge
should flag this problem.
However, after installing ME I tried to install/use COM port 2 for serial modem
connection, and the system crashed. In UNIX I did the usual enable tty2A
command--this hung the system. So I've got DOS and Windows ME installed but
cannot modem out. More trouble.
Transpower
to...@aplawrence.com
Lordy.
Is this worth it?
First of all, as I and JPR pointed out, you shouldn't have done an IPU.
You might have been way ahead if you weren't so stubborn on that.
But secondly, you are spending days of effort and frustration on
a piece of crap that could be replaced with a $500.00 or less machine
and a KVM switch.
I dunno. I wouldn't waste my time with this. Not only does it cost
precious time, but the frustration affects everything else you
do. It's just not worth it, and even if you get it working, it's always
an on-going problem: runs slow, some things won't work, you have to hold
your breath every time Windows Update runs (well, I guess we do that
anyway) - why bother? And Windows Me?? Sheesh.. tie me up and
stick me with long sharp knives before I'd willingly put that on a
computer.
Transpower
>stick me with long sharp knives before I'd willingly put that on a
>computer.
Tony:
The reason for Merge and ME is just so I can modem out using AOL, my ISP. I
don't have an ISP for the UNIX system. I will need various OpenServer
supplements in the future so that's why all the fuss. For instance I
understand that there may be a problem with dual Xeon processors using
hyperthreading--I'll probably have to download a supplement for that, etc.
to...@aplawrence.com
>>And Windows Me?? Sheesh.. tie me up and
>>stick me with long sharp knives before I'd willingly put that on a
>>computer.
>Tony:
>The reason for Merge and ME is just so I can modem out using AOL, my ISP. I
>don't have an ISP for the UNIX system. I will need various OpenServer
Seriously: why on earth do you use AOL? I can see keeping an AOL email
if you have had it for a while (though it's hokey for a business to have
an AOL address when it is so easy to get transpower.com or whatever), but
you can dump the AOL dialup and use one of the many low price nationwide
services that don't need Windows: for example, http://world.std.com,
which is what I use when my DSL at our vacation home goes away as it so
often does. Because their dial is just ppp, you can even use it
with things like Multitech's little routers with dial-out ability.
With that, you can get your AOL mail with any browser, keep the lowest
possible AOL account because you'll use it only for mail, and have a
much happier life.
Or again, put up an XP machine and have it share its connection.
Far easier than this mess.
Transpower
Tony:
I have 10 MB of disk space for my Web site included in my AOL account. I'm not
going to change to another provider.
Now, onto the problem at hand: Running SCO's modem manager freezes the system.
There is nothing wrong with the hardware. I have two hard drives on this
computer: one for SCO UNIX and one for Microsoft Windows XP Pro. I can boot
to either by means of choosing the boot channel (A or B) of the 3940AUWD SCSI
host adapter. XP Pro works with the COM port and modem perfectly. OpenServer
5.0.7 does not. Any ideas?
to...@aplawrence.com
>>Seriously: why on earth do you use AOL?
>Tony:
>I have 10 MB of disk space for my Web site included in my AOL account.
So do just about all of 'em.
> I'm not going to change to another provider.
OK. You can lead a horse to water.. you probably think I'm being annoying,
but honestly I'm trying to be helpful. You don't look like a real business
with an aol email address and an aol web site. Not to mention that you
could get better for less money..
>Now, onto the problem at hand: Running SCO's modem manager freezes the system.
SCO's modem manager has been a piece of junk since day one. Apologies to
the SCO engineers involved with this but you've been screwing it up for
years.
> There is nothing wrong with the hardware. I have two hard drives on this
>computer: one for SCO UNIX and one for Microsoft Windows XP Pro. I can boot
>to either by means of choosing the boot channel (A or B) of the 3940AUWD SCSI
>host adapter. XP Pro works with the COM port and modem perfectly. OpenServer
>5.0.7 does not. Any ideas?
Don't use it?
Configuring modems is very simple; there are a number of posts and articles at my site.
Start with http://aplawrence.com/Unixart/modems.html and a search for "modem" at
http://aplawrence.com/search.html
Transpower
>with an aol email address and an aol web site
Tony: My Web site address is www.transpowercorp.com. You wouldn't know that
it's an AOL site, would you?
>Configuring modems is very simple; there are a number of posts and articles
>at my site.
I've configured SCO UNIX modems for years. I'm telling you that there is a
problem in this release 5.0.7--something has changed and it's not working the
way it used to with serial ports.
to...@aplawrence.com
>>You don't look like a real business
>>with an aol email address and an aol web site
>Tony: My Web site address is www.transpowercorp.com. You wouldn't know that
>it's an AOL site, would you?
OK, that's good. You don't list it that way at http://aplawrence.com/consultants.html
Next you are going to say: I never got anything from that, so I don't bother.
And you are right: I see nothing in the past month indicating anyone clicked
on your link from there. But they did click on other sites: 255 at least
(those are human clicks, btw - search engine accesses don't get counted).
Which just might prove my point about aol addresses. Glad to see that you DO
have transpower.com - do they not let you use it for email or do you use
the aol address here for spam control? Just curious: I personally can't
see aol surviving too much longer, but if they start doing intelligent
things like that maybe I'm wrong..
>>Configuring modems is very simple; there are a number of posts and articles
>>at my site.
>I've configured SCO UNIX modems for years. I'm telling you that there is a
>problem in this release 5.0.7--something has changed and it's not working the
>way it used to with serial ports.
And I'm telling you that there have been problems with SCO's modem manager
forever..
But regardless: we are agreed, it's broken. You think it can be fixed, I
say to hell with it, take 20 seconds and configure it manually. I'd rather
have a working modem now than a working modem manager someday.
Jean-Pierre Radley
I'm telling you there is no problem. My modems work just as well as
they ever did on tty1A/tty2A or on my Specialix ports on 5.0.7 as they
ever did on Xenix or Unix 3.2v4.x or OSR 5.0.[02456].
--
JP
Transpower
OK, JP, I believe you. But something is wrong here. I got to page 7 of Tony's
modems.html and typed
cu -ltty2a dir
The system rebooted!!!! But in XP I use the very same port, cable, and modem
without any problem. Hence there is a software problem in my installation of
SCO 5.0.7 somewhere. That very same command worked perfectly on this very same
computer using 5.0.4.
Bela Lubkin
Ok, then tell us about the hardware. Show output of `hwconfig -h`, for
starters. `hw -v -r pci` would be good, but it's much too long to post.
Also `ls -l /dev/tty2a`, just in case it's simply a wrong device node.
Are you trying to access it from a text multiscreen or from X
(scologin)? It's possible you're getting a panic, but can't see it, if
you're running from X. Do it from tty01 (Ctrl-Alt-F1), see if there's a
panic message. If so, post it here (complete).
>Bela<
Transpower
>Show output of `hwconfig -h`, for
>starters. `hw -v -r pci` would be good, but it's much too long to post.
>Also `ls -l /dev/tty2a`, just in case it's simply a wrong device node.
device address vec dma comment
======== ============= === === ================================================
kernel - - - rel=3.2v5.0.7 kid=2003-02-18
cpu - - - unit=1 family=6 type=Pentium Pro
cpuid - - - unit=1 vend=GenuineIntel step=sA1
fpu - 13 - unit=1 type=80387-compatible
pci 0xcf8-0xcff - - am=1 sc=0 buses=3
eisarom - - - eisa (1.3.0)
PnP - - - nodes=0
clock - - - type=TSC/199.431783Mhz
serial 0x3f8-0x3ff 4 - unit=0 type=Standard nports=1 base=0 16550A/16
serial 0x2f8-0x2ff 3 - unit=1 type=Standard nports=1 base=8 16550A/16
console - - - unit=vga type=0 num=12 scoansi=0 scroll=50
adapter 0xf000-0xf0ff 15 - type=alad ha=0 bus=0 id=7 fts=sto
adapter 0xf400-0xf4ff 10 - type=alad ha=1 bus=0 id=7 fts=sto
floppy 0x3f2-0x3f7 6 2 unit=0 type=135ds18
floppy - - - unit=1 type=48ds9
kbmouse 0x60-0x64 12 - type=Keyboard|PS/2 mouse id=0x00
parallel 0x378-0x37a 7 - unit=0
udi - - - UDI environment
adapter - - - ha=0 type=usb_msto UDI SCSI HBA
OlyTune - - - Pacific CodeWorks, Inc. System TuneUp
OlyTune - - - Olympus TuneUp Release 6.0.0P
dcxf0 0xfc00-0xfc7f 9 - type=DE500-AA addr=00:00:F8:09:A5:CC
cd-rom - - - type=S ha=0 id=3 lun=0 bus=0 ht=alad unit=0
tape - - - type=S ha=1 id=6 lun=0 bus=0 ht=alad unit=0
disk - - - type=S ha=0 id=0 lun=0 bus=0 ht=alad unit=0
Sdsk - - - cyls=8942 hds=255 secs=63 unit=0 fts=stdb
Sdsk-0 - - - Vnd=MAXTOR Prd=ATLASU320_73_WLS Rev=B120
usb_ehci - 16 - PCI bus=0 dev=13 func=2
usb_ohci - 17 - PCI bus=0 dev=13 func=0
usb_ohci - 18 - PCI bus=0 dev=13 func=1
cpu - 255 - unit=2 family=6 type=Pentium Pro
cpuid - - - unit=2 vend=GenuineIntel step=sB1
fpu - - - unit=2 type=80
No obvious conflicts in hardware settings
crw-rw-rw- 1 bin bin 5, 8 Jul 17 1996 /dev/tty2a
>Do it from tty01 (Ctrl-Alt-F1), see if there's a
>panic message. If so, post it here (complete).
Unexpected trap in kernel mode [followed by a group of hex addresses I hope
you don't need]
PANIC: K_trap -kernel mode trap 0x0000000E
Cannot dump 32671 pages to dump dev hd (1/41)
space for only 25000 pages
Dump not completed
** Safe to Power Off **
-or-
** Press Any Key to Reboot **
Ronald J Marchand
memory is properly seated..
Ron
to...@aplawrence.com
>Bela:
>Unexpected trap in kernel mode [followed by a group of hex addresses I hope
>you don't need]
>PANIC: K_trap -kernel mode trap 0x0000000E
>Cannot dump 32671 pages to dump dev hd (1/41)
>space for only 25000 pages
>Dump not completed
>** Safe to Power Off **
> -or-
>** Press Any Key to Reboot **
While we are waiting for Bela to see that, go read
http://aplawrence.com/Unixart/trape.html
Bela Lubkin
> Bela:
>
> >Show output of `hwconfig -h`, for
> >starters. `hw -v -r pci` would be good, but it's much too long to post.
> >Also `ls -l /dev/tty2a`, just in case it's simply a wrong device node.
You are still assuming that your readers remember everything about the
thread. Please quote more, enough for a completely new reader of the
thread to know what's going on by reading just your one message.
We're still under the now irrelevant subject line of "Merge
Installation/Configuration Problem on OpenServer 5.0.7", so that doesn't
give me any clues.
I vaguely remember that maybe you were having trouble when accessing the
serial port. Yes, that must be it.
Hmmm, 200MHz Pentium Pro with USB 2.0 -- odd combo.
Ok, so the two serial ports are on IRQ 4 and 3, as expected. There are
three USB HCIs on three fake IRQs. To get their real IRQs, run `hw -v
-r pci > /tmp/pci`. Look through the entries for the three with
ClassCode values of 0x0c0310 and 0x0c0320 (they'll also be recognizable
by their DeviceNum 13, Function 0/1/2, and Bus 0). Note the
InterruptLine value for each of those.
Are any of them pointed at IRQ 3 or 4?
If so: go into BIOS setup and insist that IRQs 3 & 4 are reserved for
"ISA" or "Legacy" or whatever your BIOS calls them. Or, alternatively,
take the USB add-on card out of the bus.
> crw-rw-rw- 1 bin bin 5, 8 Jul 17 1996 /dev/tty2a
That looks fine.
> >Do it from tty01 (Ctrl-Alt-F1), see if there's a
> >panic message. If so, post it here (complete).
>
> Unexpected trap in kernel mode [followed by a group of hex addresses I hope
> you don't need]
Well, yeah, the hex addresses are the meat of the thing. But they also
need to be translated locally on your system, so just seeing the hex
numbers wouldn't help much anyway. Write down the "eip" number, then
run:
# crash
> ts f000baaa
> quit
(using the eip number). That should give you a symbol name and offset.
What is it?
> PANIC: K_trap -kernel mode trap 0x0000000E
> Cannot dump 32671 pages to dump dev hd (1/41)
> space for only 25000 pages
> Dump not completed
> ** Safe to Power Off **
> -or-
> ** Press Any Key to Reboot **
This shows that you have less swap space than RAM. That's fine for
normal operation, but it prevents you from capturing a crash dump. A
captured crash dump would help debug this. So, do this. Boot with:
Boot
: defbootstr mem=1m-96m
Then provoke the panic.
Then reboot (no special bootstring), go to single-user mode, run:
# crash
> panic -w /tmp/panic
> quit
Post the contents of /tmp/panic.
>Bela<
peri
>
> I ... typed
> cu -ltty2a dir
> The system rebooted!!!!
Transpower of AOL,
Do I remember reading in this thread that you
upgraded to 5.0.7 from an older version ?
I have to wonder if things would go better
for you if you had started with a new
full install from scratch.
This is one reason why I am still using 5.0.6.
I do "NOT" want to do an upgrade to 5.0.7 and haven't had
time yet to to a full install from scratch.
Peri
-
-
Bob Bailin
"Bela Lubkin" <be...@sco.com> wrote in message
news:20030807024...@sco.com...
Transpower wrote:
>> Bela:
>>
>> >Show output of `hwconfig -h`, for
>> >starters. `hw -v -r pci` would be good, but it's much too long to post.
>> >Also `ls -l /dev/tty2a`, just in case it's simply a wrong device node.
>
>You are still assuming that your readers remember everything about the
>thread. Please quote more, enough for a completely new reader of the
>thread to know what's going on by reading just your one message.
>
>We're still under the now irrelevant subject line of "Merge
>Installation/Configuration Problem on OpenServer 5.0.7", so that doesn't
>give me any clues.
Actually, still strangely relevant. See below.
>
>I vaguely remember that maybe you were having trouble when accessing the
>serial port. Yes, that must be it.
...while attempting to use serial port from Merge 5 to dialup AOL.
200MHz Pentium Pro + Merge 5 + Windows ME = bizarre combo
EISA bus + anything more than char based apps = you're wasting our time.
My god, I have a 1-yr retired PPro system that's more current than this one.
Dual PIII Overdrive processors, PCI-ISA only bus, the works! And I never
considered running anything more taxing than Win31 on it.
Last month I tossed 2 perfectly functioning Acer PPro systems because it
was just too painful to use them with Win98 (directly).
I'm sorry, but had I known this hardware configuration at the beginning of
these threads, the issue of fresh install vs. upgrade would *not* have been
my primary concern.
Bob
Transpower
>We're still under the now irrelevant subject line of "Merge
>Installation/Configuration Problem on OpenServer 5.0.7", so that doesn't
>give me any clues
Actually this problem arose under Merge when I attempted to install a modem in
Windows ME, which failed, causing me to attempt to install a modem directly in
UNIX--so here we are.
>Hmmm, 200MHz Pentium Pro with USB 2.0 -- odd combo.
> Well this a 1997 machine (shortly to be replace with a dual-Xeon 3.06 GHz
system), with a 2002 add-in USB card.
>three USB HCIs on three fake IRQs. To get their real IRQs, run `hw -v
They are at IRQ's 10, 11, and 9--not at 3 or 4.
>Write down the "eip" number, then
>run:
>
> # crash
> > ts f000baaa
> > quit
The eip number is 0x00000000. There is no text symbol near 0 in symbol table,
so no offset.
>Post the contents of /tmp/panic.
>
> panic -w /tmp/panic
System Messages:
rd=ATLASU320_73_WLS Rev=B120
G drain8042
H oeminit
%usb_ehci - 16 - PCI bus=0 dev=13 func=2
%usb_ohci - 17 - PCI bus=0 dev=13 func=0
%usb_ohci - 18 - PCI bus=0 dev=13 func=1
H cinit
NOTICE: TuneUp OK status1: EBEC8B55 F01A5AA0 909090B9 83EC8B55
H inoinit
H fsinit
H DEVFS init
H DOS init
H DTFS init
H HS init
H HTFS init
H XENIX init
H NFS init
H finit
H strinit
H ksl init
H iinit
H flckinit
H seminit
H msginit
H xsdinit
H xseminit
H cfgmsginit
I cpyrtstart
I sockstart
I igmpstart
I incfstart
I rtestart
I wdstart
I arpstart
I ipstart
I ripstart
I icmpstart
I lo_start
I tcpstart
I udpstart
I vnettstart
mem: total = 130684k, kernel = 32580k, user = 98104k
J fpeinit
K swapadd
swapdev = 1/41, swplo = 0, nswap = 200000, swapmem = 100000k
M ecc_init
rootdev = 1/42, pipedev = 1/42, dumpdev = 1/41
kernel: Hz = 100, i/o bufs = 18628k (high bufs = 13040k)
M mp_enable
CONFIG: tab: Configuration buffer full (MAX_CFGSIZE = 2048 exceeded) on dev 0/3
M crllry_rate
M sco_count_processors
M pmregister
M enable_watchdog
N kmdaemon
N htepi_daemon
N vddaemon
N init
N vhand
N bdflush
N strd
T.519-usbd0 000D1 <Drvr16>: Descriptor parse failed during enumeration!
NOTICE:
====== ERROR #1 <Status=OK> .519-usbd0 000D1 <Drvr16>
Descriptor parse failed during enumeration!
usb_msto: Inquiry Read failed, Unbinding!
usb_msto: Please disconnect and re-attach the device to try again.
T.1340-usb_msto0 0200 2 <Drvr16>: Initialization failure. Please reattach the
device to retry.
NOTICE:
====== ERROR #2 <Status=OK> .1340-usb_msto0 0200 2 <Drvr16>
Initialization failure. Please reattach the devce to retry.
No Panic
> pani -w /tmp/panic
System Messages:
rd=ATLASU320_73_WLS Rev=B120
G drain8042
H oeminit
%usb_ehci - 16 - PCI bus=0 dev=13 func=2
%usb_ohci - 17 - PCI bus=0 dev=13 func=0
%usb_ohci - 18 - PCI bus=0 dev=13 func=1
H cinit
NOTICE: TuneUp OK status1: EBEC8B55 F01A5AA0 909090B9 83EC8B55
H inoinit
H fsinit
H DEVFS init
H DOS init
H DTFS init
H HS init
H HTFS init
H XENIX init
H NFS init
H finit
H strinit
H ksl init
H iinit
H flckinit
H seminit
H msginit
H xsdinit
H xseminit
H cfgmsginit
I cpyrtstart
I sockstart
I igmpstart
I incfstart
I rtestart
I wdstart
I arpstart
I ipstart
I ripstart
I icmpstart
I lo_start
I tcpstart
I udpstart
I vnettstart
mem: total = 130684k, kernel = 32580k, user = 98104k
J fpeinit
K swapadd
swapdev = 1/41, swplo = 0, nswap = 200000, swapmem = 100000k
M ecc_init
rootdev = 1/42, pipedev = 1/42, dumpdev = 1/41
kernel: Hz = 100, i/o bufs = 18628k (high bufs = 13040k)
M mp_enable
CONFIG: tab: Configuration buffer full (MAX_CFGSIZE = 2048 exceeded) on dev 0/3
M crllry_rate
M sco_count_processors
M pmregister
M enable_watchdog
N kmdaemon
N htepi_daemon
N vddaemon
N init
N vhand
N bdflush
N strd
T.524-usbd0 000D1 <Drvr16>: Descriptor parse failed during enumeration!
NOTICE:
====== ERROR #1 <Status=OK> .524-usbd0 000D1 <Drvr16>
Descriptor parse failed during enumeration!
usb_msto: Inquiry Read failed, Unbinding!
usb_msto: Please disconnect and re-attach the device to try again.
T.1338-usb_msto0 0200 2 <Drvr16>: Initialization failure. Please reattach the
device to retry.
NOTICE:
====== ERROR #2 <Status=OK> .1338-usb_msto0 0200 2 <Drvr16>
Initialization failure. Please reattach the devce to retry.
No Panic
> panic -w /tmp/panic
System Messages:
Prd=ATLASU320_73_WLS Rev=B120
G drain8042
H oeminit
%usb_ehci - 16 - PCI bus=0 dev=13 func=2
%usb_ohci - 17 - PCI bus=0 dev=13 func=0
%usb_ohci - 18 - PCI bus=0 dev=13 func=1
H cinit
NOTICE: TuneUp OK status1: EBEC8B55 F01A5AA0 909090B9 83EC8B55
H inoinit
H fsinit
H DEVFS init
H DOS init
H DTFS init
H HS init
H HTFS init
H XENIX init
H NFS init
H finit
H strinit
H ksl init
H iinit
H flckinit
H seminit
H msginit
H xsdinit
H xseminit
H cfgmsginit
I cpyrtstart
I sockstart
I igmpstart
I incfstart
I rtestart
I wdstart
I arpstart
I ipstart
I ripstart
I icmpstart
I lo_start
I tcpstart
I udpstart
I vnettstart
mem: total = 130684k, kernel = 32880k, user = 97804k
J fpeinit
K swapadd
swapdev = 1/41, swplo = 0, nswap = 200000, swapmem = 100000k
M ecc_init
rootdev = 1/42, pipedev = 1/42, dumpdev = 1/41
kernel: Hz = 100, i/o bufs = 18628k (high bufs = 13040k)
M mp_enable
CONFIG: tab: Configuration buffer full (MAX_CFGSIZE = 2048 exceeded) on dev 0/3
M crllry_rate
M sco_count_processors
M pmregister
M enable_watchdog
N kmdaemon
N htepi_daemon
N vddaemon
N init
N vhand
N bdflush
N strd
T.505-usbd0 000D1 <Drvr16>: Descriptor parse failed during enumeration!
NOTICE:
====== ERROR #1 <Status=OK> .505-usbd0 000D1 <Drvr16>
Descriptor parse failed during enumeration!
usb_msto: Inquiry Read failed, Unbinding!
usb_msto: Please disconnect and re-attach the device to try again.
T.590-usb_msto0 0200 2 <Drvr16>: Initialization failure. Please reattach the
device to retry.
NOTICE:
====== ERROR #2 <Status=OK> .590-usb_msto0 0200 2 <Drvr16>
Initialization failure. Please reattach the devic to retry.
No Panic
You can see that there are problems with the USB.
Transpower
>
>EISA bus + anything more than char based apps = you're wasting our time.
The new system (dual Xeon 3.06 GHz) will be here next week. I wanted to
upgrade the software first, prior to upgrading the hardware. I understand that
5.0.4 will not work properly on a P4 or Xeon system--that's the reason for
upgrading the software first! BTW, the dual Pentium Pro 200 was state-of-the
art in 1997!
Bela Lubkin
> >We're still under the now irrelevant subject line of "Merge
> >Installation/Configuration Problem on OpenServer 5.0.7", so that doesn't
> >give me any clues
>
> Actually this problem arose under Merge when I attempted to install a modem in
> Windows ME, which failed, causing me to attempt to install a modem directly in
> UNIX--so here we are.
This problem has devolved to "accessing the serial port panics the
system", Merge is out of the picture -- the subject line is basically
irrelevant.
But anyway.
> >Hmmm, 200MHz Pentium Pro with USB 2.0 -- odd combo.
> > Well this a 1997 machine (shortly to be replace with a dual-Xeon 3.06 GHz
> system), with a 2002 add-in USB card.
>
> >three USB HCIs on three fake IRQs. To get their real IRQs, run `hw -v
>
> They are at IRQ's 10, 11, and 9--not at 3 or 4.
Since the USB stuff isn't working anyway, I suggest you take the card
out and see if the serial port gets better. It might.
> >Write down the "eip" number, then
> >run:
> >
> > # crash
> > > ts f000baaa
> > > quit
> The eip number is 0x00000000. There is no text symbol near 0 in symbol table,
> so no offset.
Then write down the whole set of numbers and post them here. We're
unable to read your mind.
> >Post the contents of /tmp/panic.
>
> > panic -w /tmp/panic
> System Messages:
...
> I vnettstart
> mem: total = 130684k, kernel = 32580k, user = 98104k
>
> J fpeinit
>
> K swapadd
> swapdev = 1/41, swplo = 0, nswap = 200000, swapmem = 100000k
This system was booted with its full 128MB of RAM accessible, and still
only 100MB of swap. So it cannot write a successul panic dump.
Argh. Actually I gave you the wrong command. Go back and boot with:
Boot
: defbootstr mem=1m-64m
Then provoke the panic.
Then reboot (no special bootstring), go to single-user mode, run:
# crash -d /dev/swap
> panic -w /tmp/panic
> quit
Post the contents of /tmp/panic.
I had left out the "-d /dev/swap"; the three outputs you posted were
readings of current live activity on the post-reboot kernel, not the
saved panic state.
> T.519-usbd0 000D1 <Drvr16>: Descriptor parse failed during enumeration!
> NOTICE:
> ====== ERROR #1 <Status=OK> .519-usbd0 000D1 <Drvr16>
> Descriptor parse failed during enumeration!
> usb_msto: Inquiry Read failed, Unbinding!
> usb_msto: Please disconnect and re-attach the device to try again.
> T.1340-usb_msto0 0200 2 <Drvr16>: Initialization failure. Please reattach the
> device to retry.
> NOTICE:
> ====== ERROR #2 <Status=OK> .1340-usb_msto0 0200 2 <Drvr16>
> Initialization failure. Please reattach the devce to retry.
> You can see that there are problems with the USB.
Yep. Rather than trying to solve both at once, I strongly recommend you
take out the USB card and see if the serial panic goes away.
>Bela<
Transpower
The current system--serial ports and USB ports--works perfectly under Windows
XP. Therefore, the problem is with SCO.
>Since the USB stuff isn't working anyway, I suggest you take the card
>out and see if the serial port gets better. It might.
Quite probably; however, I'm using all of the USB devices and serial ports with
XP just fine, so I'm not going to mess with the hardware right now. Next week
I hope to have the new hardware here and will retest with SCO.
>Then write down the whole set of numbers and post them here. We're
>unable to read your mind.
>
Here is the whole set:
cr0 0x8001003B cr2 0x00000000 cr3 0x00002000 tlb 0x00000000
ss 0x00006A28 uesp 0xF008CF75 efl 0x00010216 ipl 0x00000007
cs 0x00000158 eip 0x00000000 err 0x00000000 trap 0x0000000E
eax 0xF0300CBD ecx 0x00000002 edx 0xF02E6A28 ebx 0xF0328260
esp 0xE0000998 ebp 0xE00009B4 esi 0x00000008 edi 0x00000002
ds 0x00000160 es 0x00000160 fs 0x00000000 gs 0x00000000
cpu 0x00000001
># crash -d /dev/swap
> > panic -w /tmp/panic
Unfortunately the crash command responds with 'dumpfile = /dev/swap, namelist =
/unix, outfile = stdout, 0xdfffc03c is an invalid current process adress.'
Whatever that means...
Hey at least my UNIX accounting system and database files still work. ;)
Bela Lubkin
> The current system--serial ports and USB ports--works perfectly under Windows
> XP. Therefore, the problem is with SCO.
Agreed. I'm trying to find out what the problem is, using the tools
available.
> >Since the USB stuff isn't working anyway, I suggest you take the card
> >out and see if the serial port gets better. It might.
>
> Quite probably; however, I'm using all of the USB devices and serial ports with
> XP just fine, so I'm not going to mess with the hardware right now. Next week
> I hope to have the new hardware here and will retest with SCO.
Another way you can disable USB is this. Boot with:
Boot
: defbootstr disable=usb_uhci,usb_ohci,usb_ehci
Then try to access the serial port. If the problem was due to an
interaction with USB, the serial port should now work. If it panics the
same as before, it probably isn't USB.
> >Then write down the whole set of numbers and post them here. We're
> >unable to read your mind.
> >
>
> Here is the whole set:
>
> cr0 0x8001003B cr2 0x00000000 cr3 0x00002000 tlb 0x00000000
> ss 0x00006A28 uesp 0xF008CF75 efl 0x00010216 ipl 0x00000007
> cs 0x00000158 eip 0x00000000 err 0x00000000 trap 0x0000000E
> eax 0xF0300CBD ecx 0x00000002 edx 0xF02E6A28 ebx 0xF0328260
> esp 0xE0000998 ebp 0xE00009B4 esi 0x00000008 edi 0x00000002
> ds 0x00000160 es 0x00000160 fs 0x00000000 gs 0x00000000
> cpu 0x00000001
>
> ># crash -d /dev/swap
> > > panic -w /tmp/panic
>
> Unfortunately the crash command responds with 'dumpfile = /dev/swap, namelist =
> /unix, outfile = stdout, 0xdfffc03c is an invalid current process adress.'
> Whatever that means...
It basically means that it looks like a corrupt dump to `crash`. Well,
one of the numbers up there looks weird: the "uesp" value looks like
what should be in "eip". So, run:
# crash # not -d /dev/swap
> ts f008cf75
> quit
What's the symbol+offset?
Two other tools might be able to make more sense of the dump; it's not
terribly likely, but worth a try anyway. One:
# scodb -d /dev/swap
scodb> stack
Two:
# sysdump -i /dev/swap -a
Both should be attemped immediately after you've forced another panic,
and gone straight to single-user mode afterwards. Otherwise /dev/swap
may already have been overwritten by system activity.
> Hey at least my UNIX accounting system and database files still work. ;)
Good...
>Bela<
to...@aplawrence.com
You'd be a lot better off if you'd stop buying "state of the art".
Spending big money for that when you don't need it just makes you
reluctant to move up - demonstrated quite well by the fact that you
are still running a 1997 machine!
This is your office machine, right? Do you really need anything
even half this powerful???
Buy less expensive hardware and upgrade more often. You'll spend
the same amount of money perhaps, maybe even more, but you'll
be more willing to do it and you won't fall so far behind.
to...@aplawrence.com
Think you might consider a fresh install?
Transpower
>Another way you can disable USB is this. Boot with:
>
> Boot
> : defbootstr disable=usb_uhci,usb_ohci,usb_ehci
>
>Then try to access the serial port. If the problem was due to an
>interaction with USB, the serial port should now work. If it panics the
>same as before, it probably isn't USB.
>
>
Unfortunately it panics the same as before, with USB disabled (but it was nice
not seeing the USB error messages). We'll debug the USB stuff later when the
new computer gets here. (Actually one of my reasons for upgrading to 5.0.7 was
to be able to access my USB devices.)
># crash # not -d /dev/swap
> > ts f008cf75
> > quit
>
>What's the symbol+offset?
>
The symbol + offset: _M_mdhi_com_for_mrg + 0x9
> One:
>
> # scodb -d /dev/swap
> scodb> stack
>
>Two:
>
> # sysdump -i /dev/swap -a
>
These didn't come back with anything intelligible. We will have to keep
working on this until the matter is fixed. I have clients on 5.0.2, 5.0.4,
5.0.5, 5.0.6--I cannot "upgrade" them until my own 5.0.7 system is working
properly, including the Calendar.
Transpower
>Think you might consider a fresh install?
Nah, here's an old repost of mine from 1998, which gives the Steps to Go from
5.0.2 to 5.0.4. I don't think you understand real-world implementations very
well, but I do like your Web site.
S T E P S T O G O F R O M
S C O 5.02 T O 5.04
by
Ronald W. Satz, Ph.D., Certified Systems Engineer
May 7, 1998
1. For safekeeping and easy restoration, copy special configuration files to a
special files directory on a secondary hard drive, e.g. an Iomega Jaz drive.
These files include hwconfig -h (piped to a file and printed out; contains
interrupts and hardware addresses; annotate the printout with video driver
information), /etc/conf/cf.d/mscsi (the list of SCSI devices and ID numbers),
/etc/rc.d/2/mntfs (the list of file systems to mount after normal booting,
including the above secondary drive), /etc/hosts, /etc/ttytype, /etc/inittab,
/etc/passwd, /usr/spool/cron/crontabs/root, /.profile, /usr/lib/uucp/Devices,
/usr/spool/lp/admins/lp/printers/*, /usr/spool/lp/admins/lp/interfaces/*,
/usr/spool/lp/default, /usr/spool/fax/faxconfig (Arnet fax configuration),
/usr/vsifax3/lib/vsisrv.ini (VSI-Fax configuration),
/usr/vsifax3/lib/printers.lst, /usr/vsifax3/lib/mailers.lst,
/usr/vsifax3/lib/retrys.lst, /etc/visfax3.sh, /etc/default/merge (various
default settings for Merge), autoexec.bat and config.sys (for DOS under Merge).
To be extra safe, make hard copies of all these files and place in a labeled
folder. This folder should also have a list of all UNIX and Gateway for
Netware printers and their configurations, a list of all Equinox serial ports
and their configuration (obtained by running ssdiag), a list of all Boundless
multiconsole units and their configurations (obtained by running srstat, srstat
-c 0, srstat -c 1, etc.), a list of all data and fax modems and their
configurations, and a list of all mice and their configuration (from mkdev
mouse). (Most of these files will not copy over in a non-destructive restore
so they must be re-installed separately.) Be sure to have already downloaded
the latest drivers from Boundless (3.07, with a Merge 4 fix) and from Equinox
(3.32c) and have made the appropriate diskettes (using dd) for later use by
custom. Copy the three Boundless replacement files (serialOsa, update, and
Xsco) to the special files directory. Also include a list of all Mail aliases.
Note objects on X-Windows desktops of users. Make a second labeled folder to
contain all software licenses, certificates, and registration numbers.
2. Make a text list of all other directories and files (including all
application programs and users) to be restored to the new system. Call this
file "mustsave" and copy it to the special files directory. (These files will
copy over in a non-destructive restore.)
3. Make CTAR master backup of 5.02 system and verify that it has no errors
whatsoever.
4. Shutdown the system and reboot on the 5.04 installation diskette. Use new
license numbers if necessary. From the msci file listing, enter the correct
SCSI ID for the CDROM drive.
5. Begin fresh install, since in-place install doesn't work. Set up monitor,
video board, keyboard, and mouse as on 5.02 system (refer to data gathered in
step 1). Set up the network card using the same TCP/IP and domain information
as on 5.02 system. Choose to install Gateway for Netware. Keep existing file
layout.
6. The fresh install program should copy all operating system files and relink
the kernel without problems. When finished, shutdown and reboot.
7. Install SCO SMP software (using the Software Manager (custom)). License
each additional CPU. Install RS504C and OSS469. Relink kernel and reboot.
8. Install OSS474A (license manager for Merge 4). Install Merge 4 and license
it. Relink kernel and reboot. Add test user (because Windows 95 will not
install for root), log in as test user, and install (from Merge setup) Windows
95 from its CD. Select Merge mouse and monitor. Windows 95 should then appear
in its own X-window.
9. Install OSS449F for 5.04 to patch TCP/IP files. Relink kernel and reboot.
10. Check that Gateway for Netware is installed. If not, install it now;
relink kernel and reboot.
11. Install any other optional SCO programs (from the 5.04 CD or the Merge CD)
at this time; relink kernel and reboot.
12. Install DAT tape drive SCSI driver, using mkdev tape. Use SCSI ID from
the mscsi printout. Device is /dev/rStp0. Relink kernel and reboot.
13. Install CTAR and configure it. Test the tape drive by retensioning the
tape (use the CTAR utilities). Create emergency boot and root diskettes.
14. Do master CTAR backup of all that has been done to this step. If problems
occur after this step, we can always do a fresh restore of this tape.
15. Run mkdev hd to add the drive or drives listed in the mntfs file. Be sure
not to disturb the contents of these drives (usually accept the default
settings offered by the mkdev hd program). Relink kernel. Edit the mntfs file
manually to match the printout in the folder. Reboot. Make sure the secondary
drive is recognized by the system on startup. The special files directory on
the secondary hard drive should now be accessible.
16. Before copying files from the special files directory, copy the fresh 5.04
versions to other files with a ".o" (for "original") extension in case there
are problems later. For example, copy /etc/inittab to /etc/inittab.o.
17. Restore the /etc/hosts file from the special files directory. Test the
TCP/IP network; all connected PC's should now function.
18. Install the Equinox 3.32c serial port driver from diskette, using custom.
Relink the kernel. Restore the /etc/inittab, /etc/ttytype files from the
special files directory. Disable the multiconsole lines in /etc/inittab
temporarily. Reboot. Run Equinox ssdiag; make sure all previous settings
(including speed, flow control, transparent printing, and enabled or not
enabled) are correct. Test the serial terminals and transparent printing.
19. Copy the Boundless serialOsa, update, and Xsco files from the special file
directory to the appropriate directories and chown, chgrp, and chmod them (as
stated in the Boundless readme file). Then install the 3.07 driver (using the
interrupt and no. of multiscreens found in step 1) with Merge 4 fix using
custom. Relink kernel. Re-enable (if disabled) multiconsole lines in
/etc/inittab. Reboot. Run mkdev mouse to install the Sunriver mice (channel 0
serial port 1 is /dev/srs001, channel 1 serial port 1 is /dev/srs011, etc.).
Run mkdev graphics and add the Sunriver adapter (use 1024x768x256 colors, 70
Hz, 21" or whatever), and choose the appropriate no. of function keys for the
number of multiscreens. Relink kernel and reboot. Run srstat to check that
the configuration is correct. Enable the multiconsole units if not already
enabled (enable tty00a, tty00b, tty00c, tty00d,...,tty10a, tty10b, tty10c,
tty0d,..., etc.) Test the multiconsole units.
20. Install the three diskettes of Olympus Tuneup 6.0K using custom. Relink
kernel. Reboot. Run it and license it.
21. Do a second master CTAR backup of everything that has been done to this
step.
22. Copy the mustsave file from the special files directory back to the hard
drive, say to /usr/bin/. With the master backup tape in the tape drive (and
write-protected to be safe), use the following CTAR command (from root) to
restore all the files listed in the mustsave file:
ctar -xVNFfbk /usr/bin/mustsave /dev/rStp0 120 4194304
This accomplishes a non-destructive restore. (We don't want to do a
destructive restore because this may overlay operating system files, causing
innumerable problems.)
23. Install Arnet Fax software. Relink kernel. Configure it exactly as on
5.02, using the printout from /usr/spool/fax/faxconfig or copying the file from
the special files directory. Reboot. Check that the Arnet fax server has
started and that the corresponding fax modem works properly.
24. Install VSI-Gold Fax software. Configure it as before (copy the files
from the special files directory). Reboot. Test that the VSI-Fax server has
started and that the corresponding modem works properly.
25. Install the parallel port driver (using the interrupt from the hwconfig
printout). Restore all printer files from the special files directory. Using
Printer Manager, check that all printers are properly displayed and configured.
Test console printer (default). Log in to Novell via the Gateway and check
that Netware printers can print. Check that the multiconsole printers can
print. If there are problems, simply enter the printer information manually
from the configuration printouts.
26. Restore the /usr/lib/uucp/Devices file from the special files directory.
Check that the data modems are functioning properly.
27. Restore /etc/passwd from the special files directory. Reboot. Check that
all users can log in and function as before.
28. Restore /usr/spool/cron/crontabs/root. Reboot. Make sure that cron is
running.
29. Check application programs. If some files are missing, restore from
master diskettes. Check that X-desktops of users resemble what they were
before.
30. Perform Merge installation of Windows 3.1/3.11 for root; it should
recognize the Windows directory restored from tape. Check that all previous
Windows programs run correctly in an X-Window. Set Merge defaults to be same
as before. Check that autoexec.bat and config.sys function as before, e.g.,
logging into Novell with lccipx and netx and being able to use the CDROM drive
as drive K; they may have to be modified to work with Merge 4.
31. Make another CTAR backup of everything that has been done up to this step.
Make a new set of emergency boot and root diskettes.
32. Shutdown, reboot, and test every PC, terminal, multiconsole unit, modem,
and printer one more time.
33. Run Tuneup to re-tune the system (hopefully it will be able to use
information from the 5.02 history).
34. From SCO's Web-site, obtain all appropriate registration numbers. Enter
the information in the license manager.
--------
...and similarly for a fresh install now.
to...@aplawrence.com
>Tony:
>>Think you might consider a fresh install?
>Nah, here's an old repost of mine from 1998, which gives the Steps to Go from
>5.0.2 to 5.0.4. I don't think you understand real-world implementations very
>well, but I do like your Web site.
Of course I don't understand real world implementations. After all,
I only have a few hundred clients and have only been doing this stuff
since 1983.
What the heck would *I* know about SCO upgrades? I probably have
never even done more than a handful.
Oh, and pay no attention to that pesky JPR. I know for a fact
he hardly does any of this stuff either. Another dilettante with
nothing to offer.
You are entirely justified in ignoring our babblings. We base our
opinions strictly on mental conjecture, never from real world
experience. I don't know why JPR is so dumb, but in my case
it probably comes from dropping out of high school the very day
I was legally old enough to do so. Clawing my way
from that to a rather nice lifestyle has nothing to do with
abiliies to work in the real world, of course.
Nope, you are on the right track. Wait for SCO to "fix" the
problems so that you can go forth and do your IPU's. Obviously
the quickest and most reliable method, despite other folks wild opinions.
>S T E P S T O G O F R O M
>S C O 5.02 T O 5.04
>by
>Ronald W. Satz, Ph.D., Certified Systems Engineer
.. stuff deleted ..
So tempted to say it..
Oh, what the hell. No offense, but:
Worked real well for you this time, didn't it?
Bela Lubkin
> >Another way you can disable USB is this. Boot with:
> >
> > Boot
> > : defbootstr disable=usb_uhci,usb_ohci,usb_ehci
> >
> >Then try to access the serial port. If the problem was due to an
> >interaction with USB, the serial port should now work. If it panics the
> >same as before, it probably isn't USB.
>
> Unfortunately it panics the same as before, with USB disabled (but it was nice
> not seeing the USB error messages). We'll debug the USB stuff later when the
> new computer gets here. (Actually one of my reasons for upgrading to 5.0.7 was
> to be able to access my USB devices.)
Ok. Start by seeing whether they're problematic on the new system.
> ># crash # not -d /dev/swap
> > > ts f008cf75
> > > quit
> >
> >What's the symbol+offset?
>
> The symbol + offset: _M_mdhi_com_for_mrg + 0x9
Now we're getting somewhere. That symbol is part of NeTraverse Merge.
Now I'd like you to remove Merge (again), boot up, and see if you can
successfully access the serial ports. By "remove Merge" I mean "boot
from a kernel in which no Merge device driver code is linked" -- if you
have one of those laying around you don't need to actually go through
the gyrations of removing Merge.
> > One:
> >
> > # scodb -d /dev/swap
> > scodb> stack
> >
> >Two:
> >
> > # sysdump -i /dev/swap -a
>
> These didn't come back with anything intelligible. We will have to keep
> working on this until the matter is fixed. I have clients on 5.0.2, 5.0.4,
> 5.0.5, 5.0.6--I cannot "upgrade" them until my own 5.0.7 system is working
> properly, including the Calendar.
I don't expect to have anything to do with fixing the calendar problem.
The advice to try it on a not-upgraded system sounds very good to me.
Suppose it works: then you have a baseline for comparison. You can
compare the calendar-related files in the doesn't-work-upgraded system
and the works-new-install system, mimic permissions, copy file contents,
whatever it takes, until both work.
>Bela<
peri
> The new system (dual Xeon 3.06 GHz) will be here next week. I wanted to
> upgrade the software first, prior to upgrading the hardware. I understand that
> 5.0.4 will not work properly on a P4 or Xeon system--that's the reason for
> upgrading the software first!
I am now very curious.
If you already know that 5.0.4 is not going to work properly,
does this mean you will be loading a fresh install with 5.0.7
on this new machine ?
Or are you planning on some disaster attempt at a tape backup full
restore from the old machine to the new machine. Yikes I hope not !
And why are we wasting time wondering why serial ports and numerous
other stuff doesn't work on this old SOON to be retired machine.
Or maybe you are planning on networking the two and mounting
the old computers filesystem ?
Your whole approach to this has led to some terrible mess.
I am amazed at how some of the regulars like Tony and JPR have
put up with this thread, and Bela and a few others are
still attempting to help !
Look, Fresh installs are the way to go, but what do I know ?
I'm just another inexperienced ol'fart that has nothing
to offer. Tony should advise you to keep away from me too
because I babble alot too.
peri
-
to...@aplawrence.com
I'll add you to the list.
Actually, related to this:
Many times subjects come up where people don't realize the preponderance
of opinion on a particular subject. One of us will post opining that
Supertars are the only way to go or that IPU's are generally not
advised, but the original poster doesn't realize how many very
experienced people share similar opinions.
I've thought about a web page or pages just for that purpose: a place
where people could say "yes, I too feel this way" or "no, I think
otherwise" and indicate their experience, years in business etc.
I'm going to set that up later this morning. I think it will be
very useful.
Transpower
Thanks for continuing this thread. Some of the other contributors are just too
impatient. Once we have the problems resolved, I will have a stable system for
six years, before going through this again; our corporate policy is to upgrade
every six years. Of course, individual SCSI devices can be changed more often.
Currently I'm using two 73 GB Ultra320 harddrives (one for UNIX, one for XP),
an HP LTO 2 tape drive, and a Yamaha F1ZSX CDROM drive (all drives are
external). These very same drives will be used on the new system. I will use
the very same keyboard (an IBM Space Saver 2 with the magnificent track stick)
and monitor (an Eizo 16" LCD). I will be using matching internal cards (video,
network, SCSI), so it should be a matter of swapping out the old box for the
new box...hopefully.
Now back to the problem at hand.>> >
What's the symbol+offset?
>>
>> The symbol + offset: _M_mdhi_com_for_mrg + 0x9
>
>Now we're getting somewhere. That symbol is part of NeTraverse Merge.
>Now I'd like you to remove Merge (again), boot up, and see if you can
>successfully access the serial ports. By "remove Merge" I mean "boot
>from a kernel in which no Merge device driver code is linked" -- if you
>have one of those laying around you don't need to actually go through
>the gyrations of removing Merge.
>
At the UNIX boot prompt, I typed "dir" and spotted the "unix.install" kernel,
which does not have Merge in it. Booting with that, I was able to do "cu
-ltty2a dir" without a problem--the modem connected.
So, what's next, chief?
to...@aplawrence.com
>Bela:
>Thanks for continuing this thread. Some of the other contributors are just too
>impatient. Once we have the problems resolved,
*If* you get the problems resolved. I'm not saying that they can't be
resolved, but some problems take far too much time and effort. By most
estimations, you are way beyond that already.
Wasn't the point of this to make the upgrade as painless as possible?
I don't know why we can't make you understand that fresh installs are
quicker, easier, and create less problems.
BTW, Bela, whose opinions I highly respect, has weighed in on my
site with a negative "it depends" opinion on this. I'm sorry, Bela,
but you are wrong. No amount of engineering excellence can compensate
for whatever might ALREADY be wrong with a system, and THAT is the
reason that IPU's often cause annoying little problems - couple
that with the fact that IPU's almost always take longer, and there
is really no contest. Fresh is faster, easier, and has less potential
for problems.
Quite possibly THIS problem might have happened even with a fresh
install. After all, the hardware is ridiculously old. But the
major concept is that IPU's are just headaches waiting to happen.
I'm going to shut up now. I've shown the horses the water and
that's all I can do.
I hope this particular horse solves his problem and doesn't
find too many more. These things can be extremely frustrating,
and take up too much time.
Bela Lubkin
omitting his real name) wrote:
> BTW, Bela, whose opinions I highly respect, has weighed in on my
> site with a negative "it depends" opinion on this. I'm sorry, Bela,
> but you are wrong. No amount of engineering excellence can compensate
> for whatever might ALREADY be wrong with a system, and THAT is the
> reason that IPU's often cause annoying little problems - couple
> that with the fact that IPU's almost always take longer, and there
> is really no contest. Fresh is faster, easier, and has less potential
> for problems.
I thought I made my opinion clear enough on your survey page. The
choices you offered were not rich enough. Asking for a flat "yes" or
"no" is too restrictive.
A successful IPU preserves characteristics of a system that the current
administrator may have no idea about -- obscure driver settings in
space.c files, for instance. That could be very helpful in some cases
(and yes, it could also be harmful). A successful IPU is much easier
than a backup, restore, put everything back together cycle.
Of course I am talking about a _successful_ IPU, and yes, there's every
chance it will fail. It would be insane to attempt an IPU without a
good verified backup. If the IPU fails, you can fall back to the fresh
install, restore, put everything back together plan.
The fresh install route is easy on a system where user modifications
have been carefully documented and mostly kept in separate directory
hierarchies. You may have been managing your systems like that for
10-15 years and naturally assume that your experience is similar to
others'. Most systems are not so carefully managed. Getting all user
mods back into place after a fresh install could be a big effort. It's
even worse if a system has been managed by various people over time, the
current one having no idea what predecessors did. (Again, that could be
seen as an argument for the fresh install route -- start from a clean
slate. In some cases yes. In others, no. Depends what the current
admin knows about the specific system and about Unix and OpenServer
system management in general.)
> Quite possibly THIS problem might have happened even with a fresh
> install. After all, the hardware is ridiculously old. But the
> major concept is that IPU's are just headaches waiting to happen.
Quite possibly.
> I'm going to shut up now. I've shown the horses the water and
> that's all I can do.
>
> I hope this particular horse solves his problem and doesn't
> find too many more. These things can be extremely frustrating,
> and take up too much time.
I think you're wrong to focus on the IPU vs. fresh install aspect of
this situation. He's got a panic, I highly doubt it has anything to do
with the IPU. You also take the position that Merge is useless, and
since Merge is involved, there really isn't anything for you to add.
But that's entirely separate from the IPU issue.
>Bela<
Bela Lubkin
> Transpower <trans...@aol.com> wrote:
> >Bela:
>
> >Thanks for continuing this thread. Some of the other contributors are just too
> >impatient. Once we have the problems resolved,
This article never arrived for me, but I was able to look it up via
dejagoo. Thus:
Bela>>>> What's the symbol+offset?
Transpower>>> The symbol + offset: _M_mdhi_com_for_mrg + 0x9
Bela>> Now we're getting somewhere. That symbol is part of NeTraverse
Bela>> Merge. Now I'd like you to remove Merge (again), boot up, and
Bela>> see if you can successfully access the serial ports. By "remove
Bela>> Merge" I mean "boot from a kernel in which no Merge device driver
Bela>> code is linked" -- if you have one of those laying around you
Bela>> don't need to actually go through the gyrations of removing
Bela>> Merge.
Transpower> At the UNIX boot prompt, I typed "dir" and spotted the
Transpower> "unix.install" kernel, which does not have Merge in it.
Transpower> Booting with that, I was able to do "cu -ltty2a dir" without
Transpower> a problem--the modem connected.
Transpower> So, what's next, chief?
Link scodb into the kernel: change 'N' to 'Y' in
/etc/conf/sdevice.d/scodb, relink, reboot. Provoke the panic. You
should get a scodb prompt. Tell it "stack". Post the resulting output
as exactly as possible (all the hex gibberish is important).
Tony may be right. This may be caused by the Merge device drivers not
being installed 100% correctly (and that would probably have been caused
by doing an IPU). Besides recording the above stack trace, I would like
you to run the following commands and mail the results directly to me
(it's going to be a lot of binary junk, not appropriate for a newsgroup
posting):
# cd /etc/conf
# tar cfL - */merge */mpip */sv* */v[dkmw]* | bzip2 > /tmp/merge.tar.bz2
Mail the resulting file to me. Post the stack trace here. I intend to
continue the debugging process in public, I just want the one file
directly.
>Bela<
to...@aplawrence.com
>to...@aplawrence.com (whose news poster of the week is once again
>omitting his real name) wrote:
>> BTW, Bela, whose opinions I highly respect, has weighed in on my
>> site with a negative "it depends" opinion on this. I'm sorry, Bela,
>> but you are wrong. No amount of engineering excellence can compensate
>> for whatever might ALREADY be wrong with a system, and THAT is the
>> reason that IPU's often cause annoying little problems - couple
>> that with the fact that IPU's almost always take longer, and there
>> is really no contest. Fresh is faster, easier, and has less potential
>> for problems.
>I thought I made my opinion clear enough on your survey page. The
>choices you offered were not rich enough. Asking for a flat "yes" or
>"no" is too restrictive.
>A successful IPU preserves characteristics of a system that the current
>administrator may have no idea about -- obscure driver settings in
And that's exactly the reason I don't like IPU's: because it WILL
preserve changes and settings that it shouldn't.
>space.c files, for instance. That could be very helpful in some cases
>(and yes, it could also be harmful). A successful IPU is much easier
>than a backup, restore, put everything back together cycle.
How do you know when it is successful? That's the point I think you
are missing. The fallout from settings that shouldn't be may take
days or weeks to become apparent. Nor do I have any easy way to
tell WHAT was preserved.
>Of course I am talking about a _successful_ IPU, and yes, there's every
>chance it will fail. It would be insane to attempt an IPU without a
>good verified backup. If the IPU fails, you can fall back to the fresh
>install, restore, put everything back together plan.
Again, that's not the type of failure I'm talking about. Complete
failures are unimportant. It's the nasty subtleties that are the problem.
>The fresh install route is easy on a system where user modifications
>have been carefully documented and mostly kept in separate directory
>hierarchies. You may have been managing your systems like that for
That's nice, but it isn't really necessary. It isn't hard to search out
modified files and adjust as required. And that IS the whole point:
you have a fresh install, and everything from the old system available
to look at. If you are the normal admin, you adjust the system as
necessary. If not, you compare files, and copy and change as indicated.
>10-15 years and naturally assume that your experience is similar to
>others'. Most systems are not so carefully managed. Getting all user
You misunderstand my role in the world. Yes, I have some systems I
have managed since day one. But much more often my job is to go into
systems I've never seen before in my life.
>mods back into place after a fresh install could be a big effort. It's
It isn't. It is far LESS effort than hunting down misbehavior.
Actually, if the IPU produced a list of files it preserved from the old
system, I could work from that direction. I'd want a diff listing
of all system directories so I could see files that would NOT have been
there with a fresh install, and a diff for any system file that would
have been put down new but was preserved. If I had THAT, IPU's
would be neat.
Note that when you do a fresh install and restore your old system to a sub
directory somewhere, information like that is very easy to generate. That's
why I do fresh installs: because you can see what was modified on the
old system and put it back if you want to.
>even worse if a system has been managed by various people over time, the
>current one having no idea what predecessors did. (Again, that could be
>seen as an argument for the fresh install route -- start from a clean
>slate. In some cases yes. In others, no. Depends what the current
>admin knows about the specific system and about Unix and OpenServer
>system management in general.)
>> Quite possibly THIS problem might have happened even with a fresh
>> install. After all, the hardware is ridiculously old. But the
>> major concept is that IPU's are just headaches waiting to happen.
>Quite possibly.
>> I'm going to shut up now. I've shown the horses the water and
>> that's all I can do.
>>
>> I hope this particular horse solves his problem and doesn't
>> find too many more. These things can be extremely frustrating,
>> and take up too much time.
>I think you're wrong to focus on the IPU vs. fresh install aspect of
>this situation. He's got a panic, I highly doubt it has anything to do
>with the IPU. You also take the position that Merge is useless, and
>since Merge is involved, there really isn't anything for you to add.
I don't mean to really: it's a side discussion that grew out of this.
As noted, the Merge issue may have nothing to do with IPU's. But the
IPU, and the other difficulties he had getting Merge up at all, do
muddy the waters.
As to silly: Merge is silly for this purpose. He needs it to make
his AOL connection, a task which a stand alone XP machine could do far
more easily.
Transpower
> # cd /etc/conf
> # tar cfL - */merge */mpip */sv* */v[dkmw]* | bzip2 > /tmp/merge.tar.bz2
>
I sent the file directly to you, as requested.
>Link scodb into the kernel: change 'N' to 'Y' in
>/etc/conf/sdevice.d/scodb, relink, reboot. Provoke the panic. You
>should get a scodb prompt. Tell it "stack". Post the resulting output
>as exactly as possible (all the hex gibberish is important).
>
I changed the line in scodb to 'Y' and attempted to re-link but got several
symbol table errors relating to scodb! So, that didn't work. Weird, though.
On a happier note I got the calendar client to work; see post in "Sorry, cannot
connect to Calendar Server."
Bela Lubkin
> Bela:
>
> > # cd /etc/conf
> > # tar cfL - */merge */mpip */sv* */v[dkmw]* | bzip2 > /tmp/merge.tar.bz2
>
> I sent the file directly to you, as requested.
and I looked at it and didn't see anything amiss.
> >Link scodb into the kernel: change 'N' to 'Y' in
> >/etc/conf/sdevice.d/scodb, relink, reboot. Provoke the panic. You
> >should get a scodb prompt. Tell it "stack". Post the resulting output
> >as exactly as possible (all the hex gibberish is important).
>
> I changed the line in scodb to 'Y' and attempted to re-link but got several
> symbol table errors relating to scodb! So, that didn't work. Weird, though.
It should have worked. Now please post the actual errors you got, the
summary "several symbol table errors relating to scodb" is not useful.
> On a happier note I got the calendar client to work; see post in "Sorry, cannot
> connect to Calendar Server."
Good...
>Bela<
Transpower
>I changed the line in scodb to 'Y' and attempted to re-link but got several
>> symbol table errors relating to scodb!
Here are the errors, verbatim:
Root for this system build is /
i386ld: Symbol usage in
/var/opt/K/SCO/link/1.1.1Hw/etc/conf/pack.d/drt/Driver.o
is multiply defined. First defined in /var/opt/K/SCO/link/1.1.1Hw/etc/conf/pack
.d/scodb/Driver.o
i386ld: Symbol umode in
/var/opt/K/SCO/link/1.1.1Hw/etc/conf/pack.d/drt/Driver.o
iis multiply defined. First defined in
/var/opt/K/SCO/link/1.1.1Hw/etc/conf/pack
.d/scodb/Driver.o
i386ld: Symbol offset in
/var/opt/K/SCO/link/1.1.1Hw/etc/conf/pack.d/drt/Driver.
ois multiply defined. First defined in
/var/opt/K/SCO/link/1.1.1Hw/etc/conf/pack
k.d/scodb/Driver.o
ERROR: Can not link-edit unix
idbuild: idmkunix had errors.
System build failed. >
Back to the serial/modem ports for a moment:
what operating system files directly relate to these ports? Perhaps we could
just remove and reinstall those files from the CD--what do you think? I tried
removing and reinstalling the serial/modem manager but that didn't help--"cu -l
tty2a dir" panicked the system, as before.
By the way, I don't mind taking the time to troubleshoot these issues; we all
become better systems engineers as a result. The in-place install allowed me
to have access to my accounting/database files within an hour and a half, which
is much more quickly than a fresh install would have.
RWS
trans...@aol.com
Bela Lubkin
> >I changed the line in scodb to 'Y' and attempted to re-link but got several
> >> symbol table errors relating to scodb!
>
> Here are the errors, verbatim:
>
> Root for this system build is /
> i386ld: Symbol usage in /etc/conf/pack.d/drt/Driver.o
> is multiply defined. First defined in /etc/conf/pack.d/scodb/Driver.o
> i386ld: Symbol umode in /etc/conf/pack.d/drt/Driver.o
> is multiply defined. First defined in /etc/conf/pack.d/scodb/Driver.o
> i386ld: Symbol offset in /etc/conf/pack.d/drt/Driver.o
> is multiply defined. First defined in /etc/conf/pack.d/scodb/Driver.o
> ERROR: Can not link-edit unix
>
> idbuild: idmkunix had errors.
> System build failed.
[de-butchered from what your mailer did; also removed useless SSO path
elements]
scodb is conflicting with the device driver "drt", which I don't
recognize. What is it, where does it come from?
... A bit of web searching suggests it comes from Pacific CodeWorks'
Olympus TuneUp. For the moment you will have to turn off TuneUp in
order to be able to use scodb. (In truth, both drivers are faulty for
exposing symbol names that they have no business trying to own.)
> Back to the serial/modem ports for a moment:
> what operating system files directly relate to these ports? Perhaps we could
> just remove and reinstall those files from the CD--what do you think? I tried
> removing and reinstalling the serial/modem manager but that didn't help--"cu -l
> tty2a dir" panicked the system, as before.
Removing and reinstalling packages isn't going to fix this. It's an
interaction between Merge and serial port access. If you remove Merge
it will definitely "fix" the problem, but you don't want to remove
Merge, so that's not really a solution.
Merge + OSR507 does not prevent serial port access on other systems, so
there's some other factor here that we have to dig up.
> By the way, I don't mind taking the time to troubleshoot these issues; we all
> become better systems engineers as a result. The in-place install allowed me
> to have access to my accounting/database files within an hour and a half, which
> is much more quickly than a fresh install would have.
We may reach a dead end on this one. You don't have kernel source, I
don't have easy access to Merge source, and we're well outside your
skill set for debugging it on site.
>Bela<
Transpower
>For the moment you will have to turn off TuneUp in
>order to be able to use scodb.
OK, I took TuneUp out of the kernel, relinked with scodb and got the following
at the debug prompt, after the panic:
E0000A30 8BEC8B55(F03844FC) <- siointr+A0A
E0000C84 sinointr(3,E0000cA0) <- nosti+26
nosti() <- INT[E0000CA0]
E0000D1C INTERRUPT <- sioopen+3E1
E0000D1C sioopen(?,508,7,2,5) <- devfs_openi+176
E0000DF0 devfs,open(? FB8FB390,7,FB8FB390,800) <- copen1+276
E0000D94 copen1(? FB8FB390,7,1,FB8FB390) <- copen+FC
E0000DD8 copen(7,A) <- open+17
E0000DE8 open(? 4,8047C04,8047CEC,E0000E10) <- systrap+1C8
E0000E10 systrap(E0000E1C) <- scall_nokentry+14
Hope it helps.
Bela Lubkin
Now we can do some steps with user-level scodb, without having to panic
the kernel. On my 507 desktop, I do:
# /etc/scodb
scodb> u siointr+a00
siointr+A00 movl %edx,30(%ebx)
siointr+A03 pushl %edx
siointr+A04 call mdhi_com_for_merge_fp
siointr+A0A addb %esp,4
scodb> u mdhi_com_for_merge_fp
old_com_for_merge pushl %ebp
old_com_for_merge+1 movl %ebp,%esp
etc.
My system doesn't have Merge installed, else the mdhi_com_for_merge_fp
pointer would point to a more modern version of the Merge code.
Your system is panicing on a call to an address "8BEC8B55", which looks
suspiciously like code. In fact, the first 4 bytes of
old_com_for_merge() are 55 8B EC 8B, or 8BEC8B55. Very strange.
Run these commands as root; send the output (don't retype -- use cut and
paste or save & edit):
M=mdhi_com_for_merge_fp
S=siointr
s=" "
echo "u$s$S+a00\n$s$s qdb$s$S+a04\nq$M\ndl$s&$M\nqu$s$M\n qq" | /etc/scodb
This is very slow, running a debugging session by USENET remote
control...
>Bela<
Transpower
>Run these commands as root; send the output (don't retype -- use cut and
>paste or save & edit):
>
> M=mdhi_com_for_merge_fp
> S=siointr
> s=" "
> echo "u$s$S+a00\n$s$s qdb$s$S+a04\nq$M\ndl$s&$M\nqu$s$M\n qq" | /etc/scodb
Here's the result (are you sure the echo statement is correct or maybe I
mistyped?):
dumpfile = /dev/mem
namelist = /unix
stunfile = /etc/conf/packd/scodb/defs/stun.def
varifile = /etc/conf/pack.d/scodb/defs/vari.def
PID 0004: CPU1 idle process
scodb: 1 > u+a00
Error: not a value
scodb: 2 > qdb+a04
Error: expected expression
scodb: 3 > q
Bela Lubkin
You typed, therefore you mistyped. That's why I said to use cut and
paste. You can't expect to type that much gibberish accurately without
some frame of reference.
You're supposed to be doing this as root, with root's standard Bourne
shell. ksh would work, csh variants would not, I have no idea about
other shells.
>Bela<
Transpower
As requested:
M=mdhi_com_for_merge_fp
S=siointr
s=" "
echo "u$s$S+a00\n$s$s qdb$s$S+a04\nq$M\ndl$s&$M\nqu$s$M\n qq" | /etc/scodb
Got back:
dumpfile = /dev/mem
namelist = /unix
stunfile = /etc/conf/pack.d/scodb/defs/stun.def
varifile = /etc/conf/pack.d/scodb/defs/vari.def
PID 004: CPU1 idle process
scodb:1> siointr+a00
siointr+A00 movl %edx,30(%ebx)
siointr+A03 pushl %edx
siointr+A-4 call mdhi_com_for_merge_fp
siointr+A0A addb %esp,4
scodb:2> db siointr+a04
siointr+A04 FF 15 CC EF 2D F0 83 C4 04 85 C0 0F 85 F0 04 00 ....-...........
scodb:3> mdhi_com_for_merge_fp
F008CF6C _M_mdhi_com_for_mrg text
scodb:4> dl &mdhi_com_for_merge_fp
mdhi_com_for_ F008CF6C F008CD1C F008B86C F008B72C 1.......1...,...
scodb:5> u mdhi_com_for_merge_fp
_M_mdhi_com_for_mrg pushl %ebp
_M_mdhi_com_for_mrg+1 movl %ebp,%esp
scodb:6> q