Bug 9899

Summary: Removable media partitions marked in-use even though not mounted
Product: Mageia Reporter: Frank Griffin <ftg>
Component: RPM PackagesAssignee: Mageia Bug Squad <bugsquad>
Status: RESOLVED OLD QA Contact:
Severity: normal    
Priority: Normal CC: balcaen.john, lmenut, mageia, mageia
Version: 3   
Target Milestone: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Source RPM: systemd CVE:
Status comment:

Description Frank Griffin 2013-04-28 05:48:35 CEST
I have no idea what's causing this, but I'm going to start by guessing that it's some udev thing controlled by systemd.  Corrections most welcome.

Insert a USB flash drive, and use whatever you like (I used gparted) to put an MBR on it and define a partition, say /dev/sdb1, and format it as ext4.

Leave the drive inserted, and reboot the system.  When it comes up, log into a KDE desktop.  The Device Manager will produce a popup showing the removable drive partition, but a "df" will show that it is not mounted.  Likewise, "umount /dev/sdb1" will say that /dev/sdb1 is not mounted.

Now try "mount -t ext4 /dev/sdb1 /mnt/disk", and you'll be told that /dev/sdb1 is already mounted or /mnt/disk is busy.  If you create a totally new mount point, say /mnt/disk2, and retry the mount using that, you'll get the same response, indicating that the problem is actually that /dev/sdb1 is considered to be in use.

This is consistently reproducible, but it gets better.  Now, edit /etc/fstab and add an entry mounting /dev/sdb1 at /mnt/disk, and reboot.

"df" will show that /dev/sdb1 is indeed now mounted at /mnt/disk, and is perfectly usable.

My experience with this stuff dates from the days when the error messages actually meant what they said, and I know of nothing other than a mount that would mark /dev/sdb1 as "in use".  But clearly something during system initialization is grabbing /dev/sdb1 in some way, and just as clearly the systemd unit that mounts the /etc/fstab mounts gets there first and prevents it.

By way of background, this came up because I was trying to use drakx-in-chroot to install a system on a USB Flash Drive partition.  The script I used for this would normally umount the partition, create a filesystem on it, mount it under /mnt/disk, and then run drakx-in-chroot.  It was failing on the mkfs.ext4, saying that the partition was in use and that it would not create a filesystem there, and then again on the mount.  When I added the partition to /etc/fstab, rebooted, and issued the drakx-in-chroot command directly, it worked fine (note that the partition had already been formatted as ext4 by gparted above, so the preliminary steps in the script were not necessary).

Reproducible: 

Steps to Reproduce:
Comment 1 Frank Griffin 2013-04-28 21:17:49 CEST
One additional note: this only appears to happen with the first partition.  The system is still set up with /dev/sdb1 in the /etc/fstab.  However, there is a second partition (/dev/sdb2) on the drive, and while it comes up in the KDE device notification along with the first one, and is *not* in /etc/fstab, a mount issued for it works fine.
Manuel Hiebel 2013-05-28 22:23:45 CEST

CC: (none) => balcaen.john, lmenut, mageia, nicolas.lecureuil
Version: Cauldron => 3
Source RPM: ystemd => systemd

Comment 2 Colin Guthrie 2013-05-29 12:19:59 CEST
I would guess something related to udisks, but will have to have a poke. Will try and do that soon.
Comment 3 Marja Van Waes 2015-03-31 16:05:54 CEST
Mageia 3 changed to end-of-life (EOL) status 4 months ago.
http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/ 

Mageia 3 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: NEW => RESOLVED
Resolution: (none) => OLD