On Thu, Nov 20, 2025 at 2:50 PM Thomas Schmitt <[email protected]> wrote:
> 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=cdrkit
> 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.
Tim
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀
