Hi,
Max Nikulin wrote:
> Instead of manual "ln", looking into /lib/udev/rules.d/60-cdrom_id.rules, I
> expect something like (untested, I do not have an optical drive)
>
> SUBSYSTEM=="block", KERNEL=="sr[0-9]*", ENV{DEVTYPE}=="disk",
> ACTION!="remove", SYMLINK+="scd%n"
>
> in /etc/udev/rules.d/
This would indeed be preferrable, because it automagically creates
the symlinks as drives appear.
> <https://salsa.debian.org/debian/cdrkit>
> is public enough. There is no separate upstream repository. Last commits to
> this one are almost exclusively related to Debian packaging staff.
https://salsa.debian.org/debian/cdrkit/-/commits/main
looks like the history of a Debian packaging repo, like the one which i
have to deal with when a new release of xorriso et.al. shall be
prepared as .deb files. The upstream source in such a repo is usually
not up for changes. So it is suitable only for patches.
I wonder by which channel this patch came in:
"isoinfo: support EFI architectur"
"Heinrich Schuchardt authored Mar 08, 2025 and Andreas Beckmann's
avatar Andreas Beckmann committed Sep 28, 2025"
https://salsa.debian.org/debian/cdrkit/-/commit/97000c15e42ec923bcf9fec3ec439f0400e85909
The bug tracker does not show a matching bug report:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src="">
So it must have been submitted somewhere else.
> You info related
> to scdX vs. srX device naming and to locking issues with sgX may be
> extremely valuable though to those whose who have optical drives and some
> time to prepare a fix.
I think all tangible info for this case is in my 8 years old comment:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833346#35
My fix proposals there look still overall valid to me:
-------------------------------------------------------------------------
In libusal/scsi-linux-sg.c, check_linux_26(), line 254:
- return ( 0==uname( &buf ) && sscanf(buf.release, "%d.%d", &gen, &tmp)>1 && tmp>=6);
+ return ( 0==uname( &buf ) && sscanf(buf.release, "%d.%d", &gen, &tmp)>1 && (gen>2 || tmp>=6));
This one would return 1 with 1.6 or higher. But
https://en.wikipedia.org/wiki/Linux_kernel_version_history
says that kernel 1.x ended at 1.3.100.
Since the patch will only be applied to new Debian packages of cdrkit,
one may safely assume that the kernel version will be 6 or higher.
-----------------------------------------------------------------------
In libusal/scsi-linux-sg.c, usalo_open(), line 532:
- pattern="/dev/scd%d";
+ pattern="/dev/sr%d";
One may safely assume that /dev/sr* will be there in Debian >=13, when
optical drives are attached.
(I re-entered the Debian world with Jessie in 2015. No /dev/scd* were
ever seen and /dev/sr* reliably showed up for each drive. But in 2006
when wodim was forked from cdrecord, the /dev/scd* aberration was
obviously in full bloom. I once had both, /dev/scd* and /dev/sr*, on
SuSE.)
-----------------------------------------------------------------------
Have a nice day :)
Thomas
I also ran into this problem. It was caused by permissions.
Running:
sudo chmod 4711 /usr/bin/wodim
sudo chmod 4711 /usr/bin/cdrdao
Fixed the problem for me.