I keep getting a weird error in OBS Studio while trying to enable my virtual camera, "format not support". This is after installing packages in Manjaro 19.0.2:
yay -S dkms linux56-headers
yay -S obs-v4l2sink v4l2loopback-dkms
Is this a OBS issue or a v4l2loopback one?
I found it. I forgot to run sudo modprobe v4l2loopback. It enables it I think.
Some stuff that help me figure out a similar issue:
Note that this issue can also arise from a video device that is not available e.g.
/dev/video1 when there is no active device /dev/video1 changing to another device e.g. /dev/video0 may resolve this error
list devices with:
ls /dev | grep video
you may be able to make additional devices available when you load the kernel module:
sudo modprobe v4l2loopback devices=2
See also:
https://github.com/CatxFish/obs-v4l2sink/issues/5
Related
Can I get a tip for installing on rasp buster? Im hung up on the install directions to check the status of the rabbitMQ server. Traceback of bash console:
(volttron) pi#raspberry:~/Desktop/volttron $ echo 'export RABBITMQ_HOME=$HOME/rabbitmq_server/rabbitmq_server-3.7.7'|sudo tee --append ~/.bashrc
export RABBITMQ_HOME=$HOME/rabbitmq_server/rabbitmq_server-3.7.7
(volttron) pi#raspberry:~/Desktop/volttron $ source ~/.bashrc
pi#raspberry:~/Desktop/volttron $ RABBITMQ_HOME/sbin/rabbitmqctl status
bash: RABBITMQ_HOME/sbin/rabbitmqctl: No such file or directory
There are a few tracebacks earlier on the installation...
If it makes a difference or not here is the entire bash console process. The git gist link I just created the name install.py even though its just bash commands copied pasted per install directions...
`pi#raspberry:~/Desktop $ git clone https://github.com/VOLTTRON/volttron --branch releases/7.x`
It looks like there are a couple of different issues going on here:
The issue you quote above (RABBITMQ_HOME/sbin/rabbitmqctl: No such file or directory) is that your shell isn't finding the rabbitmqctl command. It looks like you added the RABBITMQ_HOME environment variable to your .bashrc, but used the string RABBITMQ_HOME instead of the variable expansion $RABBITMQ_HOME when you tried to run the command. Try running it as $RABBITMQ_HOME/sbin/rabbitmqctl status instead.
The rabbitmqctl status command will check the status of the rabbitmq application, but I don't think you've done anything to start it yet (that happens when you bootstrap the platform and/or start the platform configured to use the RMQ broker)
I think that the traces earlier in the installation process are problematic (appears to be the same error hit two different ways), but you just haven't run into them yet. I haven't seen any issues building gevent on the RPi 4 with buster (though it is pretty slow), but the ctypes error makes me wonder if there's an issue with the underlying c library it is trying to build on top of. I did notice that you're getting amd64 erlang packages, are you running Raspbian on an x86 processor? (if so this isn't a permutation we've tried and you may be hitting some package compatibility edge case we haven't seen)
One thing to try is to manually install cython into your virtualenvironment and then try running the bootstrap script again with the virtualenvironment activated. You could also try and pip install gevent==20.6.1 directly in that virtualenvironment (this is what the bootstrap script was doing at the failure point). VOLTTRON depends on gevent, so if that isn't installing the platform won't be able to run.
I am not able to install the package odl-dlux-all on the Ubuntu 16.04 machine. Following is the error message
Error executing command: Can't install feature odl-dlux-all/0.0.0:
null
VM : Ubuntu 16.04
Opendaylight version : Carbon
What is the issue?
Should i install gnome-desktop for this?
Prat,
This is what I have found. It looks like you and I were in the same boat. I ran into this issue, also. After additional searching, I found that ODL's website has a guide for the DLUX features.
These are the features I installed and it got me where I needed:
odl-dlux-core
odl-dluxapps-nodes
odl-dluxapps-topology
odl-dluxapps-yangui
odl-dluxapps-yangvisualizer
odl-dluxapps-yangman
Be sure you enter them as separate commands using the feature:install command prior to each of them.
I found the guide on ODL's website HERE.
I hope this helps!! :)
The way OpenDaylight's DLUX features are structured was changed in Carbon. Application-specific logic was broken out into odl-dluxapps-* Karaf features for easier maintenance.
Install and start OpenDaylight:
sudo dnf install -y http://cbs.centos.org/repos/nfv7-opendaylight-70-release/x86_64/os/Packages/opendaylight-7.0.0-1.el7.noarch.rpm
sudo systemctl start opendaylight
Connect to the Karaf shell (make take a moment for Karaf's SSH server to come up):
ssh -p 8101 karaf#localhost
# password: karaf
See the available DLUX features:
opendaylight-user#root>feature:list | grep dluxapps
odl-dluxapps-yangutils
odl-dluxapps-yangui
odl-dluxapps-topology
odl-dluxapps-yangvisualizer
odl-dluxapps-applications
odl-dluxapps-yangman
odl-dluxapps-nodes
features-dluxapps
Install the ones you're interested in:
opendaylight-user#root>feature:install odl-dluxapps-topology
In a browser on the same machine:
http://localhost:8181/index.html#/yangui/index
Login with admin/admin and things should work.
Here are the DLUX docs.
Note that DLUX isn't widely used by ODL developers, and isn't packaged as a product by vendors. Most people use the REST API directly to query OpenDaylight. There are REST API examples in the NetVirt Postman Collection, as an example.
It is true. You have to install all dlux features manually.
The Change against ODL Boron is, that Carbon removed feature odl-dlux-all. And in Carbon odl-dlux-core installs only core and nothing more. I had always gray login page in DLUX WEB login, there was nothing, only blank gray page.
I suggest you to use command: feature:list | grep dlux
This will create for you complete list of available DLUX features. And You have to install all of them.
After you finish installation of DLUX use same command with parameter -i which will show you only succesfully installed features:
feature:list -i | grep dlux
so you will see the result.
Don't forget that after instalation Dlux needs a few minutes to be fully ready. If you try to login to dlux during this time, you can get ERROR403 but also login page will not accept the credentials even they are correct. So be patient and wait.
+----------------------------------------------------------------------+
DOCUMENTATION OF OPENDAYLIGHT
IS HORIBBLE AND SOMETIMES PURELY WRONG
+----------------------------------------------------------------------+
I have my Eclipse Kepler and my simple HelloWorld C-program, where I wanted to learn how to debug a C-program. When clicking on the debug-button, I get the following error message:
Error in final launch sequence
Failed to execute MI command:
-exec-run
Error message from debugger back end:
Unable to find Mach task port for process-id 359: (os/kern) failure (0x5).
Unable to find Mach task port for process-id 359: (os/kern) failure (0x5).
I searched the whole day and didn't find any solution. I already did all of the recommended things in this post Eclipse GDB MacOSX Mavericks and still get this error.
It would be really great, if somebody could help me out setting up the debugger in Eclipse.
Oh and I downloaded and installed gdb-apple via macports and I had to use the "-f" option with the codesign command as it didn't work without. Maybe these are important information.
Keep using gdb (not gdb-apple) and just do the following steps:
1- Create a certificate:
Start Keychain Access application (/Applications/Utilities/Keychain Access.app)
Open menu /Keychain Access/Certificate Assistant/Create a Certificate...
Choose a name (gdb-cert in the example), set Identity Type to "Self Signed Root", set Certificate Type to "Code Signing" and select the "Let me override defaults".
Click several times on Continue until you get to the Specify a Location For The Certificate screen, then set Keychain to System.
Using the contextual menu for the certificate, select "Get Info", open the Trust item, and set Code Signing to "Always Trust".
2- You must quit Keychain Access application (named "taskgated",from activity monitor) and open it again in order to use the certificate.
3- Assign the certificate to gdb:
using the following command: $ codesign -s gdb-cert gdb
For more details, check this link:
http://sourceware.org/gdb/wiki/BuildingOnDarwin
if any of these steps are not clear, feel free to ask.
This may happen if you signed 'gdb' before making all changes to 'gdb-cert'. Then you can restart 'taskgated' and then re-sign the 'gdb' executable.
ps -e | grep taskgated
sudo kill -9 <pid of taskgated>
codesign -f -s gdb-cert $(which gdb)
This worked for me.
If you get this below error, don't forget to add sudo in front of the command:
sudo codesign -s gdb-cert $(which gdb-apple)
codesign -s gdb-cert $(which gdb-apple)
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate: can't create output file: /opt/local/bin/gdb-apple.cstemp (Permission denied)
/opt/local/bin/gdb-apple: the codesign_allocate helper tool cannot be found or used
I've been writing some kernel module recently. For some modules everytime i insert them or remove them a huge kernel trace is shown on screen. The errors are somewhat like
ERROR: Bad EIP value.
or
ModuleName is tainted.
What does this imply. Any help is appreciated.
The Extended Instruction Pointer exists in x86 processors, but is somehow related to a missing WiFi driver, it seems:
Yesterday I could not reach this site and read your reactions, so I
experimented with several Linux versions: Xubuntu, Slacko-Puppy 5,4
Firefox ,Puppy Akita Beta and LinuxMintMaya. And with all the same
result, i.e. no result,
But in the last install - LinuxMintMaya - I discovered the problem,
which is be found here: http://www.linuxmint.com/rel_maya.php It
tells:
Boot hangs on systems using b43 wireless cards
So after entering this command
Code: sudo apt-get install firmware-b43-installer
LinuxMintMaya works.
To boot, the Mint page says:
An upstream issue in the kernel prevents Linux Mint 13 from booting on
computers with b43 wireless cards. If you're in this situation, try
the following:
To boot the live DVD, choose the "Compatibility mode" or add the
following kernel argument to the boot options: b43.blacklist=yes
Install Linux Mint on the hard drive If not present already, in Grub,
modify the boot options to add: b43.blacklist=yes Install the b43
firmware on the system
I am trying to selfupdate my Macports, but I am getting the following message:
Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing
MacPorts sources: command execution failed
I checked my /opt/local/bin/macports and the directory does not exist. Instead, it is in /opt/local/var. Could that be the issue?
Running with -dt, I get the following:
[Users/user] > selfupdate
DEBUG: MacPorts sources location: /opt/local/var/macports/sources/rsync.macports.org/release/base
---> Updating MacPorts base sources using rsync
rsync: failed to connect to rsync.macports.org: Connection refused (61)
rsync error: error in socket IO (code 10) at /SourceCache/rsync/rsync-42/rsync/clientserver.c(105) [receiver=2.6.9]
Command failed: /usr/bin/rsync -rtzv --delete-after rsync://rsync.macports.org/release/base/ /opt/local/var/macports/sources/rsync.macports.org/release/base
Exit code: 10
DEBUG: Error synchronizing MacPorts sources: command execution failed
while executing
"macports::selfupdate [array get global_options] base_updated"
Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing MacPorts sources: command execution failed
What is error 61? Any ideas how I can fix that?
I had this same problem recently, and I forgot to run the command under root. If anyone else is having the problem, be sure to run command as so:
sudo port selfupdate
I was behind a firewall. Tried on a different network and it worked.
There is no /opt/local/bin/macports. The executable you need is /opt/local/bin/port. (Port files are in /opt/local/var/..., which is correct.)
Based on the command execution failed:
you might have forgotten to run as root.
port forks the following programs: rsync, tclsh, openssl, tar, chmod, chown.
Are these executable and in the PATH? (Is /opt/local/bin in your PATH as well?)
If that doesn't help, run port with -dt to get all sorts of debug info. That might help with finding the problem. Append the interesting parts to your question, maybe.
I faced the same issue.But I used to this method in the after.
Go to:
$prefix/etc/macports/sources.conf
(my path is like this):
/opt/local/etc/macports/sources.conf
comment out the rsync entry, and add a new entry as follows:
#rsync://rsync.macports.org/release/tarballs/ports.tar [default]
https://distfiles.macports.org/ports.tar.gz [default]
After that you can run:
sudo port -d sync
It's also explained on MacPorts.com.
Update for Mavericks: to ensure the XCode command line tools are installed, open a terminal and run xcode-select –-install, then follow the instructions in the resulting pop-up window:
accept license
Of course, this is in addition to the other tips such as making sure to run sudo port selfupdate.
If anybody else is having this issue and they've recently updated XCode, the root of my problem was that Command Line Tools had been omitted from the latest build.
Opening XCode and installing Command Line Tools via the XCode preference panel fixed this error being thrown by MacPorts.
If your company block the access via rsync you can use the http tarball. Explained here
Hope this helps.
EDIT: Now prefer to use homebrew
I too had the same error. It is because the network connection is rejected. If you are using University/Company WiFi or public connection, firewall would be refusing the connection.
As you can see from the output of -dt "rsync: failed to connect to rsync.macports.org: Connection refused (61)"
There are workarounds available which are provided on the macports site:
1) Using svn.
2) If svn fails too, you can try using Daily tarball.
You can test the changes by running "sudo port -d sync"
Note: If the https fails, you can replace it with http. But doing so is not recommended, as you will be fetching from insecure connection.
I faced the same issue.
The main problem was my network. Because the NETWORK Port was blocked for;
rsync://rsync.macports.org/release/tarballs/ports.tar
Try to use use another network.
for someone who's problem still exists, maybe you've forgot agree the Xcode license:
# sudo xcodebuild license
remember to look through and type 'agree' in the end.
In my case, the problem was internal to Macports! I updated rsync (the one delivered by Apple is old) with Macports and then Macports failed to use it (/opt/local/bin/rsync) but asked instead to use /usr/bin/rsync which does not exist (or has been erased to force using Macports rsync ?). I created a soft link between the two and now it works again.