What desktop are you running ?

Source RPM: (none) => udisk

Default KDE with Mageia 2: KDE 4.8.2

maybe you can try the the updates of kde4.8.4 in updates_testing (we will have kde4.8.5 in updates) even I found nothing in their bugzilla about that)

I would like to try that. What do I have to do to get the newest KDE-version? I already checked "Core Updates Testing", but there do not seem to be any updates...

If they are not updated to that, then you can search in rpmdrake for the updates, or use urpmi --auto-updates or mark the testing repo as 'updates' one (for the two last you will receive all packages wainting for qa test)

also don't forget to disable it after that.

Source RPM: udisk => (none)

I finally did the updates and got a new kernel, 3.3.8 and KDE 4.8.4. KDE 4.8.5 was not available for me.

So far it seems to work, but I get two failed-messages when the system boots:

1) Failed to start Load legacy module configuration                                                                                                                 [[1;31mFAILED[0m]
See 'systemctl status fedora-loadmodules.service' for details.  

and

2) Failed to start LSB: VirtualBox Additions Service                                                                                                                [[1;31mFAILED[0m]
See 'systemctl status vboxadd-timesync.service' for details. 

Is this crucial or should I ignore these?

>KDE 4.8.5 was not available for me.
yes it will come only in something like 10 days 

For your messages I don't know, but if it's works :)

Depends on: (none) => 6855

I'm still _testing_ this new setup, so I am not sure if it works the next week also. ;-)

I uninstalled "VirtualBox Additions" and got rid of both(!) boot-failures.

The only thing I get now which is irritating is:

udevd[167]: could not find module by name='wl'

Everything else _seems_ to run fine.

Any ideas?

Thanks in advance!

As for the virtualbox errors: IIRC, virtualbox requires the kernel-devel package (in the same version as the newest installed kernel). If you installed a 3.3.8 kernel, but not the 3.3.8 kernel-devel package, you will get errors.

CC: (none) => wassi

kernel-desktop-devel is already installed. I got that package automatically with the new kernel version.

Unfortunately, after some days working with the new setup, especially with 3.3.8 and KDE 4.8.4, I have to say, the problem with automount and the underscore still exists. :-/

The system still mounts my USB-stick(s) every time I reboot with a new mountpoint and the underscore.

I'm also affected by this quite, this is quite a nuisance.
Weird thing is, even when you unmount the wrongly mounted partitions, and remove their mountpoints, you cannot remove the last active /media/mountpoint_ directory, even if it is empty, nothing mounted over it, it still says "device or ressource busy" for an umount -f and it can't also be rm -rf'ed :/

I don't think this is directly related to KDE, more to the systemd migration ...
Adding Colin as CC

CC: (none) => doktor5000, mageia

It works the same under gnome.
I don't remember what happened before systemd (and mga2)

It could be a minor advantage if, for example, 2 usb keys of the same brand/model and capacity are inserted at different times.
By not reassigning the same mount point, it reduces somewhat the chance of confusion as to which device is mounted.  Which I found useful in debugging a faulty system a few months back.
It is easy to do "fs /dev/sd*" to see the new mount point(s) used.

But if most prefer reusing mount points, fine with me.

BTW, neither behavior is necessarily "correct", so I'm reducing the severity level.

CC: (none) => andre999mga
Severity: major => minor

(In reply to andré blais from comment #12)
> 
> BTW, neither behavior is necessarily "correct", so I'm reducing the severity
> level.

Why reduce the severity? It is a regression since Mageia 1 of a basic functionality, there is no easy workaround if you prefer to use the mount helper of the desktop environment(s) for removable storage and requires logging off and removing stale mount points (which where automatically created by the mount helper or whatever thing creates those underscores) manually.

This is definitely normal Severity.

I agree with Florian.

It is a pain to _work_ with flash drives with this bug.

For some tasks it is _essential_ that they are mounted correctly. And it should not alter its state out of nothing. Even after a reboot.

Please take this serious, users will be upset and will switch the distribution because this behavior is simply annoying.

Note that after reboot, mount points ARE reused.
It is only on remounting before reboot that mount points are not reused.

Also note that when mount points are reused :
- assume that sda/ is always mounted with the boot disk
- if device A is mounted at sdb/, then unmounted
- then device B is mounted, it will be mounted at sdb/
- then device A is mounted while B is still mounted, it will be mounted at sdc/

So you have device A initially mounted at sdb/, and later at sdc/
And different devices using the same mount point.
Which is what used to happen.  (And I found somewhat confusing.)

With the current situation, different devices will never use the same mount point (at least not without rebooting)
Just do "ls /dev/sd*" to find the new mount point(s).

So how is reusing mount points necessarily better ?

I think it depends on personal preferences.  But I don't have a big problem if it reverts to previous functioning.
So maybe normal severity, but major severity is not appropriate.
OK, severity set to normal.

I changed the title to accurately reflect the issue.

Summary: Storage media not automounted correctly => Automatic mounting of storage media doesn't reuse the same mount points
Severity: minor => normal

From what I'm reading the the above comments, I'm pretty sure
the problems are being caused by not unmounting the usb
drives, before removing them.

For example if you open a usb stick with dolphin, before
you remove the drive, you can either select another directory,
such as home (so that the drive will not be busy), and then
right click on the name of the usb drive, and select "Safely
remove nameofdrive", or close dolphin, click on the device
manager icon and click on the small up arrow inside of a
circle, beside the name of the usb drive, (if you hold the
mouse over that arrow, the tooltip "Click to safely remove
this device" appears).

That will unmount the drive, and delete the dynamically
created mountpoint, so that it's available for reuse, when
the drive is re-mounted.

CC: (none) => davidwhodgins

Just tested, even with different usb keys.
You're right.
Explicitly unmounts nicely, releasing mount point.

With gnome you just have to click on the small up arrow beside the device name in the nautilus side bar.

So closing as invalid.

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

Seems you're speaking about different problem, or you misunderstood the problem. The problem which is reported here is definitely valid, i can confirm it. Also mount points will no be reused. E.g. by mounting something in dolphin you get a "mountpoint" /media/STICK and then you shutdown (which should unmount the mounted drives, the same way as fixed fstab mounts are unmounted) and on next boot you replug that stick (or leave it plugged) and you will get /media/STICK_ and so on an on.

Weird thing is that once you get those "underscore mounts" you cannot cleanly remove the mount points, and you cannot cleanly unmount them when the system is running. E.g. lsof/fuser don't show any processes acessing them, but umount still says the device is busy. By using fuser -k on those mount points the X server gets killed.

Maybe the fix is just to make sure that manually mounted removable media (mounted by DE mount helpers) or auto-mounted removable media are cleanly unmounted during shutdown/reboot, as it has been before.

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

One option would simply be to mount /media as tmpfs and thus it's empty on boot. That was how things were configured for a while but people complained that manually configured mounts referring to mount paths in /media then failed. If you want to solve this on your systems and do not have any statically configured mount points, I suggest you just add a tmpfs /media mount to fstab and if that works then we document this in the errata.

As Mageia 3 is nearly out and (I presume) does not suffer from this problem (due to udisks now mounting inside /run/user/* tree rather than /media these days), then I suspect doing something more on mga2 would be too invasive.

(In reply to Florian Hubold from comment #18)
> Seems you're speaking about different problem, or you misunderstood the
> problem. The problem which is reported here is definitely valid, i can
> confirm it. Also mount points will no be reused. E.g. by mounting something
> in dolphin you get a "mountpoint" /media/STICK and then you shutdown (which
> should unmount the mounted drives, the same way as fixed fstab mounts are
> unmounted) and on next boot you replug that stick (or leave it plugged) and
> you will get /media/STICK_ and so on an on.

I cannot recreate the problem.  Either rebooting, or using poweroff,
and then the power switch to restart, when I boot up, /media is
empty.  This is with a usb stick mounted, and open in dolphin,
when I reboot or poweroff.
 
> Maybe the fix is just to make sure that manually mounted removable media
> (mounted by DE mount helpers) or auto-mounted removable media are cleanly
> unmounted during shutdown/reboot, as it has been before.

We'll need to identify what special case is causing them not to
be cleanly unmounted, as that is working here.

(In reply to Florian Hubold from comment #18)
> Seems you're speaking about different problem, or you misunderstood the
> problem. The problem which is reported here is definitely valid, i can
> confirm it. Also mount points will no be reused. E.g. by mounting something
> in dolphin you get a "mountpoint" /media/STICK and then you shutdown (which
> should unmount the mounted drives, the same way as fixed fstab mounts are
> unmounted) and on next boot you replug that stick (or leave it plugged) and
> you will get /media/STICK_ and so on an on.

Sorry, I probably should have said "worksforme".
Also, I missed the point about reboot.
I have never seen automount points persist like that after reboot.

> Weird thing is that once you get those "underscore mounts" you cannot
> cleanly remove the mount points, and you cannot cleanly unmount them when
> the system is running. E.g. lsof/fuser don't show any processes acessing
> them, but umount still says the device is busy. By using fuser -k on those
> mount points the X server gets killed.

Weird indeed.
In my system, the mount points of automounted devices are removed within a few seconds of device removal, whether explicitly or automatically unmounted.
(It didn't work like that when I first installed mga2.)

If I mount 2 devices with the same name (like "lexar" for usb keys, or the partition label),
The second mount will have a "1" appended to the name.
If I remove them without explicitly unmounting, then insert them in the opposite order, it is still the second inserted has a "1" appended to the name.
(It works the same for devices in fstab.)

Just a thought ... do you have an entry for these devices in fstab ?
If so, what happens if you remove (or comment out) the entry ?

This message is a reminder that Mageia 2 is nearing its end of life.
Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life.  If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete.

-- 
The Mageia Bugsquad

Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no
longer maintained, which means that it will not receive any further security or
bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Mageia
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
The Mageia Bugsquad

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