Hi Experts,

I am getting an error while trying to run the pkgorder script ( part of anaconda-runtime rpm ) that tried to populate hte list of rpm's required for installation.

The pkgorder script imports a lot of packages like os, shutils, rpm, sys etc and all of these are successfull includin ghte import of yum package.

But when the pkgorder tries to run "from yuminstall import YumSorter", it gives the following error.

Stack Trace Snippet ::


/dev/mapper/control: open failed: Permission denied
Failure to communicate with kernel device-mapper driver.
dm.c: 1565
Traceback (most recent call last):
File "/usr/lib/anaconda-runtime/pkgorder", line 32, in ?
from yuminstall import YumSorter
File "/usr/lib/anaconda/", line 31, in ?
from packages import recreateInitrd
File "/usr/lib/anaconda/", line 19, in ?
import iutil
File "/usr/lib/anaconda/", line 16, in ?
import os, isys, string, stat
File "/usr/lib/anaconda/", line 32, in ?
import block
File "/usr/lib64/python2.4/site-packages/block/__init__.py", line 6, in ?
File "/usr/lib64/python2.4/site-packages/block/", line 190, in ?
File "/usr/lib64/python2.4/site-packages/block/", line 195, in MPNameCache
MemoryError


Please let me know what is going wrong and the reason why we get such errors, so that i can follow your leads and pursue the resolution for the issue.

Thanks,
K

Dani AI

Generated

A short, practical diagnosis for : that initial "/dev/mapper/control: open failed: Permission denied" is the real clue — the Python block package (imported by anaconda’s helpers) tries to talk to the kernel device‑mapper during module import, and when it can’t access the control node the device‑mapper codepath can cascade into the MPNameCache logic and raise a MemoryError in older pyblock/libdevmapper flows. This exact symptom has been reported in the Fedora/Red Hat trackers. (bugzilla.redhat.com)

Quick, safe checks to run (don’t blindly chmod 777):

ls -l /dev/mapper/control
id
sudo dmsetup ls
free -m
strace -f -o /tmp/trace python -c 'from yuminstall import YumSorter'
  • Confirm who owns the control node and whether the process is running as root.
  • Try sudo dmsetup ls — if that works, the issue is privilege-related.
  • Check available RAM/swap; a true MemoryError can also come from very low memory.

Changing device nodes to 777 will “fix” the symptom but is insecure and brittle; the safer approaches are to run the installer/script with appropriate privileges, or adjust udev rules / device ownership so the intended account has read access to device‑mapper devices. If the environment is an installer (anaconda) it is expected to run with root privileges. Example multipath/udev rules and ownership conventions are commonly used instead of world‑writable device nodes. (oracle-base.com)

If the problem persists after running as root, check the exact lines around MPNameCache in /usr/lib64/python2.4/site-packages/block/device.py to see what the code is doing (it iterates device‑mapper maps); historical bugs show this codepath can fail when libdevmapper/kernel versions mismatch or when the module encounters unexpected return data. If needed, capture a strace and paste the trace around the failing open()/ioctl calls — that will point to whether this is a permission, compatibility, or genuine out‑of‑memory issue. (bugzilla.redhat.com)

Short summary: ’s tip points at the problem, but prefer running the script as root or fixing device permissions via udev/group rules and confirming libdevmapper/kernel compatibility before making device nodes world‑writable.

That first line there seems like a good clue. change the permissions of /dev/map/control to 755 and see what happens. Try 777 if 755 doesnt work.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.