On Wed, Jan 28, 2015 at 05:24:19PM +0100, Lennart Poettering wrote:
> On Wed, 28.01.15 16:29, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
> > On Wed, Jan 28, 2015 at 02:09:37PM +0100, Martin Pitt wrote:
> > > Lennart Poettering [2015-01-28 13:33 +0100]:
> > > > Hmm, yeah, we apparentl
On Wed, 28.01.15 16:29, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> On Wed, Jan 28, 2015 at 02:09:37PM +0100, Martin Pitt wrote:
> > Lennart Poettering [2015-01-28 13:33 +0100]:
> > > Hmm, yeah, we apparently only add that for file systems listed in
> > > /etc/fstab...
> > >
> > > If
On Wed, 28.01.15 14:09, Martin Pitt (martin.p...@ubuntu.com) wrote:
> Lennart Poettering [2015-01-28 13:33 +0100]:
> > Hmm, yeah, we apparently only add that for file systems listed in
> > /etc/fstab...
> >
> > If you change the "get_mount_parameters_fragment()" invocation at the
> > beginning of
Zbigniew Jędrzejewski-Szmek [2015-01-28 16:29 +0100]:
> > | Where=/media/martin/Ubuntu 15.04 amd64
> > | What=/dev/sr0
> > | [...]
> > | Id=media-martin-Ubuntu\x5cx2015.04\x5cx20amd64.mount
> > | Names=media-martin-Ubuntu\x5cx2015.04\x5cx20amd64.mount
> > | Requires=-.mount
> > | Wants=system.slice
On Wed, Jan 28, 2015 at 02:09:37PM +0100, Martin Pitt wrote:
> Lennart Poettering [2015-01-28 13:33 +0100]:
> > Hmm, yeah, we apparently only add that for file systems listed in
> > /etc/fstab...
> >
> > If you change the "get_mount_parameters_fragment()" invocation at the
> > beginning of mount_a
On Wed, 28.01.15 14:09, Martin Pitt (martin.p...@ubuntu.com) wrote:
> From 0cc891bcd8d3fa9967dd733292caf86a43dd3503 Mon Sep 17 00:00:00 2001
> From: Martin Pitt
> Date: Wed, 28 Jan 2015 13:57:47 +0100
> Subject: [PATCH 2/2] rules: clean up stale CD drive mounts after ejection
>
> Ejecting a CD w
Lennart Poettering [2015-01-28 13:33 +0100]:
> Hmm, yeah, we apparently only add that for file systems listed in
> /etc/fstab...
>
> If you change the "get_mount_parameters_fragment()" invocation at the
> beginning of mount_add_device_links() in src/core/mount.c to
> "get_mount_parameters()", does
On Wed, 28.01.15 12:06, Martin Pitt (martin.p...@ubuntu.com) wrote:
> I. e. the .mount does not seem to be bound on the .device, and isn't
> taken down automatically (stopping the mount manually works fine). In
> "show" I don't see a BindsTo, and the Requires also doesn't mention
> the /dev/sr1 de
Martin Pitt [2015-01-28 11:04 +0100]:
> > In udevadm I see that this has the intended effect -- as soon as I
> > eject the CD, /dev/sr0 gets ENV{SYSTEMD_READY}="0". But there's still
> > something missing, as merely adding this property doesn't yet tell
> > systemd to stop the unit -- media-ubuntu-
Martin Pitt [2015-01-28 10:35 +0100]:
> # remove a medium/eject CD: disable corresponding .mount units
> ENV{DISK_MEDIA_CHANGE}=="?*", ENV{ID_CDROM_MEDIA}!="?*",
> ENV{SYSTEMD_READY}="0"
> # insert a medium; undo the previous rule
> ENV{DISK_MEDIA_CHANGE}=="?*", ENV{ID_CDROM_MEDIA}=="?*",
Martin Pitt [2015-01-28 10:35 +0100]:
> Turns out that there's no proper way to simulate that under QEMU --
> that has no "eject" button, and the "eject" monitor command blocks
> as long as the OS is still accessing it (i. e. it's mounted).
Lies! In fact "eject ide1-cd0" works rather well, it caus
Lennart Poettering [2015-01-27 23:33 +0100]:
> > That sounds good indeed! I can sit down at qemu tomorrow and simulate
> > some CD insertions/removals, and come up with an udev rule for this.
>
> That would be great. It would really just be a matter of setting
> SYSTEMD_READY=0 for block devices w
On Tue, 27.01.15 23:33, Martin Pitt (martin.p...@ubuntu.com) wrote:
> Lennart Poettering [2015-01-27 22:46 +0100]:
> > However, I think it would make a ton of sense to change that, and set
> > SYSTEMD_READY=0 on all block devices where the media sensing suggests
> > that no medium is in it.
>
> T
Lennart Poettering [2015-01-27 22:46 +0100]:
> However, I think it would make a ton of sense to change that, and set
> SYSTEMD_READY=0 on all block devices where the media sensing suggests
> that no medium is in it.
Thinking about it again, we already know that this rule in
60-cdrom_id.rules still
On Tue, 27.01.15 23:20, Martin Pitt (martin.p...@ubuntu.com) wrote:
> Hey Lennart,
>
> Lennart Poettering [2015-01-27 22:46 +0100]:
> > So I figure the bit that is missing here is the fact that the .device
> > units for CD drives and USB card readers don't care for media sense right
> > now.
>
>
Hey Lennart,
Lennart Poettering [2015-01-27 22:46 +0100]:
> So I figure the bit that is missing here is the fact that the .device
> units for CD drives and USB card readers don't care for media sense right
> now.
Indeed, I had a similar thought on my evening walk: This works well
for USB sticks a
On Tue, 27.01.15 17:22, Lennart Poettering (lenn...@poettering.net) wrote:
> On Tue, 27.01.15 16:24, Martin Pitt (martin.p...@ubuntu.com) wrote:
>
> > > Well, again, the right answer then is to handle it with .mount units,
> >
> > How would that look like, on a very high level? Create .mount uni
On Tue, Jan 27, 2015 at 05:33:06PM +0100, Martin Pitt wrote:
> Lennart Poettering [2015-01-27 17:22 +0100]:
> > The .mount units of device nodes already have a BindsTo= dependency on
> > their respective backing .device units. This should have the effect
> > that systemd will take the .mount units
Lennart Poettering [2015-01-27 17:22 +0100]:
> The .mount units of device nodes already have a BindsTo= dependency on
> their respective backing .device units. This should have the effect
> that systemd will take the .mount units down if the .device units are
> removed. Are you saying that doesn't
On Tue, 27.01.15 16:24, Martin Pitt (martin.p...@ubuntu.com) wrote:
> > Well, again, the right answer then is to handle it with .mount units,
>
> How would that look like, on a very high level? Create .mount units on
> the fly with udev rules when devices appear, and asking systemd to
> unmount t
Lennart Poettering [2015-01-27 13:52 +0100]:
> So, why is this a new problem, and why do you say that
> MountFlags=slave broke anything?
I didn't say that. :-) I just said that due to this the two proposed
solutions of cleaning up the mounts after CD ejection won't work.
> I mean, cdrom_id cannot
On Tue, 27.01.15 09:40, Martin Pitt (martin.p...@ubuntu.com) wrote:
> Hey Lennart,
>
> Lennart Poettering [2015-01-27 0:55 +0100]:
> > Hmm? I don't see how mount propagation would break 60-cdrom_id... The
> > eject ioctl operates on the device node, and does not care for
> > mounts. This problem
Hey Lennart,
Lennart Poettering [2015-01-27 0:55 +0100]:
> Hmm? I don't see how mount propagation would break 60-cdrom_id... The
> eject ioctl operates on the device node, and does not care for
> mounts. This problem sounds made-up to me.
Right now cdrom_id indeed wouldn't be affected as it does
On Mon, 26.01.15 15:44, Michael Biebl (mbi...@gmail.com) wrote:
> 2015-01-26 14:59 GMT+01:00 Dave Reisner :
> > This reverts part of c2c13f2df42e0, which introduced this with no
> > explanation as to *why*. Enslaving the mount namespace breaks default
> > behavior included in rules/60-cdrom_id.rul
On Mon, 26.01.15 08:59, Dave Reisner (dreis...@archlinux.org) wrote:
> This reverts part of c2c13f2df42e0, which introduced this with no
> explanation as to *why*. Enslaving the mount namespace breaks default
> behavior included in rules/60-cdrom_id.rules. Specifically, filesystems
> on optical me
2015-01-26 14:59 GMT+01:00 Dave Reisner :
> This reverts part of c2c13f2df42e0, which introduced this with no
> explanation as to *why*. Enslaving the mount namespace breaks default
> behavior included in rules/60-cdrom_id.rules. Specifically, filesystems
> on optical media will not be properly unm
This reverts part of c2c13f2df42e0, which introduced this with no
explanation as to *why*. Enslaving the mount namespace breaks default
behavior included in rules/60-cdrom_id.rules. Specifically, filesystems
on optical media will not be properly unmounted when the physical eject
button is used in t
27 matches
Mail list logo
