# Intentando hacer funcionar cdemu-daemon con DBUS

## cameta

https://forums.gentoo.org/viewtopic-t-1136316-highlight-cdemu.html

https://forums.gentoo.org/viewtopic-t-1068622-highlight-cdemu.html

El cdemu-daemon no funciona con dbus y por lo que se ve se debe a un problema con las UDEV-RULES ya que este programa está pensado para systemd y no open-rc. 

Intentare ir poniendo lo que me encuentro.

----------

## cameta

```
mestres@localhost ~ $ cdemu-daemon

Starting CDEmu daemon with following parameters:

 - config file: (null) (exists: 0)

 - num devices: 1

 - control device: /dev/vhba_ctl

 - audio driver: null

 - bus type: session

 - default CDEmu debug mask: 0x0

 - default libMirage debug mask: 0x0

```

Se arranca manualmente sin problemas.

----------

## cameta

cat  /etc/udev/rules.d/60-vhba.rules 

 KERNEL=="vhba_ctl", MODE="0660", OWNER="root", GROUP="cdrom"

Poner así la udev.rule no ha servido para nada.

Voy a probar con

KERNEL=="vhba_ctl", SUBSYSTEM=="misc", TAG+="uaccess"

A ver que sucede

PD

dbus-launch cdemu status

ERROR: Failed to connect to CDEmu daemon: g-io-error-quark: Error calling StartServiceByName for net.sf.cdemu.CDEmuDaemon: Timeout was reached (24)

Sigue sin funcionar.

Ampliación

He probado con diferentes USE en dbus pero no ha servido de nada.

Sigo pensando que se trata de un problema con las udev.rule.

----------

## chrootman

```
$  cdemu-daemon 

Starting CDEmu daemon with following parameters:

 - config file: (null) (exists: 0)

 - num devices: 1

 - control device: /dev/vhba_ctl

 - audio driver: null

 - bus type: session

 - default CDEmu debug mask: 0x0

 - default libMirage debug mask: 0x0
```

KDE CDEmu Manager monté la iso de install-amd64-minimal-20210616T214502Z.iso

Eso es todo lo que hice porque no tengo dvd. Sirve como daemon tools para montar las imágenes de los juegos? Tenía openrc en funtoo, pero lo borré. Tengo systemd solamente.

----------

## cameta

Si, pero esto debería de activarse automáticamente al iniciar DBUS.

https://cdemu.sourceforge.io/about/vhba/

Voy a leer esto atentamente, a ver que es lo que pasa.

De momento según portage

```
equery files vhba

 * Searching for vhba ...

 * Contents of sys-fs/vhba-20210418:

/lib

/lib/modules

/lib/modules/5.10.27-gentoo

/lib/modules/5.10.27-gentoo/block

/lib/modules/5.10.27-gentoo/block/vhba.ko

/lib/udev

/lib/udev/rules.d

/lib/udev/rules.d/69-vhba.rules

/usr

/usr/share

/usr/share/doc

/usr/share/doc/vhba-20210418

/usr/share/doc/vhba-20210418/AUTHORS

/usr/share/doc/vhba-20210418/ChangeLog

/usr/share/doc/vhba-20210418/README.bz2

```

Estoy observando que hay varios sitios donde van esas udev.rules

/etc/udev/rules.d/60-vhba.rules (no sale en el portage) ???? 

/lib/udev/rules.d/69-vhba.rules

----------

## chrootman

Dice que puede almacenarse tanto en /lib/udev/rules.d como en /etc/udev/rules.d. Pero dice que la etiqueta regla debe ejecutarse antes almacenandola con un número menor a 70. El enfoque obsoleto que a veces es el que mejor funciona es usando los permisos de lectura/escritura en el dispositivo de control que es lo que hiciste:

```
# locate vhba 

/etc/modules-load.d/vhba.conf

/home/chrootman/portage/metadata/md5-cache/sys-fs/vhba-20200106-r1

/home/chrootman/portage/metadata/md5-cache/sys-fs/vhba-20210418

/home/chrootman/portage/sys-fs/vhba

/home/chrootman/portage/sys-fs/vhba/Manifest

/home/chrootman/portage/sys-fs/vhba/metadata.xml

/home/chrootman/portage/sys-fs/vhba/vhba-20200106-r1.ebuild

/home/chrootman/portage/sys-fs/vhba/vhba-20210418.ebuild

/lib/modules/5.4.48-gentoo-x86_64/block/vhba.ko

/lib/udev/rules.d/69-vhba.rules

/usr/share/doc/vhba-20210418

/usr/share/doc/vhba-20210418/AUTHORS

/usr/share/doc/vhba-20210418/ChangeLog

/usr/share/doc/vhba-20210418/README.bz2

/var/db/pkg/sys-fs/vhba-20210418

/var/db/pkg/sys-fs/vhba-20210418/BDEPEND

/var/db/pkg/sys-fs/vhba-20210418/BUILD_TIME

/var/db/pkg/sys-fs/vhba-20210418/CATEGORY

/var/db/pkg/sys-fs/vhba-20210418/CBUILD

/var/db/pkg/sys-fs/vhba-20210418/CFLAGS

/var/db/pkg/sys-fs/vhba-20210418/CHOST

/var/db/pkg/sys-fs/vhba-20210418/CONTENTS

/var/db/pkg/sys-fs/vhba-20210418/COUNTER

/var/db/pkg/sys-fs/vhba-20210418/CXXFLAGS

/var/db/pkg/sys-fs/vhba-20210418/DEFINED_PHASES

/var/db/pkg/sys-fs/vhba-20210418/DEPEND

/var/db/pkg/sys-fs/vhba-20210418/DESCRIPTION

/var/db/pkg/sys-fs/vhba-20210418/EAPI

/var/db/pkg/sys-fs/vhba-20210418/FEATURES

/var/db/pkg/sys-fs/vhba-20210418/HOMEPAGE

/var/db/pkg/sys-fs/vhba-20210418/INHERITED

/var/db/pkg/sys-fs/vhba-20210418/IUSE

/var/db/pkg/sys-fs/vhba-20210418/IUSE_EFFECTIVE

/var/db/pkg/sys-fs/vhba-20210418/KEYWORDS

/var/db/pkg/sys-fs/vhba-20210418/LDFLAGS

/var/db/pkg/sys-fs/vhba-20210418/LICENSE

/var/db/pkg/sys-fs/vhba-20210418/NEEDED

/var/db/pkg/sys-fs/vhba-20210418/NEEDED.ELF.2

/var/db/pkg/sys-fs/vhba-20210418/PF

/var/db/pkg/sys-fs/vhba-20210418/RDEPEND

/var/db/pkg/sys-fs/vhba-20210418/SIZE

/var/db/pkg/sys-fs/vhba-20210418/SLOT

/var/db/pkg/sys-fs/vhba-20210418/USE

/var/db/pkg/sys-fs/vhba-20210418/environment.bz2

/var/db/pkg/sys-fs/vhba-20210418/repository

/var/db/pkg/sys-fs/vhba-20210418/vhba-20210418.ebuild

/var/db/repos/gentoo/metadata/md5-cache/sys-fs/vhba-20200106-r1

/var/db/repos/gentoo/sys-fs/vhba

/var/db/repos/gentoo/sys-fs/vhba/Manifest

/var/db/repos/gentoo/sys-fs/vhba/metadata.xml

/var/db/repos/gentoo/sys-fs/vhba/vhba-20200106-r1.ebuild
```

```
#  equery f cdemu-daemon 

 * Searching for cdemu-daemon ...

 * Contents of app-cdr/cdemu-daemon-3.2.5:

/etc

/etc/modules-load.d

/etc/modules-load.d/vhba.conf

/usr

/usr/bin

/usr/bin/cdemu-daemon

/usr/lib

/usr/lib/systemd

/usr/lib/systemd/user

/usr/lib/systemd/user/cdemu-daemon.service

/usr/share

/usr/share/dbus-1

/usr/share/dbus-1/services

/usr/share/dbus-1/services/net.sf.cdemu.CDEmuDaemon.service

/usr/share/doc

/usr/share/doc/cdemu-daemon-3.2.5

/usr/share/doc/cdemu-daemon-3.2.5/AUTHORS

/usr/share/doc/cdemu-daemon-3.2.5/README.bz2

/usr/share/locale

/usr/share/locale/ru

/usr/share/locale/ru/LC_MESSAGES

/usr/share/locale/ru/LC_MESSAGES/cdemu-daemon.mo

/usr/share/locale/sl

/usr/share/locale/sl/LC_MESSAGES

/usr/share/locale/sl/LC_MESSAGES/cdemu-daemon.mo

/usr/share/man

/usr/share/man/man8

/usr/share/man/man8/cdemu-daemon.8.bz2
```

 *cameta wrote:*   

> Voy a probar con
> 
> KERNEL=="vhba_ctl", SUBSYSTEM=="misc", TAG+="uaccess"
> 
> A ver que sucede
> ...

 

Imagino que ya lo cambiaste a udev-acl.

/lib/udev/rules.d/69-vhba.rules

```
KERNEL=="vhba_ctl", SUBSYSTEM=="misc", TAG+="udev-acl"
```

Y que esté cargado el módulo, en arch me dio 3 opciones de módulo incluído dkms.

----------

## DraGo85

Interesante hilo cameta, me suscribo para ver tus resultados en este proceso.  :Smile: 

----------

## cameta

I *Quote:*   

> magino que ya lo cambiaste a udev-acl.
> 
> /lib/udev/rules.d/69-vhba.rules
> 
> Código:	
> ...

 

Pues no ha funcionado .  :Sad:   Voy a mirar en la guia de arch. A ver como lo hacen. Claramente el problema es que esto lo han diseñado para systemd y yo uso openrc . Podría migrar a systemd pero es un trabajo de chinos y no vale la pena.

----------

## quilosaq

Creo que no hay nada que arreglar en la reglas de udev. Segun lo que he entendido dbus NO tiene que arrancar cdemu-daemon sino que cuando un programa necesite cdemu-daemon ese programa usará dbus para comunucarse con systemd para que sea systemd quien arranque cdemu-daemon.

El problema está en cómo arrancar cdemu-daemon si no usamos systemd. El paquete no proporciona un guión para openrc y avisa que en ese caso se debe iniciar manualmente. En mi opinión eso quiere decir que se debe ejecutar una vez la sesión de xorg-server está lanzada. La manera de conseguirlo sería poner el comando 

```
cdemu-daemon&
```

 en el archivo .xsession del usuario que lo necesite si usamos un display manager o en .xinitrc si usamos startx

----------

## chrootman

En mi caso uso systemd y se creo automáticamente: 

```
nano /etc/modules-load.d/vhba.conf

vhba

$ lsmod | grep vhba

vhba                   28672  1
```

Que carga el modulo vhba.

Si ejecuto KDE CDEmu Manager retorna:

 *Quote:*   

> Unable to connect to the CDEmu daemon

 

Por lo tanto debo ejecutar antes

```
$ cdemu-daemon 

Starting CDEmu daemon with following parameters:

 - config file: (null) (exists: 0)

 - num devices: 1

 - control device: /dev/vhba_ctl

 - audio driver: null

 - bus type: session

 - default CDEmu debug mask: 0x0

 - default libMirage debug mask: 0x0
```

Para poder montar una iso por ejemplo. Por lo tanto el problema no es ejecutar manualmente cdemu-daemon sino que al ejecutarlo no retorne error. Creo que  es un bug, lo busqué en internet y luego de un extenso hilo de gente usando openrc no se da una solución.

----------

## cameta

 *Quote:*   

> >>> Messages generated by process 30939 on 2021-05-31 22:39:24 CEST for package app-cdr/cdemu-daemon-3.2.5:
> 
> LOG: postinst
> 
> As of 3.2.5, cdemu-daemon no longer supports autoloading
> ...

 

Claramente con open-rc ya no va a arrancar automáticamente. 

Luego también esta este otro mensaje

 *Quote:*   

> >>> Messages generated by process 30299 on 2021-02-23 16:45:12 CET for package app-cdr/cdemu-daemon-3.2.4:
> 
> LOG: postinst
> 
> You will need to load the vhba module to use cdemu devices:
> ...

 

----------

## cameta

Lo he vuelto a dejar todo como estaba originalmente.

----------

## cameta

En conclusión.

1º Necesitas systemd para que esto arranque automáticamente

2º No tiene sentido migrar a systemd, ya que puede generar problemas y yo necesito el pc operativo.

3º Cuando haga una nueva instalación usare systemd.

4º Hacer algo con .xinitrc o xsession

----------

