Bug 2075418

Summary: kernel 5.16 prevents k3b access to /dev/cdrom
Product: [Fedora] Fedora Reporter: cornel panceac <cpanceac>
Component: k3bAssignee: KDE SIG <kde-sig>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 39CC: acaringi, adscvr, airlied, alciregi, bskeggs, dtardon, fedoraproject, filbranden, flepied, frantisek.kluknavsky, hdegoede, hhorak, hpa, jarodwilson, jglisse, jkucera, jonathan, josef, jreznik, justin.zobel, kde-sig, kernel-maint, lgoncalv, linville, lnykryn, masami256, mchehab, msekleta, pcahyna, ptalbert, rdieter, ryncsn, smparrish, ssahani, s, steved, systemd-maint, than, yuwatana, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
brasero log none

Description cornel panceac 2022-04-14 07:34:08 UTC
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:

Comment 1 cornel panceac 2022-04-14 08:05:19 UTC
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.

Comment 2 cornel panceac 2022-04-14 08:52:14 UTC
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.

Comment 3 cornel panceac 2022-06-18 08:07:48 UTC
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 .

Comment 4 cornel panceac 2022-10-25 04:08:10 UTC
It seems this only affects k3b currently. Brasero can write CDs. Have not tried CD ripping yet, though.

Comment 5 cornel panceac 2022-10-25 04:21:54 UTC
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.

Comment 6 cornel panceac 2022-10-25 04:25:01 UTC
Updated title also.

Comment 7 cornel panceac 2022-10-26 12:02:36 UTC
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.

Comment 8 cornel panceac 2022-10-26 12:04:56 UTC
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 ;)

Comment 9 David Tardon 2022-11-01 15:25:59 UTC
(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.

Comment 10 cornel panceac 2022-11-02 06:45:28 UTC
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 .

Comment 11 Zbigniew Jędrzejewski-Szmek 2022-11-02 09:39:04 UTC
There's an error about rlimits, maybe it's related somehow.
What does 'ulimit -aS' and 'ulimit -aH' say?

Comment 12 cornel panceac 2022-11-02 13:33:54 UTC
$ 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

Comment 13 Justin Zobel 2023-01-02 05:11:57 UTC
Is this still present on 6.x kernels?

Comment 14 cornel panceac 2023-01-02 15:26:43 UTC
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.

Comment 15 Ben Cotton 2023-04-25 17:00:50 UTC
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.

Comment 16 Fedora Release Engineering 2023-08-16 07:05:33 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.