You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(22) |
Dec
(39) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(32) |
Feb
(9) |
Mar
(51) |
Apr
(16) |
May
(27) |
Jun
(26) |
Jul
(28) |
Aug
(21) |
Sep
(15) |
Oct
(19) |
Nov
(41) |
Dec
(28) |
2005 |
Jan
(31) |
Feb
(12) |
Mar
(15) |
Apr
(45) |
May
(39) |
Jun
(31) |
Jul
(22) |
Aug
(26) |
Sep
(13) |
Oct
(8) |
Nov
(5) |
Dec
(18) |
2006 |
Jan
(6) |
Feb
(12) |
Mar
(12) |
Apr
(11) |
May
(12) |
Jun
(9) |
Jul
(42) |
Aug
(20) |
Sep
(28) |
Oct
(6) |
Nov
(11) |
Dec
(44) |
2007 |
Jan
(24) |
Feb
(3) |
Mar
(9) |
Apr
(19) |
May
(21) |
Jun
(19) |
Jul
(4) |
Aug
(4) |
Sep
(1) |
Oct
(14) |
Nov
(2) |
Dec
(59) |
2008 |
Jan
(20) |
Feb
(5) |
Mar
(1) |
Apr
(24) |
May
(25) |
Jun
(48) |
Jul
(9) |
Aug
(15) |
Sep
(23) |
Oct
(4) |
Nov
(25) |
Dec
(11) |
2009 |
Jan
(10) |
Feb
(4) |
Mar
(8) |
Apr
(1) |
May
(2) |
Jun
(14) |
Jul
(14) |
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
|
2010 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
(2) |
Sep
(4) |
Oct
(1) |
Nov
(3) |
Dec
|
2011 |
Jan
(4) |
Feb
(5) |
Mar
(17) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(14) |
Nov
(9) |
Dec
(9) |
2012 |
Jan
(8) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
(17) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
2015 |
Jan
(5) |
Feb
(1) |
Mar
(14) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(36) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(14) |
Sep
(15) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
(24) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Damjan J. <dam...@gm...> - 2024-08-07 06:01:39
|
Hi Would it be possible to get cdemu-daemon to run as an iSCSI network server, instead of using the vhba kernel module? It would look something like this: +--------+ +----------------+ | client | | cdemu-daemon | +--------+ +----------------+ | I/O ^ | (user mode) | ====|=========================|============== | (kernel mode) | v | iSCSI over TCP/IP +------------------+ | | iSCSI initiator |----------+ | (provided by OS) | +------------------+ This would allow for network-transparent cdemu, and make porting cdemu to *BSD and other operating systems much easier (where the vhba-module is very difficult to port). iSCSI is supported by many operating systems, and could be used on Linux as well. Has anybody tried anything like that before? Are you aware of any limitations? If I get it working, where do I send patches? Thank you Damjan |
From: <lie...@gr...> - 2022-02-01 07:21:21
|
Rok, I have taken enough of your time, I am starting to feel real bad. There is something really screwy going on here, and I cant find the reason. I am not going to bother you any longer. I will spend next week to sort it out. My scripts did not change and cdemu works as you proved. However cdemu refuses to load any iamge I tried changemoding to 777 and moving an image over to from the nfs server so it is local with cdemu, and still doesnt mount it. There must be a very strange third party to all this and it is not fair for you to be involved anymore. You proved that it is working. However on my side it refuses to mount anything and my script that worked for years doesnt, Hand mounting in CLI also dont work so I have something here that prevents the mounting process and it is not your issue afaik. The only thing I can think of right now is that something malicious borked the images which will prevent cdemu from mopunting an image. Anyway, thanks for your unselfish help. Keep well. |
From: <lie...@gr...> - 2022-02-01 01:37:46
|
At least what good came out of this, is that there is now a method to test it properly after your instructions. I have a dummy image with toc etc. Can you give me the simplest example to load a cd image I usually test with a zero sized image I created to test with cdemu load 1 ~/Cdemu_ZeroSizeCD/nullCD.img.toc How do you want me to test it ? This fails here. On 2022-01-31 20:05, Rok Mandeljc wrote: > As indicated by the logs here, the virtual device is, in fact, being > created - at least the initial one. So your problem is not kernel or > vhba. > |
From: Rok M. <rok...@gm...> - 2022-02-01 01:05:20
|
As indicated by the logs here, the virtual device is, in fact, being created - at least the initial one. So your problem is not kernel or vhba. On 1. 02. 22 01:26, lie...@gr... wrote: > Attached find file with results of what you requested. > Note I executed everything in order as you asked, but just pasted the > results of "cdemu-daemon --default-cdemu-debug-mask 0xff" last as it > is adding data perpetually and never stops and had to be killed. > > I cleared the dmesg logs before every command. > So, I posted exactly what the commands produced in dmesg. > > > Re > "On the other hand, you could have tested with stock kernel on your > side," > > I did and it didnt work. > Do I maybe have the wrong version of vhba. It cannot be as it was all > installed from GIT package. > > > On 2022-01-31 18:16, Rok Mandeljc wrote: >> Linux vm-mx21 5.15.0-12.2-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix >> 5.15-15~mx21+1 (2022-01-03) x86_64 GNU/Linux >> >> also works for me. So it's probably not kernel related (anymore; to be >> able to use 5.15, you probably had to switch to latest vhba module >> release, anyway). On the other hand, you could have tested with stock >> kernel on your side, and eliminated the kernel as problematic variable >> yourself... >> >> When you run cdemu-daemon, do you see any new CD-ROM related entries >> in dmesg log or not? >> >> If you run "cdemu-daemon --default-cdemu-debug-mask 0xff", do you see >> packet command traffic for cdemu0 device? >> >> What is the output of "cdemu enum-parsers" (once you have the daemon >> started)? >> >> What is the "quark error" you get when you try to manually load an >> image? >> > > > _______________________________________________ > Cdemu-devel mailing list > Cde...@li... > https://lists.sourceforge.net/lists/listinfo/cdemu-devel |
From: <lie...@gr...> - 2022-02-01 00:27:17
|
Attached find file with results of what you requested. Note I executed everything in order as you asked, but just pasted the results of "cdemu-daemon --default-cdemu-debug-mask 0xff" last as it is adding data perpetually and never stops and had to be killed. I cleared the dmesg logs before every command. So, I posted exactly what the commands produced in dmesg. Re "On the other hand, you could have tested with stock kernel on your side," I did and it didnt work. Do I maybe have the wrong version of vhba. It cannot be as it was all installed from GIT package. On 2022-01-31 18:16, Rok Mandeljc wrote: > Linux vm-mx21 5.15.0-12.2-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix > 5.15-15~mx21+1 (2022-01-03) x86_64 GNU/Linux > > also works for me. So it's probably not kernel related (anymore; to be > able to use 5.15, you probably had to switch to latest vhba module > release, anyway). On the other hand, you could have tested with stock > kernel on your side, and eliminated the kernel as problematic variable > yourself... > > When you run cdemu-daemon, do you see any new CD-ROM related entries > in dmesg log or not? > > If you run "cdemu-daemon --default-cdemu-debug-mask 0xff", do you see > packet command traffic for cdemu0 device? > > What is the output of "cdemu enum-parsers" (once you have the daemon > started)? > > What is the "quark error" you get when you try to manually load an > image? > |
From: Rok M. <rok...@gm...> - 2022-01-31 23:16:43
|
Linux vm-mx21 5.15.0-12.2-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix 5.15-15~mx21+1 (2022-01-03) x86_64 GNU/Linux also works for me. So it's probably not kernel related (anymore; to be able to use 5.15, you probably had to switch to latest vhba module release, anyway). On the other hand, you could have tested with stock kernel on your side, and eliminated the kernel as problematic variable yourself... When you run cdemu-daemon, do you see any new CD-ROM related entries in dmesg log or not? If you run "cdemu-daemon --default-cdemu-debug-mask 0xff", do you see packet command traffic for cdemu0 device? What is the output of "cdemu enum-parsers" (once you have the daemon started)? What is the "quark error" you get when you try to manually load an image? On 31. 01. 22 23:53, lie...@gr... wrote: > I am sorry to hassle you like this. > It must be a thankless job having to deal with these issues. > I do appreciate cdemu. Probably one of the most useful pieces of > software ever. > > My script is not the problem I just tested it on my MX18 installation. > Same script. Loads all the CDs without any trouble. > It cannot load it with one kernel and then another not due to the script. > > > Sure I checked by trying to load a single dummy image. > Refuses to. > Gives me some quark error sometimes. > > In the MX Package installer, there is a section called "MX Test Repo" > There you will find the kernel > Linux version 5.15.0-12.2-liquorix-amd64 I am using. > > The stock MX kernel you used is basically useless for any low latency > high demand processes, so the liquorix kernel is just miles ahead. > > > > > On 2022-01-31 16:55, Rok Mandeljc wrote: >> I've just tested the setup with clean installation of MX21 (the XFCE >> variant, stock kernel: "Linux vm-mx21 5.10.0-9-amd64 #1 SMP Debian >> 5.10.70-1 (2021-09-30) x86_64 GNU/Linux"). >> >> I've built cdemu debs from git checkout, which should be equivalent to >> latest release of individual components). Everything works as expected >> here (the daemon autostart does not, but that's because the >> distribution does not use systemd by default): loading an image, >> creating and removing an additional device, etc. >> >> So whatever issue you're having, it's specific to your setup or that >> script you keep mentioning... Have you tried manually loading a single >> image? Have you checked the output of dmesg for any errors? >> >> >> On 31. 01. 22 22:14, lie...@gr... wrote: >>> Rok, >>> >>> Everything loaded, the modules and cdemu-daemon, cdemu status cdemu >>> load etc all executes. >>> >>> My script in user space or cd images did not change and for some >>> reason cdemu just do not load a cdimage and attach it to a device srX >>> >>> At this stage I must conclude that cdemu installs perfectly with >>> this kernel, but that it is quietly non-functional. >>> >>> The kernel is Linux version 5.15.0-12.2-liquorix-amd64 >>> >>> Can you suggest a debian based (especially a liquorix kernel if >>> possible, I can install on my system and verify that it works with >>> your specified kernel but not the kernel I listed above. Having a >>> known to be working "certified" kernel from you, it would be easy to >>> debug this. >>> >>> >>> _______________________________________________ >>> Cdemu-devel mailing list >>> Cde...@li... >>> https://lists.sourceforge.net/lists/listinfo/cdemu-devel >> >> >> _______________________________________________ >> Cdemu-devel mailing list >> Cde...@li... >> https://lists.sourceforge.net/lists/listinfo/cdemu-devel > > > _______________________________________________ > Cdemu-devel mailing list > Cde...@li... > https://lists.sourceforge.net/lists/listinfo/cdemu-devel |
From: <lie...@gr...> - 2022-01-31 22:53:35
|
I am sorry to hassle you like this. It must be a thankless job having to deal with these issues. I do appreciate cdemu. Probably one of the most useful pieces of software ever. My script is not the problem I just tested it on my MX18 installation. Same script. Loads all the CDs without any trouble. It cannot load it with one kernel and then another not due to the script. Sure I checked by trying to load a single dummy image. Refuses to. Gives me some quark error sometimes. In the MX Package installer, there is a section called "MX Test Repo" There you will find the kernel Linux version 5.15.0-12.2-liquorix-amd64 I am using. The stock MX kernel you used is basically useless for any low latency high demand processes, so the liquorix kernel is just miles ahead. On 2022-01-31 16:55, Rok Mandeljc wrote: > I've just tested the setup with clean installation of MX21 (the XFCE > variant, stock kernel: "Linux vm-mx21 5.10.0-9-amd64 #1 SMP Debian > 5.10.70-1 (2021-09-30) x86_64 GNU/Linux"). > > I've built cdemu debs from git checkout, which should be equivalent to > latest release of individual components). Everything works as expected > here (the daemon autostart does not, but that's because the > distribution does not use systemd by default): loading an image, > creating and removing an additional device, etc. > > So whatever issue you're having, it's specific to your setup or that > script you keep mentioning... Have you tried manually loading a single > image? Have you checked the output of dmesg for any errors? > > > On 31. 01. 22 22:14, lie...@gr... wrote: >> Rok, >> >> Everything loaded, the modules and cdemu-daemon, cdemu status cdemu >> load etc all executes. >> >> My script in user space or cd images did not change and for some >> reason cdemu just do not load a cdimage and attach it to a device srX >> >> At this stage I must conclude that cdemu installs perfectly with this >> kernel, but that it is quietly non-functional. >> >> The kernel is Linux version 5.15.0-12.2-liquorix-amd64 >> >> Can you suggest a debian based (especially a liquorix kernel if >> possible, I can install on my system and verify that it works with >> your specified kernel but not the kernel I listed above. Having a >> known to be working "certified" kernel from you, it would be easy to >> debug this. >> >> >> _______________________________________________ >> Cdemu-devel mailing list >> Cde...@li... >> https://lists.sourceforge.net/lists/listinfo/cdemu-devel > > > _______________________________________________ > Cdemu-devel mailing list > Cde...@li... > https://lists.sourceforge.net/lists/listinfo/cdemu-devel |
From: Rok M. <rok...@gm...> - 2022-01-31 21:56:05
|
I've just tested the setup with clean installation of MX21 (the XFCE variant, stock kernel: "Linux vm-mx21 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux"). I've built cdemu debs from git checkout, which should be equivalent to latest release of individual components). Everything works as expected here (the daemon autostart does not, but that's because the distribution does not use systemd by default): loading an image, creating and removing an additional device, etc. So whatever issue you're having, it's specific to your setup or that script you keep mentioning... Have you tried manually loading a single image? Have you checked the output of dmesg for any errors? On 31. 01. 22 22:14, lie...@gr... wrote: > Rok, > > Everything loaded, the modules and cdemu-daemon, cdemu status cdemu > load etc all executes. > > My script in user space or cd images did not change and for some > reason cdemu just do not load a cdimage and attach it to a device srX > > At this stage I must conclude that cdemu installs perfectly with this > kernel, but that it is quietly non-functional. > > The kernel is Linux version 5.15.0-12.2-liquorix-amd64 > > Can you suggest a debian based (especially a liquorix kernel if > possible, I can install on my system and verify that it works with > your specified kernel but not the kernel I listed above. Having a > known to be working "certified" kernel from you, it would be easy to > debug this. > > > _______________________________________________ > Cdemu-devel mailing list > Cde...@li... > https://lists.sourceforge.net/lists/listinfo/cdemu-devel |
From: <lie...@gr...> - 2022-01-31 21:15:05
|
Rok, Everything loaded, the modules and cdemu-daemon, cdemu status cdemu load etc all executes. My script in user space or cd images did not change and for some reason cdemu just do not load a cdimage and attach it to a device srX At this stage I must conclude that cdemu installs perfectly with this kernel, but that it is quietly non-functional. The kernel is Linux version 5.15.0-12.2-liquorix-amd64 Can you suggest a debian based (especially a liquorix kernel if possible, I can install on my system and verify that it works with your specified kernel but not the kernel I listed above. Having a known to be working "certified" kernel from you, it would be easy to debug this. |
From: <lie...@gr...> - 2022-01-31 11:26:24
|
I always ran it in the user account, but it doesnt work. Devices are not created. Therefore I then tried it in root too, same problem. Here is the head of my script output. It calls cdemu-daemon first thing ~$ /backup1/System_Programs/MountCdemuImages/mountcdemuimages.scr 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 Why would no devices be created ? although cdemu-daemon doesnt give any errors in the user account ? On 2022-01-31 06:10, Rok Mandeljc wrote: > On 31. 01. 22 11:54, lie...@gr... wrote: >> I seemingly still have D-Bus problems. >> All modules loaded, but cannot get daemon started as root-user. >> Any idea what I dow rong ? > > > Yes, you're trying to run the daemon as root. Only regular user has > access to their session bus... > > If you want to run a system-wide instance of cdemu daemon as root, you > need to put it on system bus. As I mentioned in one of previous > e-mails, we don't provide configuration files for that anymore, but > you can back-port them yourself from an earlier release or set up your > own equivalent. > > > > _______________________________________________ > Cdemu-devel mailing list > Cde...@li... > https://lists.sourceforge.net/lists/listinfo/cdemu-devel |
From: Rok M. <rok...@gm...> - 2022-01-31 11:10:59
|
On 31. 01. 22 11:54, lie...@gr... wrote: > I seemingly still have D-Bus problems. > All modules loaded, but cannot get daemon started as root-user. > Any idea what I dow rong ? Yes, you're trying to run the daemon as root. Only regular user has access to their session bus... If you want to run a system-wide instance of cdemu daemon as root, you need to put it on system bus. As I mentioned in one of previous e-mails, we don't provide configuration files for that anymore, but you can back-port them yourself from an earlier release or set up your own equivalent. |
From: <lie...@gr...> - 2022-01-31 10:54:39
|
To ADD I followed all the advice you gave here, "https://sourceforge.net/p/cdemu/bugs/55/" and did a chmod 777 on the device you mentioned in the link. But devices are still not created. Everything just tries to map to /dev/sr0 as cdemu does not create more devices to map to. My kernel is; Linux version 5.15.0-12.2-liquorix-amd64 I seemingly still have D-Bus problems. All modules loaded, but cannot get daemon started as root-user. Any idea what I dow rong ? # 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 cdemu: Daemon: D-Bus: failed to get proxy for 'org.freedesktop.DBus' on session bus: The connection is closed! Daemon initialization and start failed! |
From: <lie...@gr...> - 2022-01-31 10:42:24
|
I seemingly still have D-Bus problems. All modules loaded, but cannot get daemon started as root-user. Any idea what I dow rong ? # 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 cdemu: Daemon: D-Bus: failed to get proxy for 'org.freedesktop.DBus' on session bus: The connection is closed! Daemon initialization and start failed! |
From: Rok M. <rok...@gm...> - 2022-01-28 10:59:21
|
I indeed meant dbus-user-session, which is what the deb package is referencing: https://github.com/cdemu/cdemu/blob/ac8d4122bddfd0de5be8af1607ba327f0094957e/cdemu-daemon/debian/control#L15 On 28. 01. 22 11:46, lie...@gr... wrote: > Rok, > > I came across a post you made here > "https://bugs.launchpad.net/cdemu/+bug/1926303" when I was searching > for dbus related errors as it seems it is what I have. > > At the end of your post you mention > "dbus-service-session" > > AFAIK there is no such dbus session and I cant find it in any > repositories. > It does sound like my problem. > > Can you confirm that "dbus-service-session" actually exists and you > didnt mean something else like "dbus-user-session" ? > > Thanks > > > _______________________________________________ > Cdemu-devel mailing list > Cde...@li... > https://lists.sourceforge.net/lists/listinfo/cdemu-devel |
From: <lie...@gr...> - 2022-01-28 10:46:53
|
Rok, I came across a post you made here "https://bugs.launchpad.net/cdemu/+bug/1926303" when I was searching for dbus related errors as it seems it is what I have. At the end of your post you mention "dbus-service-session" AFAIK there is no such dbus session and I cant find it in any repositories. It does sound like my problem. Can you confirm that "dbus-service-session" actually exists and you didnt mean something else like "dbus-user-session" ? Thanks |
From: <lie...@gr...> - 2022-01-28 10:40:02
|
It stopped working again. Maybe it was something else I installed that interferes as my setup script did not change. I understand what you say and rc.local wont work as cdemu-daemon needs to be run from a user account and seemingly I need to do something with Dbus too. But, it worked perfectly the first time I executed cdemu-daemon. I could play all my cd images - perfect. Now what it does is not loading the images at all for some reason. Unfortunately I didnt make a system backup at the previous working condition which I should have. So I most likely will have to start from scratch again. It definitely must have been something I installed that knocked cdemu out. My biggest pains in Linux are systemD, dbus and python. If those three can disappear life would be much better. Every problem I ever get always involves one or more of them as the cause. But that is not going to happen. Any history of other installations you know of that borks cdemu. Man it worked so well but tanked seemingly due to other program installations or due to Dbus as I do get Dbus quark errors. On 2022-01-28 04:57, Rok Mandeljc wrote: > Up until cdemu-daemon 3.2.4, we've been using D-BUS on-demand > activation in combination with a shell script to launch the daemon. > And we shipped both user-session and system-session configuration: > > https://github.com/cdemu/cdemu/tree/cdemu-daemon-3.2.4/cdemu-daemon/system > > https://github.com/cdemu/cdemu/tree/cdemu-daemon-3.2.4/cdemu-daemon/session > > In cdemu-daemon 3.2.5, we switched to D-BUS on demand activation in > combination with systemd unit, and removed the system-session > configuration: > > https://github.com/cdemu/cdemu/tree/cdemu-daemon-3.2.5/cdemu-daemon/service-example > > So if you're trying to auto-launch the system-wide daemon instance on > system bus, that won't work out-of-box anymore. > > If you want/need to use a different start-up mechanism or want to use > system bus for some reason, you are free to set it up however you like > (sysV init script, backport of old dbus+script activation, etc.). > > > On 28. 01. 22 05:59, lie...@gr... wrote: >> >> Rok >> |
From: Rok M. <rok...@gm...> - 2022-01-28 09:58:09
|
Up until cdemu-daemon 3.2.4, we've been using D-BUS on-demand activation in combination with a shell script to launch the daemon. And we shipped both user-session and system-session configuration: https://github.com/cdemu/cdemu/tree/cdemu-daemon-3.2.4/cdemu-daemon/system https://github.com/cdemu/cdemu/tree/cdemu-daemon-3.2.4/cdemu-daemon/session In cdemu-daemon 3.2.5, we switched to D-BUS on demand activation in combination with systemd unit, and removed the system-session configuration: https://github.com/cdemu/cdemu/tree/cdemu-daemon-3.2.5/cdemu-daemon/service-example So if you're trying to auto-launch the system-wide daemon instance on system bus, that won't work out-of-box anymore. If you want/need to use a different start-up mechanism or want to use system bus for some reason, you are free to set it up however you like (sysV init script, backport of old dbus+script activation, etc.). On 28. 01. 22 05:59, lie...@gr... wrote: > > Rok > > Got it working !! > > I got the popup as attached, but tried to start the daemon manually by > > #cdemu-daemon > > and it worked ! > > Since I could start cdemu manually, the error clearly is related to a > third party system process or daemon that is supposed to start it. > > I cant figure out who the daemon is that could not even do a simple > program start. > It cant be sysV init as it is too rugged to fail with something this > simple > Since you wrote the software I am sure you will be able to tell me > which process fails to do the trivial here so I can get rid of it. > > I will just start cdemu-daemon in rc.local in the mean time > I see that cdemu-daemon is not in .etc.init.d ? > That has been starting processes reliably since unix so you must be > using something else than > the standard init.d or you moved to systemD without any sysV support > for cdemu. > > There is a lot of us who will stick with sysV > > I am just Sooooo glad to have c demu back up and running. > Some of the best useful software ever. > > Thanks > > > > > > _______________________________________________ > Cdemu-devel mailing list > Cde...@li... > https://lists.sourceforge.net/lists/listinfo/cdemu-devel |
From: <lie...@gr...> - 2022-01-28 04:59:35
|
Rok Got it working !! I got the popup as attached, but tried to start the daemon manually by #cdemu-daemon and it worked ! Since I could start cdemu manually, the error clearly is related to a third party system process or daemon that is supposed to start it. I cant figure out who the daemon is that could not even do a simple program start. It cant be sysV init as it is too rugged to fail with something this simple Since you wrote the software I am sure you will be able to tell me which process fails to do the trivial here so I can get rid of it. I will just start cdemu-daemon in rc.local in the mean time I see that cdemu-daemon is not in .etc.init.d ? That has been starting processes reliably since unix so you must be using something else than the standard init.d or you moved to systemD without any sysV support for cdemu. There is a lot of us who will stick with sysV I am just Sooooo glad to have c demu back up and running. Some of the best useful software ever. Thanks |
From: <lie...@gr...> - 2022-01-28 01:53:24
|
You are allowed to whack me over the head,. I should have seen the trivial copy to a missing directory. It is not even bash-preschool level type error I overlooked. My work ethic seemingly has been going to the dogs lately. At my level and experience with Unix I should not have asked that question. It all installed, but got the message I have to reboot for some modules to load into kernel which I cant do right now. So far so good. You're the ACE. Very nice script. Rok should include your script in his distro. I attach the final version of your script I adapted to work for me on debian11-Bullseye flavors. This makes life much easier thanks a lot. I added the mkdir out rather to just before it is needed and rather recreate it with every rerun of the script someone else may do. Just good principles to clean all directories before a rerun as you dont want to accidentally rely on old files. See rm -r -f out && mkdir out Again it installed without any error now on Debian11-Bullseye. Thanks very much. On 2022-01-27 06:20, Anders Jonsson wrote: > Ah, > I think I see the error. The script I sent you expected there to be a > directory "out" to move all *.build and *.changes files to. There > isn't and the files are left in the root git directory, and dpkg then > tried to install those output files as debs. > > Adding a "mkdir out" in the beginning of the script should make sure > that the directory exists. > > > Sorry for sloppy scripting, it was really just a convenience script to > make cdemu building easier on my system. :-) > > Another thing that the script does not do is removing old debs, so if > there are new versions of cdemu and friend packages, you'll probably > want to remove old debs manually first. > > > Regards, > Anders > |
From: Anders J. <and...@no...> - 2022-01-27 11:45:21
|
Ah, I think I see the error. The script I sent you expected there to be a directory "out" to move all *.build and *.changes files to. There isn't and the files are left in the root git directory, and dpkg then tried to install those output files as debs. Adding a "mkdir out" in the beginning of the script should make sure that the directory exists. Sorry for sloppy scripting, it was really just a convenience script to make cdemu building easier on my system. :-) Another thing that the script does not do is removing old debs, so if there are new versions of cdemu and friend packages, you'll probably want to remove old debs manually first. Regards, Anders Den 2022-01-27 kl. 07:18, skrev lie...@gr...: > anders > > > I ran your script manually after adjusting it as I install as root > user and dont need the sudos. > > > The installation fails at the last step. > dpkg -i image-analyzer_* && dpkg -i cdemu-daemon_* && dpkg -i > cdemu-client_* && dpkg -i gcdemu_*" > > The result is the same for all three arguments, but I just list the > first error as the script will exit at the first && > > #dpkg -i cdemu-daemon_* && dpkg -i cdemu-client_* && dpkg -i gcdemu_* > > dpkg-deb: error: 'cdemu-daemon_3.2.6-1_amd64.build' is not a Debian > format archive > dpkg: error processing archive cdemu-daemon_3.2.6-1_amd64.build > (--install): > dpkg-deb --control subprocess returned error exit status 2 > dpkg-deb: error: 'cdemu-daemon_3.2.6-1_amd64.buildinfo' is not a > Debian format archive > dpkg: error processing archive cdemu-daemon_3.2.6-1_amd64.buildinfo > (--install): > dpkg-deb --control subprocess returned error exit status 2 > dpkg-deb: error: 'cdemu-daemon_3.2.6-1_amd64.changes' is not a Debian > format archive > dpkg: error processing archive cdemu-daemon_3.2.6-1_amd64.changes > (--install): > dpkg-deb --control subprocess returned error exit status 2 > (Reading database ... 521024 files and directories currently installed.) > Preparing to unpack cdemu-daemon_3.2.6-1_amd64.deb ... > Unpacking cdemu-daemon (3.2.6-1) over (3.2.6-1) ... > Setting up cdemu-daemon (3.2.6-1) ... > Processing triggers for man-db (2.9.4-2) ... > Errors were encountered while processing: > cdemu-daemon_3.2.6-1_amd64.build > cdemu-daemon_3.2.6-1_amd64.buildinfo > cdemu-daemon_3.2.6-1_amd64.changes > > The script I used is attached. > > > > _______________________________________________ > Cdemu-devel mailing list > Cde...@li... > https://lists.sourceforge.net/lists/listinfo/cdemu-devel |
From: <lie...@gr...> - 2022-01-27 06:31:03
|
anders Or, it seems that it is just due to the wildcard that you install all architectures available and see if one installs. Ok, cancel then my previous post, I see the example in my previous post actually installed so ignore that. Here are the errors for dpkg -i image-analyzer_* && dpkg -i cdemu-daemon_* && dpkg -i cdemu-client_* && dpkg -i gcdemu_* # dpkg -i image-analyzer_* (Reading database ... 521067 files and directories currently installed.) Preparing to unpack image-analyzer_3.2.5-1_all.deb ... Unpacking image-analyzer (3.2.5-1) over (3.2.5-1) ... dpkg-deb: error: 'image-analyzer_3.2.5-1_amd64.build' is not a Debian format archive dpkg: error processing archive image-analyzer_3.2.5-1_amd64.build (--install): dpkg-deb --control subprocess returned error exit status 2 dpkg-deb: error: 'image-analyzer_3.2.5-1_amd64.buildinfo' is not a Debian format archive dpkg: error processing archive image-analyzer_3.2.5-1_amd64.buildinfo (--install): dpkg-deb --control subprocess returned error exit status 2 dpkg-deb: error: 'image-analyzer_3.2.5-1_amd64.changes' is not a Debian format archive dpkg: error processing archive image-analyzer_3.2.5-1_amd64.changes (--install): dpkg-deb --control subprocess returned error exit status 2 Setting up image-analyzer (3.2.5-1) ... Processing triggers for mailcap (3.69) ... Processing triggers for desktop-file-utils (0.26-1) ... Errors were encountered while processing: image-analyzer_3.2.5-1_amd64.build image-analyzer_3.2.5-1_amd64.buildinfo image-analyzer_3.2.5-1_amd64.changes # dpkg -i cdemu-daemon_* dpkg-deb: error: 'cdemu-daemon_3.2.6-1_amd64.build' is not a Debian format archive dpkg: error processing archive cdemu-daemon_3.2.6-1_amd64.build (--install): dpkg-deb --control subprocess returned error exit status 2 dpkg-deb: error: 'cdemu-daemon_3.2.6-1_amd64.buildinfo' is not a Debian format archive dpkg: error processing archive cdemu-daemon_3.2.6-1_amd64.buildinfo (--install): dpkg-deb --control subprocess returned error exit status 2 dpkg-deb: error: 'cdemu-daemon_3.2.6-1_amd64.changes' is not a Debian format archive dpkg: error processing archive cdemu-daemon_3.2.6-1_amd64.changes (--install): dpkg-deb --control subprocess returned error exit status 2 (Reading database ... 521067 files and directories currently installed.) Preparing to unpack cdemu-daemon_3.2.6-1_amd64.deb ... Unpacking cdemu-daemon (3.2.6-1) over (3.2.6-1) ... Setting up cdemu-daemon (3.2.6-1) ... Processing triggers for man-db (2.9.4-2) ... Errors were encountered while processing: cdemu-daemon_3.2.6-1_amd64.build cdemu-daemon_3.2.6-1_amd64.buildinfo cdemu-daemon_3.2.6-1_amd64.changes # dpkg -i cdemu-client_* (Reading database ... 521067 files and directories currently installed.) Preparing to unpack cdemu-client_3.2.5-1_all.deb ... Unpacking cdemu-client (3.2.5-1) over (3.2.5-1) ... dpkg-deb: error: 'cdemu-client_3.2.5-1_amd64.build' is not a Debian format archive dpkg: error processing archive cdemu-client_3.2.5-1_amd64.build (--install): dpkg-deb --control subprocess returned error exit status 2 dpkg-deb: error: 'cdemu-client_3.2.5-1_amd64.buildinfo' is not a Debian format archive dpkg: error processing archive cdemu-client_3.2.5-1_amd64.buildinfo (--install): dpkg-deb --control subprocess returned error exit status 2 dpkg-deb: error: 'cdemu-client_3.2.5-1_amd64.changes' is not a Debian format archive dpkg: error processing archive cdemu-client_3.2.5-1_amd64.changes (--install): dpkg-deb --control subprocess returned error exit status 2 Setting up cdemu-client (3.2.5-1) ... Processing triggers for mailcap (3.69) ... Processing triggers for desktop-file-utils (0.26-1) ... Processing triggers for man-db (2.9.4-2) ... Errors were encountered while processing: cdemu-client_3.2.5-1_amd64.build cdemu-client_3.2.5-1_amd64.buildinfo cdemu-client_3.2.5-1_amd64.changes # dpkg -i gcdemu_* (Reading database ... 521067 files and directories currently installed.) Preparing to unpack gcdemu_3.2.6-1_all.deb ... Unpacking gcdemu (3.2.6-1) over (3.2.6-1) ... dpkg-deb: error: 'gcdemu_3.2.6-1_amd64.build' is not a Debian format archive dpkg: error processing archive gcdemu_3.2.6-1_amd64.build (--install): dpkg-deb --control subprocess returned error exit status 2 dpkg-deb: error: 'gcdemu_3.2.6-1_amd64.buildinfo' is not a Debian format archive dpkg: error processing archive gcdemu_3.2.6-1_amd64.buildinfo (--install): dpkg-deb --control subprocess returned error exit status 2 dpkg-deb: error: 'gcdemu_3.2.6-1_amd64.changes' is not a Debian format archive dpkg: error processing archive gcdemu_3.2.6-1_amd64.changes (--install): dpkg-deb --control subprocess returned error exit status 2 Setting up gcdemu (3.2.6-1) ... Processing triggers for mailcap (3.69) ... Processing triggers for desktop-file-utils (0.26-1) ... Processing triggers for libglib2.0-0:i386 (2.66.8-1) ... Processing triggers for libglib2.0-0:amd64 (2.66.8-1) ... Processing triggers for hicolor-icon-theme (0.17-2) ... Errors were encountered while processing: gcdemu_3.2.6-1_amd64.build gcdemu_3.2.6-1_amd64.buildinfo gcdemu_3.2.6-1_amd64.changes |
From: <lie...@gr...> - 2022-01-27 06:18:43
|
anders I ran your script manually after adjusting it as I install as root user and dont need the sudos. The installation fails at the last step. dpkg -i image-analyzer_* && dpkg -i cdemu-daemon_* && dpkg -i cdemu-client_* && dpkg -i gcdemu_*" The result is the same for all three arguments, but I just list the first error as the script will exit at the first && #dpkg -i cdemu-daemon_* && dpkg -i cdemu-client_* && dpkg -i gcdemu_* dpkg-deb: error: 'cdemu-daemon_3.2.6-1_amd64.build' is not a Debian format archive dpkg: error processing archive cdemu-daemon_3.2.6-1_amd64.build (--install): dpkg-deb --control subprocess returned error exit status 2 dpkg-deb: error: 'cdemu-daemon_3.2.6-1_amd64.buildinfo' is not a Debian format archive dpkg: error processing archive cdemu-daemon_3.2.6-1_amd64.buildinfo (--install): dpkg-deb --control subprocess returned error exit status 2 dpkg-deb: error: 'cdemu-daemon_3.2.6-1_amd64.changes' is not a Debian format archive dpkg: error processing archive cdemu-daemon_3.2.6-1_amd64.changes (--install): dpkg-deb --control subprocess returned error exit status 2 (Reading database ... 521024 files and directories currently installed.) Preparing to unpack cdemu-daemon_3.2.6-1_amd64.deb ... Unpacking cdemu-daemon (3.2.6-1) over (3.2.6-1) ... Setting up cdemu-daemon (3.2.6-1) ... Processing triggers for man-db (2.9.4-2) ... Errors were encountered while processing: cdemu-daemon_3.2.6-1_amd64.build cdemu-daemon_3.2.6-1_amd64.buildinfo cdemu-daemon_3.2.6-1_amd64.changes The script I used is attached. |
From: <lie...@gr...> - 2022-01-27 04:36:49
|
Rok Adding to my previous request: independent from the debian list I will try in turn until modules load. I currently installed the following kernels on my system but did not try them yet except for the default issued kernels; ii linux-image-amd64 5.10.92-1 ii linux-image-5.10.0-11-amd64 5.10.92-1 ii linux-image-5.10.0-9-amd64 5.10.70-1 All three above which had failed to load kernel modules So which of these do you recommend ? ii linux-image-5.10.0-11-amd64 5.10.92-1 amd64 Linux 5.10 for 64-bit PCs (signed) ii linux-image-5.10.0-9-amd64 5.10.70-1 amd64 Linux 5.10 for 64-bit PCs (signed) ii linux-image-5.14.0-11.1-liquorix-amd64 5.14-13~mx21+1 amd64 Linux 5.14 for 64-bit PCs ii linux-image-5.14.0-13.1-liquorix-amd64 5.14-15~mx21+1 amd64 Linux 5.14 for 64-bit PCs ii linux-image-5.14.0-17.1-liquorix-amd64 5.14-22~mx21+1 amd64 Linux 5.14 for 64-bit PCs ii linux-image-5.15.0-10.1-liquorix-amd64 5.15-11~mx21+1 amd64 Linux 5.15 for 64-bit PCs ii linux-image-5.15.0-12.2-liquorix-amd64 5.15-15~mx21+1 amd64 Linux 5.15 for 64-bit PCs ii linux-image-5.15.0-6.2-liquorix-amd64 5.15-8~mx21+1 amd64 Linux 5.15 for 64-bit PCs ii linux-image-amd64 5.10.92-1 amd64 Linux for 64-bit PCs (meta-package) ii linux-image-liquorix-amd64 5.15-15~mx21+1 amd64 Linux image for liquorix on 64-bit PCs It would be just nice to start with something that you believe has a good chance loading the kernel modules needed as I will have to go through a lot of kernels otherwise. |
From: <lie...@gr...> - 2022-01-27 04:11:11
|
Rok Which of the kernels published here will work according to you with cdemu. I have to use liquorix as the kernel excels in realtime use with applications needing it. "https://liquorix.net/debian/pool/main/l/linux-liquorix/" |
From: <lie...@gr...> - 2022-01-27 01:16:35
|
Anders & Rok. Thank you very much for the insights. Rok, will it be ok if I post all the kernels available for me? That way you may recognize ones that would work. Problem is, with some kernels all modules load without error but cdemu still dont work. Other kernels it works. I obviously discount kernels which fail to load the modules necessary. Once I have one working I can debug the rest. Anders, Thank you very much I will try your installation sequence. Am not afraid of source, it is my preferred way to install in any case, but I have not been successful in this case. Again I have no beef with cdemu. It is absolutely fantastic software. Just very difficult to get running, but way worth the effort. |