1 files changed, 12 insertions, 37 deletions
diff --git a/man/lvmautoactivation.7_main b/man/lvmautoactivation.7_main
index 54dab718b..808ea0d9f 100644
--- a/man/lvmautoactivation.7_main
+++ b/man/lvmautoactivation.7_main
@@ -17,13 +17,11 @@ is another way to limit autoactivation.
 .
 .SS event autoactivation
 .P
-The most common form of autoactivation is "event based", in which complete
-VGs are activated in response to uevents which occur during system startup
-or at any time after the system has started.  Another form of
-autoactivation is "static" in which complete VGs are activated at a fixed
-point during system startup by a systemd service, and not in response to
-events.  This can be controlled with the lvm.conf setting
-event_activation.
+LVM autoactivation is "event based", in which complete VGs are activated
+in response to uevents which occur during system startup or at any time
+after the system has started.  An old form of autoactivation was "static"
+in which complete VGs are activated at a fixed point during system startup
+by a systemd service, and not in response to events.
 .P
 Event based autoactivation is driven by udev, udev rules, and systemd.
 When a device is attached to a machine, a uevent is generated by the
@@ -32,7 +30,7 @@ rules to process the new device.  Udev rules use blkid to identify the
 device as an LVM PV and then execute the lvm-specific udev rule for the
 device, which triggers autoactivation.
 .P
-There are two variations of event baed autoactivation that may be used on
+There are two variations of event based autoactivation that may be used on
 a system, depending on the LVM udev rule that is installed (found in
 /lib/udev/rules.d/.)  The following summarizes the steps in each rule
 which lead to autoactivation:
@@ -179,35 +177,12 @@ concurrent commands attempt to activate a VG at once.
 .
 .SS static autoactivation
 .P
-When event autoactivation is disabled by setting lvm.conf
-event_activation=0, autoactivation is performed at one or more static
-points during system startup. At these points, a vgchange -aay command is
-run to activate complete VGs from devices that are present on the system
-at that time. pvscan commands (and lvm2-pvscan services) do not perform
-autoactivation in this mode.  pvscan commands may still be run from
-uevents but will do nothing when they read the event_activation=0 setting.
-.P
-The static vgchange -aay commands are run by three systemd services at
-three points during startup: lvm2-activation-early, lvm2-activation, and
-lvm2-activation-net. These static activation services are "generated
-services", so the service files are created at run time by the
-lvm2-activation-generator command (run by systemd).
-lvm2-activation-generator creates the services if lvm.conf
-event_activation=0.
-.P
-The limitation of this method is that devices may not be attached to the
-system (or set up) at a reliable point in time during startup, and they
-may not be present when the services run vgchange.  In this case, the VGs
-will not be autoactivated.  So, the timing of device attachment/setup
-determines whether static autoactivation will produce the same results as
-event autoactivation.  For this reason, static autoactivation is not
-recommended.
-.P
-Sometimes, static autoactivation is mistakenly expected to disable all
-autoactivation of particular VGs. This may appear to be effective if those
-VGs are slow to be attached or set up. But, the only correct and reliable
-way to disable autoactivation is using vgchange/lvchange
---setautoactivation n, or lvm.conf auto_activation_volume_list.
+A static autoactivation method is no longer provided by lvm.
+Setting event_activation=0 still disables event based autoactivation.
+WARNING: disabling event activation without an alternative may prevent a
+system from booting.  A custom systemd service could be written to run
+autoactivation during system startup, in which case disabling event
+autoactivation may be useful.
 .
 .SH EXAMPLES
 .P