CDemu - a virtual CD/DVD drive for Linux

Thanks for confirming it.

The new packages on PPA solved the problem. Thanks!

@yaohan: svn now has scripts to build ubuntu packages. and new packages
were uploaded.

do you have time to check if the problem still persists?

Is there a script to build Jaunty deb packages from the SVN checkout, or
are there instructions for completely removing the install from SVN after
testing? I'd like to try SVN but I'm not sure if I can easily clean up
afterwards.

Any chance of testing with current SVN?
I've tested the packages from PPA on Jaunty VM, and the daemon indeed
fails to start (didn't get the 'abort 767', though - the whole thing seemed
very much like #2749590). Current SVN seemed to work OK, though.

I used aptitude purge and then reinstall the packages, and they were able
to setup successfully. However, when I restarted X session cdemu was not
launched, and I don't see anything about cdemu in ~/.xsession-errors or
/var/log/Xorg.0.log.

Then I edited /etc/defaults/cdemu-daemon to make it run at startup again,
and running /etc/init.d/cdemu-daemon start again gives "[OK] [fail]
[fail]". I think the reason package setup failed for me was because
cdemu-daemon was configured to run at start up, so the post-install script
tries to run the init script, and for another reason the init script is
failing on my system. Then the package is in "unconfigured" state, but it
probably already wrote the statoverride line, so when apt tries to
configure it again, it gives the "override already exists" error. But
anyway, purging and reinstalling gets around the package setup problem.

However, cdemu is still not actually creating the virtual drives when I
load an image. Should I ask about this on mailing list?

For the record the packages installs and works just fine here, and I just
tested the init script. I'll test installation on a fresh system as well
soon.

I'm afraid I have no clue why you get that "abort 767" message. The second
error message about device mapping is most likely because vhba already
stopped working (so it's actually misleading).

I already have set cdemu daemon to run at system start up by editing
/etc/defaults/cdemu-daemon. It was working when I was using Ubuntu
Intrepid; I could load an image and mountpy would automatically detect and
mount the new file system. After I upgraded to Ubuntu Jaunty the init
script started failing like I described, and although cdemud runs and can
interact with the client, the devices don't appear to be created when I
load an image.

I should be using the default kernel from Ubuntu. This is the output from
the commands you asked:

% uname -r
2.6.28-11-generic
% cat /boot/config-`uname -r` | grep CONFIG_CHR_DEV_SG
CONFIG_CHR_DEV_SG=y
% cat /boot/config-`uname -r` | grep CONFIG_BLK_DEV_SR
CONFIG_BLK_DEV_SR=y
# CONFIG_BLK_DEV_SR_VENDOR is not set

For one do a PURGE to get rid of all old configuration files (!) before
installing new packages. Running "sudo apt-get purge cdemu-daemon
libmirage1 vhba-dkms" should do the trick. Remove the statoverride manually
if it still is there after the purge.

Second, the init script is disabled by default. The cdemu daemon is
started when you log into X so you'll have to log out then log in again for
it to start. It can be enabled/disabled via the command
"gnome-session-properties" or by editing "/etc/default/cdemu-daemon".

As for the device mapping error... SCSI support is built into the standard
Ubuntu kernel so it shouldn't be an issue, I guess you use a customized
kernel? But in any case this error pops up if the sr and sg_mod modules
aren't loaded before vhba is.

Can you tell me what the following commands says just to check?
uname -r
cat /boot/config-`uname -r` | grep CONFIG_CHR_DEV_SG
cat /boot/config-`uname -r` | grep CONFIG_BLK_DEV_SR

Sorry I forgot to login when reporting.