after upgrading from feisty to gutsy, /dev/mapper no longer contains my LVM volume group

[Michael Brunton-Spall]

I used update-manager to update from feisty to gutsy on my server, which has a number of drives mounted on an LVM volume group.
Under fiesty these drives appeared in /dev/mapper as /dev/mapper/data/applications which I added to my fstab to automount as /data/applications.

After running the full upgrade script and rebooting, the machine failed ot fully start because the /dev/mapper/data directory no longer exists (and /home is stored on there).

Running lvs, vgs or pvs correclty shows the logical volumes, physical volumes and volume groups -
root@mibsvr01:/# vgs
  VG #PV #LV #SN Attr VSize VFree
  data 9 5 0 wz--n- 145.39G 21.61G
root@mibsvr01:/# pvs
  PV VG Fmt Attr PSize PFree
  /dev/sdb1 data lvm1 a- 30.59G 1.61G
  /dev/sdc1 data lvm1 a- 9.97G 0
  /dev/sdc2 data lvm1 a- 9.97G 4.94G
  /dev/sdc3 data lvm1 a- 9.97G 9.97G
  /dev/sdc5 data lvm1 a- 9.97G 96.00M
  /dev/sdc6 data lvm1 a- 9.97G 0
  /dev/sdc7 data lvm1 a- 9.97G 0
  /dev/sdc8 data lvm1 a- 34.97G 0
  /dev/sdc9 data lvm1 a- 20.02G 5.00G
root@mibsvr01:/# lvs
  LV VG Attr LSize Origin Snap% Move Log Copy%
  apps data -wn--- 12.00G
  data data -wn--- 4.00G
  downloads data -wn--- 58.00G
  mp3 data -wn--- 44.78G
  root data -wn--- 5.00G
root@mibsvr01:/# ls /dev/mapper
control

Hope that helps

[Michael Brunton-Spall (bruntonspall)]

I tried booting from kernel 2.6.20-15 instead of the newer 2.6.22-11, but is hasn't made a differance, it still cant see the /dev/mapper/data directories

[Michael Brunton-Spall (bruntonspall)]

Downloaded Gutsy Tribe 5 - Server Edition CD, installed from fresh, adding the LVM drives during hte manual partitioning step. Everything worked fine until I rebooted at end of installation, to be met with the same issue, got dropped into a maintenance shell.

I figured this was weird, as I could mount and see the drives during installation, so I had a look to see if there was anything I could do.
Sure enough, with a fresh install, the output from LVS shows that the drives are not actually marked as available. running vgchange -a y data brought the drives online, and they promptly appeared in /dev/data and /dev/mapper/

Rebooting after having done that seems to forget, always fails the fsck, and I need to activate the volume group, and then press Ctrl-D to continue booting.

[Bart Verwilst (verwilst)]

Indeed, the automatically mounting of the volume groups have been disabled in Gutsy so it seems. Which is HIGHLY annoying. Any reason why? Any other methods that got introduced that we don't know about?

Thanks!

[Mathieu De Zutter (mathieu+launchpad)]

The new way of mounting volume groups is through evms.
However, evms does not run nice with the 2.6.22 kernel if you do not manage *all* partitions (including root) through evms.

So your options:
* install evms and run an older kernel (very annoying if you have nvidia graphics)
* install evms and use it also for your root fs (I did not manage to do this)
* make your lvm volumes activate automatically (through udev? rc#.d doesn't seem to work)

[Bart Verwilst (verwilst)]

The _new_ way of mounting is through evms?? IIRC EVMS has been an improvement on LVM1, but has been superseded by LVM2 since then. I dont even think EVMS is currently still under development anymore..

[panos (distratios)]

I ran into exact the same problem when I tried to set up a ext3 partition for LVM. I have no idea what evms is, but the workaround is found in the lvm HOWTO, section 7.2 (http://tldp.org/HOWTO/LVM-HOWTO/initscriptdebian.html).
Installing the init script solved the problem for me. However, I am asking myself why this ***** script is not provided by the lvm2 package, saving me some hours of my time ...

[Bernhard Bock (bernhard-bock)]

I was also hit by this bug. Together with a non-working EVMS (see bug #124641), it really gave me a hard time after upgrading my server...

For me, the workaround was to uninstall the EVMS package and manually put in a startup script to detect the VGs, as panos lined out in the comment above.

[Mark Stinson (markstinson)]

My Fiesty->Gutsy Upgrade wouldn't let me back in after the screensaver kicked in. I had to hard shutdown my machine. Here's an email I just sent to some of my friends (the irony that I've all typed up for you already. LOL)

   1. I booted with the Xubuntu 7.10 alternate CD started rescue mode. No sense going back.
   2. I chose my / partition for the shell and manually mounted all my Logical Disks to there respective mount points (/usr, so forth.) which used /dev/mapper/vg_pool-lv_usr convention
   3. I ran `apt-get upgrade` which after a while told me to run ` dpkg --configure -a`. That completed the Upgrade.
   4. When it rebooted, it still gave me the error about not finding or cannot e2fsck the LVM devices
   5. I checked the /etc/fstab which had them as /dev/mapper/vg_pool-lv_usr (and so forth). When I `ls /dev/mapper` their names had changed to /dev/mapper/lvm2|vg_pool|lv_usr (dashes were now vertical pipes with an extra bit of stuff in the front. What the ??? )
   6. Backed up my fstab and made the corrections with nano editor (no vi available)
   7. It's alive. ... Well, mostly. I have to manually drop back a kernel version to my old version. I guess I still need to do that upgrade from 2.6.16 to 2.6.20. Hopefully, I won't kill it again. I'll be doing it in single user mode.

   So apparently, there was some changes to LVM from the "volume groups - logical volumes" to "disk mgmt | vg | lv". That makes sense so enterprise and other folks can start mixing legacy and future LVM revisions.

UPDATE: I booted the machine with the previous kernel 2.6.16, did an `init 1` for single user. I then re-ran `apt-get upgrade` followed by ` dpkg --configure -a` again. Guess there was some more configuring to do. At the very end it generated the /boot/initrd.img-2.6.22-14-generic. Now I can boot just fine. Now I need to figure out why my X.org is consuming 100% - 135% utilization on my dual core.

Hope this helps you out. Mark S.

[Andreas Moog (ampelbein)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thank you for taking the time to report this bug and helping to make
Ubuntu better. You reported this bug a while ago and there hasn't been
any activity in it recently. We were wondering is this still an issue
for you? Can you try with latest Ubuntu release? Thanks in advance.

 status incomplete
 subscribe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAki1cvoACgkQ06FgkPZwicQXLgCfZiIwNvU3d+m4QZLyhP1Mdnz7
+j4AnjAPKXP6wPfYLnjFBQuyKf5WRr4k
=5cVF
-----END PGP SIGNATURE-----

[Javier Jardón (jjardon)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!