← Back to team overview

kernel-packages team mailing list archive

[Bug 1396213] [NEW] LVM VG is not activated during system boot

 

Public bug reported:

Hi all,

I open this report based on the linked conversation I had on the linux-lvm mailing list, and the Ask Ubuntu question I posted regarding this case.
https://www.redhat.com/archives/linux-lvm/2014-November/msg00023.html
https://www.redhat.com/archives/linux-lvm/2014-November/msg00024.html
http://askubuntu.com/questions/542656/lvm-vg-is-not-activated-during-system-boot

I have 2 VGs on my system, and for some reason, only one of them gets
activated during the initrd boot sequence, which doesn't have my root
LV, so my boot sequence halts with an initrd prompt.

When I get to the initrd BusyBox prompt, I can see my LVs are inactive
with "lvm lvscan" – then, "lvm vgchange -ay" brings them online. The
boot sequence continues as I exit the BusyBox prompt. The expected
behaviour would be that both VGs should activate automatically.

On LVM mailing list, I've been advised it may be a problem with Ubuntu
initrd scripts, hence I report this problem here. (I'm not sure if I'm
reporting it to the correct place by assigning it to "linux", but I
didn't find a package directly related to the initrd only, so I assumed
initrd scripts are maintained by the kernel team. If you think it's an
error, and know the correct package, please reassign!) Our suspicion is,
initrd prematurely issues "vgchange -ay" before all the PVs come online.
This makes sense.

I already tried to set the "rootdelay" kernel parameter to make initrd
wait longer for the boot LV to come up, but it didn't work. Note
however, it worked with previous kernel versions.

The problem came up when I upgraded to Utopic, and got kernel
vmlinuz-3.16.0-23-generic. When I boot with the old kernel from Trusty
(vmlinuz-3.13.0-37-generic), it works fine.

** Affects: linux (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1396213

Title:
  LVM VG is not activated during system boot

Status in “linux” package in Ubuntu:
  New

Bug description:
  Hi all,

  I open this report based on the linked conversation I had on the linux-lvm mailing list, and the Ask Ubuntu question I posted regarding this case.
  https://www.redhat.com/archives/linux-lvm/2014-November/msg00023.html
  https://www.redhat.com/archives/linux-lvm/2014-November/msg00024.html
  http://askubuntu.com/questions/542656/lvm-vg-is-not-activated-during-system-boot

  I have 2 VGs on my system, and for some reason, only one of them gets
  activated during the initrd boot sequence, which doesn't have my root
  LV, so my boot sequence halts with an initrd prompt.

  When I get to the initrd BusyBox prompt, I can see my LVs are inactive
  with "lvm lvscan" – then, "lvm vgchange -ay" brings them online. The
  boot sequence continues as I exit the BusyBox prompt. The expected
  behaviour would be that both VGs should activate automatically.

  On LVM mailing list, I've been advised it may be a problem with Ubuntu
  initrd scripts, hence I report this problem here. (I'm not sure if I'm
  reporting it to the correct place by assigning it to "linux", but I
  didn't find a package directly related to the initrd only, so I
  assumed initrd scripts are maintained by the kernel team. If you think
  it's an error, and know the correct package, please reassign!) Our
  suspicion is, initrd prematurely issues "vgchange -ay" before all the
  PVs come online. This makes sense.

  I already tried to set the "rootdelay" kernel parameter to make initrd
  wait longer for the boot LV to come up, but it didn't work. Note
  however, it worked with previous kernel versions.

  The problem came up when I upgraded to Utopic, and got kernel
  vmlinuz-3.16.0-23-generic. When I boot with the old kernel from Trusty
  (vmlinuz-3.13.0-37-generic), it works fine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1396213/+subscriptions


Follow ups

References