On this page
Startup errors
Startup errors are usually caused by conflicts with dlls of other applications which may be out of date or incompatible with the versions used in Arca Noae Package Manager. An example of this would be another application which utilizes VROBJEX.DLL, such as EVFSGUI through (at least) version 2.5RC7. When EVFSGUI is open, attempting to start Arca Noae Package Manager will result in an error message:
Cannot load window: Could not find class 'VRToolTip'
Check for other dlls in LIBPATH with the same names as those in the Arca Noae Package Manager installation directory.
First run errors
For systems with existing Python installations, please see this page.
On systems with no existing RPM & YUM installation, Arca Noae Package Manager should prompt to download and install the base package upon first program start. In certain instances, it is possible for the initial download of the base package to fail with:
The command terminated with error code 1.
This usually indicates that the TCP/IP stack is not 32-bit. Please upgrade the TCP/IP stack to 32-bit and re-try the operation.
YUM errors
A YUM error may cause the Arca Noae Package Manager main window to be completely blank. A basic failure of this type may be encountered when symbolic links (symlinks) are unavailable on the system or on the volume designated as %UNIXROOT%. Because YUM depends upon Python, and because Python depends upon modules which are referenced through symlinks, these modules cannot be found and thus, YUM fails to start, leaving Arca Noae Package Manager without input to display.
Running YUM from the command line, this condition may be seen more clearly:
There was a problem importing one of the Python modules required to run yum. The error leading to the problem was: dlopen rc=193 extra=X:\USR\LIB\PYTHON2.7\LIB-DYNLOAD\CSTRINGIO.PYD Please install a package which provides this module, or verify that the module is installed correctly.
(X: is a placeholder for the volume designated as %UNIXROOT%.)
This indicates a failure of YUM to resolve a symlinked file pointing to a required module.
See the Netlabs RPM and YUM project page for more assistance.
Another potential cause of such a failure is when YUM, Python, or perhaps RPM has been updated and the new version requires an updated library. The updated library may have been automatically installed, but the older one is still either in use or perhaps an older version is closer in %PATH%, precluding the new version from being loaded. If you have anything in \usr\local\lib, that’s a good place to start looking for such conflicts.
YUM metadata and cache
These tasks are available from the Manage | YUM tools | Cleanup menu in Arca Noae Package Manager. See the Netlabs RPM and YUM project page for additional assistance.
Completing transactions
Sometimes, operations fail before completing, leaving the installation and the databases in varying states of inconsistency. This task (without special options) is available from the Manage | YUM tools | Cleanup menu in Arca Noae Package Manager. See the Netlabs RPM and YUM project page for additional assistance.
Transaction check vs depsolve errors
These are not errors per se (likely nothing is broken or misconfigured with YUM itself), but rather issues with the particular operation which has been requested. Transaction check refers to the requested operation (install xyz, remove qrs, update abc), while depsolve refers to resolving dependencies (either installed packages which are dependent upon a package to be removed, updated, downgraded, or replaced, or packages which must be installed as dependencies of the package already selected for installation).
When Arca Noae Package Manager presents a message panel reporting “ERROR with transaction check vs depsolve:”, carefully read the package names, versions, and operators which follow, as in “abc = 1.1.0-1 is needed by qrs-2.1.0-0”. Bear the following in mind:
= means that exact version/release of the listed package is required.
>= means that version/release or higher is required
The part which may follow is an explanation as to why the dependency cannot be satisfied (perhaps the required package cannot be found in any enabled repository, or perhaps the required package has not been selected for removal, update, or downgrade).
Duplicate package errors
These may or may not be reported during an Arca Noae Package Manager operation, but should be shown at the command line. Often, they cause other (reported) errors, as they indicate some inconsistency either in the filesystem or (more likely) the RPM database. The cause of duplicate package errors can generally be traced to an interruption (program or system crash) while a YUM or RPM operation was in progress. Often the packages themselves are not exact duplicates, but an older version is reported as being installed along with its newer version.
If you find that you are unable to update or remove a package, and are unable to resolve the issue using the steps outlined above under Completing transactions, above, check for and clean duplicates as follows:
- Exit Arca Noae Package Manager.
- Open a shell prompt from an OS/2 window, by typing:
[c:\] sh <Enter>
- At the prompt, type:
# package-cleanup --dupes <Enter>
- If any duplicate packages are reported, remove them with:
# package-cleanup --cleandupes <Enter>
- Check for other inconsistencies with:
# package-cleanup --problems <Enter>
- Exit the shell:
# exit <Enter>
- Start Arca Noae Package Manager and attempt to complete any uncompleted transactions from the Manage | YUM tools | Cleanup menu.
- Retry the original update or remove operation.
Sometimes, scriptlet errors may be reported by package-cleanup, preventing the duplicates from being resolved. A typical error report of this kind is:
Error in PREUN scriptlet in rpm package <some package> Failed: <some package>
A possible workaround is to use the –noscripts option on the package-cleanup line:
# package-cleanup --cleandupes --noscripts
This prevents the scriptlet(s) from being called, thus bypassing the supposed error.
In case the duplicate package was also included in an incomplete transaction list, you may use the –cleanup option for yum-complete-transaction (this must be done from the command line, as Arca Noae Package Manager does not provide this functionality):
# yum-complete-transaction --cleanup
Package conflicts
Generally, when one package replaces another (similar content, but different package name), the superseding package does not properly “obsolete” the older package. This is commonly seen with “-debuginfo” packages which do not obsolete the older “-debug” packages. When this happens, Arca Noae Package Manager will return YUM’s error report, which may contain one or more entries resembling:
Transaction Check Error: file /@unixroot/usr/bin/somefile from install of something-debug-n.n.n-n.oc00.arch conflicts with file from package something-debuginfo-n.n.n-n.oc00.arch
Such packages contain the HLL (high-level language) debug data used to help diagnose problems with the named application or library package. This debug data is not needed for the normal use of the application or library, and so is stripped off and packaged separately. Normally, it is not necessary to install the -debug (or newer -debuginfo) package, but when problems occur, and a -debug or -debuginfo package is available, it should be installed.
The conflict occurs when an older -debug package (something-debug) has already been installed, or has mistakenly been selected for install when (the newer) -debuginfo package has been selected for install. While whichever one to be installed should match the binary package’s version and release (e.g., something-1.0.0-1.oc00.i686 requires something-debuginfo-1.0.0-1.oc00.i686), existing debug packages (e.g., something-debug-0.9.9-9.oc00.i686) are not considered obsolete, and thus create a conflict reported by RPM to YUM, and ultimately, to Arca Noae Package Manager.
Early in the use of RPMs on OS/2, this HLL data was packaged as something-debug. Later, the package naming convention changed to something-debuginfo. It is the package naming convention change which causes the conflict, such that a newer “-debuginfo” package is not seen as replacing (obsoleting) a “-debug” package with a lower version and/or release number.
The failure is in the macro used to build the -debuginfo package, which does not add the proper Obsoletes tag to the resulting package.
To resolve this, uninstall any outdated -debug package(s) causing the conflict, and then install the -debuginfo package matching the installed application or library package version and release.
More information concerning -debug and -debuginfo packages, as well as this specific problem with the lack of obsoleting, may be found here:
https://github.com/bitwiseworks/libc/issues/77
http://trac.netlabs.org/rpm/ticket/134
http://trac.netlabs.org/rpm/ticket/149
Similar package conflicts may occur for other types of packages, as well, which do not (for whatever reason) render obsolete another package with a different name. Careful examination of the packages involved in the conflict, what operation was requested, and what already exists should reveal what steps may be taken to resolve the conflict (uninstall one or more packages in order to install one or more new ones, or reevaluate whether the new ones are entirely appropriate, etc.).
RPM errors
The most frequent RPM errors encountered are generally due to incomplete updates, where somehow, RPM or one of its main dependencies has been updated, but a dependency farther down the chain has not. These errors can be difficult to diagnose. The best option is to compare the installed system’s packages with a working system. It may be useful to attempt a different RPM operation (such as Verify) against either the errant package or RPM itself:
[c:\] rpm -V rpm <Enter>
Sometimes, RPM may report “[Errno 13] Permission denied” when attempting to access a package for installation (this package may exist inside the YUM cache or anywhere else (assuming RPM is called directly). As OS/2’s Unix Compatibility Subsystem is rooted, unless a third party multi-user component has been installed, the OS/2 shell (CMD, 4OS2, etc.) runs with root privileges, so lack of adequate permissions is very unusual, and tends to be more of an indication of running low on some memory resource (or available file handles) than a real problem. Often, simply closing all other running applications and attempting the operation will suffice to resolve the issue in that session. Otherwise, try rebooting and retrying the operation before starting any other applications.
See the Netlabs RPM and YUM project page for further assistance and to open support tickets specifically related to RPM.
Rebuild RPM database
This task is available from the Manage | YUM tools | Maintenance menu in Arca Noae Package Manager. See the Netlabs RPM and YUM project page for additional assistance.
Submitting Tickets
Before submitting a ticket, make sure you have read the main wiki page.
Reporting bugs and requesting new features is done through the ticketing system. You may view existing tickets, add comments, and create new tickets using the corresponding buttons at the top of every page. If you want to submit a new bug or request a feature, please use the Search function first to make sure there is no ticket for the same problem or feature request already created.
- When searching or reporting, select the Package Manager (ANPM) project.
- Please follow the guidelines as discussed in the Reporting Problems – Best Practices page.
This entry last updated: by