| View previous topic :: View next topic |
| Author |
Message |
exapo
n00b
Joined: 05 Apr 2012
Posts: 1
|
 Posted: Thu Apr 05, 2012 2:21 pm Post subject: Cdemu not working |
 |
|
When i try to launch gcdemu, i get the following message:
Daemon autostart failed. Error:
| Code: | | Error calling StartServiceByName for net.sf.cdemu.CDEMUD_Daemon: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process /usr/libexec/cdemu-daemon-session.sh exited with status 255 |
|
|
| Back to top |
|
 |
Aquous
l33t
Joined: 08 Jan 2011
Posts: 700
|
| Posted: Sat Apr 07, 2012 4:06 pm Post subject: |
|
|
| Is the vhba module loaded? Post the output of lsmod |
|
| Back to top |
|
|
Linubie
Guru
Joined: 11 Jun 2004
Posts: 381
|
| Posted: Mon Apr 09, 2012 6:15 pm Post subject: |
|
|
I have the same problem, the module is installed, but can't be loaded:
emerge -s vhba
Searching...
[ Results for search key : vhba ]
[ Applications found : 1 ]
* sys-fs/vhba
Latest version available: 20110915
Latest version installed: 20110915
Size of files: 17 kB
Homepage: http://cdemu.org
Description: Virtual (SCSI) Host Bus Adapter kernel module for the CDEmu suite
License: GPL-2
modprobe vhba
FATAL: Module vhba not found.
Tried the wiki, with no success:
http://en.gentoo-wiki.com/wiki/Image_Files
_________________
Mircosoft software is like having sex with a stranger, you always have to be careful not to get infected with something... |
|
| Back to top |
|
|
VoidMage
Watchman
Joined: 14 Oct 2006
Posts: 6196
|
| Posted: Mon Apr 09, 2012 9:59 pm Post subject: |
|
|
| @Linubie: did you remember to rebuild your modules after kernel upgrade ? |
|
| Back to top |
|
|
Linubie
Guru
Joined: 11 Jun 2004
Posts: 381
|
| Posted: Tue Apr 10, 2012 12:57 pm Post subject: |
|
|
thanks VoidMage after rebuilding, the module is now loading.
But when I start the KDE-CDemu manager it says it can't connect to the deamon, which is already running:
ps aux | grep cdemu
root 3705 0.1 0.0 142508 3348 ? Sl 14:46 0:00 cdemud --ctl-device=/dev/vhba_ctl --bus=system --num-devices=2 --audio-driver=null --logfile=/tmp/cdemu-daemon.log
root 3773 0.0 0.0 14068 888 pts/0 R+ 14:47 0:00 grep --colour=auto cdemu
_________________
Mircosoft software is like having sex with a stranger, you always have to be careful not to get infected with something... |
|
| Back to top |
|
|
vexatious
Tux's lil' helper
Joined: 24 Aug 2010
Posts: 86
|
| Posted: Sat Jan 18, 2014 9:36 pm Post subject: |
|
|
Have the same problem. I also don't see any init script for cdemu-daemon. Do we have to make our own script or what? `cdemu-daemon-2.1.1`
| Code: | Daemon autostart failed. Error:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name net.sf.cdemu.CDEmuDaemon was not provided by any .service files |
_________________
Gentoo
Slackware |
|
| Back to top |
|
|
cord
Guru
Joined: 28 Apr 2007
Posts: 346
|
| Posted: Fri Mar 16, 2018 5:36 pm Post subject: |
|
|
It's all about permissions. Look to http://cdemu.sourceforge.net/about/vhba/
| Quote: | VHBA module provides the control character device via which communication between userspace and kernelspace is done. This requires both read and write permissions on the character device for the user running the CDEmu daemon.
As such, depending on the configuration (i.e. if CDEmu daemon is to be run in session, non-root mode), it might be a good idea to include an udev rule to set up appripriate permissions. E.g.:
| Code: |
KERNEL=="vhba_ctl", NAME="%k", MODE="0660", OWNER="root", GROUP="cdrom" |
Putting the above line into .rules file in udev's rules dir (i.e. /etc/udev/rules.d/vhba.rules) will allow the access to control device for daemon run as either root or any member of cdrom group. |
Good luck! |
|
| Back to top |
|
|
cord
Guru
Joined: 28 Apr 2007
Posts: 346
|
| Posted: Thu Aug 18, 2022 7:15 am Post subject: |
|
|
After update to 3.2.5 looks like there's no way for non-systemd users to autostart cdemu-daemon anymore. Thus who uses OpenRC need to start it manually.
Let's think together. We need to run bash command "cdemu-daemon" under appropriate user. As described in #815055, it doesn't have proper background run mode.
We can't use ~/.bash_profile (it hangs system on startup) or ~/.bashrc (hangs user terminal session). Maybe we can use /etc/local.d/* but, as I understand, it will start not from user session and will have no effect.
What's a variants are else? |
|
| Back to top |
|
|
steve_v
Guru
Joined: 20 Jun 2004
Posts: 409
Location: New Zealand
|
| Posted: Thu Aug 18, 2022 11:56 am Post subject: |
|
|
| cord wrote: | | Let's think together. We need to run bash command "cdemu-daemon" under appropriate user. |
A .desktop file in ~/.config/autostart/ (KDE/Plasma) or starting it with sys-apps/daemonize work here. So does a shell wrapper that just punts it into the background and pipes it's output to a file for that matter.
I haven't checked to see what happens on a real multi-user system (i.e. cleaning up on logout and whatnot), but considering Slackware has a whole kitchen-sink (ebuild anyone?) devoted to this kind of malarkey I expect there's a reason.
IMO we're probably going to need some kind of generic solution to this going forward as more upstreams lean into systemd user units. The ongoing need to unfuck lazy "just use systemd" upstream projects is pretty annoying, but it is what it is.
Ed. Looks like pipewire is the poster-child for this stupidity, and the solutions are similar. Thankfully it's just yet another newfangled abstraction layer I don't need, want, or use.
_________________
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy. |
|
| Back to top |
|
|
cord
Guru
Joined: 28 Apr 2007
Posts: 346
|
| Posted: Thu Aug 18, 2022 4:33 pm Post subject: |
|
|
| steve_v wrote: | | A .desktop file in ~/.config/autostart/ (KDE/Plasma) |
Oh, thanks. It's enough for cdemu
| Code: | [Desktop Entry]
Comment=Autostart for cdemu-daemon
Exec=/usr/bin/cdemu-daemon
Name=cdemu-daemon
NoDisplay=true
Path=
StartupNotify=false
Terminal=false
TerminalOptions=
Type=Application
X-KDE-SubstituteUID=false
X-KDE-Username=
|
Looks like working fine now.
| steve_v wrote: |
IMO we're probably going to need some kind of generic solution to this going forward as more upstreams lean into systemd user units. The ongoing need to unfuck lazy "just use systemd" upstream projects is pretty annoying, but it is what it is.
Ed. Looks like pipewire is the poster-child for this stupidity, and the solutions are similar. Thankfully it's just yet another newfangled abstraction layer I don't need, want, or use. |
You are right. And the daemonize, you mentioned, looks perspective in that way. |
|
| Back to top |
|
|
CaptainBlood
Advocate
Joined: 24 Jan 2010
Posts: 3848
|
| Posted: Thu Aug 18, 2022 6:09 pm Post subject: |
|
|
Link may help...
Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here, i.e. a countermeasure to portage implicit braces, belt & diaper paradigm
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. " |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1686
Location: South America
|
| Posted: Sat Aug 20, 2022 3:59 pm Post subject: |
|
|
| steve_v wrote: | | cord wrote: | | Let's think together. We need to run bash command "cdemu-daemon" under appropriate user. |
[...]
IMO we're probably going to need some kind of generic solution to this going forward as more upstreams lean into systemd user units. |
| CaptainBlood wrote: | | Link may help... |
Yes, I think that something like that is the best solution here. dbus-daemon is perfectly capable of spawning activatable services itself in the absence of systemd, and even performing light supervision. Upstream's shipping of a D-Bus .service file with Exec=/bin/true is sabotaging this mechanism  So for OpenRC users, or users of any other init system for that matter, it's patching time.
I would suggest this version of the patch (untested because I won't install cdemu-daemon) to do the equivalent of the unit file's use of the %h specifier:
/etc/portage/patches/app-cdr/cdemu-daemon/dbus-service.patch
| Code: | --- original/service-example/net.sf.cdemu.CDEmuDaemon.service 2021-12-18 08:18:52.000000000 -0300
+++ patched/service-example/net.sf.cdemu.CDEmuDaemon.service 2022-08-20 12:25:12.354535127 -0300
@@ -1,4 +1,4 @@
[D-BUS Service]
Name=net.sf.cdemu.CDEmuDaemon
SystemdService=cdemu-daemon.service
-Exec=/bin/true
+Exec=/usr/local/bin/activate-cdemu-daemon |
/usr/local/bin/activate-cdemu-daemon
| Code: | #!/bin/sh
exec cdemu-daemon --config-file "$HOME/.config/cdemu-daemon" |
The only purpose of the shell script here is expanding the HOME environment variable. Which sould be inherited by dbus-daemon from whatever mechanism is used to start the per-login session message bus.
_________________
| NeddySeagoon wrote: | I'm not a witch, I'm a retired electronics engineer  |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
CaptainBlood
Advocate
Joined: 24 Jan 2010
Posts: 3848
|
| Posted: Fri Sep 13, 2024 6:38 pm Post subject: |
|
|
GDH-gentoo,
Nice clarifications.
Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here, i.e. a countermeasure to portage implicit braces, belt & diaper paradigm
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. " |
|
| Back to top |
|
|
|
Desktop Environments
