bugCompact Disc Input and Control Library - Bugs: bug #56576, eject_media_linux () not working...

 
 

bug #56576: eject_media_linux () not working on some CD-ROM drives

Submitter:  Jacek Rużyczka <professor_fate>
Submitted:  Wed 03 Jul 2019 07:52:35 PM UTC
   
 
Category:  library code Severity:  5 - Average
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  scdbackup
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 14 Jul 2019 10:26:10 AM UTC, comment #18: 

Hi,

i close this bug report now. The bug is already fixed in current release.

Whether the newest release of libcdio is available on a particular distro
depends on the efforts of the packagers and distro maintainers.

In case of Debian, it might be possible to get new releases packaged if
they fix important bugs by filing a Debian bug report.
A look at
  http://git.savannah.gnu.org/cgit/libcdio.git/log/
between [release-2.1.0] and [release-2.0.0] does not show such an emergency
situation.

So one would have to strive for becomming sponsored uploader via
  https://mentors.debian.net/
The mentors will probably urge the new candidate to first clean up the
bug reports and to solve the non-trivial packaging issues shown at
  https://tracker.debian.org/pkg/libcdio
This will be no picknick. Multiarch hinter complaints ... ewww.
Then there is a "FAIL" result with test "testiso9660" in the second build
run for the reproducibility test:
  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libcdio.html
which does not show up in the first run. Tricky to debug.

Have a nice day :)

Thomas

Thomas Schmitt <scdbackup>
Group Member
Wed 10 Jul 2019 08:10:07 PM UTC, comment #17: 

In fact, the tracker contradicts itself 'cause it states: "stable:  2.0.0-2". Yet in the news section, there is no notice about moving version 2.0.0-2 to the "stable" branch.

Jacek Rużyczka <professor_fate>
Sun 07 Jul 2019 01:48:28 PM UTC, comment #16: 

Hi,

> Unfortunately, the official Raspbian packages for the latest stable OS
> version (Stretch) are still at 0.83, only the unstable branch offers 2.0.0


Since yesterday, the job of Debian stable went to Buster. Stretch is now
old-stable. See https://www.debian.org/releases/ or
https://security-tracker.debian.org/tracker/source-package/libcdio .
But the package tracker https://tracker.debian.org/pkg/libcdio did not yet
notice.

More problematic is that libcdio is declared to be orphaned on Debian.
The bug report situation is rather messy than disastrous.
But the fact that pending and future bug fixes would need to go via
debian-mentors might become annoying.


Have a nice day :)

Thomas

Thomas Schmitt <scdbackup>
Group Member
Sun 07 Jul 2019 12:55:29 PM UTC, comment #15: 

You were absolutely right: It was the outdated version of cdio! After installing the fresh 2.1.0 version, everything suddenly worked fine:

pi@autoradio:/import/valen/autoradio $ cdda-player -ev
   INFO: found driver GNU/Linux
   INFO: found driver GNU/Linux
open /dev/cdrom... ok
action: eject...
   INFO: BLKRRPART request failed: Invalid argument

action: read toc...
   INFO: Null CdIo object passed

   INFO: Null CdIo object passed

error: read toc header: Invalid argument
action:

Unfortunately, the official Raspbian packages for the latest stable OS version (Stretch) are still at 0.83, only the unstable branch offers 2.0.0: https://packages.debian.org/search?keywords=libcdio

Thank you for your hint & have a nice Sunday!

Jacek Rużyczka <professor_fate>
Sun 07 Jul 2019 06:20:36 AM UTC, comment #14: 

Hi,

> https://github.com/cisco-open-source/libcdio/


This is obviously an unauthorized and unmaintained copy of the libcdio
repository. Dead and frozen at version 0.92, Nov 17, 2014.

Rocky's genuine libcdio releases are at
  https://ftp.gnu.org/gnu/libcdio/
Most recent is
  https://ftp.gnu.org/gnu/libcdio/libcdio-2.1.0.tar.bz2

If you want the development repo, see:
  http://git.savannah.gnu.org/cgit/libcdio.git/

More resource links are at the project page
  https://savannah.gnu.org/projects/libcdio/ 

--------------------------------------------------------------------------

For finalizing our diagnose endeavor, consider to change the two occurences
of O_RDONLY to O_RDWR, and test whether the Linux kernel allows it to
issue the necessary SCSI commands for ejection.
It would be interesting to know whether this was the only obstacle.

Afterwards it seems urgent to catch up with 4.5 years of libcdio
development. There were some more improvements and bug fixes since then.

Did you make any persistent changes to your copy ?
Are they of interest for the mainstream of users ?


Have a nice day :)

Thomas

Thomas Schmitt <scdbackup>
Group Member
Sat 06 Jul 2019 10:54:21 PM UTC, comment #13: 

OK, thank you for the hint. But: How by the pack ice of the Arctic Ocean can the tarball I had downloaded from https://github.com/cisco-open-source/libcdio/tree/8428d3303693d770b7710749ee087c211cafb930 be so terribly old? oO

Jacek Rużyczka <professor_fate>
Sat 06 Jul 2019 10:04:23 PM UTC, comment #12: 

Hi,

your attached file lacks the unconditional re-opening of the device file
with O_RDWR. And even if the condition is true, the device file gets
opened O_RDONLY.

See a part of the diff between yours ("-") and the current git "master" ("+"):
=======================================================================
@@ -786,13 +731,14 @@ eject_media_linux (void *p_user_data) {
   bool was_open = false;
   char mount_target[PATH_MAX];
 
-  if ( p_env->gen.fd <= -1 ) {
-    p_env->gen.fd = open (p_env->gen.source_name, O_RDONLY|O_NONBLOCK);
-  }
-  else {
+  /* Make sure the device is opened in read/write mode. */
+  if ( p_env->gen.fd >= 0 ) {
+    close(p_env->gen.fd);
     was_open = true;
   }
 
+  p_env->gen.fd = open (p_env->gen.source_name, O_RDWR|O_NONBLOCK);
+
   if ( p_env->gen.fd <= -1 ) return DRIVER_OP_ERROR;
 
   if ((status = ioctl(p_env->gen.fd, CDROM_DRIVE_STATUS, CDSL_CURRENT)) > 0) {
@@ -818,26 +764,17 @@ eject_media_linux (void *p_user_data) {
            it got umounted (at least the commandline eject program
            opens the device just after umounting it) */
         close(p_env->gen.fd);
-        p_env->gen.fd = open (p_env->gen.source_name, O_RDONLY|O_NONBLOCK);
+        p_env->gen.fd = open (p_env->gen.source_name, O_RDWR|O_NONBLOCK);
       }
 
       if((ret = ioctl(p_env->gen.fd, CDROMEJECT)) != 0) {
         int eject_error = errno;
-         cdio_info("ioctl CDROMEJECT status: %s",
-                   strerror(eject_error));
         /* Try ejecting the MMC way... */
         ret = mmc_eject_media(p_env->gen.cdio);
-       
         if (0 != ret) {
-          ret = cd_eject_scsi (p_env->gen.fd);
-         
-          if (ret < 0) {
-            eject_error = errno;
-            cdio_info("ioctl CDROMEJECT and MMC as well as SCSI eject failed: %s",
-                      strerror(eject_error));
-            ret = DRIVER_OP_ERROR;
-          }
-          else cdio_info ("ioctl CDROMEJECT and MMC eject not supported, yet SCSI eject worked.\n");
+          cdio_info("ioctl CDROMEJECT and MMC eject failed: %s",
+                    strerror(eject_error));
+          ret = DRIVER_OP_ERROR;
         }
       }
       /* force kernel to reread partition table when new disc inserted */
=======================================================================

The O_RDONLY would explain why your PREVENT/ALLOW MEDIA REMOVAL command
is rejected with EPERM by the kernel.

Your libcdio source code seems to be older than 4 years. git blames
the O_RDWR on enzo1982, 2015-06-12
  http://git.savannah.gnu.org/cgit/libcdio.git/commit/lib/driver/gnu_linux.c?id=08ae734f59ddbb012cd914e7443dc8dba777ce35

Consider to use a newer version of libcdio and to port your possible own
changes to that version.


Have a nice day :)

Thomas

Thomas Schmitt <scdbackup>
Group Member
Sat 06 Jul 2019 09:39:00 PM UTC, comment #11: 

The empty CD medium is an audio CD. Maybe this is the cause.

About using SG_IO: Caution! I've tried to take the SCSI way of ejecting the disc from eject.c and implant it into gnu_linux.c. See attachment. However, I also ran into the missing privilege issue! Strangely, this tactic did work with libcdaudio. Maybe it has something to do with the initial open () operation? I took the file descriptor as it was without opening anything myself. But take a look yourself.

I've got your mail. Thank you.

Jacek Rużyczka <professor_fate>
Sat 06 Jul 2019 07:15:57 PM UTC, comment #10: 

Hi,

> Media current: CD-ROM
> Media status : is written , is closed
> Media summary: 1 session, 0 data blocks,     0 data,     0 free


If this is not expected, then we should discuss the perceived emptiness
of this CD medium via mail. Public: bug-xorriso@gnu.org, or in private.


> …and the media is ejected!


... and i have no idea why it works better than libcdio.

The most obvious difference is ioctl(SG_IO) of libburn's Linux adapter
versus ioctl(CDROM_SEND_PACKET) of libcdio's Linux driver.
Linux-specific program "eject" uses SG_IO. growisofs uses SG_IO.

It looks like libcdio needs an SG_IO based version of run_mmc_cmd_linux()
so that we can check whether this is the decisive trick.


> Does this mean I should rather use libburn instead of cdio?


I will send you a private mail. If you get none until tomorrow, ping me
here.

Back on topic:

Function eject_scsi() from
  https://github.com/karelzak/util-linux/blob/master/sys-utils/eject.c#L567
would be a great guideline for deriving an SG_IO version of
libcdio's run_mmc_cmd_linux().
(I would peek into libburn/sg-linux.c, too.)

I will consider to develop such a function. It may last a few days, though.
(Oh my ... where is my libcdio git cheat sheet ... ?)


Have a nice day :)

Thomas

Thomas Schmitt <scdbackup>
Group Member
Sat 06 Jul 2019 05:30:51 PM UTC, comment #9: 

pi@autoradio:/import/valen/autoradio/libcdio-master $ xorriso -outdev /dev/sr0 -eject all
xorriso 1.3.2 : RockRidge filesystem manipulator, libburnia project.

xorriso : NOTE : Disc status unsuitable for writing
Drive current: -outdev '/dev/sr0'
Media current: CD-ROM
Media status : is written , is closed
Media summary: 1 session, 0 data blocks,     0 data,     0 free

…and the media is ejected!

Does this mean I should rather use libburn instead of cdio? The eject utility, unfortunately, is a stand-alone program, not a library, so I'd have to use system () to call it. :/

Jacek Rużyczka <professor_fate>
Sat 06 Jul 2019 05:04:45 PM UTC, comment #8: 

Hi,

the whole issue is highly riddling.

What happens if you use libburn for ejecting ?
E.g.

  xorriso -outdev /dev/sr0 -eject all

Does, after some thinking and blinking, the tray come out ?

----------------------------------------------------------------------

The only idea i have is that somehow the effective access mode of the
file descriptor gets altered to O_RDONLY in the course of the ioctl
implementation.

This implementation is complicated and i still did not find the kernel
code which derives fmode_t mode from the filedescriptor which is used
with the userland ioctl call.
This mode seems to be the key to the permission to perform the tray
unlocking command.

----------------------------------------------------------------------

I used the Search facility of https://github.com/torvalds/linux to
dive into the contemporary processing of CDROM_SEND_PACKET.

The best suspect is in  block/scsi_ioctl.c :

  int blk_verify_command(unsigned char *cmd, fmode_t mode)
  {
        struct blk_cmd_filter *filter = &blk_default_cmd_filter;

        /* root can do any command. */
        if (capable(CAP_SYS_RAWIO))
                return 0;

        /* Anybody who can open the device can do a read-safe command */
        if (test_bit(cmd[0], filter->read_ok))
                return 0;

        /* Write-safe commands require a writable open */
        if (test_bit(cmd[0], filter->write_ok) && (mode & FMODE_WRITE))
                return 0;
        return -EPERM;
  }
 
So some commands are only performed if there is w-permission.
The failing unlocking command is among them. Line 190 has:

        __set_bit(GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL, filter->write_ok); 

On the other hand, the ejecting command is allowed for read-only
file descriptors:

        __set_bit(START_STOP, filter->read_ok);

I see the same attributions in my local kernel source.

(It seems unbalanced that removing the tray lock needs rw-perms whereas
 really ejecting the tray is allowed with only r-perms. Shrug.)

----------------------------------------------------------------------------

This theory has the problem that eject_media_linux() makes sure to open
the device file with O_RDWR. If it cannot due to lacking w-permission,
then it does not reach code which calls CDROMEJECT or CDROM_SEND_PACKET.


> https://github.com/karelzak/util-linux/blob/master/sys-utils/eject.c#L686


Here the first try is with O_RDWR. If this fails, then O_RDONLY is tried,
in the hope that no w-permission will be needed in the further course of
the run.

In line 595 one can see the sequence of unlocker and mover command.
io_hdr.cmdp = allowRmBlk; ioctl(SG_IO);
io_hdr.cmdp = startStop1Blk; ioctl(SG_IO);


Have a nice day :)

Thomas

Thomas Schmitt <scdbackup>
Group Member
Sat 06 Jul 2019 04:43:51 PM UTC, comment #7: 

In the meantime, I've tried to reproduce your experiment with the SCSI_MMC_DATA_NONE, but again: No use! The output looks pretty much the same:

pi@autoradio:/import/valen/autoradio/libcdio-master $ cdda-player -ev /dev/sr0
open /dev/sr0...    INFO: found driver GNU/Linux
ok
action: eject...
   INFO: ioctl CDROM_SEND_PACKET for command PREVENT ALLOW MEDIUM REMOVAL (0x1e) failed:
        Operation not permitted
   INFO: ioctl CDROMEJECT and MMC eject failed: Input/output error
   INFO: BLKRRPART request failed: Invalid argument

error: eject: Invalid argument
action: read toc...
   INFO: Null CdIo object passed

   INFO: Null CdIo object passed

error: read toc header: Invalid argument
action:

Jacek Rużyczka <professor_fate>
Sat 06 Jul 2019 04:16:24 PM UTC, comment #6: 

Here we go:

pi@autoradio:~ $ getfacl /dev/sr0
getfacl: Removing leading '/' from absolute path names
# file: dev/sr0
# owner: root
# group: cdrom
user::rw-
user:pi:rw-
group::rw-
mask::rw-
other::---

pi@autoradio:/import/valen/autoradio/libcdio-master $ cdda-player -ev /dev/sr0open /dev/sr0...    INFO: found driver GNU/Linux
ok
action: eject...
   INFO: ioctl CDROM_SEND_PACKET for command PREVENT ALLOW MEDIUM REMOVAL (0x1e) failed:
        Operation not permitted
   INFO: ioctl CDROMEJECT and MMC eject failed: Input/output error
   INFO: BLKRRPART request failed: Invalid argument

error: eject: Invalid argument
action: read toc...
   INFO: Null CdIo object passed

   INFO: Null CdIo object passed

error: read toc header: Invalid argument
action:

So: No use! :-(

I only know that the authors of the eject utility sometimes use RDONLY and sometimes RDWR when opening a CD drive. See here, for instance: https://github.com/karelzak/util-linux/blob/master/sys-utils/eject.c#L686

This is my kernel version BTW:

pi@autoradio:/import/valen/autoradio/libcdio-master $ uname -a
Linux autoradio 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux

Jacek Rużyczka <professor_fate>
Sat 06 Jul 2019 07:36:55 AM UTC, comment #5: 

Hi,

libcdio tries to issue an SCSI command too and reports:

  INFO: ioctl CDROM_SEND_PACKET for command PREVENT ALLOW MEDIUM REMOVAL (0x1e) failed:
       Operation not permitted

(CDROM_SEND_PACKET is the old, deprecated transport ioctl for SCSI
 commands. Currently advised by the Linux kernel community is ioctl(SG_IO).)

It works for me if the user has rw-permission to the drive and i run:

  ./src/cdda-player -ev /dev/sr4

But the symptoms of lack of rw-permission differ from the symptoms
in this bug report. I get:

  open /dev/sr4... ++ WARN: open (/dev/sr4): Permission denied

Do you get any better result if you give cdda-player the drive address
/dev/sr0 explicitely ? Like:

  cdda-player -ev /dev/sr0
 
---------------------------------------------------------------------

It can hardly be due the way how the drive device file gets opened.
Function eject_media_linux() has:

    /* Make sure the device is opened in read/write mode. */
    ...
    p_env->gen.fd = open (p_env->gen.source_name, O_RDWR|O_NONBLOCK);

That's how growisofs and libburn open their drives, too.
I assume that the growisofs gesture is older than growisofs' transition
from ioctl(CDROM_SEND_PACKET) to ioctl(SG_IO).

So let's look into the SCSI level:
mmc_eject_media() calls mmc_prevent_allow_medium_removal().
(The call to mmc_start_stop_unit(), which would trigger the ejection,
 does obviously not happen after allowing medium removal failed.)

In mmc_prevent_allow_medium_removal() and in mmc_start_stop_unit()
i see transport direction SCSI_MMC_DATA_WRITE.
Both SCSI commands are actually of direction SCSI_MMC_DATA_NONE,
because payload data is neither sent nor received.

It works for me if only the permissions are ok. No superuser power needed.

My kernel is quite old, though. New restrictions might have been added
to the SCSI passthrough facility.

So i propose as experiment to set the proper transport direction in
  lib/driver/mmc/mmc_ll_cmds.c
for the involved low-level functions:
==========================================================================
diff --git a/lib/driver/mmc/mmc_ll_cmds.c b/lib/driver/mmc/mmc_ll_cmds.c
index 66679f4..9e28bfc 100644
--- a/lib/driver/mmc/mmc_ll_cmds.c
+++ b/lib/driver/mmc/mmc_ll_cmds.c
@@ -197,7 +197,7 @@ mmc_prevent_allow_medium_removal(const CdIo_t *p_cdio,
     if (b_prevent)         cdb.field[4] |= 1;
     if (b_persistent)      cdb.field[4] |= 2;
    
-    return MMC_RUN_CMD(SCSI_MMC_DATA_WRITE, i_timeout_ms);
+    return MMC_RUN_CMD(SCSI_MMC_DATA_NONE, i_timeout_ms);
 }
 
 /* Maximum blocks to retrieve. Would be nice to customize this based on
@@ -470,7 +470,7 @@ mmc_start_stop_unit(const CdIo_t *p_cdio, bool b_eject, bool b_immediate,
       cdb.field[4] = 3; /* close tray for tray-type */
   }
 
-  return MMC_RUN_CMD(SCSI_MMC_DATA_WRITE, mmc_timeout_ms);
+  return MMC_RUN_CMD(SCSI_MMC_DATA_NONE, mmc_timeout_ms);
 }
 
 /**
==========================================================================

This change compiles. Afterwards cdda-player -ev still ejects.
But my observation may well be just a red herring.

---------------------------------------------------------------------

> pi@autoradio:/import/valen/autoradio/libcdio-master $ ls -al /dev/sr0
> brw-rw----+ 1 root cdrom 11, 0 Jul  5 22:42 /dev/sr0


I wonder what is hidden behind the "+" permission. What do you get from

  getfacl /dev/sr0

I see

  # file: dev/sr4
  # owner: root
  # group: cdrom
  user::rw-
  user:thomas:rw-
  group::rw-
  mask::rw-
  other::---

Have a nice day :)

Thomas

Thomas Schmitt <scdbackup>
Group Member
Sat 06 Jul 2019 05:00:53 AM UTC, comment #4: 

I do not recall nor do I see any kind of test for root (or other) privileges. Therefore I am guessing the the GNU/Linux system is doing this.

However in the past the way we decided to indicated special access would be needed for the CD drive was to open the drive with one of those access modes that I mentioned with regard to bug #38202

The specific modes are  "MMC_RDWR" and "MMC_RDWR_EXCL" for read/write access and exclusive read/write access. See

http://git.savannah.gnu.org/cgit/libcdio.git/tree/lib/driver/gnu_linux.c#n133

I believe Thomas Schmitt was in on this discussion of the  various modes. He also is a more knowledgeable on things SCSI/MMC and GNU/Linux.

Finally, I should say that email to -email is unavailable- is probably a better place to discuss this and the other bug more people who are more familiar are likely to see this.


You have to join the mailing list to post (thanks spammers!) however you can unsubscribe at any time and the mailing list is very low volume most of the time (i.e. when there is nothing to discuss).

Rocky Bernstein <rocky>
Group administrator
Fri 05 Jul 2019 09:43:34 PM UTC, comment #3: 

What I've found out in the meantime with hte help of strace, is that different packets are sent to the drive with resp. without root privileges:

As root:
ioctl(3, CDROMEJECT, 0x20000)           = -1 EIO (Input/output error)
ioctl(3, CDROM_SEND_PACKET, 0x7ef2b474) = 0
ioctl(3, CDROM_SEND_PACKET, 0x7ef2b47c) = 0

As ordinary user:
ioctl(3, CDROMEJECT, 0x20000)           = -1 EIO (Input/output error)
ioctl(3, CDROM_SEND_PACKET, 0x7ea93384) = -1 EPERM (Operation not permitted)

Sorry for being an absolute beginner in MMC and ioctl, but why is a different packet sent when the eject command is issued with root priliveges?

Jacek Rużyczka <professor_fate>
Fri 05 Jul 2019 08:53:43 PM UTC, comment #2: 

OK, after fiddling around a bit I could at least pinpoint the problem: The ioctl command is rejected, whereas the MMC operation fails due to insufficient privileges! sudo helps, but it can't be the final solution. See this output:

pi@autoradio:/import/valen/autoradio/libcdio-master $ cdda-player -ev
   INFO: found driver GNU/Linux
   INFO: found driver GNU/Linux
open /dev/cdrom... ok
action: eject...
   INFO: ioctl CDROM_SEND_PACKET for command PREVENT ALLOW MEDIUM REMOVAL (0x1e) failed:
        Operation not permitted
   INFO: ioctl CDROMEJECT and MMC eject failed: Input/output error
   INFO: BLKRRPART request failed: Invalid argument

error: eject: Invalid argument
action: read toc...
   INFO: Null CdIo object passed

   INFO: Null CdIo object passed

error: read toc header: Invalid argument
action:

pi@autoradio:/import/valen/autoradio/libcdio-master $ sudo cdda-player -ev
   INFO: found driver GNU/Linux
   INFO: found driver GNU/Linux
open /dev/cdrom... ok
action: eject...
   INFO: BLKRRPART request failed: Invalid argument

action: read toc...
   INFO: Null CdIo object passed

   INFO: Null CdIo object passed

error: read toc header: Invalid argument
action:

My user rights for the CD drive seem fairly normal as user pi is part of the cdrom group:

pi@autoradio:/import/valen/autoradio/libcdio-master $ ls -al /dev/sr0
brw-rw----+ 1 root cdrom 11, 0 Jul  5 22:42 /dev/sr0
pi@autoradio:/import/valen/autoradio/libcdio-master $ ls -al /dev/sg0
crw-rw----+ 1 root cdrom 21, 0 Jul  5 22:38 /dev/sg0

The troublemaker in the linux driver seems to lie in line #1284 (the CDROM_SEND_PACKET command), as it apparently requires some missing privilege, but nobody knows which.

Jacek Rużyczka <professor_fate>
Wed 03 Jul 2019 08:00:29 PM UTC, comment #1: 

original submission:

> Ejecting a CD by using eject_media_linux () or cdda-player -e ends up in an error ...
> May I suggest to patch the eject routine of CDIO correspondingly?, so that it uses SCSI the eject command as a fallback? Thank you.


A patch to fix this would would be fantastic - thanks!

Rocky Bernstein <rocky>
Group administrator
Wed 03 Jul 2019 07:52:35 PM UTC, original submission:  

Ejecting a CD by using eject_media_linux () or cdda-player -e ends up in an error like this one:

pi@autoradio:~ $ cdda-player -ev
   INFO: found driver GNU/Linux
   INFO: found driver GNU/Linux
open /dev/cdrom... ok
action: eject...
   INFO: ioctl CDROM_SEND_PACKET for command PREVENT ALLOW MEDIUM REMOVAL (0x1e) failed:
        Operation not permitted
   INFO: ioctl CDROMEJECT and MMC eject failed: Input/output error
   INFO: BLKRRPART request failed: Invalid argument

error: eject: Invalid argument
action: read toc...
   INFO: Null CdIo object passed

   INFO: Null CdIo object passed

error: read toc header: Invalid argument
action:

The CD drive (/dev/cdrom -> /dev/sr0) is an external USB 2.0 drive (Matshita CD-RW  CW-8124 rev. DA0D)

After having run into the same issue in another project
(libcdaudio), I found out that cdio apparently has the same flaw: Some drives no longer support the ioctl CDROMEJECT command! The eject utility (not related to cdio) works itself around this issue by issuing SCSI commands to the drive to eject the media: https://github.com/karelzak/util-linux/blob/master/sys-utils/eject.c#L1002

May I suggest to patch the eject routine of CDIO correspondingly?, so that it uses SCSI the eject command as a fallback? Thank you.

Jacek Rużyczka <professor_fate>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #47165:  cdaudio.c added by professor_fate (22KiB - text/x-csrc - Extension of cdaudio.c with the SCSI-based eject method (which works here!!))
file #47164:  gnu_linux.c~ added by professor_fate (52KiB - application/x-trash - gnu_linux.c with the scsi-based eject method from eject.c)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by scdbackup (Posted a comment)
  • -email is unavailable- added by rocky (Posted a comment)
  • -email is unavailable- added by professor_fate (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-07-14 scdbackup StatusNone Fixed
        Open/ClosedOpen Closed
    2019-07-06 professor_fate Attached File- Added cdaudio.c, #47165
    2019-07-06 professor_fate Attached File- Added gnu_linux.c~, #47164
    2019-07-06 rocky Assigned toNone scdbackup

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code