search

pali / udftools

Linux tools for UDF filesystems and DVD/CD-R(W) drives
GNU General Public License v2.0
108 stars 30 forks source link

Problem with pktsetup/pktsetup.rules #32

Closed scdbackup closed 3 years ago

scdbackup commented 5 years ago

Hi,

as developer of program xorriso i read with rollercoaster feelings this report of Barry Kauler

http://bkhome.org/news/201908/cannot-write-to-optical-drive.html

where he experiences EBUSY errors when trying to use his optical drive with my burn program.

In the end it seems to have been triggered by

"pktsetup: Add udev rules file for automatic managing of packet writing devices" https://github.com/pali/udftools/commit/7b997961be3c752ba90100886bb0e2080ce6a9da#diff-448d2ed59e8349ec9a1f3e9ad0714665

I cannot see where pktsetup (as of Debian) would use open(2) flag O_EXCL, which shall cause this error on Linux a device file when it is already open with the same flag. In principle it is not a bad idea by whomever to prevent similtaneous use of the pktcdvd driver and a burn program. So i do not criticise this but rather agree that this is the right thing to do.

But i doubt the wisdom in pktsetup/pktsetup.rules to start the packet driver whenever any kind of optical medium shows up.

Could you please share with me the motivations of having the udev rules and your view on co-existence with burn programs ? I plan to discuss this coordination on Debian level. Thus it would be helpful to know your thoughts on this issue.

Have a nice day :)

Thomas

pali commented 5 years ago

Hi! It is really bad if drive is locked by pktsetup. I tested it on some drivers and it worked fine, I was able to burn CD/DVD discs. At that time I tested that created CD-R image by mkudffs 2.1 can be correctly burned to CD-R and read by Linux kernel.

Adding that pktsetup.rules was just conversion from old Debian init script which was in same udftools package. Init scripts are now old and udev is today correct way how to handle events from kernel. So there was no new functionality, just rewritten one from old-way to new-way.

I think I saw similar problem in Debian bug tracker. Also I asked on some Debian mailing list if pktsetup should be moved from udftools package and conclusion was that it should say where is. In my opinion it should have been in separate package as all other tools in udftools project are for UDF and pktsetup is for packet writing and not relevant to UDF filesystem. (You can use packet writing for any filesystem, including FAT).

If you open a new discussion about it, please CC me. Thanks!

scdbackup commented 5 years ago

Hi,

pali wrote:

If you open a new discussion about it, please CC me. Thanks!

For that i need your mail address. :)

Mine is scdbackup@gmx.net, in public: bug-xorriso@gnu.org .

I tested it on some drivers and it worked fine, I was able to burn CD/DVD discs.

The EBUSY error seems to be something new. I am on old stuff currently. I will have to ask Barry Kauler for experiments in his environment. (Still some way to go before bothering Debian.)

After setting up by $ pktsetup 0 /dev/sr4 i have a device file

crw-r--r-- 1 root cdrom 10, 57 Aug 27 10:46 /dev/pktcdvd/control

which does not vanish when i remove /dev/pktcdvd0 by $ pktsetup -d 0

(All time stamps say it is new. But i did not check before the experiment whether it did not exist yet.)

Any idea what it does ?

Have a nice day :)

Thomas

pali commented 5 years ago

My email address is in every git commit message... pali (dot) rohar (at) gmail (dot) com

/dev/pktcdvd/control is file for communication with kernel's pktcdvd.ko module. It is used for creating and deleting pktcdvd devices by pktsetup.

pali commented 3 years ago

@scdbackup: I have updated pktsetup.rules to register pktcdvd device only for supported types of optical discs. Changed are in git master branch. Could you please look of this issue is still there?

scdbackup commented 3 years ago

Hi,

Could you please look of this issue is still there?

IIRC i never reproduced this problem myself. (I came here for a theoretical discussion of those rules.)

So i will first have to learn how to do create the situation. I guess i have to install the Debian package of udftools on my test machine and then copy the new pktsetup/pktsetup.rules from your repo over 80-pktsetup.rules. Right ?

Or is there an easy way to install (and de-install) your current git version onto a Debian 10 system while Debians udftools is not installed ?

Have a nice day :)

Thomas

pali commented 3 years ago

Just copy udev rules file to your udev system rules directory (normally it is stored in file /lib/udev/rules.d/80-pktsetup.rules). Also compile pktsetup binary and put it into /usr/sbin/.

scdbackup commented 3 years ago

Hi,

sorry for the delay. ($WORK and the other usual excuses ...)

I did on a quite fresh Debian 10:

git clone https://github.com/pali/udftools cd udftools

and found that INSTALL does not mention the need for

./autogen.sh

This script complains

cdrwtool/Makefile.am:3: warning: source file '../mkudffs/mkudffs.c' is in a subdirectory, cdrwtool/Makefile.am:3: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. [...] automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. ... cdrwtool/Makefile.am:3: warning: source file '../mkudffs/defaults.c' is in a subdirectory, cdrwtool/Makefile.am:3: warning: source file '../mkudffs/file.c' is in a subdirectory, udflabel/Makefile.am:3: warning: source file '../udfinfo/readdisc.c' is in a subdirectory, udflabel/Makefile.am:3: but option 'subdir-objects' is disabled

Nevertheless ./configure && make worked fine. So i did

cp ./pktsetup/pktsetup /usr/sbin/pktsetup cp ./pktsetup/pktsetup.rules /usr/lib/udev/rules.d/80-pktsetup.rules

and put in two trick questions: a blank CD-RW and an unformatted appendable DVD-RW with 13 sessions on it.

pktsetup -s shows that both get piggybacked a /dev/pktcdvd/pktcdvd* although they are not in a suitable state for random-access writing. More accurate info about the medium would be desirable.

That would mean to request that systemd publicly differentiates between sequential DVD-RW and formatted DVD-RW. In function feature_profile_media() of

https://github.com/systemd/systemd/blob/master/src/udev/cdrom_id/cdrom_id.c

i see cd_media_dvd_rw_ro=1 for profile 0x13 (DVD-RW Restricted Overwrite, i.e. formatted) and cd_media_dvd_rw_seq=1 for profile 0x14 (DVD-RW Sequential, i.e. unfomatted). But both do not influence any IDCDROM* variable.

The CD-RW state can be inquired by ID_CDROM_MEDIA_STATE= with its values "blank", "appendable", "complete", "other". I assume that values "blank" and "appendable" indicate an unformatted CD-RW. I still have a cdrwtools formatted CD-RW which is reported as ID_CDROM_MEDIA_STATE=complete. So it is indistinguishable from a closed sequential CD-RW.

With DVD-RW, ID_CDROM_MEDIA_STATE= is ambiguous, too. Value "appendable" would indicate an unformatted DVD-RW. But "blank" is possible with formatted DVD-RW and "closed" is a normal state of sequential DVD-RW. So one would have to ask systemd for a variable like ID_CDROM_MEDIA_PROFILE=.

A CD-R and a DVD-R did not get a /dev/pktcdvd/* device.

(back in august:) Adding that pktsetup.rules was just conversion from old Debian init script which was in same udftools package.

But was that init script supposed to react on any medium change as the rules file does now ?

Whatever, i experience no negative interference with xorriso's media activities. It can inspect, read, and write to media which have a /dev/pktcdvd/* associated.

So the original problem why i opened this issue stays obscure.

Have a nice day :)

Thomas

pali commented 3 years ago

But was that init script supposed to react on any medium change as the rules file does now ?

That script just created pktcdvd mapping for optical drive (specified in config file) at the boot time, independently if there is any medium inserted into drive and independently of the fact if medium (if is inserted) is supported by kernel.

So at conversion, I used same logic, just it was called at the time when optical was plugged into compter (in most cases at boot time, but allows also hotplug).

And now I did another improvement that mapping is created after inserting medium (and removed after ejecting it) and only for some supported subset. But as you have pointed it is still not optimal (for some unformatted it is created too). I will try to look at it.

pali commented 3 years ago

This script complains

cdrwtool/Makefile.am:3: warning: source file '../mkudffs/mkudffs.c' is in a subdirectory,
cdrwtool/Makefile.am:3: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
[...]
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
...
cdrwtool/Makefile.am:3: warning: source file '../mkudffs/defaults.c' is in a subdirectory,
cdrwtool/Makefile.am:3: warning: source file '../mkudffs/file.c' is in a subdirectory,
udflabel/Makefile.am:3: warning: source file '../udfinfo/readdisc.c' is in a subdirectory,
udflabel/Makefile.am:3: but option 'subdir-objects' is disabled

This is known for me, but there is no easy fix. For now it is just a warning and there is no issue with building udftools. Enabling of subdir-objects as suggeted would break compilation of udftools when using GNU Make with parallelism (this adds a race condition for building shared files outside of current directory). If you are going to look at it, then please create a new issue/ticket where it can be solved separately. This is not relevant to the pktsetup udev rules.

pali commented 3 years ago

Kernel's pktsetup.ko driver has following requirements for optical medias to be usable for writing:

Common requirements:

CD-RW requirements:

DVD medias requirements:

Additional CD-RW and DVD-RW (for mmc3_profile 0x13) requirements:

All those requirements are not possible to detect via cdrom_id.c and that is the reason why I check only ID_CDROM_MEDIA_* variables which basically checks for mmc3 profile.

But maybe I can write a new tool for this detection and use it in udev script.

pali commented 3 years ago

Now I created a new tool pktcdvd-check and pushed it into git master and is used in pktsetup.rules file. So for blank/unformatted CD-RW media is not created pktcdvd mapping anymore.

pali commented 3 years ago

I'm closing this issue. As nobody was able to reproduce this issue again and also because now is pktcdvd device created only in the case when it can be really used in r/w mode by kernel pktcdvd.ko driver, thanks to the new pktcdvd-check tool. So issue should not happen again.

If somebody spot this or other similar problem with the latest version (with pktcdvd-check tool) feel free to open a new issue with steps how to reproduce it.