On 01/29/2016 09:08 AM, Laurent Bigonville wrote:
> On Thu, 21 Jan 2016 10:06:59 +0100 Peter Rajnoha
> wrote:
>> That's a bug in configure script. It should be fixed by this upstream
>> patch:
>>
>>
> https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=43
That's a bug in configure script. It should be fixed by this upstream
patch:
https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=43b436398ec81c8d0a2dbd2062ce864997d22f26
--
Peter
> `dmsetup udevcookies` lists no cookies. Adding `dmsetup
> udevcomplete_all` before `dmsetup remove` doesn't help.
Well, if dmsetup remove is waiting on a cookie as the log displays,
"dmsetup udevcookies" should display it (otherwise the dmsetup
remove wouldn't hang).
You need to call dmsetup ud
On 10/13/2015 06:20 AM, Nick Black wrote:
> Package: libdevmapper-dev
> Version: 2:1.02.104-1
> Severity: important
>
> Dear Maintainer,
>
> Use of pkg-config with libdevmapper isn't working due to a
> Requires.private dependence on librt. There's no librt.pc file, so this
> breaks:
>
> [skynet]
On 09/02/2015 07:35 PM, Andreas Henriksson wrote:
> Hello Alasdair G Kergon.
>
> I'm mailing you because of an issue I've run into which I think comes
> from your commit:
> https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=3cd644aeb5cac432a92ad50584973a3430168ed6
>
> On Debian there's librt.s
Just noticed this option is not yet documented!
I've filed a report for udev guys to add mention
this in the man page and describe it a bit since
it's quite important and yet it's hidden functionality
if not documented:
https://bugzilla.redhat.com/show_bug.cgi?id=1247210
--
To UNSUBSCRIBE, ema
On 07/27/2015 04:12 PM, Peter Rajnoha wrote:
> It's the OPTIONS+="db_persist" that needs to be used in initramfs
> for MD devices. This marks udev db records related to this device with
> sticky bit then which is then recognized by udev code and the udev
> db state is
On 07/27/2015 03:57 PM, Peter Rajnoha wrote:
> That's how it was supposed to work. I can imagine the problematic
> part here may be the transfer of the udev database state from initramfs
> to root fs - there is a special way that udev uses to mark devices
> so that the udev db s
On 07/25/2015 09:34 PM, Bastian Blank wrote:
> Hi Peter
>
> Currently I think that all this problems are related to missing or
> broken pvscan --cache calls.
>
> I found one problematic case regarding coldplug; I believe Redhat does
> not longer use this code path. In none of my tests the "artif
On 07/10/2015 01:48 AM, Josh Triplett wrote:
> Package: lvm2
> Version: 2.02.122-1
> Severity: grave
> File: /lib/systemd/system/lvm2-monitor.service
>
> On a laptop with encrypted root and swap, I now get a minutes-long delay at
> boot
> time, due to lvm2-monitor. Here's the complete set of mes
I think this is fixed already with this upstream patch (appeared in lvm2
v2.02.115):
https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=f94f8463b0d3dddaa0e429123aba673d106f783e
Peter
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Troub
On 04/23/2015 04:12 PM, Michael Biebl wrote:
> Am 23.04.2015 um 11:40 schrieb Peter Rajnoha:
>> On 04/23/2015 11:04 AM, Michael Biebl wrote:
>>> Looking at the udev rule shipped by Debian's lvm2 package, it has:
>>>
>>> 69-lvm-metad.rules:ACTION!="
On 04/23/2015 12:22 PM, Michael Biebl wrote:
> Am 23.04.2015 um 12:13 schrieb Michael Biebl:
>> /dev/md0 has major:minor 9:0, but there is no
>> lvm2-pvscan@9:0.service instance.
>>
>> lvm2-pvscan@8:35.service points at /dev/sdc3, which hosts /dev/vg.
>>
>> Why is no lvm2-pvscan@9:0.service instanc
On 04/23/2015 11:53 AM, Michael Biebl wrote:
> Am 23.04.2015 um 11:40 schrieb Peter Rajnoha:
>> In systemd environment, there should also be this rule
>> which updates lvmetad for each new PV that appears in the system:
>>
>> ENV{SYSTEMD_WANTS}="lvm2-pvscan@$maj
On 04/23/2015 11:04 AM, Michael Biebl wrote:
> Looking at the udev rule shipped by Debian's lvm2 package, it has:
>
> 69-lvm-metad.rules:ACTION!="remove", ENV{LVM_PV_GONE}=="1",
> RUN+="/bin/systemd-run /sbin/lvm pvscan --cache $major:$minor",
> GOTO="lvm_end"
>
That rule is to cover immediate r
On 04/23/2015 10:57 AM, Michael Biebl wrote:
> On Fri, 02 Jan 2015 12:13:06 +0100 Peter Rajnoha
> wrote:
>> So this just seems that the initramfs scripts and systemd units
>> are not set up properly - this needs to be inspected:
>>
>> 1) is lvm2-lvmetad.socket
On 01/13/2015 09:43 AM, chrysn wrote:
>> I'd say the best "who-uses" tool in this case is "lsblk" [...]
>>
>> LVM itself already uses this tool within helper "blkdeactivate" script
>> [...]
>
> so you see a chance that lvm could delegate the diagnoistic messages for
> where to find the offending m
I'd say the best "who-uses" tool in this case is "lsblk" - it's directly
a part of util-linux which is everywhere and it shows quickly the block
device tree as well as mount status (it just looks at sysfs info and
provides it in nice human readable form, machine readable form is also
possible thoug
The way the LV with root FS is activated depends on distribution,
but most of the time, this LV is not activated automatically as
lvmetad is not running in initramfs. Therefore, it's a matter of
initramfs script to activate the LV with root FS directly with
direct vgchange/lvchange -aay call.
For
Is there "dmeventd -R" called in update script? This one should be
called each time dmeventd is updated to pick up any changes
in libdevmapper (the dmeventd is reexecuted and the monitoring
state is transferred from the old dmeventd instance).
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...
On 08/23/2013 04:03 PM, Bastian Blank wrote:
> On Fri, Aug 23, 2013 at 03:22:18PM +0200, Peter Rajnoha wrote:
>> On 08/23/2013 01:59 PM, Bastian Blank wrote:
>>> Second the init-script and the generated unit have different names, so
>>> systemd won't be able to con
On 08/23/2013 01:59 PM, Bastian Blank wrote:
> Second the init-script and the generated unit have different names, so
> systemd won't be able to consider them equal. I have no idea how this
> really works anyway.
The aim of the lvm2-activation-generator is to:
- do nothing if global/use_lvmetad=
On 10/03/2012 12:13 PM, Michael Stapelberg wrote:
> To give a bit more information about how I reproduce this issue:
>
> lvcreate -n snap_web -L 1G -s plana/domu-web
> kpartx -a /dev/mapper/plana-snap_web
...
> kpartx -d /dev/mapper/plana-snap_web
Please, try "kpartx -s", where -s is
On 10/11/2010 12:24 PM +0100, Sam Morris wrote:
> It appears that each lvcreate/lvremove operation creates four cookies,
> but 'dmsetup udevcomplete' is run only once, thereby leaking three
> cookies per operation.
Can you run that lvcreate/lvremove again with "-" debug messages
together with
On 08/18/2010 10:54 AM +0100, Marco d'Itri wrote:
> After I started not deleting the initramfs database as you asked,
> I received multiple bug reports like this one.
> Version of LVM in Debian is 2.02.66-2, please advise.
>
>> After upgrade from 160 to 161, udev doesnt create lvm volumes symlinks
Dňa 28.07.2010 21:50, Christoph Anton Mitterer wrote / napísal(a):
> I've recently read several comments by Milan Broz (dm-crypt realted)
> etc. that the rules have vastly improved and changed over time, and
> fixed many problems...
>
> So I guess making sure that we got all that changes is worth
Dňa 28.07.2010 12:07, Christoph Anton Mitterer wrote / napísal(a):
> The current version in sid seems to be pretty much outdated.
> At least version 2.2.02.70 is available.
Just one important note regarding the udev support and the udev rules
shipped since version 2.02.68. From the lvm2 upstream
On 04/07/2010 03:24 AM, Celejar wrote:
> Eventually, I noticed that after a suspend / resume cycle, mount now shows
> that
> the snapshot volume is mounted where the original should be:
Not exactly this case, I suppose, but maybe it's worth mentioning because
it's very similar...
There's a flag
On 04/07/2010 03:24 AM, Celejar wrote:
> I'm seeing the same problem trying to remove a snapshot volume. It is not
> mounted, but it can't be removed:
>
> ~# lvremove /dev/lizzie/var_backup
> Can't remove open logical volume "var_backup"
>
> ~# lvchange -a n /dev/lizzie/var_backup
> Can't
On 05/15/2010 12:35 PM, Sheridan Hutchinson wrote:
> In the interim is there any known work-around for this?
>
> It's a bit of a jip because my / file system initially mounts as read only.
>
Well, it should be just a warning, it shouldn't break anything.
As for the warning message removal, the o
On 05/14/2010 10:03 AM, QuadCEM wrote:
> It might be related to dmsetup ... I assumed it was udev because the
> warnings started appearing right after I upgraded udev to 154-1. Plus,
> the full warning said:
>
> udevd-work[180]: kernel-provided name 'dm-0' and
> NAME='/mapper/sdb2_crypt' disagree
On 02/14/2010 01:06 AM, Bastian Blank wrote:
> On Sat, Feb 13, 2010 at 02:28:12PM -0800, Kees Cook wrote:
>> In debian/tree/lvm2/lib/udev/rules.d/56-lvm.rules, several internal LVM
>> names are checked so that they will be skipped for symlinks. I think that
>> _mlog (for the mirror log) and -cow &
On 09/07/2009 08:55 PM, Bastian Blank wrote:
> Package: dmsetup
> Version: 2:1.02.36-4
> Severity: important
>
> The device-mapper udev rules currently produces UUID and LABEL entries
> for all devices, including the LVM specific -real device and snapshot
> devices.
>
> [...]
>
> So the LVs test
On 08/19/2009 05:15 PM, Bastian Blank wrote:
> On Wed, Aug 19, 2009 at 04:50:09PM +0200, Marc Haber wrote:
>> Since the last update, my crypto devices are recognized by the system as
>> /dev/dm-xx, for example in fsck and in df's output:
>> /dev/dm-15 12G 11G 565M 96% /mnt/home
>> /
34 matches
Mail list logo
