Bug 154326

Created attachment 70763 [details]
shortened log

Created attachment 70769 [details]
shortened log

Argh, the first attachment had lines cut off.

I don't see a release() call in the Callbacks::requestMedia() function of pkg-bindings. Is this called anywhere ?

Yes, see SourceImpl.cc SourceImpl::provideFile()

Good spotting, there is the bug.
It calls the report->requestMedia() callback directly without(!) releasing the media.

            else if ( user == media::MediaChangeReport::RETRY  ||
            user == media::MediaChangeReport::CHANGE_URL )
            {
              // retry
              DBG << "Going to release and attach again" << endl;

              media_mgr.release (_media, false);
              media_mgr.attach( _media );

              break;

Thats wrong. The "media_mgr.release (_media, false);" must be called before(!) the callback.

            else if ( user == media::MediaChangeReport::EJECT )
            {
              DBG << "Eject: try to release" << endl;

              media_mgr.release (_media, true);
              // FIXME: this will not work, probably

Well, indeed this works.
Marius, will this still work if the media is already released ??

From looking at the source, I'm pretty sure the eject does work even though the media is unmounted.

If the media is already released, a release(_media, true) will work.
If will eject all drives that are not attached.

So this one fixes the "eject button does not work" bug:
Index: SourceImpl.cc
===================================================================
--- SourceImpl.cc       (revision 2169)
+++ SourceImpl.cc       (working copy)
@@ -125,10 +125,15 @@
        catch ( Exception & excp )
         {
            media::MediaChangeReport::Action user;
+
          do {
+
+           DBG << "Media couldn't release file, releasing." << endl;
+           media_mgr.release (_media, false);
+
            user  = checkonly ? media::MediaChangeReport::ABORT :
              report->requestMedia (
-               source_factory.createFrom(this),
+               source_factory.createFrom( this ),
                media_nr,
                media::MediaChangeReport::WRONG, // FIXME: proper error
                excp.msg()
@@ -152,9 +157,8 @@
            user == media::MediaChangeReport::CHANGE_URL )
            {
              // retry
-             DBG << "Going to release and attach again" << endl;
+             DBG << "Going to attach again" << endl;

-             media_mgr.release (_media, false);
              media_mgr.attach( _media );

              break;

This one is fixed

*** Bug 152260 has been marked as a duplicate of this bug. ***

*** Bug 151786 has been marked as a duplicate of this bug. ***

*** Bug 157419 has been marked as a duplicate of this bug. ***

*** Bug 157483 has been marked as a duplicate of this bug. ***

SLES10 Beta7 still has the same behaviour - when installing software with yast I cannot insert another CD without calling eject in a terminal window. Per the above the fix wasn't applied for beta6, but obviously it wasn't applied for beta7 either. 
This cripples the yast sw_single module, as you can't really use it to install software with dependencies spread over several CDs. 
Will the fix be in beta8?

Seems like you are pointing to a running system. Please:

1) remove /var/log/YaST2/y2log*
2) reproduce the bug
3) attach the resulting logs.

Created attachment 72764 [details]
YaST2 log

You are right, it's the running system (but had this during installation as well).
Created and attached the logs as described above.

This bug is still in 10.1 beta 8.

I use an external usb cdrom drive, sr0
When yast asks for the next disc
the media is still mounted.

Mount when inserting a new media before
pressing ok to accept the new media in yast:

notebook:/home/tilo/Modem # mount
/dev/hda1 on / type reiserfs (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
securityfs on /sys/kernel/security type securityfs (rw)
/dev/sr0 on /media/disk-1 type iso9660 (ro,nosuid,nodev,noatime,uid=1000,utf8)


When yast asks for the next disc, the old one ist still mounted:
notebook:/home/tilo/Modem # mount
/dev/hda1 on / type reiserfs (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
securityfs on /sys/kernel/security type securityfs (rw)
/dev/sr0 on /media/disk-1 type iso9660 (ro,nosuid,nodev,noatime,uid=1000,utf8)
/dev/sr0 on /var/adm/mount/AP_0x00000005 type iso9660 (ro)

I isn't possible to release the media. The eject button in yast isn't working.
When I press the eject button at the drive I get an kde error:
kio_media_mounthelper "authorization refused"

I have to unmount /var/adm/mount/AP_0x000000005 before I can change
the media.

After unmounting I was able to change the media.

The problem is not the /var/adm/mount/AP_0x000000005 (or AP_0x0000000d
in the log) mountpoint, but the additional one: /media/disk-1

YaST2/ZYPP umounts its own mount on AP_*, but the eject request fails:
  MediaCD.cc(openTray):173 Eject /dev/sr0 failed (Input/output error)
because the media is still mounted on /media/disk-1.

In earlier versions it was not a problem (eject failed because of other
reasons), because the subfs mounter used fake-mounts only. Now, it realy
mounts the media on /media/disk-1.

I've added a fix, that trys to umount the other (user) mountpoints as
well if eject was requested.

we need to avoid the automatic mounting somehow.

With the above changes (zypp SVN revision 2585), it works
fine, although it is very ugly to umount foreign media.

Perhaps somebody has an better idea how to solve it finally.

Beta8 RPMs containing this fix/workaround will be avaliable
at http://www.suse.de/~mt/zypp/ (as soon as it is mirrored)
for testing.
Note, that installing them, may break other (yast2) pieces,
because there was some symbol changes in the libraries...

Does bug 153241 solves your problem?

OK, this allows to disable the automounter. Not a problem
to add the calls to zypp.

I would propose to disable the automounter and limit my hack
to try to umount the automounter mountpoint if it is there.

If the user has mountet it manually, eject will still fail.

If the eject fails, it will be currently not reported to the
above layers (complains in log only). I would like to throw
an Busy/NotEjected-exception, but Stano does no like it :-)

This means, the problem remains in cases, where the media is
busy.
We have to decide how exactly to handle it. Stano / Klaus?

*** Bug 159263 has been marked as a duplicate of this bug. ***

Looks fixed in Beta9, no further reports.