writing to /dev/uinput (on ubuntu 12.04) - linux

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));

Related

Changing path to WSL remote

I have an issue with VS Code and WSL remote extension. On my machine, Windows Defender Firewall blocked node. I do not have sufficient rights to unblock it, but admins created excluded folder, where based on what they said "I can copy everything that I will need and it is excluded from Windows Defender Firewall check". So I copied VS Code there but I need to also copy the package with Debian Linux there and link it to the new path.
But I was not able to find where this path to Debian is stored, and how it can be changed. For me, the folder is now in
C:\Users\{username}\AppData\Local\Packages\TheDebianProject.DebianGNULinux_... and need to be moved to C:\ExcludedFolder
Is this possible? Thank you very much for your response.
First up, you might be able to solve your firewall problem a slightly different way. I can't say for certain (and things are always changing), but it's been my experience that Firewall/Defender only detect and block for WSL1 applications. This is at least true for the malware/antivirus detection, but I believe it would extend to the firewall functionality as well. On the other hand, if it doesn't, then moving the instance to a different directory may not help with your issue.
You can double-check the version of your Debian instance using wsl -l -v. If it's version 1, then let's try converting it to 2 (if you have that permission on your system).
The first steps here are going to be the same regardless of whether you just convert the instance or move it:
First, exit your WSL/Debian instance and then issue wsl --shutdown. You can do this from PowerShell, CMD, or the Start Menu; but I'm going to assume for the rest of the instructions that you are in PowerShell.
Run the following in PowerShell:
cd <your exclusion directory>
mkdir wsl\images
cd wsl\images
wsl --export Debian 2021-11-02_Debian_backup.tar
Assuming that your instance is WSL1 and you want to try to convert to WSL2, you at least now have a backup. Run wsl --set-version Debian 2 to convert it to WSL2. Then start it up and see if there are any differences in how node behaves. You can always convert it back with wsl --set-version Debian 1, of course.
If you still need to try moving it:
cd <your exclusion directory>\wsl
mkdir instances\debian_exclude
wsl --import debian_exclude instances\debian_exclude images\2021-11-02_Debian_backup.tar --version 2
wsl -d debian_exclude
Note that you can, of course, call the filenames and directories whatever you want. Also note that you can change the version number when you import it. Select whichever WSL version you need there.
You should now be in a new instance of Debian, but you'll be running as root by default. You need to set the default user of the imported instance by creating /etc/wsl.conf with the following:
[user]
default=<your_wsl_username>
Exit the instance, run another wsl --shutdown, and restart. You should now be running as your normal user. Try node again there to see if new location allows it to be excluded from the firewall rules.
If everything is working as intended, you can wsl --unregister Debian to remove the old instance. Please note that this will remove all files in the instance, so please make sure that your backup and new instance have everything you need first.
Unregistering the old instance should set the new one as your default, but if not, you can use wsl --set-default debian_exclude.

Starting a program in a chroot environment returns immediately

I am working in a virtual environment, trying to start open vm tools in a chroot environment.
I tested with bash and it seems to work fine.
I used ./configure --options --prefix=/home/chroot_env to install the program, then using ldd on vmtoolsd, i copied the corresponding libraries to the /lib directory.
Now when I start chroot /home/chroot_env /bin/vmtoolsd, nothing happens, the chroot returns directly. Launching the same binary in the normal environment does work.
Does someone have an idea why it isn't working, the correct libraries are there, and it works with bash.
EDIT : strace showed that vmtoolsd is trying to access /dev/console, I added mount --bind /dev/ /home/chroot_env/dev/ but it is still failing.
EDIT2 : another strace showed it was looking for another plugin loaded dynamically, i added it and it worked, conclusion strace is great for debugging such issue!
When you run a program and nothing happens, you can always run it with strace in order to see which syscalls are made. This is an easy way to obtain the list of the files (regular or not) that are opened. In your case, check that your program doesn't try to access a file that is not in the chroot.

How does "biosdevname" really work?

I know the purpose of "biosdevname" feature in Linux, but I'm not sure how
exactly it works.
I tested it with Ubuntu 14.04 and Ubuntu 14.10 (both 64-bit server editions)
and it looks like they enable it by default - right after system startup my
network interface has a name such as p4p1 instead of eth0, no customization
is needed. As I understood it, in order for biosdevname to be enabled, BOTH
of these two conditions must be met:
a boot option biosdevname=1 must be passed to a kernel
biosdevname package must be installed
As I already mentioned, both Ubuntu 14.04 and 14.10 seem to offer biosdevname
as a default feature: they come with biosdevname package already installed, I
didn't need to modify grub.cfg either - GRUB_CMDLINE_LINUX_DEFAULT has no
parameters and my network interface still has a BIOS name (p*p*) instead of a
kernel name (eth*.)
Later I wanted to restore the old style device naming and that's where the
interesting part begins. I decided to experiment a bit while trying to disable
the biosdevname feature. Since it requires biosdevname package to work (or
so I read here and there), I assumed removing it would be enough to disable the
feature, so I typed:
sudo apt-get purge biosdevname
To my surprise, after reboot my network interface was still p4p1, so
biosdevname clearly still worked even though biosdevname package had been
wiped out.
As a next step, I applied appropriate changes to /etc/network/interfaces in
order to restore the old name of my network interface (removed entry for p4p1
and added entry for eth0). As a result, after another reboot, ifconfig
reported neither eth0 nor p4p1 which was another proof that OS still
understood BIOS names instead of kernel names.
It turned out that I also had to explicitly change GRUB entry to
GRUB_CMDLINE_LINUX_DEFAULT=biosdevname=0 and update GRUB to get the expected
result (biosdevname disabled and old name of network interface restored).
My question is: how could biosdevname work without biosdevname package? Is
it not required after all? If so, what exactly provides the biosdevname
functionality and how does it work?
The reason biosdevname keeps annoying you even after you uninstall the package, is that it installed itself in the initrd 'initial ramdisk' file as well.
When uninstalling, the /usr/share/initramfs-tools/hooks/biosdevname is removed, but there is no postrm script in the package so update-initramfs is not executed and biosdevname is still present in the /boot/initrd... file used in the first stage of system startup.
You can fully get rid of it like this:
$ sudo update-initramfs -u

Cannot enable PRU on Beaglebone Black

I am trying to enable the PRU module on my BeagleBone Black, but I came across two errors.
The first one, is when I am trying to activate it:
echo BB-BONE-PRU-01 >/sys/devices/bone_capemgr.9/slots
and I get this error:
-sh: echo: write error: No such file or directory
And the second one comes up when I try to run a simple example, like this:
./PRU_memAccessPRUDataRam
with this error:
./PRU_memAccessPRUDataRam: error while loading shared libraries: libprussdrv.so: cannot open shared object file: No such file or directory
Ho you have any ideea on how can I resolve this two issues? Thank you!
Re first question: check whether your file system has /sys/devices/bone_capemgr.9 or /sys/devices/bone_capemgr.8. Many use the command: >sudo echo BB-BONE-PRU-01 >/sys/devices/bone_capemgr.*/slots, so it doesn't matter; note also the need for sudo unless you have previously done a sudo su or have logged in as root (not normally recommended).
Re second question: it may be related to first problem. Also, see: http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2. As explained in Step 1), do an >lsmod to see if pru is enabled. If not, you can do a >modprobe uio_pruss or better, change the device tree loaded at bootup (am335x-boneblack.dtb) to have the pru parameter status = "disabled" changed to status = "okay". The link above, authored by Shabaz, is the most useful and understandable link I have found in about a year (on and off) of working with the BBB; it's well worth going through everything there as a tutorial.

Linux (Mageia): make not found /usr/bin/make

I recently installed Lazarus 1.0.12 on Mageia Linux Operating System. While in the middle of bring back everything to where It was, before my computer crashed. I am running into this error which I have never seen before.
Take a look at the following image:
I found some solutions online, but they all pointed me to the fact that I need to set the correct make path within Option->>Environment->>File->>Make to /usr/bin/make
I did make the change, but it still raises same error.
What am I doing wrong?
According to the comment made by the asker, /usr/bin/make does not exist, so we need to install make first.
Try this:
urpmi make
This requires root privilege.
See URPMI and Software management.

Resources