On 03/19/2015 02:34 PM, MegaBrutal wrote:
Now I think I figured out what's going on. It seems to be
Debian/Ubuntu specific, but I post here, maybe Debian/Ubuntu devs are
here and see this.
Bug report:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1396213
What actually makes the VG activation so long is that I have a
snapshot. Activating the snapshot takes very long, and bringing up the
entire VG takes about 5 minutes. This wouldn't be such a big problem,
as I could just patiently wait for the activation (with rootdelay).
But it seems something (maybe some kind of watchdog) kills vgchange
before it could finish bringing up all VGs. I had the fortune to boot
a developmental Vivid, and I've seen some 'watershed' messages stating
that 'vgchange' was killed because it was taking "too long". If we'd
let 'vgchange' to finish properly, I had the 2nd VG activated
properly, which contains my root FS.
It's a server. If it has a long boot time, so be it, it doesn't get
rebooted often anyway during normal circumstances. But it is required
to boot up without user interaction, e.g., when I issue a reboot
remotely. The main problem is that currently, user interaction is
necessary to pass initrd (as the root VG needs to be manually
activated), which means, I can only reboot the server when I'm
physically near.
I've had the same problem on Fedora - so it is not ubuntu specific. On
Fedora, systemd has a timeout for VG activation. That can be
increased. However, you can flag the snapshot to *not* be activated
automatically (Skip activation: -k) at volume group activation. That
allows the system to boot (remote reboot), and then you can manually
activate the big snapshot (or automatically in a later script) - waiting
the requisite 5 or 10 minutes.
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
