30

I'm using Debian squeeze, and running LVM on top of software RAID 1. I just accidentally just discovered that most of the links under /dev/mapper are missing, though my system seems to be still functioning correctly.

I'm not sure what happened. The only thing I can imagine that caused it was my failed attempt to get a LXC fedora container to work. I ended up deleting a directory /cgroup/laughlin, corresponding to the container, but I can't imagine why that should have caused the problem. /dev/mapper looked (I made some changes, see below) approximately like

orwell:/dev/mapper# ls -la
total 0
drwxr-xr-x  2 root root     540 Apr 12 05:08 .
drwxr-xr-x 22 root root    4500 Apr 12 05:08 ..
crw-------  1 root root  10, 59 Apr  8 10:32 control
lrwxrwxrwx  1 root root       7 Mar 29 08:28 debian-root -> ../dm-0
lrwxrwxrwx  1 root root       8 Apr 12 03:32 debian-video -> ../dm-23

debian-video corresponds to a LV I had just created.

However, I have quite a number of VGs on my system, corresponding to 4 VGs spread across 4 disks. vgs gives

orwell:/dev/mapper# vgs
  VG         #PV #LV #SN Attr   VSize   VFree  
  backup       1   2   0 wz--n- 186.26g  96.26g
  debian       1   7   0 wz--n- 465.76g 151.41g
  olddebian    1  12   0 wz--n- 186.26g  21.26g
  testdebian   1   3   0 wz--n- 111.75g  34.22g

I tried running

 /dev/mapper# vgscan --mknodes

and some devices were created (see output below), but they aren't symbolic links to the dm devices as they should be, so I'm not sure if this is useless or worse. Would they get in the way of recreation of the correct links? Should I delete these devices again?

I believe that udev creates these links, so would a reboot fix this problem, or would I get an unbootable system? What should I do to fix this? Are there any diagnostics/sanity checks I should run to make sure there aren't other problems I haven't noticed? Thanks in advance for any assistance.

orwell:/dev/mapper# ls -la
total 0
drwxr-xr-x  2 root root     540 Apr 12 05:08 .
drwxr-xr-x 22 root root    4500 Apr 12 05:08 ..
brw-rw----  1 root disk 253,  1 Apr 12 05:08 backup-local_src
brw-rw----  1 root disk 253,  2 Apr 12 05:08 backup-video
crw-------  1 root root  10, 59 Apr  8 10:32 control
brw-rw----  1 root disk 253, 15 Apr 12 05:08 debian-boot
brw-rw----  1 root disk 253, 16 Apr 12 05:08 debian-home
brw-rw----  1 root disk 253, 22 Apr 12 05:08 debian-lxc_laughlin
brw-rw----  1 root disk 253, 21 Apr 12 05:08 debian-lxc_squeeze
lrwxrwxrwx  1 root root       7 Mar 29 08:28 debian-root -> ../dm-0
brw-rw----  1 root disk 253, 17 Apr 12 05:08 debian-swap
lrwxrwxrwx  1 root root       8 Apr 12 03:32 debian-video -> ../dm-23
brw-rw----  1 root disk 253, 10 Apr 12 05:08 olddebian-etch_template
brw-rw----  1 root disk 253, 13 Apr 12 05:08 olddebian-fedora
brw-rw----  1 root disk 253,  8 Apr 12 05:08 olddebian-feisty
brw-rw----  1 root disk 253,  9 Apr 12 05:08 olddebian-gutsy
brw-rw----  1 root disk 253,  4 Apr 12 05:08 olddebian-home
brw-rw----  1 root disk 253, 11 Apr 12 05:08 olddebian-lenny
brw-rw----  1 root disk 253,  7 Apr 12 05:08 olddebian-msi
brw-rw----  1 root disk 253,  5 Apr 12 05:08 olddebian-oldchresto
brw-rw----  1 root disk 253,  3 Apr 12 05:08 olddebian-root
brw-rw----  1 root disk 253, 14 Apr 12 05:08 olddebian-suse
brw-rw----  1 root disk 253,  6 Apr 12 05:08 olddebian-vgentoo
brw-rw----  1 root disk 253, 12 Apr 12 05:08 olddebian-wsgi
brw-rw----  1 root disk 253, 20 Apr 12 05:08 testdebian-boot
brw-rw----  1 root disk 253, 18 Apr 12 05:08 testdebian-home
brw-rw----  1 root disk 253, 19 Apr 12 05:08 testdebian-root
Improve this question
2
  • I'll be the first to state the obvious here. Back up your important data on that box immediately, then diagnose whether the box is hosed or not.
    – rfelsburg
    Apr 12, 2011 at 2:25
  • 4
    You should try /etc/init.d/lvm2 start. It did the trick for me (but I was not exactly in your situation).
    – Totor
    Feb 3, 2014 at 13:26

5 Answers 5

Reset to default
54

I just had a similar problem to what you describe, though for me it happened when I was attempting to install the new Ubuntu 11.10 Oneiric Ozelot to an LVM volume. I had done the following to set lvm up on a live boot system (the logical volumes I needed were already present):

apt-get install lvm2
vgscan --mknodes -v

Now lvscan -v showed my volumes but they were not in /dev/mapper nor in /dev/<vg>/. I finally found that I needed to activate the volume group, like so:

vgchange -a y <name of volume group>

The above command created all the missing device files for me. Now I could start the install program and it would find the lvm volumes and allow me to install to them.

Finding this information on google was hard, so I write this answer in the hope that others will have an easier time of it -- hence the in-depth context and namedropping.

Though not part of the question, for completeness I'll add that in the above situation (Ubuntu LVM install) you need to add lvm2 to the initrd of the newly installed system once it's done installing, or it won't boot. Your new system should be set up for you in /target, but if it is not, do it manually like this:

mount /dev/vg/new_root /target
mount /dev/sdx1 /target/boot       # important
mount -o bind /proc /target/proc
mount -o bind /sys /target/sys
mount -o bind /dev /target/dev
mount -o bind /dev/pts /target/dev/pts

I needed to do this to make networking work in the chroot, which I'll come to next:

cp /etc/resolv.conf /target/etc/

Now chroot to the new system and install lvm2:

chroot /target
apt-get install lvm2

Notice that it runs update-initramfs. Now just type exit and reboot, and your system should boot properly.

Improve this answer
1
  • Activating volume group worked for me. It was inactive because I removed cache logical volume before reboot.
    – n.podbielski
    May 7, 2021 at 13:43
23

These days /dev is on tmpfs and is created from scratch each boot by udev. You can safely reboot and these links will come back.

You should also find LVM symlinks to the /dev/dm-X nodes in the /dev/<vg> directories, one directory for each volume group. However, those nodes re-created by vgscan --mknodes will also work fine, assuming they have the right major/minor numbers - and it's a safe assumption they were created properly.

You can probably also get udev to re-create the symlinks using udevadm trigger with an appropriate match, testing with --dry-run until it is right. It hardly seems worth the effort though when a reboot will fix it too.

Improve this answer
4
  • Thanks for the answer. One request for clarification: when you say "those re-created nodes will also work fine" you are referring to "the /dev/dm-X nodes", right? What do you mean by "re-created" here, and also, "also work fine" in what sense? Work fine for what? Excuse my slowness. I assume all the LVM devices are recreated from information stored in /etc/lvm/archive?
    – Faheem Mitha
    Apr 12, 2011 at 12:10
  • I mean the nodes created by vgscan --mknodes. They aren't the original symlinks, but are the block dev nodes the symlinks would have pointed to. You should find, for example, that /dev/olddebian/root is a symlink to ../dm-3, which will have the same major:minor numbers as the re-created /dev/mapper/olddebian-root.
    – camh
    Apr 12, 2011 at 12:31
  • Thanks for the clarification. I checked that what you say was correct for /dev/mapper/debian-video, which was one of my two intact symbolic links. :-) I just did a read about major/minor device numbers. Thanks for the educational answer.
    – Faheem Mitha
    Apr 12, 2011 at 19:59
  • Only thing that worked for me was shutdown -r now :(
    – user1133275
    Jan 16, 2021 at 19:17
9

This also worked for me.

vgchange -a y -name of volume group-

Following a kernel patch my RHEL system failed to reboot. Complaining of a missing /dev/mapper/VG-lv file.

Booted to single-user and commented out of /etc/fstab. Once online I found my encrypted disk was showing as "unkown device" using pvs.

Fixed this but still no device files for the Volume group. Running the above command recreated the device mapper files and allowed me to mount.

Improve this answer
2
  • Thank you! God forbid you have to take an LVM offline so you can use mdadm without getting locking errors. 6 hours later I finally figure out how to bring it back online via vgchange. LVM is truly a heavily fragmented and poorly documented piece of software.
    – Brain2000
    Jun 19, 2020 at 17:02
  • I'm using LVMs in guestfish and qemu and this is EXACTLY what I needed. It took me almost a day to find this post, but thank you very much. To anyone else creating LVMs on a virtual disk, you have to do this in order to see them in the guest system after it boots.
    – Raj
    Mar 17, 2021 at 20:40
3

I had a similar problem after upgrading my debian. During the reboot, this message appeared to me:

Unable to find LVM Volume. 
/dev/mapper/debian-root does not exist.

I found the solution here:

cryptsetup luksOpen /dev/sda5 lvmsys
lvm
lvm> vgscan        ## scan for volume groups
lvm> vgchange -a y ## activates the volume groups

And voilà, it rebooted nicely after this.

Improve this answer
0

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616689 is relevant here. It's to do with timeouts such that lvm root does not appear in time.

Improve this answer
1
  • 2
    It might be worth posting the highlights, or important information in-line, as is customary.
    – HalosGhost
    Jun 27, 2014 at 22:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .