Short answer: it's OK.
/lib/systemd/system/lvm2.service
is created as a symbolic link to /dev/null
by the lvm2
Debian package, causing the service to be permanently masked, because the job of the SysVinit-style /etc/init.d/lvm2
start-up script is actually split into multiple native systemd
units.
lvm2.service
needs to exist, though, because otherwise the SysVinit compatibility logic would automatically create a systemd
unit that would just run that script. Since a systemd
-native /lib/systemd/system/lvm2.service
exists, that won't happen - but because all the actual work is done by instances of lvm2-pvscan@.service
and the lvm2-monitor.service
, the only job of unit lvm2.service
is to mask out the redundant SysVinit-style startup script.
Also, you're correct that LVM can be used on a Debian system disk, as long as /boot
is placed into a traditional non-LVM partition that the system firmware can understand - as GRUB is using the services of the system firmware to access files from that filesystem.
(Yes, modern versions of GRUB do include the capacity to read filesystems on LVM. Debian 9's version of GRUB even includes the lvm.mod
GRUB module. But the problem is mostly that the Debian Installer cannot yet set it up reliably - or could not at the time of Debian 9 release. I would guess it's probably mostly about getting the installer to "understand" the new possibilities when having /boot
inside LVM, and getting it to warn the user about configurations that won't work.)