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.
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.
Sometimes, operations fail before completing, leaving the installation and the databases in varying states of inconsistency. This task 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.
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 to 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.
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