Arch recently upgraded systemd to 245.6. Shortly afterwards, users began
reporting[0] that systemd detected an ordering cycle, and they were
unable to log in. The reason they were unable to log in was because of
ordering cycle resolution:

    [...]
    systemd[1]: sysinit.target: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with sysinit.target/start
    systemd[1]: sysinit.target: Job systemd-update-done.service/start deleted to break ordering cycle starting with sysinit.target/start
    systemd[1]: sysinit.target: Job systemd-journal-catalog-update.service/start deleted to break ordering cycle starting with sysinit.target/start
    systemd[1]: sysinit.target: Job local-fs.target/start deleted to break ordering cycle starting with sysinit.target/start
    systemd[1]: sysinit.target: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with sysinit.target/start
    [...]

Whether the resolution did the right thing here or not is a longer-term
discussion, but in the interim we should at least make this distinction
between automount dependencies and mount dependencies clearer in the
documentation, so that users and distribution maintainers know what's
acceptable. In this case Arch actually backed out b3d7aef entirely and
released a new version due to the confusion.

Also see systemd/systemd-stable#69.

0: https://bugs.archlinux.org/task/66908

…ied to the mount unit

If an entry in fstab uses "x-systemd.automount" option and also asks for
additionnal dependencies via x-systemd.requires or such, then the dependencies
were applied to the automount unit.

But this unlikely to do the right thing and is consistent with network mount
network mounts.

Indeed for entries specifying "_netdev,x-systemd.automount" options, both a
network mount is generated as well as an automount one. But the network
dependencies are only applied to the mount unit, the automount unit remains
ordered against local-fs.target.

The same logic should be followed when extra deps are specified via the mount
options as automount units should always be ordered against local-fs.target.

Note: in general such extra deps should be used with care and should specify
dependencies on other mount units only. Indeed it can easily create ordering
cycles like it's been seen in
systemd/systemd-stable#69 as mount units (as well as
automount ones) are ordered before local-fs.target which is a low-level target
that most other units depend on.

…ied to the mount unit

If an entry in fstab uses "x-systemd.automount" option and also asks for
additionnal dependencies via x-systemd.requires or such, then the dependencies
were applied to the automount unit.

But this unlikely to do the right thing and is inconsistent with what's done
for network mounts.

Indeed when an fstab entries has "_netdev,x-systemd.automount" options, the
dependencies against the network requested by "_netdev" are (correctly) applied
to the mount unit only and the automount unit remains ordered against
local-fs.target.

The same logic should be followed when extra deps are specified via the mount
options as automount units should always be ordered against local-fs.target.

Note: in general explicit deps specified via mount options should be used with
care and should be used to specify dependencies on other mount units only as it
can easily create ordering cycles otherwise like it's been seen in
systemd/systemd-stable#69. Mount units (as well as
automount ones) are ordered before local-fs.target by default which is a
low-level target that most other units depend on.

Arch recently upgraded systemd to 245.6. Shortly afterwards, users began
reporting[0] that systemd detected an ordering cycle, and they were
unable to log in. The reason they were unable to log in was because of
ordering cycle resolution:

    [...]
    systemd[1]: sysinit.target: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with sysinit.target/start
    systemd[1]: sysinit.target: Job systemd-update-done.service/start deleted to break ordering cycle starting with sysinit.target/start
    systemd[1]: sysinit.target: Job systemd-journal-catalog-update.service/start deleted to break ordering cycle starting with sysinit.target/start
    systemd[1]: sysinit.target: Job local-fs.target/start deleted to break ordering cycle starting with sysinit.target/start
    systemd[1]: sysinit.target: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with sysinit.target/start
    [...]

Whether the resolution did the right thing here or not is a longer-term
discussion, but in the interim we should at least make this distinction
between automount dependencies and mount dependencies clearer in the
documentation, so that users and distribution maintainers know what's
acceptable. In this case Arch actually backed out b3d7aef entirely and
released a new version due to the confusion.

Also see #69.

0: https://bugs.archlinux.org/task/66908
(cherry picked from commit 69876f9)

…ied to the mount unit

If an entry in fstab uses "x-systemd.automount" option and also asks for
additionnal dependencies via x-systemd.requires or such, then the dependencies
were applied to the automount unit.

But this unlikely to do the right thing and is inconsistent with what's done
for network mounts.

Indeed when an fstab entries has "_netdev,x-systemd.automount" options, the
dependencies against the network requested by "_netdev" are (correctly) applied
to the mount unit only and the automount unit remains ordered against
local-fs.target.

The same logic should be followed when extra deps are specified via the mount
options as automount units should always be ordered against local-fs.target.

Note: in general explicit deps specified via mount options should be used with
care and should be used to specify dependencies on other mount units only as it
can easily create ordering cycles otherwise like it's been seen in
#69. Mount units (as well as
automount ones) are ordered before local-fs.target by default which is a
low-level target that most other units depend on.

(cherry picked from commit 045c5fa)

Arch recently upgraded systemd to 245.6. Shortly afterwards, users began
reporting[0] that systemd detected an ordering cycle, and they were
unable to log in. The reason they were unable to log in was because of
ordering cycle resolution:

    [...]
    systemd[1]: sysinit.target: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with sysinit.target/start
    systemd[1]: sysinit.target: Job systemd-update-done.service/start deleted to break ordering cycle starting with sysinit.target/start
    systemd[1]: sysinit.target: Job systemd-journal-catalog-update.service/start deleted to break ordering cycle starting with sysinit.target/start
    systemd[1]: sysinit.target: Job local-fs.target/start deleted to break ordering cycle starting with sysinit.target/start
    systemd[1]: sysinit.target: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with sysinit.target/start
    [...]

Whether the resolution did the right thing here or not is a longer-term
discussion, but in the interim we should at least make this distinction
between automount dependencies and mount dependencies clearer in the
documentation, so that users and distribution maintainers know what's
acceptable. In this case Arch actually backed out b3d7aef entirely and
released a new version due to the confusion.

Also see systemd/systemd-stable#69.

0: https://bugs.archlinux.org/task/66908
(cherry picked from commit 69876f9)

…ied to the mount unit

If an entry in fstab uses "x-systemd.automount" option and also asks for
additionnal dependencies via x-systemd.requires or such, then the dependencies
were applied to the automount unit.

But this unlikely to do the right thing and is inconsistent with what's done
for network mounts.

Indeed when an fstab entries has "_netdev,x-systemd.automount" options, the
dependencies against the network requested by "_netdev" are (correctly) applied
to the mount unit only and the automount unit remains ordered against
local-fs.target.

The same logic should be followed when extra deps are specified via the mount
options as automount units should always be ordered against local-fs.target.

Note: in general explicit deps specified via mount options should be used with
care and should be used to specify dependencies on other mount units only as it
can easily create ordering cycles otherwise like it's been seen in
systemd/systemd-stable#69. Mount units (as well as
automount ones) are ordered before local-fs.target by default which is a
low-level target that most other units depend on.

(cherry picked from commit 045c5fa)