Bug#719738: [PATCH] Please install the lvm2 systemd generator
control: reopen -1 Hi Bastian, Bastian Blank wa...@debian.org writes: Thanks. I'm closing the bug, because systemd is broken. I will add a conflict in the near future. Bastian, excuse my blunt words, but this is a stupid choice. Are you seriously saying that Debian is the only distribution where users can’t have lvm and a modern init system, just because you don’t like how upstream does things nowadays? I am not giving up on this so easily, and, if necessary, will raise this all the way up to the ctte. I’ll ask you one more time: please just ship the generator, which has no side-effects for non-systemd users and makes booting work for systemd users. There is no udev.service in the upstream systemd source. In the Debian package it is a symlink to systemd-udevd.service. Yes, as you noticed, the upstream name is systemd-udevd. No. udev != systemd-udevd. I don’t understand what you mean here. udev upstream has renamed the udev binary to systemd-udevd. Why would they not be equal? -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719738: [PATCH] Please install the lvm2 systemd generator
Hi Bastian, Bastian Blank wa...@debian.org writes: Bastian, excuse my blunt words, but this is a stupid choice. Are you seriously saying that Debian is the only distribution where users can’t have lvm and a modern init system, just because you don’t like how upstream does things nowadays? And? systemd decided to randomly break things, you did not communicate it and now expect others to unbreak it. Sorry. I _did_ communicate it, that is what this bugreport is about. I do not expect others to unbreak it, in fact I debugged it and provided a well-tested (works on my machine, confirmed by two other users) patch with sufficient explanation, ready to merge. What can we do to constructively arrive at a solution? Are there any doubts and blockers beyond the very vague and general “systemd breaks things” statement that you wrote? I would be happy to have a video hangout and discuss this in a more face-to-face manner, if you’d like. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719738: [PATCH] Please install the lvm2 systemd generator
On Sun, Aug 25, 2013 at 06:21:45PM +0200, Bastian Blank wrote: All the other generators do the same, they use predictable filenames in /tmp if there is no argument provided. Please fix this. An alternative (restricted access) directory argument is always supplied when the system invokes this generator so the default was apparently only included for testing purposes: I agree that it should not be there and we'll remove it from the upstream lvm generator. Alasdair -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719738: [PATCH] Please install the lvm2 systemd generator
Hi Bastian, Replying to multiple mails at once: Bastian Blank wa...@debian.org writes: There is no udev.service in the upstream systemd source. In the Debian package it is a symlink to systemd-udevd.service. Yes, as you noticed, the upstream name is systemd-udevd. What upstream thinks is irrelevant if the system expecations are different. Why can't this be a symlink to systemd-udev-settle.service, which provides the backward compatible behaviour I disagree. We should follow upstream unless there is a really compelling and good technical reason not to. I don’t see any reason in our case. Upstream considers software that needs “udevadm settle” (what you refer to with systemd-udev-settle.service) as broken. In case there is really no other solution, in the systemd world you can use Wants=systemd-udev-settle.service together with After=systemd-udev-settle.service. Also please show me where the generator stuff is documented. First google hit for “systemd generator” for me: http://www.freedesktop.org/wiki/Software/systemd/Generators/ I don’t quite understand why you are hesitant to do that, given that there are absolutely no changes to sysvinit users. Maybe you can clarify what your concern is, if any? Because it deliberately breaks stuff. Nothing will be broken when shipping the generator as I asked you to. On the contrary, this fixes booting for many people. Can you elaborate on what would be broken? Bastian Blank wa...@debian.org writes: The string udev.service does not show up in the upstream source, so you actually lied about this being something upstream does. This make it a deliberate and undocumented choice of the Debian maintainer to make this a symlink to systemd-udev.service and break backward compatibility. The upstream name for udev.service changed to systemd-udev.service in commit f13b388f97bc3ba8db844bd3413d510e2466a0b6, see http://cgit.freedesktop.org/systemd/systemd/commit/?id=f13b388f97 The symlink that we ship in Debian is necessary because we still have sysvinit scripts, whereas other distributions don’t need to care. This is why it lives in the Debian package and not upstream. My statement that we take systemd-udev.service directly from upstream still stands and is true. I did in fact not lie. The mere accusation of lying is something that makes me angry and I don’t find it acceptable. This is really not the spirit in which we want to work together in Debian. I request an apology from you. Because the shipped generator from RedHat does not fail gracefully, I consider doing this a different way Can you please elaborate on what you mean by “does not fail gracefully”? Have you opened an upstream bug about that? If so, where can I find it? -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719738: [PATCH] Please install the lvm2 systemd generator
Control: tags -1 -patch Control: clone -1 -2 -3 Control: reassign -2 systemd/204-2 Control: reassign -3 systemd/204-2 Control: retitle -1 lvm2 - Add systemd support Control: retitle -2 systemd - Missing backward compatibility for udev Control: retitle -3 systemd - Generators uses predictable file names in /tmp Control: submitter -3 ! After carefully examining this whole mess, I consider this a bug in systemd for breaking backward compatibility without reason. On Fri, Aug 23, 2013 at 01:59:06PM +0200, Bastian Blank wrote: On Thu, Aug 22, 2013 at 11:38:42PM +0200, Michael Stapelberg wrote: The systemd service file for udev, which we take directly from upstream, There is no udev.service in the upstream systemd source. In the Debian package it is a symlink to systemd-udevd.service. The string udev.service does not show up in the upstream source, so you actually lied about this being something upstream does. This make it a deliberate and undocumented choice of the Debian maintainer to make this a symlink to systemd-udev.service and break backward compatibility. Instead, upstream’s view (specifically Kay’s view as the udev maintainer) is that Linux is event-driven and udev handles these events whenever they occur, What upstream thinks is irrelevant if the system expecations are different. Why can't this be a symlink to systemd-udev-settle.service, which provides the backward compatible behaviour? Please actually answer my questions. First this needs a security check. The tool uses /tmp as default directory and most likely runs as root. So at least this can be used for DoS. All the other generators do the same, they use predictable filenames in /tmp if there is no argument provided. Please fix this. Because the shipped generator from RedHat does not fail gracefully, I consider doing this a different way: - Ship lvm2.service and the local-fs.wants-symlink in the package. - Ship a generator that masks lvm2.service by creating a symlink to /dev/null if lvmetad is enabled. However I have not tried this yet. Bastian -- The heart is not a logical organ. -- Dr. Janet Wallace, The Deadly Years, stardate 3479.4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719738: [PATCH] Please install the lvm2 systemd generator
On Thu, Aug 22, 2013 at 11:38:42PM +0200, Michael Stapelberg wrote: The systemd service file for udev, which we take directly from upstream, There is no udev.service in the upstream systemd source. In the Debian package it is a symlink to systemd-udevd.service. Instead, upstream’s view (specifically Kay’s view as the udev maintainer) is that Linux is event-driven and udev handles these events whenever they occur, What upstream thinks is irrelevant if the system expecations are different. Why can't this be a symlink to systemd-udev-settle.service, which provides the backward compatible behaviour? Therefore, I ask you again to please include the patch I attached to this bugreport in order to make lvm work much better on a Debian machine using systemd. First this needs a security check. The tool uses /tmp as default directory and most likely runs as root. So at least this can be used for DoS. Second the init-script and the generated unit have different names, so systemd won't be able to consider them equal. I have no idea how this really works anyway. Also please show me where the generator stuff is documented. I don’t quite understand why you are hesitant to do that, given that there are absolutely no changes to sysvinit users. Maybe you can clarify what your concern is, if any? Because it deliberately breaks stuff. That it only supports one of the kernel types supported by Debian does not help eather. Bastian -- I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, Errand of Mercy, stardate 3198.9 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719738: [PATCH] Please install the lvm2 systemd generator
On 08/23/2013 01:59 PM, Bastian Blank wrote: Second the init-script and the generated unit have different names, so systemd won't be able to consider them equal. I have no idea how this really works anyway. The aim of the lvm2-activation-generator is to: - do nothing if global/use_lvmetad=1 in lvm.conf This is because when using lvmetad, the LVM event-based autoactivation is used as well so we don't need any direct call to activate LVM volumes and also we don't need any wait for udev to complete - the LVM volumes are activated automatically once the VG is complete (it has all the PVs present in the system). - generate the systemd units to activate the LVM volumes if global/use_lvmetad=0 in lvm.conf. These units (lvm2-activation*.service) then bring in all that's needed - udev wait service as well as being called before and after the encrypted volumes are in place Though it works only in one layer of course - PV - VG - LV - encrypted - PV ..., so we have lvm2-activation-early.service for the first layer, then decryption and then lvm2-activation.service after decrypting - if such layout is chosen by user for any reason. If more encrypted layers are needed, then a loop is needed with vgchange (but I haven't seen such a request yet). When using the generator, all the former initscripts (or whatever else was used before) is not needed and should be removed since the generator will generate the units to activate the volumes if needed. I don't know what exactly is used in Debian, but in Fedora the former vgchange -ay call was part of the initscripts packaged was removed after the introduction of lvm2-activation-generator (which is part of the lvm2 package). But as I said, I don't know what's the exact logic used in Debian... so take this as a hint only. Current movement is to use event-based activation together with lvmetad. The lvm2-activation-generator is here for the transition as using lvmetad + event-based activation is configurable in lvm.conf via that use_lvmetad configuration option. Systemd services can't be run conditionally based on external configuration. That's what the generator solves - it either generates the units if needed or not. And those units with direct LVM activation are not needed if lvmetad is used as that activation is event-based and done via udev rules (69-dm-lvmetad.rules) and with the help of lvmetad. It all happens automatically then. This solution with the generator for lvm2 was discussed directly with Lennart Poettering from systemd. Similar generator is used for fstab, for example - which is also an external configuration from systemd point of view. The fstab generator which generates systemd units on the fly for fstab content. The same logic applies for lvm2 and its lvm.conf configuration... Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719738: [PATCH] Please install the lvm2 systemd generator
On Fri, Aug 23, 2013 at 03:22:18PM +0200, Peter Rajnoha wrote: On 08/23/2013 01:59 PM, Bastian Blank wrote: Second the init-script and the generated unit have different names, so systemd won't be able to consider them equal. I have no idea how this really works anyway. The question was about the handling of init-script and systemd-service of same name. The aim of the lvm2-activation-generator is to: - do nothing if global/use_lvmetad=1 in lvm.conf I'm not sure why this is useful. The systemd units would only call vgchange -aay --sysinit, which is already a no-op if lvmetad is enabled. Instead of units, which can be overwritten by distribution means, dpkg-divert for example, it generates _static_ files within a binary. I only see that it makes the complexity of the system higher, but I don't see the gain. Bastian -- Witch! Witch! They'll burn ya! -- Hag, Tomorrow is Yesterday, stardate unknown -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719738: [PATCH] Please install the lvm2 systemd generator
On 08/23/2013 04:03 PM, Bastian Blank wrote: On Fri, Aug 23, 2013 at 03:22:18PM +0200, Peter Rajnoha wrote: On 08/23/2013 01:59 PM, Bastian Blank wrote: Second the init-script and the generated unit have different names, so systemd won't be able to consider them equal. I have no idea how this really works anyway. The question was about the handling of init-script and systemd-service of same name. If both init-script and systemd service are of the same name, systemd service prevails. I've read it once in some systemd manual (though I can't find it now quickly in those tons of systemd doc :) ). I've just tried that directly and yes, it's systemd service that prevails, the other one is ignored. The aim of the lvm2-activation-generator is to: - do nothing if global/use_lvmetad=1 in lvm.conf I'm not sure why this is useful. The systemd units would only call vgchange -aay --sysinit, which is already a no-op if lvmetad is enabled. Instead of units, which can be overwritten by distribution means, dpkg-divert for example, it generates _static_ files within a binary. I only see that it makes the complexity of the system higher, but I don't see the gain. Well, it depends on the view. The aim is to make the boot clean. So there are no extra unneeded calls that could make the boot process unclear (and if the generator is NOP for use_lvmetad=1, we can assure that). Thing is that we're slowly switching to using lvmetad by default. And calling direct vgchange on boot will get more and more deprecated in the future. Also, if the system is configured in a way that all needed paths are accessible even during boot time (e.g. using tmpfs for paths where lvm's file-based locking is used and sockets/fifos placed), we actually don't even need the --sysinit for vgchange call. Then the vgchange is not a NOP anymore. And you need to call that vgchange more than once (e.g. because of the encryption placed in between layers etc.). What I want to say is that the generator is here just for the case when someone backs out of using lvmetad and uses the old classic event-unaware lvm without lvmetad which should become rather an exception in the future. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719738: [PATCH] Please install the lvm2 systemd generator
On Thu, Aug 15, 2013 at 10:24:42AM +0200, Michael Stapelberg wrote: Bastian Blank wa...@debian.org writes: The init-script calls vgchange -ay. Why does this not work? Because the init script is called only once during boot, whereas new devices may also appear later. As an example, in the case that Vincent Bernat brought up, the lvm2 init script runs after the first hard disk is crypto-unlocked and available, but does not run again (obviously) after the second hard disk becomes crypto-unlocked (with a key file that is stored on the first one). The lvm2 init-script declares a lazy dependency on the udev init-script, which is unquestionable available. The later makes sure the hardware is available by waiting. The description tells me: | # Short-Description: Start udevd, populate /dev and load drivers. If this is not longer true, fix this first. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, Day of the Dove, stardate unknown -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719738: [PATCH] Please install the lvm2 systemd generator
Hi Bastian, Bastian Blank wa...@debian.org writes: On Thu, Aug 15, 2013 at 10:24:42AM +0200, Michael Stapelberg wrote: Bastian Blank wa...@debian.org writes: The init-script calls vgchange -ay. Why does this not work? Because the init script is called only once during boot, whereas new devices may also appear later. As an example, in the case that Vincent Bernat brought up, the lvm2 init script runs after the first hard disk is crypto-unlocked and available, but does not run again (obviously) after the second hard disk becomes crypto-unlocked (with a key file that is stored on the first one). The lvm2 init-script declares a lazy dependency on the udev init-script, which is unquestionable available. The later makes sure the hardware is available by waiting. The description tells me: | # Short-Description: Start udevd, populate /dev and load drivers. If this is not longer true, fix this first. The systemd service file for udev, which we take directly from upstream, does not wait on all the hardware arriving before continuing. Instead, upstream’s view (specifically Kay’s view as the udev maintainer) is that Linux is event-driven and udev handles these events whenever they occur, not in a “let’s wait for all hardware and just ignore anything that comes up later” fashion :-). We don’t want to diverge from upstream in that key point of how udev works. Therefore, I ask you again to please include the patch I attached to this bugreport in order to make lvm work much better on a Debian machine using systemd. I don’t quite understand why you are hesitant to do that, given that there are absolutely no changes to sysvinit users. Maybe you can clarify what your concern is, if any? Thanks. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719738: [PATCH] Please install the lvm2 systemd generator
Hi Bastian, Michael Stapelberg stapelb...@debian.org writes: Bastian Blank wa...@debian.org writes: On Wed, Aug 14, 2013 at 08:49:02PM +0200, Michael Stapelberg wrote: Debian users who use systemd sometimes have trouble booting their machines (see e.g. http://bugs.debian.org/718190). Here at DebConf I had the chance to reproduce the issue and noticed that the lvm2 package does not ship the systemd generator that upstream provides. The init-script calls vgchange -ay. Why does this not work? Because the init script is called only once during boot, whereas new devices may also appear later. As an example, in the case that Vincent Bernat brought up, the lvm2 init script runs after the first hard disk is crypto-unlocked and available, but does not run again (obviously) after the second hard disk becomes crypto-unlocked (with a key file that is stored on the first one). systemd in general does things based on events and whenever appropriate, so this generator is required to make things work. I hope this clarifies, if not, please let me know. Thanks. Nearly a week has passed without hearing anything from you. Was my explanation not sufficient? Can I be of any help in moving this forward? -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719738: [PATCH] Please install the lvm2 systemd generator
Hi Bastian, Bastian Blank wa...@debian.org writes: On Wed, Aug 14, 2013 at 08:49:02PM +0200, Michael Stapelberg wrote: Debian users who use systemd sometimes have trouble booting their machines (see e.g. http://bugs.debian.org/718190). Here at DebConf I had the chance to reproduce the issue and noticed that the lvm2 package does not ship the systemd generator that upstream provides. The init-script calls vgchange -ay. Why does this not work? Because the init script is called only once during boot, whereas new devices may also appear later. As an example, in the case that Vincent Bernat brought up, the lvm2 init script runs after the first hard disk is crypto-unlocked and available, but does not run again (obviously) after the second hard disk becomes crypto-unlocked (with a key file that is stored on the first one). systemd in general does things based on events and whenever appropriate, so this generator is required to make things work. I hope this clarifies, if not, please let me know. Thanks. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719738: [PATCH] Please install the lvm2 systemd generator
Package: lvm2
Version: 2.02.98-5
Severity: normal
Tags: patch
Dear maintainer,
Debian users who use systemd sometimes have trouble booting their
machines (see e.g. http://bugs.debian.org/718190). Here at DebConf I had
the chance to reproduce the issue and noticed that the lvm2 package does
not ship the systemd generator that upstream provides.
The attached patch calls the install_systemd_generators and
install_tmpfiles_configuration make targets to install the files, adds
them to debian/lvm2.install and fixes the hard-coded path in
scripts/lvm2_activation_generator_systemd_red_hat.c (patch sent
upstream).
In my tests, this fixes the lvm boot issues with systemd. Therefore,
please merge it for your next upload.
Thank you.
diff -Nru lvm2-2.02.98/debian/lvm2.install lvm2-2.02.98/debian/lvm2.install
--- lvm2-2.02.98/debian/lvm2.install 2012-05-27 16:25:21.0 +0200
+++ lvm2-2.02.98/debian/lvm2.install 2013-08-14 19:02:39.0 +0200
@@ -8,3 +8,5 @@
usr/share/man/man8/pv*
usr/share/man/man8/vg*
usr/share/man/man5
+usr/lib/tmpfiles.d/lvm2.conf
+lib/systemd/system-generators/lvm2-activation-generator
diff -Nru lvm2-2.02.98/debian/patches/lvm_path.patch lvm2-2.02.98/debian/patches/lvm_path.patch
--- lvm2-2.02.98/debian/patches/lvm_path.patch 1970-01-01 01:00:00.0 +0100
+++ lvm2-2.02.98/debian/patches/lvm_path.patch 2013-08-14 20:41:10.0 +0200
@@ -0,0 +1,28 @@
+Description: Use LVM_PATH instead of hard-coded /usr/sbin/lvm
+Author: Michael Stapelberg stapelb...@debian.org
+Last-Update: 2013-08-14
+Forwarded: https://www.redhat.com/archives/linux-lvm/2013-August/msg00033.html
+
+---
+
+Index: lvm2-2.02.98/scripts/lvm2_activation_generator_systemd_red_hat.c
+===
+--- lvm2-2.02.98.orig/scripts/lvm2_activation_generator_systemd_red_hat.c 2013-08-14 18:44:12.005448150 +0200
lvm2-2.02.98/scripts/lvm2_activation_generator_systemd_red_hat.c 2013-08-14 18:52:14.403183063 +0200
+@@ -20,6 +20,7 @@
+ #include sys/stat.h
+ #include fcntl.h
+ #include lvm2app.h
++#include lib.h /* for LVM_PATH */
+
+ #define KMSG_DEV_PATH/dev/kmsg
+ #define LVM_CONF_USE_LVMETAD global/use_lvmetad
+@@ -125,7 +126,7 @@
+ fputs(Before=local-fs.target shutdown.target\n
+ Wants=systemd-udev-settle.service\n\n
+ [Service]\n
+- ExecStart=/usr/sbin/lvm vgchange -aay --sysinit\n
++ ExecStart= LVM_PATH vgchange -aay --sysinit\n
+ Type=oneshot\n, f);
+
+ if (fclose(f) 0) {
diff -Nru lvm2-2.02.98/debian/patches/series lvm2-2.02.98/debian/patches/series
--- lvm2-2.02.98/debian/patches/series 2013-07-13 12:32:01.0 +0200
+++ lvm2-2.02.98/debian/patches/series 2013-08-14 18:43:42.0 +0200
@@ -7,3 +7,4 @@
dm-event-api.patch
monitoring-default-off.patch
missing-dmeventd.patch
+lvm_path.patch
diff -Nru lvm2-2.02.98/debian/rules lvm2-2.02.98/debian/rules
--- lvm2-2.02.98/debian/rules 2013-07-14 16:30:54.0 +0200
+++ lvm2-2.02.98/debian/rules 2013-08-14 19:02:46.0 +0200
@@ -140,6 +140,8 @@
dh_testroot
rm -rf $(INSTALL_DIR)
+$(MAKE_REAL) -C $(DIR) install DESTDIR=$(CURDIR)/$(INSTALL_DIR) LIB_VERSION_DM=$(DEVMAPPER_ABINAME)
+ +$(MAKE_REAL) -C $(DIR) install_systemd_generators DESTDIR=$(CURDIR)/$(INSTALL_DIR) LIB_VERSION_DM=$(DEVMAPPER_ABINAME)
+ +$(MAKE_REAL) -C $(DIR) install_tmpfiles_configuration DESTDIR=$(CURDIR)/$(INSTALL_DIR) LIB_VERSION_DM=$(DEVMAPPER_ABINAME)
touch $@
install-base-prep:
Bug#719738: [PATCH] Please install the lvm2 systemd generator
On Wed, Aug 14, 2013 at 08:49:02PM +0200, Michael Stapelberg wrote: Debian users who use systemd sometimes have trouble booting their machines (see e.g. http://bugs.debian.org/718190). Here at DebConf I had the chance to reproduce the issue and noticed that the lvm2 package does not ship the systemd generator that upstream provides. The init-script calls vgchange -ay. Why does this not work? Bastian -- Only a fool fights in a burning house. -- Kank the Klingon, Day of the Dove, stardate unknown -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
