Hi, i wrote: > > I am astonished that K3B from Debian tries to use cdrecord. > > Shouldn't it try to use wodim ? > > What do you get from: > > > > ls -l /usr/bin/cdrecord
Timothy M Butterworth wrote: > lrwxrwxrwx 1 root root 5 Nov 15 2024 /usr/bin/cdrecord -> wodim I must have missed the point in time when Debian began to install this softlink. On a machine which began as Debian 10 in 2020, was updated to Debian 11 in 2022, and to Debian 12 in 2024, i get lrwxrwxrwx 1 root root 5 Jun 24 2022 /usr/bin/cdrecord -> wodim I.e. it looks that this change came with Debian 11. https://tracker.debian.org/media/packages/c/cdrkit/changelog-91.1.11-5 has * Add mkisofs (and such) compatibility symlinks and adjust the necessary Conflits/Provides/Replaces, this puts the debian package inline with the other distributions (Closes: #680949) -- Laurent Bigonville <[email protected]> Thu, 09 Jan 2020 20:22:43 +0100 The remaining riddle is why wodim needs superuser powers. AFAIK it was made ready for working as normal user, back in 2006 when it was forked from cdrecord. A test as normal user on Debian 12: $ wodim dev=/dev/sr0 blank=fast -v -eject debian-12.7.0-amd64-netinst.iso ... wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits. ... Profile: 0x000A (CD-RW) (current) ... Track 01: data 631 MB Total size: 724 MB (71:47.65) = 323074 sectors Lout start: 725 MB (71:49/49) = 323074 sectors ... wodim: Cannot get next writable address for 'invisible' track. wodim: This means that we are checking recorded media. wodim: This media cannot be written in streaming mode anymore. wodim: If you like to write to 'preformatted' RW media, try to blank the media first. ... Performing OPC... Blanking PMA, TOC, pregap Blanking time: 20.008s Performing OPC... Starting new track at sector: 0 Track 01: 631 of 631 MB written (fifo 100%) [buf 100%] 10.6x. Track 01: Total bytes read/written: 661651456/661651456 (323072 sectors). Writing time: 432.311s Average write speed 10.0x. Min drive buffer fill was 100% Fixating... Fixating time: 32.383s BURN-Free was never needed. wodim: fifo had 10422 puts and 10422 gets. wodim: fifo was 0 times empty and 10228 times full, min fill was 98%. $ echo $? 0 After loading the tray again and waiting for the drive to end blinking: $ dd if=/dev/sr0 bs=2048 count=323072 status=progress oflag=dsync | md5sum 1fa7b3052cc79d68a543ee370b236670 - $ md5sum debian-12.7.0-amd64-netinst.iso 1fa7b3052cc79d68a543ee370b236670 debian-12.7.0-amd64-netinst.iso So the burn run worked indeed, despite all the warning messages which it inherited from cdrecord. The wodim binary does not have the setuid bit set. So i riddle what might be missing on your machine. (I don't have Debian 13 on real iron yet.) Jeff Walton wrote: > $ sudo setcap cap_ipc_lock+pe /usr/bin/wodim > https://bugzilla.redhat.com/show_bug.cgi?id=1583845#c12 A newly appeared demand for CAP_IPC_LOCK would be a candidate. getcap /usr/bin/wodim does not report anything on Debian 12. But the bugzilla.redhat thread is from 2019 and my wodim is from 2022. This does not look like a new demand. Possibly https://bugzilla.redhat.com/show_bug.cgi?id=1583845#c5 describes reasons why it sometimes works and sometimes does not. Have a nice day :) Thomas
