Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I resized my logical volume and filesystem and all went smoothly. I installed new kernel and after reboot I can't boot neither current nor former one. I get volume group not found error after selecting grub(2) option. Inspection from busy box reveals the volumes are not registered with device mapper and that they are inactive. I wasn't able to mount them after activating, I got file not found error (mount /dev/mapper/all-root /mnt).

Any ideas how to proceed or make them active at the boot time? Or why the volumes are all of sudden inactive at boot time?



EDIT: Further investigation revealed that this had nothing to do with the resizing of logical volumes. The fact that logical volumes had to be activated manually in ash shell after failed boot and possible solution to this problem is covered in my reply below.

share|improve this question
What I've tried so far: 1) your patch 2) diffing /etc/lvm/lvm.conf 3) GRUB_PRELOAD_MODULES="lvm" 4) GRUB_CMDLINE_LINUX="scsi_mod.scan=sync" 5) sudo grub-install /dev/sda && sudo grub-install /dev/sdb && sudo update-grub && sudo update-initramfs -u -k all 6) sudo apt-get install --reinstall lvm2 grub-pc grub-common 7) adding lvm vgchange -ay to the end of /usr/share/initramfs-tools/scripts/local-top/lvm2 I'm quickly running out of things to try. – isaaclw Jun 21 '14 at 5:27
up vote 6 down vote accepted

So I managed to solve this eventually. There is a problem (bug) with detecting logical volumes, which is some sort of race condition (maybe in my case regarding the fact that this happens inside KVM). This is covered in the following discussion. In my particular case (Debian Squeeze ) the solution is as follows:

  • backup the script /usr/share/initramfs-tools/scripts/local-top/lvm2
  • apply the patch from mentioned bug report
  • run update-initramfs -u

This helped me, hope it'll help others (strangely, this is not part of mainstream yet).

Link to patch: _;filename=lvm2_wait-lvm.patch;att=1;bug=568838

Below is a copy for posterity.

--- /usr/share/initramfs-tools/scripts/local-top/lvm2 2009-08-17 19:28:09.000000000 +0200
+++ /usr/share/initramfs-tools/scripts/local-top/lvm2 2010-02-19 23:22:14.000000000 +0100
@@ -45,12 +45,30 @@

  eval $(dmsetup splitname --nameprefixes --noheadings --rows "$dev")

- if [ "$DM_VG_NAME" ] && [ "$DM_LV_NAME" ]; then
-   lvm lvchange -aly --ignorelockingfailure "$DM_VG_NAME/$DM_LV_NAME"
-   rc=$?
-   if [ $rc = 5 ]; then
-     echo "Unable to find LVM volume $DM_VG_NAME/$DM_LV_NAME"
-   fi
+ # Make sure that we have non-empty volume group and logical volume
+ if [ -z "$DM_VG_NAME" ] || [ -z "$DM_LV_NAME" ]; then
+   return 1
+ fi
+ # If the logical volume hasn't shown up yet, give it a little while
+ # to deal with LVM on removable devices (inspired from scripts/local)
+ fulldev="/dev/$DM_VG_NAME/$DM_LV_NAME"
+ if [ -z "`lvm lvscan -a --ignorelockingfailure |grep $fulldev`" ]; then
+   # Use default root delay
+   slumber=$(( ${ROOTDELAY:-180} * 10 ))
+   while [ -z "`lvm lvscan -a --ignorelockingfailure |grep $fulldev`" ]; do
+     /bin/sleep 0.1
+     slumber=$(( ${slumber} - 1 ))
+     [ ${slumber} -gt 0 ] || break
+   done
+ fi
+ # Activate logical volume
+ lvm lvchange -aly --ignorelockingfailure "$DM_VG_NAME/$DM_LV_NAME"
+ rc=$?
+ if [ $rc = 5 ]; then
+   echo "Unable to find LVM volume $DM_VG_NAME/$DM_LV_NAME"
share|improve this answer

Create a startup script in /etc/init.d/lvm containing the following:


case "$1" in
    /sbin/vgchange -ay
    /sbin/vgchange -an

exit 0

Then execute the commands

# chmod 0755 /etc/init.d/lvm

# update-rc.d lvm start 26 S . stop 82 1 .

Should do the trick for debain systems

share|improve this answer
for those who are wondering, like i was, vgscan searches for volume groups on the system, and vgchange -a makes volume groups available (-ay) or not (-an). – Dan Pritts Jun 16 '14 at 21:30

If vgscan "finds" the volumes, you should be able to activate them with vgchange -ay /dev/volumegroupname

$ sudo vgscan
[sudo] password for username: 
  Reading all physical volumes.  This may take a while...
  Found volume group "vg02" using metadata type lvm2
  Found volume group "vg00" using metadata type lvm2

$ sudo vgchange -ay /dev/vg02
  7 logical volume(s) in volume group "vg00" now active

I am not sure what would cause them to go inactive after a reboot though.

share|improve this answer
Hi, thanks I did exactly that before. But if I reboot we are back to the inactive thing. I tried to mount immediately after activating them but it shuts me with file not found error. – zeratul021 Nov 7 '10 at 23:59
Can be problem with /etc/lvm/lvm.conf, take backup of current file and try to copy lvm.conf from some other system and see if it solves the problem – Saurabh Barjatiya Nov 8 '10 at 10:57

Without any of the configuration details or error messages we'd need to give an actual answer, I'll take a stab in the dark with grub-mkdevicemap as a solution.

share|improve this answer

Assuming you system uses initramfs, there's probably a configuration problem there. You should update your initramfs image that's started at boot time by grub (in Debian you do this with update-initramfs, don't know about other distros).

You could also do this by hand by unpacking initramfs and changing /etc/lvm/lvm.conf (or something like it) in your initramfs image and then repack it again.

share|improve this answer
Hi, thanks for suggestion I will try inspecting them later tonight. Strange thing is that after installing new kernel deb, update initramfs and update grub followed immediately. – zeratul021 Nov 8 '10 at 14:37
something likewise happened to me with two raid arrays that were needed to boot. They didn't start anymore in initramfs, although update-initramfs ran fine. I had to manually change the way mdadm looked for the raid arrays in mdadm.conf and then rerun initupdate-ramfs. – Jasper Nov 8 '10 at 16:47
I commented on post below regarding lvm.conf. I found out that when i run command lvm and then vgscan and vgchange -ay and drop out of initramfs shell I boot like I'm supposed to. So the problem is somewhere in initramfs, that it doesn't activate LVM. Just for the record, /boot is on separate partition. – zeratul021 Nov 9 '10 at 10:33
Your problem is still with update-initramfs not working properly. Maybe you should see if there's an update for initramfs-tools and then try update-initramfs. If this doesn't work, you should still look inside the initramfs image at lvm.conf. – Jasper Nov 9 '10 at 12:33
Sadly I don't know how to configure LVM, all I ever did was during installation. Next hint is taht other virtual machine with exactly same disk layout fails in the exact same way, so I need to dig why LVMs are not activated at boot time. – zeratul021 Nov 10 '10 at 21:45

I had this problem too. In the end this is what seemed to fix it:

diff -u /usr/share/initramfs-tools/scripts/local-top/lvm2-backup /usr/share/initramfs-tools/scripts/local-top/lvm2
--- /usr/share/initramfs-tools/scripts/local-top/lvm2-backup    2014-06-06 19:55:19.249857946 -0400
+++ /usr/share/initramfs-tools/scripts/local-top/lvm2   2014-06-21 01:26:01.015289945 -0400
@@ -60,6 +60,7 @@

 modprobe -q dm-mod

+lvm vgchange -ay
 activate_vg "$ROOT"
 activate_vg "$resume"

Other things I tried:

  1. your patch
  2. diffing /etc/lvm/lvm.conf
  4. GRUB_CMDLINE_LINUX="scsi_mod.scan=sync"
  5. sudo grub-install /dev/sda && sudo grub-install /dev/sdb && sudo update-grub && sudo update-initramfs -u -k all
  6. sudo apt-get install --reinstall lvm2 grub-pc grub-common

I went through and undid the other changes, this is the only one that mattered for me, though it's probably the least elegant.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.