Created attachment 1872392 [details] brasero log Description of problem: can not write audio cd anymore. Version-Release number of selected component (if applicable): wodim-1.1.11-48.fc35.x86_64 How reproducible: always Steps to Reproduce: 1.try to write audio cd with brasero or k3b 2. 3. Actual results: BraseroTranscode called brasero_job_get_output_type BraseroWodim stderr: wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits. BraseroWodim called brasero_job_get_flags BraseroWodim stdout: TOC Type: 0 = CD-DA BraseroWodim stderr: wodim: Resource temporarily unavailable. Cannot get mmap for 31461376 Bytes on /dev/zero. BraseroWodim called brasero_job_get_flags Expected results: Additional info:
I've installed an older kernel (5.15.18-200). With this kernel the problem is gone. So the problem is present in the 5.16 kernel. Reassigning.
also, ripping audio cds is very slow on 5.16: ~ 30 minutes (extract at ~ 2x) for an freshly written audio cd. A similar action in 5.15 completes in about 11 minutes (extract at ~ 8x). in both cases i used Sound Juicer.
ok, after various investigations i've found that in 5.15 wodim (used by k3b) works fine but in 5.16, 5.17 or 5.18 gives this error: /usr/bin/wodim: Cannot allocate memory. Cannot open SCSI driver! For possible targets try 'wodim --devices' or 'wodim -scanbus'. For possible transport specifiers try 'wodim dev=help'. For IDE/ATAPI devices configuration, see the file README.ATAPI.setup from the wodim documentation. Changing component to cdrkit, and version to Fedora 36. wodim-1.1.11-49.fc36.x86_64 for the record, in Linux 5.15 wodim says: Linux sg driver version: 3.5.27 Wodim version: 1.1.11 SCSI buffer size: 64512 Beginning DMA speed test. Set CDR_NODMATEST environment variable if device communication breaks or freezes immediately after that. I wonder what is brasero using, it works now in 5.17/5.18 .
It seems this only affects k3b currently. Brasero can write CDs. Have not tried CD ripping yet, though.
Also, for some reason i believe this is due to a new SSL requirement (or similar security component) in 5.16 or newer, but i don't remember now the actual reason behind this belief. When i'll get the chance i'll run a strace.
Updated title also.
So the problem may be this: # ls -l /dev/sr0 brw-rw----+ 1 root cdrom 11, 0 Oct 26 14:44 /dev/sr0 but, # chown root:cdrom /dev/cdrom # ls -l /dev/cdrom lrwxrwxrwx. 1 root root 3 Oct 26 14:44 /dev/cdrom -> sr0 I am not aware of any method of changing the link group from root to cdrom. If this is kernel's fault, i don't know. I'm tempted to believe this is coming from systemd-udev so i'll change the component accordingly. (Except there's no systemd-udev in the list, so i use systemd instead.) For the record, k3b works fine as root. Alos, brasero works probably because it uses sr0, not cdrom device.
So the problem may be this: # ls -l /dev/sr0 brw-rw----+ 1 root cdrom 11, 0 Oct 26 14:44 /dev/sr0 but, # chown root:cdrom /dev/cdrom # ls -l /dev/cdrom lrwxrwxrwx. 1 root root 3 Oct 26 14:44 /dev/cdrom -> sr0 I am not aware of any method of changing the link group from root to cdrom. If this is kernel's fault, i don't know. I'm tempted to believe this is coming from systemd-udev so i'll change the component accordingly. (Except there's no systemd-udev in the list, so i use systemd instead.) For the record, k3b works fine as root. Also, brasero works probably because it uses sr0, not cdrom device. I apologize this needed two steps but changing the component while adding some comment caused a mid-air collision ;)
(In reply to cornel panceac from comment #7) > So the problem may be this: > > # ls -l /dev/sr0 > brw-rw----+ 1 root cdrom 11, 0 Oct 26 14:44 /dev/sr0 > > but, > # chown root:cdrom /dev/cdrom > > # ls -l /dev/cdrom > lrwxrwxrwx. 1 root root 3 Oct 26 14:44 /dev/cdrom -> sr0 No, it isn't. AFAIK the rights on the symlink don't matter at all. > I am not aware of any method of changing the link group from root to cdrom. > > If this is kernel's fault, i don't know. > I'm tempted to believe this is coming from systemd-udev so i'll change the > component accordingly. (Except there's no systemd-udev in the list, so i use > systemd instead.) > > For the record, k3b works fine as root. Okay, so k3b is doing something that's not permitted for a regular user. > Alos, brasero works probably because it uses sr0, not cdrom device. Again, it doesn't matter.
Thank you David. I've done a quick test and indeed, on a root:root directory symlink i've created, the regular user can create files. It would be nice now to know how can i investigate more .
There's an error about rlimits, maybe it's related somehow. What does 'ulimit -aS' and 'ulimit -aH' say?
$ ulimit -aS real-time non-blocking time (microseconds, -R) unlimited core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 127595 max locked memory (kbytes, -l) 8192 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 127595 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited and $ ulimit -aH real-time non-blocking time (microseconds, -R) unlimited core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 127595 max locked memory (kbytes, -l) 8192 max memory size (kbytes, -m) unlimited open files (-n) 524288 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) unlimited cpu time (seconds, -t) unlimited max user processes (-u) 127595 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
Is this still present on 6.x kernels?
i confirm is not working in linux 6.0.12. also xfburn gave a 'write mode not available' error but maybe it's a different problem. brasero still works.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.