Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
Hello all, Robert Milasan [2015-01-12 9:39 +0100]: 1. add a CD/DVD into the driver 2. mount the driver: mount /dev/sr0 /mnt/my_cd (ensure you don't use the Gnome/KDE auto-mounting or reproduce this in a server setup) 3. eject the media (using the hardware button) and add a new one media (different disk) 4. ls /mnt/my_cd (it will be an empty output or the previous media) Is this expected? no, it's not. It's been several years since I've actually had a CD drive and looked at this stuff, but this is how it is *supposed* to work today: - Mounting (manually or through udisks) keeps the kernel default policy of locking the door, so that users can't yank out a mounted medium. - *When* the tray is locked (the default), pressing the eject button is supposed to cause a change event with DISK_EJECT_REQUEST. - udev rules (60-cdrom_id.rules) picks that up and calls eject /dev/srX on the device; the eject program takes care to unmount everything before physical ejection. Note that the kernel will *not* generate DISK_EJECT_REQUEST uevents if the tray is not locked. Your case sounds exactly like that? I suggest running udevadm monitor -e --udev, then press the eject button while a CD is mounted, and check whether you get such an uevent. Then clean up (umount, etc.), re-mount, and this time manually lock with sudo hdparm -L 1 /dev/sr0, and check how it works then? Then you could compare hdparm -L vs. /lib/udev/cdrom_id --lock-media; maybe the former works but not the latter? Or do both report an error that the drive might not support locking? Until a few years ago I've never seen a drive which didn't, but who knows what modern drives do.. Also, I remember a while back (long time ago) that once you added a media into the driver and it was properly mounted, you couldn't eject the media until you unmounted the media. Right, because we didn't have the kernel (or userspace in udisks, as it was before that) polling for eject button presses. But users (IMHO rightfully) complained about the non-working button, and with the current system it's indeed so much more natural (if it works :) ). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Thu, Jan 15, 2015 at 11:03 AM, Martin Pitt martin.p...@ubuntu.com wrote: Hello all, Robert Milasan [2015-01-12 9:39 +0100]: 1. add a CD/DVD into the driver 2. mount the driver: mount /dev/sr0 /mnt/my_cd (ensure you don't use the Gnome/KDE auto-mounting or reproduce this in a server setup) 3. eject the media (using the hardware button) and add a new one media (different disk) 4. ls /mnt/my_cd (it will be an empty output or the previous media) Is this expected? no, it's not. It's been several years since I've actually had a CD drive and looked at this stuff, but this is how it is *supposed* to work today: - Mounting (manually or through udisks) keeps the kernel default policy of locking the door, so that users can't yank out a mounted medium. - *When* the tray is locked (the default), pressing the eject button is supposed to cause a change event with DISK_EJECT_REQUEST. - udev rules (60-cdrom_id.rules) picks that up and calls eject /dev/srX on the device; the eject program takes care to unmount everything before physical ejection. So what's the point of locking tray in the first place if it will be unlocked as soon as you press eject button? Right, because we didn't have the kernel (or userspace in udisks, as it was before that) polling for eject button presses. But users (IMHO rightfully) complained about the non-working button, and with the current system it's indeed so much more natural (if it works :) ). You call it natural that now we apparently do not have any way to actually lock CD tray? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Thu, 2015-01-15 at 11:38 +0100, Martin Pitt wrote: Oliver Neukum [2015-01-15 11:31 +0100]: No, the events are generated. And it is processed. There is just no unmounting. That sounds like a bug/missing feature in cdrom_id --eject-media then. You could try and replace it with /usr/bin/eject, which does the unmounting of all partitions first, fail on busy, and does the eject at last? That does work. But what is the motivation of in effect disabling door locking? We don't -- we specifically leave it locked so that we get the eject button pressed events. (See my other response for some details). Well, yes, but why is policy that should be left to the GUI placed into udev? Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Thu, 15 Jan 2015 11:38:33 +0100 Martin Pitt martin.p...@ubuntu.com wrote: Oliver Neukum [2015-01-15 11:31 +0100]: No, the events are generated. And it is processed. There is just no unmounting. That sounds like a bug/missing feature in cdrom_id --eject-media then. You could try and replace it with /usr/bin/eject, which does the unmounting of all partitions first, fail on busy, and does the eject at last? But what is the motivation of in effect disabling door locking? We don't -- we specifically leave it locked so that we get the eject button pressed events. (See my other response for some details). Martin We could add the unmount functionality also to cdrom_id if we are on the subject. -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmila...@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Thu, 2015-01-15 at 09:03 +0100, Martin Pitt wrote: - udev rules (60-cdrom_id.rules) picks that up and calls eject /dev/srX on the device; the eject program takes care to unmount everything before physical ejection. Note that the kernel will *not* generate DISK_EJECT_REQUEST uevents if the tray is not locked. Your case sounds exactly like that? No, the events are generated. And it is processed. There is just no unmounting. But what is the motivation of in effect disabling door locking? Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
Oliver Neukum [2015-01-15 11:31 +0100]: No, the events are generated. And it is processed. There is just no unmounting. That sounds like a bug/missing feature in cdrom_id --eject-media then. You could try and replace it with /usr/bin/eject, which does the unmounting of all partitions first, fail on busy, and does the eject at last? But what is the motivation of in effect disabling door locking? We don't -- we specifically leave it locked so that we get the eject button pressed events. (See my other response for some details). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Thu, 15 Jan 2015 11:39:36 +0100 Robert Milasan rmila...@suse.com wrote: On Thu, 15 Jan 2015 11:31:48 +0100 Oliver Neukum oneu...@suse.de wrote: On Thu, 2015-01-15 at 09:03 +0100, Martin Pitt wrote: - udev rules (60-cdrom_id.rules) picks that up and calls eject /dev/srX on the device; the eject program takes care to unmount everything before physical ejection. Note that the kernel will *not* generate DISK_EJECT_REQUEST uevents if the tray is not locked. Your case sounds exactly like that? No, the events are generated. And it is processed. There is just no unmounting. But what is the motivation of in effect disabling door locking? Regards Oliver Unmounting usually happens, but only in the desktop environment, most probably because of udisk2 or whatever is called. In console mode or server mode lets say, if the media is mounted (usually manually) it is not unmounted if I press the eject button on the driver, on the other hand it is not unmounted even if I would use eject command, because none of this commands or the hardware button are aware of the media being mounted and it also makes sense. In Gnome/KDE the mount is not done by user but by the actual software, using most probably fuse or something like that and Gnome/KDE is aware when the disk is ejected, similar to a USB stick (I might be wrong). Sorry, eject command is aware and it will unmount the media if mounted. My bad. -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmila...@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Thu, 15 Jan 2015 12:22:50 +0100 Robert Milasan rmila...@suse.com wrote: On Thu, 15 Jan 2015 12:00:15 +0100 Oliver Neukum oneu...@suse.de wrote: On Thu, 2015-01-15 at 11:38 +0100, Martin Pitt wrote: Oliver Neukum [2015-01-15 11:31 +0100]: No, the events are generated. And it is processed. There is just no unmounting. That sounds like a bug/missing feature in cdrom_id --eject-media then. You could try and replace it with /usr/bin/eject, which does the unmounting of all partitions first, fail on busy, and does the eject at last? That does work. But what is the motivation of in effect disabling door locking? We don't -- we specifically leave it locked so that we get the eject button pressed events. (See my other response for some details). Well, yes, but why is policy that should be left to the GUI placed into udev? Regards Oliver What about this little bundle of joy, the patch I mean, of course. Please check attachment :) Might need work, but the basic idea seems to work, at least in my tests. Forget about the patch. If we are using cdrom_id from the console, it actually works and unmounts the media, but not from within a udev rule. Need to see why and will get back. -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmila...@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
В Thu, 15 Jan 2015 11:36:33 +0100 Martin Pitt martin.p...@ubuntu.com пишет: Andrei Borzenkov [2015-01-15 11:24 +0300]: So what's the point of locking tray in the first place if it will be unlocked as soon as you press eject button? So that we can do a clean unmount and avoid the situation in the original post :-) Also, we can delay or fail the unlocking and ejection if the device is busy, e. g. during burning. With the eject button directly working without telling userspace, we could never lock it during writing, nor do a clean unmounting. Right, because we didn't have the kernel (or userspace in udisks, as it was before that) polling for eject button presses. But users (IMHO rightfully) complained about the non-working button, and with the current system it's indeed so much more natural (if it works :) ). You call it natural that now we apparently do not have any way to actually lock CD tray? Well, you deny someone with physical access the usage of a physical button. Yes. This is the whole point of locking tray. For any read-only mount I don't consider that friendly. When you are performing installation and someone passing by ejects installation media from your system? Sure, it is mush more friendly. Tray is locked because it is in use. How can udev know mount point is not being used right now? Locking is of course desirable (and ought to work) if the device is being written to. Locking is desirable when you have long term work from CD and want to make sure it is not interrupted. It does not matter whether this is reading or writing. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Mon, Jan 12, 2015 at 02:02:50PM +0100, Oliver Neukum wrote: On Mon, 2015-01-12 at 04:46 -0800, Greg KH wrote: Let me rephrase. Is this desirable? Probably not. But with some hardware, as you have seen, you need to run some type of userspace daemon to poll the device to handle media removal issues when the hardware itself does not report media removal. Well, we have been polling in kernel space since 3.13 Ok, then it seems I don't know what's up in this area at all, so I'm totally out of the loop and am not the one to answer this. sorry, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Mon, 2015-01-12 at 04:46 -0800, Greg KH wrote: Let me rephrase. Is this desirable? Probably not. But with some hardware, as you have seen, you need to run some type of userspace daemon to poll the device to handle media removal issues when the hardware itself does not report media removal. Well, we have been polling in kernel space since 3.13 It doesn't tell us whether the hardware button should eject the medium in the first place. Some hardware doesn't allow you to lock the door, so this question comes down to what to do if you try to lock it but it does not happen. No, for currently udev doesn't care. And the choice is pretty clear anyway. We are not going to refuse to use the device, are we? So we'll use it anyway. The question is, do we lock if we can? We need to be able to handle surprise removal. That doesn't mean we should in effect never lock the door if we can do so. I think we support locking the door, if userspace asks to, right? Yes and and that is not the problem. To do what? The kernel on its own and udev on their own behave differently. What is the correct way? The kernel on its own does not dictate this type of policy, it's up to userspace to determine if you want to lock the door when you mount I am afraid I am forced to strongly disagree with your statement. The kernel does have a default policy. It locks the door upon open() (which is implied in mount()) If you press the button during such a lock, an event is passed to user space. The question is why udev contains a rule that overrides the kernel and in user space implements an effective policy of no door locking. something, and to poll the device to detect media removal if the device is broken and does not report such things. That is why systems use udisks today, to handle all of these issues. Why not just use it? Could you elaborate on how to use udisks if udev has a rule that unconditionally ejects media if the button is pressed? And what is wrong with the kernel's default? Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Mon, Jan 12, 2015 at 09:39:30AM +0100, Robert Milasan wrote: Hello, a while back, around 2011, in cdrom_id was added --eject-media, --lock-media and --unlock-media for not much explanation. Now, recently some people noticed that this might actually be a problem. Reference: http://bugzilla.opensuse.org/show_bug.cgi?id=909418 Here is a scenario: 1. add a CD/DVD into the driver 2. mount the driver: mount /dev/sr0 /mnt/my_cd (ensure you don't use the Gnome/KDE auto-mounting or reproduce this in a server setup) 3. eject the media (using the hardware button) and add a new one media (different disk) 4. ls /mnt/my_cd (it will be an empty output or the previous media) Is this expected? Yes, because you didn't unmount the media and tell the kernel that the filesystem is now gone. Also, I remember a while back (long time ago) that once you added a media into the driver and it was properly mounted, you couldn't eject the media until you unmounted the media. It depends on the hardware, some devices support this, others don't. NOTE: This works somewhat OK in the desktop setup, probably due to udisks (using Gnome/KDE), but in the console not really. Then use udisks :) thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Mon, 2015-01-12 at 04:15 -0800, Greg KH wrote: On Mon, Jan 12, 2015 at 09:39:30AM +0100, Robert Milasan wrote: Hello, a while back, around 2011, in cdrom_id was added --eject-media, --lock-media and --unlock-media for not much explanation. Now, recently some people noticed that this might actually be a problem. Reference: http://bugzilla.opensuse.org/show_bug.cgi?id=909418 Here is a scenario: 1. add a CD/DVD into the driver 2. mount the driver: mount /dev/sr0 /mnt/my_cd (ensure you don't use the Gnome/KDE auto-mounting or reproduce this in a server setup) 3. eject the media (using the hardware button) and add a new one media (different disk) 4. ls /mnt/my_cd (it will be an empty output or the previous media) Is this expected? Yes, because you didn't unmount the media and tell the kernel that the filesystem is now gone. You are correct, but not really helpful :) Let me rephrase. Is this desirable? It doesn't tell us whether the hardware button should eject the medium in the first place. Also, I remember a while back (long time ago) that once you added a media into the driver and it was properly mounted, you couldn't eject the media until you unmounted the media. It depends on the hardware, some devices support this, others don't. If the device does not support locking the door, the question is moot. We need to be able to handle surprise removal. That doesn't mean we should in effect never lock the door if we can do so. NOTE: This works somewhat OK in the desktop setup, probably due to udisks (using Gnome/KDE), but in the console not really. Then use udisks :) To do what? The kernel on its own and udev on their own behave differently. What is the correct way? Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Mon, Jan 12, 2015 at 01:33:46PM +0100, Oliver Neukum wrote: On Mon, 2015-01-12 at 04:15 -0800, Greg KH wrote: On Mon, Jan 12, 2015 at 09:39:30AM +0100, Robert Milasan wrote: Hello, a while back, around 2011, in cdrom_id was added --eject-media, --lock-media and --unlock-media for not much explanation. Now, recently some people noticed that this might actually be a problem. Reference: http://bugzilla.opensuse.org/show_bug.cgi?id=909418 Here is a scenario: 1. add a CD/DVD into the driver 2. mount the driver: mount /dev/sr0 /mnt/my_cd (ensure you don't use the Gnome/KDE auto-mounting or reproduce this in a server setup) 3. eject the media (using the hardware button) and add a new one media (different disk) 4. ls /mnt/my_cd (it will be an empty output or the previous media) Is this expected? Yes, because you didn't unmount the media and tell the kernel that the filesystem is now gone. You are correct, but not really helpful :) Sorry, it's early in the morning for me :) Let me rephrase. Is this desirable? Probably not. But with some hardware, as you have seen, you need to run some type of userspace daemon to poll the device to handle media removal issues when the hardware itself does not report media removal. It doesn't tell us whether the hardware button should eject the medium in the first place. Some hardware doesn't allow you to lock the door, so this question comes down to what to do if you try to lock it but it does not happen. Also, I remember a while back (long time ago) that once you added a media into the driver and it was properly mounted, you couldn't eject the media until you unmounted the media. It depends on the hardware, some devices support this, others don't. If the device does not support locking the door, the question is moot. Agreed. We need to be able to handle surprise removal. That doesn't mean we should in effect never lock the door if we can do so. I think we support locking the door, if userspace asks to, right? NOTE: This works somewhat OK in the desktop setup, probably due to udisks (using Gnome/KDE), but in the console not really. Then use udisks :) To do what? The kernel on its own and udev on their own behave differently. What is the correct way? The kernel on its own does not dictate this type of policy, it's up to userspace to determine if you want to lock the door when you mount something, and to poll the device to detect media removal if the device is broken and does not report such things. That is why systems use udisks today, to handle all of these issues. Why not just use it? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
