The need to remove the fstab entry is documented at
https://wiki.mageia.org/en/Mageia_2_Errata#Base_system

The problem with udisksd Cleaning up mount point /media/disk (device 2:0 is not mounted) is likely a timeout problem with udiskd not
waiting long enough.

Changing the rpm to udisks.

CC: (none) => davidwhodgins
Source RPM: pcmanfm-0.9.10-1.mga2.src.rpm => udisks-1.0.2-3.mga1.src.rpm

Fixing the version of the rpm and the summary.

Summary: pcmanfm cannot mount floppy disc with fstab entry as created by default => udisks cannot mount floppy disc
Source RPM: udisks-1.0.2-3.mga1.src.rpm => udisks-1.0.4-4.mga2.src.rpm

This was a clean install from a beta 1 dvd. 
The fd line in fstab produces the mount failure and instantaneous "Cleaning up mount point /media/floppy".
With no fd0 line in fstab the mount point is /media/disk and there is no cleanup until you decide to unmount the floppy, but the user mounting the floppy cannot write it.

 so:
1 What do you think created the cdrom and fd entries in fstab? Is that a separate bug?
2 With no entry in fstab for fd0 (so udisks works) how do I correct the incorrect mount options udisks is applying (root:root 0755) and the unfortunate mount point name (disk)?
3 In light of the referenced Mageia 2 Errata, why do you think DVD automount/icon-click eject is working despite the cdrom entry in fstab? It is either mounted (because you have just inserted it) or ejected - there is no state for being in the drive but not mounted. Is that another bug I should report?

Sorry, I misread the original report.

If the fstab entries are being created during the install,
that would be a bug in the installer, stage 2 I believe.

What type of filesystem is the floppy formatted with?

What's the output of "getfacl /dev/fd0", when the floppy
is mounted?

I know that with a filesystem on a usb drive, the permissions
are different, depending on what type of file system is used.

It's either the choice of filesystem type, or a failure to
set the facl permissions, depending on the answers.

[rich@Copper ~]$ getfacl /dev/fd0
getfacl: Removing leading '/' from absolute path names
# file: dev/fd0
# owner: root
# group: floppy
user::rw-
group::rw-
other::---

It's a vfat floppy.

So, depending on the answers, how would I make the floppy really believe that it is not a read-only device?

Richard

(In reply to comment #5)
> [rich@Copper ~]$ getfacl /dev/fd0
> getfacl: Removing leading '/' from absolute path names
> # file: dev/fd0
> # owner: root
> # group: floppy
> user::rw-
> group::rw-
> other::---
> 
> It's a vfat floppy.
> 
> So, depending on the answers, how would I make the floppy really believe that
> it is not a read-only device?

It is rw, not ro.  The problem is that udisks is not setting the facl
user to your user id.

As a temporary workaround, use userdrake to add your id to the floppy
group, log out/in for the groups change to take affect, then you
should have rw access to the floppy.

So the bug is in the udisks package, not setting the facl the same
way for a filesystem on a floppy, as it does for a filesystem on
a partition on a usb stick.

I did that as one of the first post-install operations, added self to audio,cdrom,cdwriter,floppy (and maybe video too, don't remember now).

Note also that the mount point is given the same name as an unlabelled disc or USB device (I think ... I certainly have one USB stick that gets a "disk" or "disk-n" mount point).

Trouble is, only /dev/fd0 is root:floppy. The mount point is root:root (0755) which for me (or every other ordinary user) is effectively read-only on a floppy disc. I realise that all mount points in /media are created root:root 0755, but files and directories on, for example, the /media/disk-1 USB device are created rich:root and are thus writeable.

I have hit similar problems in the past with brand new USB hard drives. I usually have to create a folder as root in the root of each partition I want to use, then chown it and use that folder as the destination for all writes.

You said "The problem is that udisks is not setting the facl user to your user id" and I think you are spot-on, but the only workaround I have at the moment is to do all work on the floppy as root! The dodge described above for USB drives doesn't work. MC tells me I am not allowed and chown says "changing ownership of `/media/disk/test': Operation not permitted". Can you point me at the place where the behaviour is controlled? Maybe I can hack about there for a bit and see if I can get it going. 

Richard

Sorry, I would have tried the workaround, but my floppy died a couple
of years ago.

Can someone on the bug sqaud assign this bug to whoever maintains the
udisks rpm package.

ok and thanks.
eandry seems not very active so also added the other committers

/me is lost with all mount like issue :/

CC: (none) => boklm, dmorganec, eandry, mageia, mageia

I have discovered a fix (?) for the problem while trying to repeat bug 4645 (udisks is not installed from x86-64 DVD causing urpmi/rpmdrake to fail on first boot). 

After confirming udisks was absent and before installing it I tried to mount the floppy disc in this fresh (unmodified fstab) install. It worked perfectly for the user and allows the user to walk all over the disc and wreak havoc.

So, pending further investigation to confirm, it looks like the fix is "Do not install udisks if you want to go on using your floppy".

is this bug still valid ?

Keywords: (none) => NEEDINFO

Recent discussions on the forum seem to suggest that KDE and Gnome users may not be able make use of the fixes discovered in this bug discussion (and the related Bug 4645).

I still have no answers from the forum when I asked a month or so ago if anyone understood/could explain how removable media handling is implemented by Mageia2 so I am not much wiser now myself. However, I can state that to get floppy disc mounting to work with workable permissions it is only necessary to remove the old version of udisks and ensure that you have a proper fstab entry for the floppy (but not for the CD).

perl-HAL-cdroms must go as well as it depends on udisks, but that doesn't prevent CD and DVD mounting/removal as it is handled, along with plug-in usb disk media, by udisks2.

My recollection is that HAL must be removed to prevent an unseemly squabble with udisks2 as they fight over which one should mount and unmount some types of media (usb thumb drives perhaps, but I could be wrong). The expression of the problem is that udisks2 cannot unmount the device without root authority but HAL has mounted it for the current user so that cannot be the real reason. Removing HAL removes the problem.

So with only udisks2 on my test systems I have no issues with removable drive (or unmounted internal drive) mounting.

I suspect, but I cannot confirm without testing again, that rpmdrake won't mount the CD/DVD in the drive, but I seem to recall I only have to click on the icon to mount it in pcmanfm for rpmdrake to use it.

hum seems you mix a lot of bugs and personnly I don't understand at all

I feel your pain. I have been trying to understand how many different systems are trying to control my hot-plug devices since I first discovered things going wrong. 

None of the ordinary users on the forum seem to understand either. Even some of the "old hands" have difficulty with this.

From what I can see there are at least four software systems I can find which have some influence on how the hardware is handled. So far I have identified

gvfs
udisks2
udisks
HAL

The only two which I need to get things to work are gvfs and udisks2

In addition there seems to be at least two (possibly more) ways in which authentication of the user's right to perform actions with the hardware is controlled. I have only been able to identify (not understand the contribution of) three of these

consolekit
polkit
PolicyKit

By process of elimination I have determined that I only need two of these as well, namely consolekit and polkit.

This information has only been gleaned by deduction and by synthesising the information which emerged in the pursuit of solutions to three bugs:

Bug 4642 - This one
Bug 4645 - Involving CD mounting and rpmdrake
Bug 5051 - Consolekit and SLiM dm - all user mounting broken

Various Cauldron forum discussions have also been helpful in nailing down a working solution, which I now gather is not available to KDE and Gnome users who are stuck with udisks, HAL and all attendant problems.

So you say I mix up a whole lot of bugs. I have a slightly different perspective. I see it as only one problem which manifests in a number of different ways.I do not think that there is a bug in a program somewhere. I think that the problem is the way in which several programs, with overlapping areas of influence, have been integrated. But then, I am still only scratching the surface of understanding. I am only guessing at what the integrators are trying to achieve and how they intend these tools should work together.

Sorry I can't help but I've not used a floppy disk in over 10 years and I'm not about to use them anytime soon!

I can say that you should forget HAL. Uninstall it and forget about it.

Also ignore PolicyKit. The name is deprecated, polkit is the future.


While I don't know the right way of doing it, you could likely create an automount entry in fstab easily enough. I'm not sure users *should* be given write permission on /dev/fd0 or similar.


All I can say is ask the right people. Don't get yourself tied in knots. Get on IRC and go ask the udisks people upstream, If it's not their responsibility, I'm sure they'll tell you who you need to speak to next. That's all I ever do when dealing with bug reports and such like. It's pretty easy to find such things out. But I have no such hardware nor, frankly, any major inclination to look into this. If there is stuff I can do to make it work for you then I'll happily do it, but I simply don't have enough time to do the ground work.

Thank you Colin for confirming that I was right to remove HAL and PolicyKit, though I was basing that action on the fact that it contributes to the fix.

The fstab entry simply defines the basic requirements for mounting a FAT formatted floppy so that I can write to it. I am not sure if an "automount" entry is possible as there is no notification on this machine of a disc change. I might be able to get it to auto-detect the disc format so that it will be a bit more flexible, but that is not a priority.

> I'm not sure users *should* be given
> write permission on /dev/fd0 or similar.

I sure hope you keep those thoughts to yourself :) If I remove the fstab entry for fd0 then udisks2 will mount it read-only, but what use would that be? Ash-tray on a motorcycle springs to mind.

> All I can say is ask the right people.

I'm guessing that this mixture of obsolete, deprecated and bleeding-edge components was in part inherited from Mandriva. I gather from some of the Gnome and KDE users on the forum that those desktops still require udisks. Given that udisks will disappear and HAL is all but gone and I only use LXDE, I am not sure if it would be an effective use of the time and group-effort required to make these work together for MGA2. Having said that, I noticed that an update in the last 30-odd hours has re-introduced root-authorisation required for mounting a DVD/CD! Luckily I still have a working Cauldron to compare it with and find the culprit.

To sum up - I can get it to work the way I think it should. With a it of time I might be able to figure out why it works but I am having to use up a lot of it in firefighting after updates. First the sound disappeared on Saturday, now CD/DVD needs permission to use it ... roll on Beta3++

(In reply to comment #16)
> Thank you Colin for confirming that I was right to remove HAL and PolicyKit,
> though I was basing that action on the fact that it contributes to the fix.
> 
> The fstab entry simply defines the basic requirements for mounting a FAT
> formatted floppy so that I can write to it. I am not sure if an "automount"
> entry is possible as there is no notification on this machine of a disc change.

What I meant by an automount was that the mount will be tried when the user attempts to enter the directory. It has nothing to do with notifications of a disk insertion. Automounts would, to some degree, get rid of the problem of needing notifications. It would however be a low level solution that might not be appropriate for some higher level solutions (e.g. perhaps the whole gfs layer will do it's own thing here - I don't know).

> > I'm not sure users *should* be given
> > write permission on /dev/fd0 or similar.
> 
> I sure hope you keep those thoughts to yourself :) 

:) What I meant here was similar to how e.g. USB Flash drives are handled. Users do NOT get write permission on /dev/sdX and I see no reason why they should get write permission on /dev/fd0 either. Other processes deal with mounting and it's the mounted filesystem that the user has permission to access not the drive itself.

> > All I can say is ask the right people.
> 
> I'm guessing that this mixture of obsolete, deprecated and bleeding-edge
> components was in part inherited from Mandriva. I gather from some of the Gnome
> and KDE users on the forum that those desktops still require udisks. Given that
> udisks will disappear and HAL is all but gone

Yup those two and PolicyKit too. They are just around for those apps that have not yet updated to newer versions.

> might be able to figure out why it works but I am having to use up a lot of it
> in firefighting after updates. First the sound disappeared on Saturday, now
> CD/DVD needs permission to use it ... roll on Beta3++

What happened with sound? Have you got a bug number? I have a report of HDA no longer loading for a user.

> I have a report of HDA no
longer loading for a user.

Yes, that happened to me too.  I can modprobe the snd-hda-intel module by hand to fix it after booting, or I can put snd-hda-intel in modprobe.preload. In the end I did a brutal mass delete of all /etc/mod* directories and files. Sound worked straight away so one by one I replaced the deleted configuration files until I broke the sound again. 

I have left it at that to get some other stuff done, but I had narrowed down the time of the failure to some time after 20:00 on Saturday last. The only vaguely related update I could find in that session was a small collection of alsa libraries. I'll get back to it soon though as I have blocked updates on a working system so I can do some A/B checks.

It is a bit annoying not be able to read old files and programs that may be needed for customer support, or own needs.

Actually even current mageia sort of depends on floppy, as at least for me the "bug" utility failed to write my USB stick - bug 5685 - so i had it write my floppy but mageia could not read it and i had to boot sysresccd.org live system to transfer from floppy to USB.

CC: (none) => fri

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

Yes. I am not aware of any activity on this bug.

I 'm running with Mageia Vers.2 (thornicroft) (32-Bit)-3.3.6-desktop586-2.mga2

When I boot with a floppy 'udisks - Vers 1.0.4 and udisks2 - Vers 1.93.0' in /run/media/<user>/disk is working perfectly - but the permissions are: Owner = root + group = root / Oktal = 40755 and 100755

Look here:
[ossi@localhost ~]$ getfacl /dev/fd0
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: dev/fd0
# owner: root
# group: floppy
user::rw-
group::rw-
other::---

Other MEDIA (USB-Flash, SDHC-Card, DVD-RW and Mobilphone) are working perfectly with USER !
The bug still valid in Mageia 2. What can I do??

CC: (none) => Osw.Kropp

The only thing I can suggest (because it's what I did) to fix that particular problem is get rid of udisks (v1) and add an entry in /etc/fstab for your floppy. Something like:
/dev/fd0 /media/floppy auto umask=0,users,iocharset=utf8,noauto,exec,flush 0 0

That works for me. Just tested it again to make sure. Warning, though. If you use KDE (and possibly Gnome, but I can't be sure) then you will likely have a whole list of things depending on udisks. Try something more up-to-date like LXDE instead.

Richard

Yes, I 'm working with GNOME 3.4.1 !
Ok, if I add in the /etc/fstab the line 
'/dev/fd0 /media/floppy auto umask=0,users,iocharset=utf8,noauto,exec,flush 0 0',
I can mount FLOPPY  with 'udisks --mount /dev/fd0' (but only in terminal - ALT+F2 is not possible!) and the permissions for /media/floppy are: Owner = <user> + group = root / Oktal = 40777 and 100777

But the changed line in /etc/fstab stops working the automatic-mounter (in german: >ORTE >WECHSELMEDIEN >FLOPPYDISK )!

And will I repair the automatic-mounter over >WERKZEUGE >SYSTEMWERKZEUGE >LAUFWERKE >FLOPPY DRIVE >EINHAENGEOPTIONEN and switch it to ON : the added line in /etc/fstab is deleted and the permissions of /dev/fd0 are also returned - look COMMENT 22.

Is it possible  the BUG is in 'gnome-disk-utulity - Vers. 3.4.1' = 'palimpsest, etc.' ??

Oswald it has been quite some time since I last investigated this issue and I am not entirely sure I even understand what was going wrong. I do recall that when I had udisks 1 AND HAL there was contention between HAL/udisks/udisk2 as they fought with each other over which should mount and unmount removable drives (including floppies). 

I was fortunate in at least one respect; I use LXDE. I saw that HAL was mounting the floppy (which I could then read but not write!) but udisk2 was trying to unmount it and failing because "I" hadn't mounted it. At least, I think that is what was happening. I also had issues having to use a root password to unmount some drives and cdrom access was broken (cured by _removing_ its /etc/fstab entry!).

In short, all of these problems went away and the system returned to normal, helpful and predictable operations with all internal and external media.
1. I removed HAL and away went perl-HAL-cdrom or some such name.
2. I removed udisks v1 - it was entirely surplus to requirements and has NO dependents in the LXDE environment.
3. I removed the cdrom entry and added the fd0 entry in /etc/fstab

The result has been a perfectly normal system with automounting and unmounting through the file manager icons. It has been working flawlessly since last February or March.

As for palimpsest; I do not know it, but something makes me doubt that it would introduce a bug which is so similar to the one which is caused by having HAL and udisks v1.

Have you determined how much the package manager would expect to uninstall if you remove HAL and udisks1? If it is a lot then I would be tempted to try rpm -e --nodeps, or whatever the command is, to get rid of udisks and the HAL stuff and see if that changes the problem you have. You can always put them back if it changes nothing.

Richard

Thanks to Richard for the discription.
Also I have removed udisk v1 and the automatic-mounter is now running perfectly.
But only the permissions or rights for FLOPPY have not changed: Owner = root + group = root / Oktal = 40755 and 100755

Please look to the 3 last lines in my momentary /etc/mtab:

"/dev/sdd1 /run/media/ossi/CN4 vfat rw,nosuid,nodev,relatime,uid=500,gid=500,fmask=0022,dmask=0077,codepage=cp437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,errors=remount-ro 0 0
/dev/sr0 /run/media/ossi/disk iso9660 ro,nosuid,nodev,relatime,uid=500,gid=500,iocharset=utf8,mode=0400,dmode=0500 0 0
/dev/fd0 /run/media/ossi/disk1 vfat rw,nosuid,nodev,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0"

(There ar mounted a)USB-Flash-Drive with label CN4  b)DVD-RW and c) Floppy Disk)
And we can see, that the values for 1) uid=??? + 2) gid=??? only by FLOPPY are not written to mtab!! This is probably the mistake or bug and the user can not have permissions to FLOPPY!? - 
On my Desktop-PC there is an intern Floppy-Drive (DMA2 = floppy)!

(Sorry for my bad english) - Oswald

Oswald,
Just for comparison, these are equivalent mtab entries for a USB memory stick, a DVD-ROM and a floppy:

/dev/sdi1 /run/media/richard/ADATA\040UFD vfat rw,nosuid,nodev,relatime,uid=501,gid=501,fmask=0022,dmask=0077,codepage=cp437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,errors=remount-ro 0 0
/dev/sr0 /run/media/richard/Ubuntu\0406.10\040i386 iso9660 ro,nosuid,nodev,relatime,uid=501,gid=501,iocharset=utf8,mode=0400,dmode=0500 0 0
/dev/fd0 /media/floppy vfat rw,nosuid,nodev,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=utf8,shortname=mixed,flush,errors=remount-ro 0 0


The first two entries appear to be very similar to yours
The /etc/fstab entry I use for the floppy is:

/dev/fd0 /media/floppy auto umask=0,users,iocharset=utf8,noauto,exec,flush 0 0
none /proc proc defaults 0 0

I don't usually fiddle with permissions so I am just guessing when I say that the fmask and dmask settings shown in mtab for the floppy are derived from the combined file and directory permissions mask represented by my fstab umask entry as they are all the same; read,write and nuclear war :-)

Does this help?

Richard

No comment in over 2 years. Is this still valid? Does anyone use floppies any more or is the bug relevant to other media?

Nic

CC: (none) => nic

Yes floppy could come handy some time but not often...
(i.e servicing old equipment, or reading old backups)

My former workstation built 2006 sucessfully boot DRDOS from a floppy.
Putting in or already having the floppy in while running mageia 5 on same machine
produces no reaction neither on floppy drive lamp, motor sound or logs

searching the output of
 # journal --boot
for "floppy", "FDC" and "fd0" only finds three lines from booting

...
jan 12 10:02:13 silver kernel: Floppy drive(s): fd0 is 1.44M
jan 12 10:02:13 silver kernel: FDC 0 is a post-1991 82077
...
jan 12 10:02:13 silver fedora-loadmodules[1045]: Loading modules: evdev powernow-k8 cpufreq_powersave cpufreq_conservative cpufreq_ondemand floppy
...

So it seem broken, or am i supposed to configure something manually?

/Morgan

Assigning to all packagers collectively since udisks has no registered maintainer.

Status comment: (none) => In recent cauldron (future mga6), inserting a floppy disk has no effect.
Assignee: bugsquad => pkg-bugs
Summary: udisks cannot mount floppy disc => Floppy disks not mounted (udisks?)

Closing due to irrelevance in 2018

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

(In reply to Richard Walker from comment #31)
> Closing due to irrelevance in 2018

Reading old floppy may be very relevant to retrieve crucial data - i just retrieved default setup for an 22 year CNC machine, little used can go twenty year plus more, with new disk and maybe some other electronic refreshing later... :)

Works this way today:

I booted Mageia 8 Live xfce on a USB stick with added persistence, on an old computer that have a floppy drive. Put in floppy, nothing happened.

But easily:

$ su -
# modprobe -v floppy

- and floppy icon appeared on desktop.

(Hm i should put this on wiki!)

Double clicked it and file manager opened
Copied floppy content to home (persistent)

Could later put that stick in my office computer and read from the persistent partition

:)

(In reply to Morgan Leijström from comment #32)

> - and floppy icon appeared on desktop.
> 
> (Hm i should put this on wiki!)

https://wiki.mageia.org/en/Floppy