archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <>
To: LVM general discussion and development <>,
	Christoph Pleger <>
Subject: Re: [linux-lvm] dmsetup says "Device does not exist", though it exists
Date: Wed, 14 Aug 2019 13:07:45 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Dne 14. 08. 19 v 9:22 Christoph Pleger napsal(a):
> Hello,
>>> I have a volume group with 20 logical volumes. Only the last one of these 
>>> volumes has a strange problem with dmsetup, shown by these commands and 
>>> output on the command line:
>>> root@host:/home/linux# /sbin/dmsetup info -c -o name --noheadings /dev/vg/lv20
>>> Device does not exist.
>>> Command failed
>>> root@host:/home/linux# lvdisplay -c /dev/vg/lv20
>>>    /dev/vg/lv20:vg:3:1:-1:0:4194304:512:-1:0:-1:253:19
>>> root@host:/home/linux# mount /dev/vg/lv20 /mnt
>>> root@host:/home/linux# ls /mnt
>>> lost+found data1 data2
>>> That is, dmsetup says "Device does not exist" about a logical volume, 
>>> though the volume exists and is operating normally. What is the possible 
>>> problem here?
>> Have you tried  strace ?
> I attached the relevant lines of the strace output. I am really wondering what 
> is happening there:
> 1. A stat() on /dev/mapper/lv20 is performed, though I requested 
> /dev/mapper/vg-lv20
> 2. A stat() on/dev/mapper/vg-lv15-real is performed. What does this have to do 
> with lv20 (after I wrote what is at number 3, I know)
> 3. I do not even know where /dev/mapper/vg-lv15-real is coming from. I created 
> a logical volume named lv15, but none named lv15-real. And really, 'ls -l 
> /dev/vg/' does not list lv15-real, but 'ls -l /dev/mapper' lists vg-lv15-real 
> and shows that is has the same link target /dev/dm-18 as lv20.
> 4. Though stat() found /dev/mapper/vg-lv15-real, ioctl() says that this device 
> does not exist.
>> Kernel version, lvm version,  distribution... ?
> Kernel Debian amd64 4.9.168-1+deb9u2, LVM version 2.03.02(2), Debian 9 (stretch)


So are you actually trying to access not a 'normal' LV - but an LV under 
snapshot ?

Debian is using it's own modified udev-rules - so I can't really tell without
exactly looking what sort of rules are running there.

You can try to provide   'lvchange -ayvvvv' debug trace when you activate such 
LV and you can enable verification of udev rule processing with lvm.conf option:

         verify_udev_operations = 1

That should 'create'  missing links if they were not created by udev.

NOTE: this is a cruel hack - nothing I'd advice to use normally - since udev 
rules should handle this case normally - but it can give us some hints,
where the issue could be buried-in.

So try above steps and check if the  LV links are in  /dev/vgname dir.



  reply	other threads:[~2019-08-14 11:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-13  7:11 [linux-lvm] dmsetup says "Device does not exist", though it exists Christoph Pleger
2019-08-13 13:54 ` Zdenek Kabelac
2019-08-13 21:25   ` Bernd Eckenfels
2019-08-14 11:09     ` Zdenek Kabelac
2019-08-14  7:22   ` Christoph Pleger
2019-08-14 11:07     ` Zdenek Kabelac [this message]
2019-08-14 12:49       ` Christoph Pleger
2019-08-14 13:06       ` Christoph Pleger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).