General Problem-Solving Hints

From Wiki
Jump to: navigation, search

Return to The Warp Pharmacy:Procedures

Last Updated: 5th December, 1994

Okay, in spite of your careful reading and pre-planning, you discover that your OS/2 Warp installation is not proceeding as you expected. What should you do?

First, step back from the machine and take a deep breath. Better yet, go get a cup of coffee, or even take a walk around the block. If you skipped supper to get an early start, go eat.

After you finish your break, skim back over the documentation one more time. No, it hasn't changed, but <you> have. You now have more experience to relate to those dry words on paper; now they make a little more sense, and sections you skipped before suddenly take on new relevance.

Re-read your IRQ & IOA list. If you didn't already create one, now is the time; it could save you several hours on the telephone talking to IBM OS/2 Support and several days' delay before Warp is installed and ready to run. If the installation process is mysteriously hanging, and none of the problem descriptions in this document seem to fit, an IRQ conflict is always a possibility.

Re-read Chapter 14 of the "User's Guide to OS/2 Warp". This was specifically written to address installation problems and how to address them.

Tools and Techniques

The new boot Alt-F1 (boot to a command line) and Alt-F2 (display drivers being installed) are not available during the initial phase of installation. However, if you boot from the installation floppies you are given an opportunity to exit to an OS/2 command prompt via the F3 key. This will let you run:

  • RMVIEW (Installation Diskette)
  • TEDIT (Installation Diskette, Diskette 1)
  • CHKDSK and FORMAT (Diskette 2, or in \OS2IMAGE\DISK_2 on the CD)
  • FDISK (Diskette 1, or in \OS2IMAGE\DISK_1 on the CD)

I'll assume that you are already familiar with CHKDSK, FORMAT, and FDISK. If your experience with these utilities is solely under DOS, be aware that the OS/2 versions have additional features.

TEDIT is a text-mode line-oriented ASCII file editor. It is small (TEDIT.EXE and TEDIT.HLP together weigh in at about 25K), but has all of the features you need for performing emergency edits to CONFIG.SYS from an OS/2 Full Screen session. Press F1 to open the Help file.

RMVIEW is new in OS/2 Warp, and its use as a problem determination tool (together with the RESERVE.SYS pseudodriver) deserves an entire section to itself, but that will have to wait for version 1.2 at least.

Disk Partition Listing

If your problem involves disk partitioning, or is related in any way to hard disk access, having a current and complete description of your partition layout is esssential. The simplest way to do this is by using FDISK to dump a complete report to a file, as in:

  FDISK /QUERY >layout.rpt

You can then print a hard copy of layout.rpt to examine at your leisure, or include it in in e-mail messages to IBM or others. Be sure to add a description of how <you> plan to use the partition as well.

For example, here's part of the FDISK /QUERY report from my current setup, with comments:

Drive Name  Partition Vtype FStype Status   Start     Size

      ** Boot Manager **
    1              :    1    0a      2          0        1

      ** OS/2 2.11 and MS-DOS 5.0 (Dual Boot) **
    1 os2-211     C:    1    06      1          1       80

      ** Warp! (no longer Gamma!) **
    1 os2-warp    D:    2    07      1         81       80

      ** swap partition **
    1             E:    2    06      0        162       50

Translation for undocumented flags:

   Vtype:  1=Primary, 2=Logical Drive
   FSType: 06=FAT, 07=HPFS, 0a=Boot Manager
   Status: 0=Non-bootable, 1=Bootable, 2=Startable

Display Driver Problems

This is one of those nasty Catch-22 situations, since it's hard to do much under OS/2 if your display is not operational.

With very few exceptions (I'll ignore my experiences with the ISA Stealth 24 under OS/2 2.1), adapters will run properly in VGA mode. This isn't the best and most colorful mode, but it will let you get work done. Warp has specific boot-time support for switching your adapter back to VGA mode; all you have to do as you are booting up is press Alt-F1 when you see the white rectangle (the "boot-blob").

If, after loading adapter-specific drivers, your display acts oddly, goes completely black, or suddenly becomes covered with randomly- colored snow and fails to respond in any recognizable way to Ctl-Esc or mouse clicks, then shut down and re-boot. As OS/2 comes up, wait for the boot-blob, press Alt-F1, and follow the instructions for switching back to VGA mode.

Can you do a clean shutdown with a mangled display? The answer, as usual, is "it depends". If the machine is completely locked up, or in a tight loop in the display driver with interrupts disabled, probably not. If OS/2 is still running underneath that odd screen, and it frequently is, try RMB-clicking on where the Desktop should be to bring up the System Menu, then pressing the D key to select the Shut<d>.own entry and pressing the space bar to answer [OK] to the WPS prompt for confirmation.

If you have DOS or OS/2 command prompts or DOS or MSWin programs running, you'll need to press the "Y" key for each to let it complete the shutdown process.

Other Driver-related Problems

Many of the drivers in CONFIG.SYS were supplied with a /Q ("quiet") parameter, apparently because IBM prefers a message-less boot. If you are experiencing problems that may be related to one or more of your OS/2 drivers, this is not very useful.

Try adding a /V to any driver that you think might provide additional information. If it has a /Q parameter, replace it with a /V. Details for many driver parameters are listed in the Warp online Command Reference in the Information object on the WPS Desktop, but this can be difficult to reach if you are in the middle of an installation.

Problems with WinOS/2

If MSWin applications fail to start, and/or the Win-OS/2 Full Screen object cross-hatches briefly, but nothing further happens, there may be a simple problem with one or more of the object's drivers or one of the MSWin DLLs.

To narrow down your search, you need more information. The text messages displayed by a WPS-started Win-OS/2 session are thrown away, but these may contain information critical to problem determination. To see the messages, do the following:

  • Start a DOS Full Screen session.
  • Switch to the MSWin directory (generally \WINDOWS, but mine happens to be \MS-WIN31).
  • Type: WINOS2 and watch the messages that appear.
  • If you fail to see any usefule messages, but WINOS2 exits without giving you a full screen Win-OS/2 session, start it up again, adding a /B parameter:
           WINOS2 /B    
    This will create a text file containing the startup messages you may have missed. After WINOS2 exits, examine the contents of this file for additional information.

One common problem is having critical DLL directories left out of the active DOS PATH setting. This can be a user error or the result of an improperly modified PATH statement in the OS/2 AUTOEXEC.BAT file.

For example, I re-installed MSWin 3.1 after formatting my Warp Gamma partition. I had previously modified the OS/2-created AUTOEXEC.BAT file by adding several lines, including my own PATH setting. When I ran Warp's Selective Install to add WIN-OS/2 suport, it modified the OS/2 AUTOEXEC.BAT file to add my C:\MS-WIN31 directory to the PATH. All very reasonable...

Except that SI modified the <first> PATH statement it saw, which was the original supplied at Warp installation. My <customized> PATH statement, ten lines further down the file, was left untouched. Result? I couldn't start any WIN-OS/2 sessions of <any> kind until I went back and added C:\MS-WIN31 to my own PATH statement.

Removing Adapters

If you experience problems that appear to be hardware related, IBM OS/2 Support may ask you to remove all non-essential adapters and devices from your machine. I have heard remarks from several people to the effect that doing this was pointless, since without those adapters or devices (e.g. a tape backup unit) up and running their system was useless, and they might as well just throw in the towel... er, CD.

The rationale behind pulling all that hardware is not to force you to work that way forever. It is intended as a temporary measure to help get a handle on what is causing your problem. There are simply too many things that <could> be causing a given problem to allow each and every one to be explored.

A smart problem solver will try to use a divide-and-conquer aproach. If the problem is still present with all the extra hardware removed, then it is probably not contributing to the problem. If it <does> go away, then the adapters can be replaced, one by one, until the problem resurfaces. As a result, less time is spent (by both IBM and you) chasing down dead-end paths, and in most cases your problem can be resolved much more quickly.

It's all a question of getting specific information that is solid enough for you as a user to make decisions with. It's the difference between "Warp won't install" and "Warp won't install on your system as long as that 8-bit antique 9600-baud modem is installed". You may not even care about <why> the two can't co-exist if you were planning to replace it anyway. If the adapter <is> critical, you and IBM can concentrate your efforts on figuring out how to re-jumper it (manual long since lost) to make it work properly instead of trying to replace every OS/2 driver in sight.

This page is part of Frank McKenney's Warp Installation Notes, a major contribution to The Warp Pharmacy project.

Return to The Warp Pharmacy:Procedures