From: Zdenek Kabelac <email@example.com>
To: LVM2 development <firstname.lastname@example.org>,
Eric Ren <email@example.com>,
LVM general discussion and development <firstname.lastname@example.org>
Subject: Re: [linux-lvm] [lvm-devel] Aborting. LV mythinpool_tmeta is now incomplete
Date: Fri, 12 Apr 2019 12:05:33 +0200 [thread overview]
Message-ID: <email@example.com> (raw)
Dne 11. 04. 19 v 19:33 Eric Ren napsal(a):
> Hi Zdenek,
>> Anyway - proper reproducer with full -vvvv log would be really the most
>>> explanatory and needed to move on here.
> The activation error is reproduced once more. Please see lvm2.log attached.
> Please search the error message like this:
> $grep -rn Aborting lvm2.log
> ./lvm2.log:1386:activate/dev_manager.c:2459 lvcreate Aborting. LV
> mythinpool_tmeta is now incomplete and '--activationmode partial' was
> not specified.
> $grep -rn "Failed to suspend" lvm2.log
> ./lvm2.log:1399:metadata/lv_manip.c:7416 lvcreate Failed to suspend
> thin snapshot origin vg0/6.
Looking at provided log file - the system seems to be using some weird udev
rule - which results in generating strange /dev/__ symlinks.
My assumption can be the udev rule has missed to set some variable properly
so instead of /dev/xxxx__yyyyy you end with /dev/__
There are already visible some other devices like i.e.:
/dev/disk/by-id/virtio-instance-store0___O-part1 pointing to /dev/vda1
From log is visible lvm2 wants to actually store metadata on /dev/__
so for some reason thins symlink was preffered over real mknode device.
So the fact there is missing device for _tmeta comes from the fact,
there is probably mess in /dev directory and lvm2 becuase can't cope better
with this particular case.
IMHO fixing the udev rules should be enough to get things running properly.
Since the log shows tons of 'nbd' device - it could be some race in udev rule
processing as well.
The selection of preferred name in lvm2 is somewhat out-of-data and now it
would be probably always better to prefer real node name over any symlink
at the price of less explanatory logging but with higher chance of figure out
real state of system.
But ATM it's important to figure out how this situation happens.
BTW - you can always setup filter (and you really SHOULD in this case),
to whitelist devices for scanning to avoid similar issues.
I assume you want to set something like a|/dev/vd|, r|.*|
Also you should collect udev rules and post them here so we can check
which rule could be suspected.
next prev parent reply other threads:[~2019-04-12 10:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-11 0:27 [linux-lvm] Aborting. LV mythinpool_tmeta is now incomplete Eric Ren
2019-04-11 10:01 ` Eric Ren
2019-04-11 11:21 ` [linux-lvm] [lvm-devel] " Zdenek Kabelac
2019-04-11 11:03 ` [linux-lvm] " Zdenek Kabelac
2019-04-11 11:26 ` Eric Ren
2019-04-11 11:32 ` Zdenek Kabelac
2019-04-11 11:49 ` Eric Ren
2019-04-11 12:12 ` Zdenek Kabelac
2019-04-11 13:09 ` Eric Ren
2019-04-11 13:13 ` Zdenek Kabelac
[not found] ` <CAKM4Aez9H=GuRLK0EDJTwpb7j34tCu1aY4dS5_L4saDGERestg@mail.gmail.com>
2019-04-11 17:33 ` Eric Ren
2019-04-12 10:05 ` Zdenek Kabelac [this message]
2019-04-12 10:42 ` [linux-lvm] [lvm-devel] " Eric Ren
2019-04-12 13:44 ` [linux-lvm] " Zdenek Kabelac
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).