Indeed udisks2 is installed but not udisks

Thierry, maybe add a require on perl-hal-disk ?

Priority: Normal => release_blocker
CC: (none) => thierry.vignaud
Component: Release (media or process) => RPM Packages
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=3639

isn't udisks2 supposed to work the same way as udisks?
What's the error message?

I've looked through my logs for 22 Feb, around 00:42, but no sign of error messages. I have removed udisks-1.0.4-4 to see if I get a recognisable error I can report now.
First a re-boot......

That did not reproduce the error message (which did, from memory, specifically mention udisks). I will re-install as before and try again.

(In reply to comment #2)
> isn't udisks2 supposed to work the same way as udisks?
I don't know, I'am bit lost with all these stuff :s

> What's the error message?

strange I can't reproduce with a new install :(

it was something like bug 3458 modulo s/hal/udisk iirc

Just finished re-installing following the steps used for the previous install, for convenience listed below.
This time there was no error from udisks when I tried to set up the repositories and install xrandr. I found this from the notes I took during the first install/run of Beta 1; I noted the error as "Udisks daemon (udisks-daemon) is not running or not ready"
I then did a "locate udisks" and found only references to udisks2. 

Install process;

re-format sdb1 as /

Desktop Selection - Custom

Package Group Selection:
deselect all except
1. Console Tools
2. Configuration
3. LXDE Desktop
4. Individual package selection
remove:
fortune-mod, xscreensaver
samba-client
emacs
dasher
icewm-light
gdm

Total Size: 1326 MB (21:44)

no selection available;
1. lxdm
2. leafpad
3. xrandr

(21:50) post-install
The package gdm needs to be installed. Do you want to install it?
----where do I click "no", there is no option, so why the question? Do I really have to click "previous"?
Next

hardware clock is UTC
use NTP
configure network - 21:58->22:00 - takes a loooong time - connectivity test failed! (as usual)

22:01 - 1st boot - no "init=/bin/systemd" - must be deliberate after all
no KDM! good, uses GDM
initialise remote repositories
no xrandr! bad - urpmi xrandr 
IT WORKED!
check for presence of udisks - not installed.

This is not a bug, it is a FEATURE and I love it. It fixes Bug 4642.

The udisks thing was a completely confusing and almost perfect red herring (http://en.wikipedia.org/wiki/Red_herring).

udisks is not installed because it is not needed. If it is installed as well as udisks2 then it breaks floppy disc mounting in filemanagers (BUG 4642). It does not do anything else dramatic, so if you are not using your floppy drive then you will never notice.

This does not explain why urpmi wouldn't work until I had installed udisks, but that behaviour has not been repeated in an almost identical fresh install.

If there is no compelling reason that anyone knows of to install udisks then I think I will blacklist it and keep it away from my system.

well it is a bug, I can reproduce again.
make an install with only lxde (I have not checked with the other)
reboot and don't put the dvd
try to install something

=> "Proceed with the installation of the 18 packages? (Y/n) y
Udisks daemon (udisks-daemon) is not running or not ready"

Keywords: NEEDINFO => (none)
CC: sysadmin-bugs => dmorganec, eandry, mageia

Thank you Manuel, when I couldn't repeat it I started to think that I had a non-causal sequence of events and that the error was coincidental and nothing to do with urpmi. 

Now I know that the difference between my two installs is that on the second one I did not remove the DVD when prompted and relied on my BIOS boot order to boot from the USB install drive. 

From your findings I must have removed the DVD the first time. I can even remember trying to find somewhere safe to put it. After failing to set up the network repositories I put the DVD in and used the file manager to locate and install udisks, having wrongly convinced myself it was causing the error. 

Am I right in believing that it was using urpmi while the DVD was set was an active source medium, but with no DVD in the drive that was causing the udisks2 error?

Richard

Juergen Harms ([Mageia-discuss] One Beta more install story) has identified an old bug which might have reared its head again; Bug 145 - Urpmi fails to mount cdrom when they're already listed in /etc/fstab.

Fixed in SVN

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

Something caused this:

Feb 27 18:34:39 Tureen rpmdrake[2563]: [RPM] udisks-1.0.4-4.mga2.x86_64 installed

It took me until today to discover that removable disc automounting/unmounting was broken again for /dev/fd0 and /dev/cdrom and unmounting of USB memory drives again requires root privileges.

The almost complete workaround is:

Mar  4 14:08:30 Tureen rpmdrake[3715]: [RPM] udisks-1.0.4-4.mga2.x86_64 removed

This also needs the /dev/fd0 line in /etc/fstab, though the /dev/cdrom may be left or deleted as desired. The workaround is "almost" complete because when you first try to unmount a USB stick you are still prompted for root password, but thereafter the stick may be mounted/unmounted by the user.

If you delete the /etc/fstab line for /dev/fd0 then it will still mount, but you will be unable to write to it unless you are root.

With the /etc/fstab lines the mountpoints for /dev/fd0 and /dev/cdrom are in /media. Without the /etc/fstab lines they will, of course, be in some directory dependent on user name in /run/media/USERNAME. The mountpount name for /dev/fd0 in /media is, of course, /media/floppy. In /run/media/USERNAME it is /run/media/USERNAME/disk. The USB stick drive will be in /media/disk.

All very confusing, but it sorta works now - just remove udisks-1

see above comment

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

I see now why I got udisks-1 back on 27 Feb, but not why I was given perl-Hal-Cdroms.

In my current configuration without udisks-1 and without perl-Hal-Cdroms, my cdrom drive works perfectly well.

The changelog for perl-Hal-Cdroms says:

 * Mon 27 Feb 2012 12:00:00 GMT tv <tv> 0.04-2.mga2
        
        + Revision: 215454
        - requires udisks (mga#4645)
        
As adding back udisks-1 breaks so much, would it not be better to find a less intrusive solution?

Alternatively, if we must use udisks-1 to satisfy some need of urpmi, can we find a way to fix the problems it introduces?

Please see comment 11, can you please test?

CC: (none) => ennael1

Comment 11 says "Fixed in SVN". That was back in February. If there is a new update available now then I will happily and eagerly test it. Otherwise the system is updated daily (since January) so I must assume that the problems I am discussing are the ones on the system you want me to test. 

I will repeat the tests I did last week.

That took longer than expected as the current rpmdrake bug (4918) made setting up for the tests with and without udisks-1 a lot harder than it should have been.

I can confirm that there is no change to the condition described a couple of weeks ago.

Configuration A
With udisks-1 and perl-Hal-cdroms and no cdrom entry in fstab; mounting of CD is correct. Floppy mounting is broken with or without an fd0 line in fstab.

Configuration B
Without udisks-1 and perl-Hal-cdrom and no cdrom entry in fstab; mounting of CD is correct. Floppy mounting is broken but can be fixed by adding an fd0 line in fstab.

Floppy mounting in Configuration A with an entry for fd0 in fstab causes the udisks-1 mounted disc to be immediately unmounted by udisks-1

Floppy mounting in Configuration A with no entry for fd0 in fstab allows udisksd to mount the floppy at /run/media/USERNAME/disk for the current user, but the permissions are still wrong, so you cannot write to it.

Floppy mounting in Configuration B with no entry for fd0 in fstab allows udisksd to mount the floppy at /run/media/USERNAME/disk for the current user, but the permissions are still wrong, so you cannot write to it. This is the same as Configuration A

Floppy mounting in Configuration B with an entry for fd0 in fstab causes udisksd to mount the floppy at /media/floppy for the current user with correct permissions (depending, of course, on the entry in fstab).

The situation for USB memory drives is not so easy to summarise: a lot depends on the nature of the file system on the stick and whether you object to typing in the root password to unmount it.

Needing the root password to unmount a filesystem where the root
password is not needed to mount it, may be related to bug 3533.

CC: (none) => davidwhodgins

I thought so too and added a speculative comment to that bug back in February. I am more inclined to think that these mount and unmount problems I have with removable devices is udisks-related but I am still struggling to get my head around the way this works and how it is configured to meet user requirements. I can only say that I am not ruling out the possibility of a shared cause.

The extra confusion of the change in dynamic mount point location isn't helping. Some of them are in /media and some in /run/something/something.... I can't remember the path, but I know my username is in there somewhere. I fully expect to see /mnt back in use soon!

Richard

seems fixed on an updated cauldron. can you confirm ?

I'll gladly give it a go, though I must say that most of my problems went away when I added HAL to usdisks1 in my list of things to keep off the machine. What environment should I use to test in?

Richard

Ping ? Shall we close that bug?

(In reply to comment #22)
> Ping ? Shall we close that bug?

yes

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

(In reply to comment #21)
> I'll gladly give it a go, though I must say that most of my problems went away
> when I added HAL to usdisks1 in my list of things to keep off the machine. What
> environment should I use to test in?
> 
> Richard

I reckon we are waiting for rc1 to discover if urpmi or rpmdrake still requires udisks 1 to be installed and to find out if having udisks 1 installed still breaks floppy disk use. 

That's ok by me, it's only a few days away now.