I've got an external hard drive as part of an LVM volume group backupdrive1. It is an old, slow drive and even when mounted, it takes 5-6 seconds to respond. On initial boot, the lvm.service unit shows up as failed: (I have another LVM volume group that is successfully assembled on boot), and the VG shows up as 'not available' until I restart the lvm.service unit (or run 'vgchange -ay').
Oct 11 16:13:03 homeserver systemd: lvm.service: main process exited, code=exited, status=5 Oct 11 16:13:03 homeserver systemd: Failed to start LVM activation. Oct 11 16:13:03 homeserver systemd: Unit lvm.service entered failed state.
I have the drive setup for systemd automount, which works fine once the lvm.service unit is restarted.
/dev/mapper/backupdrive1-backup /mnt/backup ext4 noauto,x-systemd.automount,noatime 0 2
I have tried:
1. Adding lvmwait=/dev/mapper/backupdrive1-backup to my kernel boot line. No effect, I think because the LV is not involved in the boot process. Seems like everyone I've read about that uses lvmwait has issues with their root partition on LVM, which is not the problem here.
2. Modifying the default lvm.service unit to increase the timeout parameter (but I'm not sure if this is useful or not...seemed like a good thing to try!)
[Unit] Description=LVM activation DefaultDependencies=no Requires=systemd-udev-settle.service After=systemd-udev-settle.service Before=basic.target shutdown.target Conflicts=shutdown.target [Service] ExecStart=/sbin/vgchange --sysinit --available y Type=oneshot + TimeoutSec=40 - TimeoutSec=0 RemainAfterExit=yes [Install] WantedBy=basic.target
Before systemd, I just put 'vgchange -ay' in /etc/rc.local, and that worked fine. I could try creating a custom unit to replicate the rc.local function, but it seems there should be a more elegant way to solve this!
Last edited by firecat53 (2012-10-12 00:45:11)
I am having the same issue. Have you solved it?