I'm trying to move away from running an application using OpenCL (on an Intel GPU, using beignet) as root all the time. I seem to have run into some permission issue though. clinfo seems to show the same permission issue. Is there some easy way of finding out what permissions/capabilities are needed?
When I run clinfo from the Linux console as an ordinary user I get the following:
drm_intel_gem_bo_context_exec() failed: Invalid argument
/dev/dri/card0 not authenticated
Device open failed, aborting...
error in /home/magnus/lcam-deb/libbeignet-lcam/src/cl_api.c line 298
Invalid device
As root it works fine.
If I start X as the same user and then run clinfo in an xterminal it works just fine too.
For me the solution was passing drm.rnodes=1 to the kernel at boot. I found that information hidden in the How to run section on the beignet wiki.
Related
I have been installing locally the latest hplip 3.6.11 (HP Linux Imaging and Printing) for two computers that run on Ubuntu 14.04 LTS. The general installation procedure is described here. The whole procedure finished seamlessly for one machine but not for another one. I would like to pinpoint the cause of this failure and complete the installation.
Incident description
The step where one computer fails is when using hp-setup to configure the printer. hp-setup is a symbolic link to a Python script. On both machines, this file has the same attributes:
ll -Z $(realpath `which hp-setup`)
-rwxr-xr-x 1 root root ? 38026 Mar 1 08:10 /usr/share/hplip/setup.py*
In the failing computer, launching hp-setup throws an import error
Please make sure your printer is connected and powered on at this time.
Do you want to setup printer in GUI mode? (u=GUI mode*, i=Interactive mode) : i
Running 'hp-setup -i' command....
Traceback (most recent call last):
File "/usr/bin/hp-setup", line 48, in <module> from base import device, utils, tui, models, module, services, os_utils
File "/usr/share/hplip/base/device.py", line 42, in <module> from . import status
File "/usr/share/hplip/base/status.py", line 33, in <module> import cupsext
ImportError: libgpg-error.so.0: failed to map segment from shared object: Permission denied
error: hp-setup failed. Please run hp-setup manually.
Concerning cupsext (in the most recent call), in both computers the build directory of hplip contains ./hplip-3.16.11/prnt/cupsext/ that contains cupsext.h and cupsext.o. Conditions are equal here.
The requisite shared object lives in the same location /lib/x86_64-linux-gnu/libgpg-error.so.0.10.0 in both computers. The ll -Z shows same attributes and permissions, again.
Concerning the suggestion to run the script manually, it does not matter whether hp-setup is run by a script or manually. Actually, I get the same error if I launch one other script hp-plugin.
Also, the fact that installation script went this far means that all dependency and conflict issues have been ironed out.
This error is repeatable. If I remove the build/object directory manually and re-install from scratch, it occurs again. Note that the installation script itself has a rule to clean existing versions of hplip, including the one I had just installed with the same script.
With this evidence I searched possible causes of this error around the internet.
HPLIP diagnostics and troubleshooting tips
hp-check cannot only find what hp-setup has not accomplished, which is consistent. Then, the troubleshoot documentation does not seem to cover this error.
SELinux permission, security contexts and the like
This cause is suggested, for example, here and here.
I do acknowledge that SELinux issues are far beyond my experience and expertise.
However, the ll -Z command above shows that the SELinux tag ? is the same for same files in both computers. So the SELinux spoor does not quite isolate the issue.
Question
What can be the reason for a Python script
to throw an import error
to fail to map a segment from a so file
to encounter a permission denied
at the same time?
Disclaimer I has already lodged a question on this error in the past https://askubuntu.com/questions/743164/hplip-update-cannot-install-plugin, but I cannot quite recall which workaround or heavenly twist worked then. The description of this one incident is much more thorough since it isolates the problem within a scripting and library issue, which is independent of Ubuntu.
I am trying to build firefox os on a Ubuntu 12.04 64 (4Gb RAM,30GB of free space, GCC-4.8.1 and g++4.8.1) following strictly all the steps from developers.mozilla and the true it is not working and I need help from community in the very last step, with my inari device connected in dev mode and visible from adb devices ./build.sh inari is giving me this error:
Blob setup script has changed, re-running Pulling files from
**../../../backup-inari** cat: **../../../backup-inari/system/build.prop**: No such file or directory Found firmware with build ID Pulling "`libOmxAacDec.so`" cp: cannot stat
**../../../backup-inari/system/lib/libOmxAacDec.so'**: No such file or directory Failed to pull `libOmxAacDec.so`. Giving up.
Build failed!
Build with `|./build.sh -j1|` for better messages
If all else fails, use |rm -rf objdir-gecko| to clobber gecko and |rm -rf out| to clobber everything else.
i tried also doing this rm stuff and start from the beginning with ./config.sh with the same result
This error seems to be causing because you either have a different version from what the builder is expecting. Or that you don't have root access to the device.
It is because of this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1121600
Please, report it and I could take it a look. Tell what branch are you trying to compile and any other relevant information.
Im trying to compile a Qt project based on the example given here.
I managed to compile without errors, but during execution there are errors. I'm getting these errors in pop up windows:
-open /dev/dsp error
-init failed
-start capture failed
-get frame failed
Moreover, the output displays:
sh: line 0: .:setqt4env:file not found
Trying open file
Could not open File! Error code: 5
/home/QFaceRec/QTFaceRecForPC exited with code 0
SIGSEGV Error when debugging with Qt Creator.
I have googled, answers are due to the application tries to access memory illegally.
Therefore, I try to execute in su - / root, but the run time error remain unsolved.
Im trying to compile and run the code in fedora with qt creator without the GPIO and serial port setting.
Anyone got any ideas to my problem? or knows how to compile the qt code in the link above
Answers are due to the application tries to access memory illegally. Therefore, I try to execute in su - / root
Do not do that! The illegal memory access is not a matter of permissions, it's a matter of the software having bugs. By running it as root, there's a possibility that those bugs will wreck your system.
So, I need to run this command:
vnstat -tr
But as a user I just created, not as root, as root it works fine, but as a regular user I get this:
Error: Unable to get interface "eth0" statistics.
Error: Interface "eth0" not available, exiting.
Operating system: Debian Linux 6.0.6
The problem was grsecurity locking /proc/net/dev from viewing it by users. The solution was to downgrade from ovhs linux core from 3.10.X to 3.8.13.
I'm developing a little program that creates virtual joysticks on linux, with a python front end. It is a fork of Linux-Virtual-Joystick.
I need to write to dev/uinput in order to create the user-defined joystick.
The file is opened with O_RDWR (I temporarily added read/write access others for the file whilst debugging). When I do
write(uifd, &uidev, sizeof(uinput_user_dev));
it returns -1 and sets errno to 22(EINVAL). The arguments are correct, and the file was successfully opened.
Did anyone else encounter this problem? I shelved the project for about a month, but I remember that it worked in the last version of Ubuntu.
Update: uinput works on ubuntu 12.10
I think the problem you have is with access rights to uinput. The error message you receive is typical of that and I have seen the identical behaviour before with other devices.
In order to test that assumption, change the /dev/uinput permissions to allow access to all:
chmod +0666 /dev/uinput
Then try again your code. If now it works fine, you will need to make that change permanent, since otherwise it will revert back to the original permissions after reboot.
To do that in a safe fashion, add a rule file to be located at: /etc/dev/rules.d
with the following line:
KERNEL=="uinput", GROUP="udev_group"
To see how a rule file should look like, check the udev rules file located at:
/lib/udev/rules.d/50-udev-default.rules
When ready, add a a group named udev_group and add your user name to it (or any user that is supposed to have write access to uinput).
You may need to reboot to get the new rule working.
The outcome would be that any user who's member of that group will have full access to uinput, which is exactly what you wanted.
to add the group you can install "Users and Groups":
sudo apt-get install gnome-system-tools
and launch it at:
Application -> System Tools -> Administration -> Users and Groups**
or in terminal:
gnome-system-tools
Since uinput module is missing, you should consider building it before going further.
I've never rebuilt a Linux kernel module this way, so you can follow the explanation here
First, you need to get the corresponding Linux source code and headers. Also install module-init-tools
Then, change dir to /usr/src/linux and do as root
cp /boot/config-* ./.config
make drivers/input/misc/uinput.ko
It'll take a minutes to build uinput.ko
Check if it works before move uinput.ko to /lib/modules/<"yourkernelversion">/kernel/drivers/input/misc
insmod ./drivers/input/misc/uinput.ko
Edit 1:
It seems that since Linux 2.6.35-17.23, uinput is a built-in module. That's why it's not shown by lsmod.
I have just taken a look at your code, and I think the problem is in this line
if (write(uifd, &uidev, sizeof(uinput_user_dev) != sizeof(uinput_user_dev)))
It should be
if (write(uifd, &uidev, sizeof(uinput_user_dev)) != sizeof(uinput_user_dev))
Hope that helps
I had this error in Ubuntu 14.04 too, from your repo (https://github.com/ferry-/Linux-Virtual-Joystick-cpp) . I fixed it by zeroing out the device::uidev member in the device constructor in device.h.
memset(&uidev, 0, sizeof(uidev));