How to add a CD-ROM device to a profile?

Incus
1

I’m trying to get Automatic Ripping Machine in its docker form to work in a container via a profile and container instance created with that profile.

I cannot solve is how to add the CD-ROM device to the profile.

I have tried acting like it is a disk, to no avail:
sudo incus profile device add Ripz cdrom disk source=/dev/sr0 path=/dev/sr0

This fails with Failed to start device "cdrom": Failed detecting source path "/dev/sr0" block device filesystem: Failed to run: blkid -s TYPE -o value /dev/sr0: exit status 2

Based on these old links reddit post and blog post, I cooked up these calls after finding how to call lxc calls directly (theoretically):

sudo incus profile set Ripz raw.lxc.cgroup.devices.allow='b 11:0 rwm'
sudo incus profile set Ripz raw.lxc.autodev=1
sudo incus profile set Ripz raw.lxc.hook.autodev='sh -c "mknod -m 666 /dev/sr0 b 11 0; ln -s /dev/sr0 /dev/cdrom"'

These fail with Error: Unknown configuration key: and the key following, indicating that this is not the way to set lxc settings - yet the description sounds like it should be. I could also be lost in time such that these are no longer relevant lxc settings, since the links are between 6 and 9 years old. It’s not clear to me how to find relevant ones, if the names changed.

I also have attached to the profile

sudo incus profile set Ripz security.nesting=true
sudo incus profile set Ripz security.syscalls.intercept.mknod=true
sudo incus profile set Ripz security.syscalls.intercept.setxattr=true

The first lets docker work, the second would let a mknod command work I assume, and the third honestly idk I found it with an add-a-GPU guide and seemed like an idea here.

The autoripper docker will call udevadm info --query=env /dev/sr0 to check /dev/sr0 on startup, so that call in the Ripz instance is my baseline to see if the cdrom access works. Some relevant output is here just in case it’s needed:

❯ udevadm info --query=env /dev/sr0
DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:01:00.0/ata6/host5/target5:0:0/5:0:0:0/block/sr0
DEVNAME=/dev/sr0
DEVTYPE=disk
DISKSEQ=9
MAJOR=11
MINOR=0
SUBSYSTEM=block
USEC_INITIALIZED=3515651
ID_CDROM=1

Love using Incus btw, thanks for forkin and keeping it truckin!

Edit: full command in case someone finds this is

sudo incus profile device add Ripz cdrom unix-block source=/dev/sr0
2

Try unix-block source=/dev/sr0

3

Sadly it looks like eject does not work, nor any disc detection. Next benchmark is for eject to work in the container, I guess!

This snippet of errors comes from the docker itself:

eject: tried to use `/dev/mapper/shotbox--vg-root' as device name but it is no block device
eject: tried to use `/mnt//dev/sr0' as device name but it is no block device
eject: device name is `/dev/sr0'
eject: expanded name is `/dev/sr0'
eject: `/dev/mapper/shotbox--vg-root' is mounted at `/dev/sr0'
eject: expanded name is `/mnt//dev/sr0'
eject: `/mnt//dev/sr0' is not mounted
eject: `/mnt//dev/sr0' is not a mount point
eject: unable to find or open device for: `/dev/sr0'

Calling eject in the container yields a similar error:

root@autoripper:~# eject /dev/sr0
eject: /dev/mapper/shotbox--vg-root: not found mountpoint or device with the given name

As far as I can tell, shotbox--vg-root is the main drive of my computer. I’m not sure why that’s getting linked to /dev/sr0 instead of the actual /dev/sr0.

I added /dev/sr0 with sudo incus profile device add Ripz cdrom unix-block source=/dev/sr0

udevadm info --query=env /dev/sr0 also gives only 6 lines in the container instead of the many, many lines in the main OS. They’re the same 6 lines as the main OS, though. Was hoping that was good enough - mayhaps not.

Any ideas why /dev/sr0 is getting lost?

4

What does eject -F -m -r -v /dev/sr0 get you?

5

Thanks for the quick reply!

The response calling that in the container is:

root@autoripper:~# eject -F -m -r -v /dev/sr0
eject: device name is `/dev/sr0'
eject: /dev/mapper/shotbox--vg-root: mounted on /dev/sr0
eject: /dev/mapper/shotbox--vg-root: not found mountpoint or device with the given name
6

I tried adding the CD-ROM drive as a PCI device (...pci address=/devices/pci... from the udevadm info above), but that didn’t work. That was a small hope since the PCI device is the SATA controller not the drive itself.

I haven’t been able to finagle any other solution.

The aforementioned blog post did get it working a long long while ago, so LXC can do it. I wasn’t able to get the direct-to-LXC calls working that mimic what said blog post shows:

sudo incus profile set Ripz raw.lxc.cgroup.devices.allow='b 11:0 rwm'
sudo incus profile set Ripz raw.lxc.autodev=1
sudo incus profile set Ripz raw.lxc.hook.autodev='sh -c "mknod -m 666 /dev/sr0 b 11 0; ln -s /dev/sr0 /dev/cdrom"

Do you have experience with .lxc.calls via Incus to set LXC settings directly? That might be what is needed to get this working

7

I found that

sudo incus config set autoripper raw.lxc "lxc.cgroup.devices.allow='b 11:0 rwm'"

and similar commands (note, not profile) worked but they only worked once (can’t have multiple calls) and overrode sudo incus config set autoripper raw.idmap if you had used that, as I had.

I tried

sudo incus config edit autoripper

but the documentation on multi-line isn’t there where I looked and whatever I winged up from other people’s examples (specifically in the reddit thread comments about working it on LXD ubuntu 16.04) made the edit thing mad. Like it accepted it, but said it was wrong. Ctrl+C out of it and it’s still there though, idk! Didn’t change it.

Anyway, I tried to implement the hook thing mentioned in the reddit thread (ACTION=="change", ENV{ID_FS_TYPE}!="", SUBSYSTEM=="block", KERNEL=="sr0", RUN+="incus exec autoripper -- docker exec -it autoripper /opt/arm/scripts/thickclient/arm_wrapper.sh") but that didn’t go anywhere. Mostly since it never seemed to trigger, when I call udevadm info --query=env /dev/sr0 it doesn’t show the ID_FS_TYPE. Maybe some issue with Linux not understanding bluray drives?

Either way, it is clear to me this ain’t happening in Incus. Oh well. Maybe someday the disc drive support will be there! I do understand why it’s a low priority, Incus is clearly focused on servers.

8

Revisiting this topic, from rootless container testing I found that to access /dev/sr0 in a Docker/Podman container without “privileged” enabled you also need to include its accompanying /dev/sg# device.

You can find /dev/sg# with sudo lsscsi --generic and seeing which /dev/sg# corresponds to /dev/sr0. Note that /dev/sg# can change, I think it is linked to the specific SATA port plugged into the mobo.

Adding in /dev/sg# with sudo incus profile device add Ripz cdromG unix-char source=/dev/sg1 (and sudo incus profile device add Ripz cdrom unix-block source=/dev/sr0 for /dev/sr0) I get the same/similar error but lsscsi --generic gains the /dev/sg1 link like the host has [1:0:0:0] cd/dvd HL-DT-ST BD-RE WH16NS60 1.00 /dev/sr0 /dev/sg1. Prior it was just a - there. Same/similar error output from an Incus container, Debian 13 cloud image, terminal access:

root@testy:/dev# eject -F -m -r -v /dev/sr0
eject: device name is `/dev/sr0'
eject: tmpfs: mounted on /dev/sr0
eject: tmpfs: not found mountpoint or device with the given name

@stgraber does that jog any thoughts? Or is this niche use still out of reach of Incus?

Also, I found that /dev/sr0 has to be a unix-block device to be added successfully, and /dev/sg1 has to be a unix-char device.