Just as a general comment we should really ensure we use udisks2 rather than udisks here. With any luck, I'll try and take a look at this at the weekend.

The problem is that the DBus API for udisks2 is way different from udisks one.

Compare http://udisks.freedesktop.org/docs/latest/ with http://hal.freedesktop.org/docs/udisks/

Else we could try using libudisks2 or http://developer.gnome.org/gio/unstable/GDBusObjectManagerClient.html through Glib::Object::Introspection.

This bug affects mounting CD/DVD generally, not just when installing with urpmi.

In mga3alpha2 with LXDE install  clicking on a DVD/CD with PCmanfm  gives the same error message.

so does the command 'mount /media/cdrom'  although 'mount /dev/sr0 /media/cdrom' works OK

fstab contains
/dev/cdrom /media/cdrom auto umask=0,users,iocharset=utf8,noauto,exec,flush 0 0

My mga2 lists the CD drive as /dev/sr0 in fstab.  Is this the problem?

CC: (none) => derekjenn

The problem is likely related to udisks rather than the mount point specifically.

Do you have a /dev/cdrom symlink and does it follow eventually through to /dev/sr0 anyway?

e.g. on my machine:
$ readlink -f /dev/cdrom
/dev/sr0

(In reply to comment #4)
> The problem is likely related to udisks rather than the mount point
> specifically.
> 
> Do you have a /dev/cdrom symlink and does it follow eventually through to
> /dev/sr0 anyway?
> 
> e.g. on my machine:
> $ readlink -f /dev/cdrom
> /dev/sr0

Yes  /dev/cdrom is a symlink of /dev/sr0
If I edit fstab to make /dev/sr0 the device then
mount /dev/sr0   still does not work.

I am seeing the same thing in Alpha 3.  Wasn't the fix to take the line out of /etc/fstab, or is that all different now?

CC: (none) => laidlaws

AFAIK the problem is in /etc/fstab. Somehow /dev/cdrom ends up in this file and udisks(2) won't touch the device anymore. We have to find out what component is adding this line.

And this seems to be release blocker to me.

Priority: Normal => release_blocker
CC: (none) => sander.lepik
Whiteboard: 3alpha2 => 3alpha2, 3beta2

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

CC: (none) => tablackwell

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

CC: (none) => futureway

I just replied to the effect that I agree, but I must have forgotten to press "Save Changes."  (Or perhaps it clashed with your further posts.) I made the same point in Comment 6.

After commenting out the line in /etc/fstab, I could get the CD to mount under /run/media in the same way as a USB key, but that didn't help with rpmdrake, no doubt because the mountpoint wasn't /media/cdrom.  I still had to mount the CD manually under /media/cdrom.

I had another strange effect, no doubt related, that after mounting the DVD under /media/cdrom, when I ran "urpmi --auto-update --auto" it would find the DVD, say it was up to date, then say it wasn't available, and the process would abort.  I got around that by updating from the repos.

To get the mount to work, I couldn't use /media/cdrom; I had to use /media/sr0. AND I had to specify the iso9660 filesystem using the -t flag.

There appears to be no activity on this bug, and the status is still "NEW" - given comment #7 and Beta3 approaching this is alarming

With no technical understanding, it would be inappropriate for me to agree.

What has changed from previous releases?  It sounds like something that should never have happened in the first place.

I missed the history.  What has changed is udisks, according to Comment 2.

In my fstab.old, dated 11 Jan, the line including /media/cdrom is there.  On 19 Jan I reported on commenting out the line.  In my current fstab, dated 8 Feb, it is back.

> What has changed is udisks, according to Comment 2
exclusively udisk? - but I am reluctant to get involved into a level of technical/hstorical details which is beyond my competence: it just does not work

Another issue: seeing the limited feedback, I am not sure whether this bug concerns all cauldron installations (everybody silently just applying one of the work-arounds), or whether it is limited to certain installations - see also https://bugs.mageia.org/show_bug.cgi?id=8405, the discussion on the qa-discuss ML of around 1.17.2013, plus another duplicate bug for which I lost the reference.

To be more specific on how I see the problem on my system: it is not limited to media/cdrom access from urpmi, but to any attempt to read a DVD

It is beyond my competence too.  On a suggestion, I took the DVD out of my update sources, and update exclusively from the online repos.  I run Cauldron only out of interest, so I had no occasion to see that the line had been restored to /etc/fstab.  What I don't understand is that the arrangement in Mga2 works, and might have been transferred to Cauldron.  If it works, don't tamper with it.  But no doubt, it isn't that simple.

I can only agree that it is true that no CD/DVD will mount automatically without a workaround.  Updates were the only reason I inserted media in the drive.  If I could help track down the mechanism Sander mentions in Comment &, I would, but I can't use any tool more esoteric than strace.

This is still a problem with M3B2.  It isn't just urpmi; the DVD is seen and icon appears (with xfce4).  Clicking on the icon gives the same error message as originally reported here.

The problem is that the disk is seen but not mounted.  Just running 'mount /dev/cdrom /media/cdrom' fixes the problem, either at desktop level or to enable urpmi to run.

It's not a proper fix of course, in that DVD's are not being flexibly mounted and unmounted as required.  Why is a dvd not mounted, despite being seen by M3B2 and an icon for it being placed on the desktop??

See my Comment 10.  The icon shows that the DVD is detected.  Normally you can mount it by clicking on the icon.  Sometimes there is a permission problem, and you see a message that the DVD won't mount.  Normally, adding "users" to the line in /etc/fstab will cure that. 

Roughly the same thing is happening here, only the reason is different, and more elusive. In Mga2, CDs are handled differently, and the line in /etc/fstab isn't there.  It shouldn't be there in Cauldron, either, but something is putting it there (Comment 7.)  What that "something" is, is the $64 000 question.  Merely deleting the line, or commenting it out, isn't a complete cure (Comment 10.)

I can't explain what is happening.  I hope that I have described the crunch point correctly

So, the bug has not just simply gone to oblivion. The workarounds are perfect for users of cauldron - in an official release they are inacceptable: a point to be made at the end of the beta release period.

No, they are still working on it -- and all the others.  I know that Colin Guthrie is VERY busy.  His proposals are all gobbledygook to me.  That suggests that the problem is hi-tech.  If you don't like the pace at which things are moving, you are welcome to pitch in and help.

Just to avoid misunderstandings: I have the highest possible esteem for both the competence and the workload done by the developpers.

What is documented in bugzilla is: still "NEW", no "progress noise". That is not a question of pace, but a question of not seeing an ACK - I take your reply as an ACK.

There is no such option on the STATUS pulldown.  The only applicable category is ASSIGNED, and the bug hasn't been assigned "out" to anybody in particular; it is still with the Bugsquad in general.

The "progress noise" is the comments by the various developers.

I don't propose to continue this unproductive discussion any further.  Mageia has a 9-month release cycle, and this really puts the pressure on.  This bug No 7657 has been around since October, and current bug numbers in the 9000's are being allocated. That is how quickly bugs mount up.  Many developers are volunteers with other jobs.  Perhaps it is time to say again what has been said to me so often: "You get what you pay for."

I can confirm it is the fstab entry that is preventing CDs/DVDs mounting in mga3.
If I comment out the fstab entry CDs/DVDs work OK.

I can see *where* the fstab entry gets written by the installer, although I do not have a fix for it.

In install/stage2/live/usr/lib/libDrakX/install/any.pm  the subroutine write_fstab

sub write_fstab {
    my ($o) = @_;
    fs::write_fstab($o->{all_hds}, $::prefix) 
	if !$::local_install && (!$o->{isUpgrade} || $o->{isUpgrade} =~ /redhat|conectiva/ || $o->{migrate_device_names});
}

It appears that the fstab entry for the cdrom is set in
usr/lib/libDrakX/fs/get.pm  in the subroutine really_all_fstab at Line 22

I edited it like this and the installer no longer writes the fstab line for cdrom drives.

sub really_all_fstab {
    my ($all_hds) = @_;
    my @l = fstab($all_hds);
#    @l, @{$all_hds->{raw_hds}}, @{$all_hds->{nfss}}, @{$all_hds->{smbs}}, @{$all_hds->{davs}};
    @l, @{$all_hds->{nfss}}, @{$all_hds->{smbs}}, @{$all_hds->{davs}};
}

To test it out I copied the DVD contents to a folder, extracted the stage2 from the sqfs with mdkinst_stage2_tool,  edited the usr/lib/libDrakX/fs/get.pm file, and then created an iso from the folder.
This iso was not bootable, so I booted a vbox from boot.iso and declared my test iso as a second cdrom drive.

By using the command line during the install I could monitor the status of fstab.

Created attachment 3519 [details]
disable writing CDROM drives to fstab during install

Now I have finally managed to do a full network install  with this patch in place I can confirm that after installation the CD/DVD drives behave normally  and get automatically mounted on insertion.

The only negative is that  if the CDROM GUI in Mageia Control Centre is used, then it writes an entry to fstab, and the CD/DVD drives stop working. Unless there is a good reason for keeping it, the CD GUI should be removed.

Created attachment 3545 [details]
blacklist ISO9660 instead

Humm, I fear this breaks using a whole disk as a mount point.
Can you test this patch instead?

(In reply to Thierry Vignaud from comment #27)
> Created attachment 3545 [details]
> blacklist ISO9660 instead
> 
> Humm, I fear this breaks using a whole disk as a mount point.
> Can you test this patch instead?


No that does not work. It still writes the fstab entry for the cdrom.

What precisely is the scenario where you think the first patch might cause a problem? I could try testing it.

Having two disks, using them as:
- sda1: /
- sda2: /home
- sdb: directly formated

On second though I'm not sure we enable to do this so we might ignore this
(this could only be possible on upgrade)

Created attachment 3556 [details]
what about this?

(In reply to Thierry Vignaud from comment #30)
> Created attachment 3556 [details]
> what about this?

Yes. That is better. I was able to successfully install from DVD without an entry appearing in fstab

Fixed in SVN

Status: NEW => RESOLVED
Resolution: (none) => FIXED

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

CC: (none) => davidwhodgins

(In reply to Thierry Vignaud from comment #32)
> Fixed in SVN

Does that mean that it will reach Cauldron?  In my reply to Juergen, I mentioned the idea of "If it works, don't fiddle with it."  I can see why that is no help (new libraries, for one,) but what are the other distros doing about it?