Known issues commonly reported

Wikis > ArcaOS > Known issues commonly reported

Before opening a fresh ticket, please review the README files in the root of the installation ISO and installed to \sys\doc\ArcaOS, paying particular attention to the Known Issues sections. Additionally, per the Best Practices wiki page, please search the bug tracker for similar issues before reporting another instance of the same condition. Duplicate tickets cause more work for everyone.

This page is meant to supplement the README with the latest information available concerning the most commonly reported issues of which we are already aware.

On this page

DOS and/or WIN-OS/2 sessions
USB device issues
Serial ports
IBM File and Print Client issues
High CPU utilization and/or unexplained hangs
File system case retention vs case sensitivity
Update-related issues

DOS and/or WIN-OS/2 sessions do not work

This is a known condition on many newer systems. It is mentioned in the README in the list of known issues. Generally, this is due to an incompatibility in the BIOS of the system with the DOS VDM code in ArcaOS (inherited from IBM’s OS/2 Warp 4).

Arca Noae is continuing to work on addressing this (and other causes of failure of DOS sessions to start).

Some possible workarounds:

Modify the VSVGA.SYS line in CONFIG.SYS to include the following parameter:

DEVICE=N:\OS2\MDOS\VSVGA.SYS /int10textgrfxsafe

With the above change, it may be necessary to append the following to AUTOEXEC.BAT (located either in the root directory of the boot volume or where specified for the DOS session object):

mode co80
 cls

Another option, when full screen sessions work but windowed ones do not, is to open a full screen session first, and then press Alt-Home to switch it to a windowed session (this only works for DOS sessions, not OS/2 full screen and windowed sessions).

The main tracking ticket for progress on this issue is #1193.

USB device issues

Issues pertaining to inability to access USB-connected drives, often involving USB-attached DVD drives, where the installation disc starts to boot and then prompts for insertion of the medium (which is obviously already installed) are often the result of unsupported USB controllers (USB 3).

To be clear, it is not always easy to tell which systems have USB 2 controllers driving their USB 2 ports, and which ones actually only have USB 3 controllers driving their USB 2 ports. ArcaOS 5.0.2 requires the presence of a USB 2 controller, attached to the USB 2 port where the device to be accessed is attached.

USB 3 support is under active development and it is anticipated that this restriction will be lifted in a future release.

Note that this same behavior will be observed for USB-attached keyboards and mice. When so-called legacy support is enabled in the system BIOS, USB devices are handled by the system BIOS directly. Once the device driver has been loaded, however, control is handed off to the software driver. If the software driver lacks support for the type of USB controller to be driven, then nothing has control of USB, and these ports, while still allowing current to flow (they work for charging and powering other devices, of course, with or without a software driver) are effectively ignored by ArcaOS. This is why keyboards will work for preboot selection during installation, for example, but upon entering the installation environment following boot, no input is possible.

Possible workarounds

If this is a desktop system, install a USB 2 controller card. Often, these cards include 2 or 4 ports on the bracket and perhaps an internal port or header, as well. This allows them to supplement the onboard USB 3 controller present in the system. Connect all devices needed to be accessed by ArcaOS to this USB 2 adapter.

Portables offer greater challenges for workarounds. It is likely that support for USB 3 will be available before we have any viable workarounds for these machines.

Phantom serial port devices

It is possible that the installer will recognize an Intel Manageability Engine serial port (KT Controller) device as a normal serial (COM) port, and install the PSCOM.SYS driver (and matching VCOM.SYS driver, if DOS support is selected). These ports are not usable by ArcaOS. Upon booting, the system will generate a SYS1201 error attempting to load PSCOM.SYS (and again, for VCOM.SYS, if specified, as this depends upon a valid OS/2 COM port driver being loaded).

Possible workarounds

If there are no other valid serial ports in the system, press <Enter> to acknowledge each of these when presented during boot. Edit CONFIG.SYS to comment out each of these (insert “REM” at the beginning of each affected DEVICE= line). Save the file and reboot.

If there are valid, enabled serial ports in the system, it will be necessary to add the proper entries to \OS2\BOOT\PCIDEV.TBL to force PSCOM.SYS to ignore the KT controller device. See \OS2\BOOK\COM16.TXT for more details.

IBM File and Print Client issues

IBM File and Print Client connectivity issues to Windows 7 and newer

When using the NetBIOS-based IBM File and Print Client to connect to Windows 7 and above, file transfers may fail with SYS0240. ArcaOS versions prior to 5.0.3 utilized the OS/2 Warp standard configuration for multiplexed SMB (Server Message Block) reads and writes. Once a multiplexed read or write is attempted from or to one of these newer Windows versions, the Windows system resets the connection.

The solution is to set bits 14 and 15 of the wrkheuristics parameter in \IBMLAN\LANMAN.INI to 0 to disable multiplexed reads and writes. This is now the default in ArcaOS 5.0.3 and above, and should have no negative impact on performance.

This change affects native NetBIOS and NetBIOS over TCP/IP equally.

More information may be found here.

Arca Noae recommends the use of Samba for file sharing between ArcaOS and other systems, including Windows, Linux, and other ArcaOS systems. Samba supports enhanced authentication protocols, encrypted file transfers, and pure-IP connectivity (no NetBIOS required).

Restoring default IBM File and Print Client user accounts

There may be situations where recovery of the existing user accounts file (NET.ACC) is either impossible or undesirable. It is possible to restore the original (default) file from the ArcaOS installation medium:

  1. Reboot
  2. Shut down the requester
    NET STOP REQUESTER
  3. Mount the ArcaOS installation DVD or ISO
  4. Extract the default NET.ACC
    unzip -oj X:\CID\SERVER\IBMLS\IBM500R1\REQRINST.ZIP IBMLAN\INSTALL\NET.ACC -d C:\IBMLAN\ACCOUNTS

    (where X: is the drive letter assigned to the ArcaOS DVD or ISO and C: is the drive where NET.ACC is located)

  5. Select LAN Logon (Workgroup) and enter the default username/password (USERID/PASSWORD) which will start the requester
  6. Open Sharing and Connecting and add user accounts and groups as required

Arca Noae highly recommends creating an alternative administrator account and after logging out and back in with the new account, deleting the USERID account.

Loss of User and Group tabs in Sharing and Connecting object

This may happen if all administrator accounts have been deleted. While it is not normally possible to delete the last remaining administrator account, creating a new administrator account while logged in as the existing one and subsequently deleting the existing administrator account will cause the new account to not be saved, resulting in all administrator accounts being lost.

To recover, follow the procedure above to restore the default NET.ACC file and reconfigure accounts.

High CPU utilization (one core) or lockups on multi-CPU systems

Not all software is “SMP-safe” or even “SMP-aware.” This is particularly true of older software written for Warp 4 or earlier versions of OS/2, when only servers had multiple CPUs. If you experience abnormally high CPU utilization on a multi-CPU or multi-core system when running a particular application, this could be the cause.

Possible workarounds

Before opening a trouble ticket, try changing the PSD=ACPI.PSD line in CONFIG.SYS to read:

PSD=ACPI.PSD /MAXCPU=1

Save the file, reboot, and retry the failing application. If this seems to avoid the problem, please include this information in your trouble ticket. In some cases, older applications may be patched to address such shortcomings. For third-party applications, it is best to contact the maintainer/publisher of the application to request a fix.

File system case retention vs case sensitivity

OS/2 is by design a case-insensitive operating system. Its native filesystems (HPFS and JFS) support case retention, so when opening MyFile.tXt and saving it to an HPFS or JFS volume, the file will be saved as MyFile.tXt. However, this does not mean that in the same directory mYfILE.TxT may also exist. To OS/2, these are the same file.

The situation becomes more complicated when accessing remote filesystems via Samba which are, in fact, case-sensitive as well as case-retentive. On a Linux system, for example, it is perfectly accepaible to have myfile.txt and MYFILE.TXT coexisting in the same directory, and to a Linux system, these are indeed unique files. The issue for ArcaOS, however, is that if both files are listed, opening the lower case one and saving it may result in the file with the uppercase name being overwritten. This is because internally, both the OS/2 kernel (and the ArcaOS kernel, by extension) and the Workplace Shell will “upcase” the filename. Thus, ArcaOS appears blissfully unaware of what file was actually opened.

Possible workaround

Ensure that filenames are unique per OS/2 local filesystem requirements before editing and saving them on remote volumes which are otherwise case-sensitive where such filenames would not conflict on the host system.

Update-related issues

Watch this space for confirmed issues and possible workarounds relating to the new update facility in ArcaOS 5.0.4.

This entry last updated: by Lewis Rosenthal