Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#62289 - [lvm2] Please disable lvmetad in lvm2 package

Attached to Project: Arch Linux
Opened by mkkot (mkkot) - Tuesday, 09 April 2019, 19:15 GMT
Last edited by David Runge (dvzrv) - Friday, 17 January 2020, 12:53 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To Christian Hesse (eworm)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No



Please disable lvmetad, as it's deprecated now:

"The lvmetad daemon for caching metadata has been deprecated. In a future major release of Red Hat Enterprise Linux, LVM will always read metadata from disk."

Currently our package builds with --enable-lvmetad and config file comes with use_lvmetad = 1. I just changed this in wiki documentation here:

Why I did this? Because it solves problem with delayed shutdown described here:
This task depends upon

Comment by James Harvey (jamespharvey20) - Wednesday, 10 April 2019, 08:22 GMT
I very strongly disagree. Upstream has neither made lvmetad disabled by default, nor removed it, in their released stable branch. Nor has Red Hat (primary LVM developers) done so in RHEL or Fedora. I'm not going to look at non-RH distributions for this purpose, but I'm not sure if there are any major distributions that have decided to do this yet. With LVM being central to data integrity, Arch shouldn't (potentially) be the first to do it by default and see if any problems arise.

The term "deprecated" isn't relevant to if there should be a change to this package. It merely means something has been flagged as on its way or is being replaced. Lots of deprecated things can be enabled by default.

What matters if it should be enabled by default. Arch's philosophy is to follow upstream. If we look to RHEL, although their documentation says it's deprecated, it is still in use until "a future major release of [RHEL]." If we look to Fedora's lvm2-2.02.184-1.fc31.src, lvmetad is enabled by default in its lvm2.spec. So, neither of Red Hat's distributions have disabled it.

lvm2 has for a very long time caused slow boot and shutdown in some situations for Arch users. This isn't some catastrophic situation that justifies deviating from upstream any more than it has in the past.

Fedora's most recent srpm also builds with "--enable-lvmetad". And, its config file comes with "use_lvmetad = 1". Arch's "/etc/lvm/lvm.conf" comes from upstream, and is not Arch specific.

There's an upstream bugreport about slowing down boot and shutdown on linux 5 here: --- they're aware of it, but have not chosen to issue a new stable release disabling or removing lvmetad.

Upstream has a commit totally removing lvmetad, but they haven't released that or a configuration file that defaults it to off in their stable branch. It's only in their developmental 2.03 branch. See: --- And note that although this commit is from last July, for whatever reason, they haven't submitted it to their stable branch. Who knows what other commits are in their unstable branch that they would say should go along with disabling lvmetad.

The default needs to be to keep it as provided by upstream, and let users manually disable it if they wish, until lvm2 makes the change in their stable branch.
Comment by James Harvey (jamespharvey20) - Wednesday, 10 April 2019, 08:42 GMT
I wanted to double check this before posting, so wasn't in my initial reply. When I tried a month or so ago disabling lvmetad, I could no longer boot, so I had to re-enable it, and this is still the case. I'm seeing others in the original poster's linked threads saying they're having this happen as well, if the root volume is on an LVM volume. Looks like it happens once mkinitcpio is ran the next time, because it disables lvmetad in the initramfs, and the lvm2 hook has no fallback. Implementing this change without changing this hook as well will make who knows how many Arch users be unable to boot.
Comment by Simon Wydooghe (HyperBaton) - Wednesday, 10 April 2019, 16:13 GMT
Today I updated to lvm2 2.02.184-2 and it broke my boot. Hangs during the local encrypted volumes waiting for the LVM volumes to appear it seems. Root disk is (LUKS -> LVM -> btrfs -> root subvol). Had to live USB boot, arch-chroot and downgrade to lvm2 2.02.184-1 to fix it. Is this ticket related somehow?
Comment by Simon Wydooghe (HyperBaton) - Wednesday, 10 April 2019, 17:15 GMT
<< woops, posted comment twice >>
Comment by loqs (loqs) - Wednesday, 10 April 2019, 17:16 GMT
I agree lvmetad support should not be removed to address bugs.
That does not mean it should not be considered for removal or be disabled by default on performance grounds.
Any such change would obviously need to be extensively tested for data integrity issues.

etc/lvm/lvm.conf is generated from which contains use_lvmetad = @DEFAULT_USE_LVMETAD@
If you build with --disable-use-lvmetad then it will contain "use_lvmetad = 0" removes --enable-lvmetad why is that commit or other commits needed for --disable-use-lvmetad or --disable-lvmetad ?
Without lvmetad the mkinitcpio hooks would need to be changed I do not believe mkknot was suggesting otherwise.

Unless upstream reverses its intention to remove support for lvmetad such a change can be deferred until it is removed from stable.

@HyperBaton only tangentially.