On Sun, Jan 21, 2018 at 10:09:14AM +0100, Andreas Henriksson wrote:
> The fsadm(.sh) script does indeed invoke both tune2fs and resize2fs
> under certain circumstances, so from a laymans view there should
> definitely be a dependency added.
That's backwards.
*If* you are using ext (for example)
On Fri, Jul 31, 2015 at 09:50:08AM +0200, Laurent Bigonville wrote:
In the global section of the configuration file, it seems that the
value of the etc parameter is not expanded as exected:
etc = ${exec_prefix}/etc
This probably need to be fixed.
Drop ${exec_prefix} here perhaps?
rules:
On Fri, Jul 03, 2015 at 11:50:39PM +0200, Julius Seemayer wrote:
Please tell me if/how I can help to further debug this issue.
1) People need to see the complete debug output from the failing command with
- added. That is what enables people to reproduce issues.
2) There have been a lot
On Wed, Sep 17, 2014 at 01:44:52PM -0700, Mike Bird wrote:
Version: 2.02.95-8
From an upstream point of view, that's a pretty old release now
and there have been numerous improvements and fixes to the
relevant allocation code.
Two choices:
Use a more up-to-date version and there's a good
On Wed, Feb 05, 2014 at 11:15:14PM +0100, Miquel van Smoorenburg wrote:
See the messages posted in December 2013 at
https://bugzilla.redhat.com/show_bug.cgi?id=862085 .
I'm not quite sure what the best course of action is now.
Give the bugzilla a nudge.
Alasdair
--
To UNSUBSCRIBE, email
On Sun, Aug 25, 2013 at 06:21:45PM +0200, Bastian Blank wrote:
All the other generators do the same, they use predictable filenames in
/tmp if there is no argument provided. Please fix this.
An alternative (restricted access) directory argument is always supplied
when the system invokes this
On Mon, Jun 24, 2013 at 05:17:21PM +0200, Frank Steinborn wrote:
What i basically want to ask is - are there any ETAs possible when this
will be resolved? We are seriously considering a downgrade to squeeze. That
would be a _huge_ pain, though.
I made some suggestions further back on the bug
On Thu, May 09, 2013 at 11:57:18PM +0200, Helmut Grohne wrote:
On Thu, May 09, 2013 at 06:04:51PM +0100, Alasdair G Kergon wrote:
How are you ensuring the passphrase is securely handled and no remnants
of it remain in memory or on disk?
I hope that it is ok to quote your question
On Thu, Mar 21, 2013 at 03:34:30AM -0400, Daniel Dickinson wrote:
On Mon, 4 Mar 2013 23:48:12 +
Alasdair G Kergon a...@redhat.com wrote:
The upstream uevent-driven activation upstream should address that:
Are these post-wheezy features? Or undocumented?
Upstream
LVM itself has supported nesting for a long time.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Mon, Mar 04, 2013 at 06:26:32PM -0500, Daniel Dickinson wrote:
However, it seems that /dev/vg is not created for the nested volume
group by the /etc/init.d/lvm2 initscript, and the nested volume group is
not started on boot.
A second vgscan / vgchange -ay starts it.
The upstream
On Tue, Jan 15, 2013 at 04:25:18PM +0100, Oskar Liljeblad wrote:
After several tries, I managed to reproduce the problem. This time I ran
lvremove - -f /dev/vg1/backup, and the output is attached. I hope you
can make some sense out of it.
#libdm-deptree.c:1547 Unable to deactivate open
On Tue, Jan 15, 2013 at 05:09:34PM +0100, Oskar Liljeblad wrote:
Do you know which rules?
It's hard to debug piecemeal: the rules work together as a whole.
Also look for 'watch' rules in other rule files that might be triggering
incorrectly. (They should ignore this private lvm device.)
Are
On Mon, Jan 14, 2013 at 03:22:26PM +0100, Petr Nosek wrote:
Package: lvm2
Version: 2.02.95-4
setting up lvm volume groups
mlock failed cannot allocate memory
munlock failed
If you don't have this patch installed, try it:
Clustered lvm remains fully supported upstream and a new experimental
version is even under development (using sanlock).
If the current maintainer chooses not to maintain it in Debian any more,
then perhaps a new maintainer would step forward and package it
separately? Otherwise you could switch
On Tue, Jan 08, 2013 at 10:10:07PM +0100, Markus Raab wrote:
--ignoremonitoring seems to be added for lvcreate, but not for lvremove in
squeeze. Maybe lvm2 should recommend the package dmeventd, because without
dmeventd installed most lvm2 commands issue the warning:
/sbin/dmeventd:
On Tue, Oct 23, 2012 at 08:24:11PM +0200, Laurent Bigonville wrote:
Package: lvm2
Version: 2.02.95-4
Severity: important
I'm not sure if this should be reported against the LVM package or
LVM
Today I've tried to move data[0] between my old HD to my new SSD. I first
set issue_discards = 1
On Mon, Aug 13, 2012 at 12:25:04PM +0200, Miquel van Smoorenburg wrote:
This patch makes sure that disks with signatures of one of these
metadata formats are also filtered out. To minimize the chance of
regressions, it only does this if md is actually running (i.e.
/proc/mdstat is present).
On Sun, May 27, 2012 at 02:42:14AM +0200, Simon Ruderich wrote:
- CLDFLAGS=$CLDFLAGS -Wl,--version-script,.export.sym
+ CLDFLAGS=$LDFLAGS $CLDFLAGS -Wl,--version-script,.export.sym
What are typical contents of the LDFLAGS environment variable in Debian?
- Which cmdline
Logged upstream as https://bugzilla.redhat.com/820203
Alasdair
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Maybe some udev interaction.
dmsetup info -c
dmsetup table
dmsetup status
will show the current device-mapper state
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Mon, Nov 21, 2011 at 03:56:55PM -0800, dblack wrote:
In other words, the idiot-proofing is broken and this could easily lead to an
LV being deleted and data loss.
Grave?!
A known 'feature' - the code's been like that for about ten years now
and I've never heard of any 'idiot' being caught
On Fri, Nov 04, 2011 at 12:31:28AM +, Paul LeoNerd Evans wrote:
root@ina:~# lvrename vg_ina/home backups
Works OK for me with upstream code.
Alasdair
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
On Fri, Nov 04, 2011 at 01:07:04AM +, Alasdair G Kergon wrote:
On Fri, Nov 04, 2011 at 12:31:28AM +, Paul LeoNerd Evans wrote:
root@ina:~# lvrename vg_ina/home backups
Works OK for me with upstream code.
Wrong. It fails upstream too.
Alasdair
--
To UNSUBSCRIBE, email to debian
On Fri, Nov 04, 2011 at 01:12:39AM +, Alasdair G Kergon wrote:
Wrong. It fails upstream too.
Not thoroughly tested, but probably fix along these lines.
I.e. some recursion is missing.
Alasdair
--- lv_manip.c 3 Nov 2011 15:46:51 - 1.319
+++ lv_manip.c 4 Nov 2011 01:24:26 -
On Sun, Sep 04, 2011 at 06:14:23PM +0200, Witold Baryluk wrote:
No mention of -j, -m. Also man page doesn't
show anything.
The message gets it wrong - neither j nor m should be mentioned in it now.
Will be fixed in next upstream release.
Alasdair
--
To UNSUBSCRIBE, email to
On Sun, Jul 24, 2011 at 04:52:55PM +0100, Ian Jackson wrote:
Therefore, how about we retain this bug for the parse error problem
(about which I don't currently have any useful idea).
Run lvm with full debugging output (-) and you should be able to
see which device the errors refer to from
On Sun, Jul 24, 2011 at 05:25:07PM +0100, Ian Jackson wrote:
should activate the underlying lv if that's necessary. Or at the very
least there should be some way to ask lvchange/vgchange to do so.
So the real bug is in the lvm tools themselves, not in the initramfs
scripts.
This could
What snapshot targets does your kernel contain?
(run 'dmsetup targets' and check for a line starting 'snapshot-merge')
(Error messages got improved in later upstream releases.)
Check your kernel message log for any related errors.
Run the command with - for more detailed information about
On Fri, Jan 07, 2011 at 03:49:14AM +0100, Michael Biebl wrote:
(*) If upstream would have provided a git repo I probably would have tried a
git
bisect.
http://sourceware.org/git/?p=lvm2.git;a=summary
Alasdair
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a
On Thu, Dec 09, 2010 at 08:46:50AM +0100, Goswin von Brederlow wrote:
In what case does it break?
That's the wrong question:)
You should ask: Under what conditions are its hard-coded assumptions
about LVM metadata true?
Alasdair
--
To UNSUBSCRIBE, email to
/etc/lvm has several functions.
Read-only config - leave it where it is.
cache_dir - in general can be cleared on each boot so a tmpfs location
would be fine or /var/cache or something
Metadata backups
ideally would be stored persistently outside lvm but otherwise
/var/backups sounds OK
(The
On Sun, Dec 05, 2010 at 05:11:19AM +0300, Andrew Shirayev wrote:
Package: lvm2
Version: 2.02.39-8
Severity: critical
Justification: causes serious data loss
Bug fixed upstream in version 2.02.46.
Other not so serious pvmove issues fixed in 2.02.55, 2.02.61 and 2.02.74.
Please use a newer
On Mon, Dec 06, 2010 at 04:29:57PM +0100, Maik Zumstrull wrote:
As far as I can see, all lvm2 block devices are owned by root:disk and 0660
and
there is no easy way to change it. chown/chmod is lost on reboot when udev
recreates the node. Writing your own udev rules is very iffy, as you would
If the complex processing doesn't work for everyone then yes, simplify
it and activate everything always.
To do it the other way you need logic something like:
Every time you boot, check if the stack of devices necessary to be
activated has changed, and if so, update the information for use
On Sat, Oct 09, 2010 at 12:36:03PM +0100, Sam Morris wrote:
Version: 2.02.39-8
day. A few days after upgrading to device mapper 2:1.02.48-3, the backup
I don't recall reports of any similar problem with any upstream versions of
this code but it's trival to perform this specific test to double
To view the dm semaphores use 'dmsetup udevcookies'.
To delete all dm semaphores use 'dmsetup udevcomplete_all' (don't run that
while there are any other lvm or dm processes running).
'man dmsetup' has a little more information.
Alasdair
--
To UNSUBSCRIBE, email to
On Fri, Sep 17, 2010 at 12:29:35PM +0200, Marc Lehmann wrote:
I think pvcreate should have some kind of force option that lets one write
or restore a pv header no matter what - the tool already has support
for restore operations, and this should not be thwarted in emergency
situations.
I'm
On Wed, Jul 28, 2010 at 12:07:48PM +0200, Christoph Anton Mitterer wrote:
The current version in sid seems to be pretty much outdated.
At least version 2.2.02.70 is available.
And I'm preparing another release as I write this with some
important fixes, so go for 2.02.71.
Alasdair
--
To
On Wed, Jul 28, 2010 at 11:35:38AM +0100, Alasdair G Kergon wrote:
And I'm preparing another release as I write this with some
important fixes, so go for 2.02.71.
Make that 2.02.72 - I decided to divide the release into two.
Version 2.02.72 - 28th July 2010 [CVE-2010-2526
On Thu, Jun 24, 2010 at 12:47:49AM +0200, Christoph Anton Mitterer wrote:
It seems that the current Where a list of VGs is required but is left empty,
a
list of all VGs will be substituted. is also true for LVs (checked it with
lvdisplay, which seems to lists all LVs).
Yes
- Also
On Sun, Jun 13, 2010 at 10:42:14PM +0200, Thomas Koch wrote:
I've updated by accident (lack of better knowledge...) only
libdevmapper, but not dmsetup. Afterwards my system didn't boot anymore:
The package manager should enforce updating the packages together.
It makes no sense to have a
Try this upstream patch:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/libdm/libdm-common.c.diff?cvsroot=lvm2r1=1.95r2=1.96
Alasdair
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
If this is LVM2, use pvs, vgs or lvs for queries - it should be simpler!
See man pages for how to control output format. Remember PVs can move
on booting - it's the UUIDs found on the devices that matter, not the device
names, so detection/waiting must be done during the actual boot.
Latest
On Tue, Mar 30, 2010 at 09:04:54PM +0200, Zdenek Kabelac wrote:
I'd like to know for curisity why
there is need for this patch at all?
Historic perhaps, dating from some time when upstream detection wasn't
working properly for Debian?
Alasdair
--
To UNSUBSCRIBE, email to
On Mon, Mar 01, 2010 at 01:35:43PM +0100, Gabriel Andreas wrote:
If host tag settings in lvm.conf are enabled
lvm dumpconfig doesn't show the tags section.
Forward to upstream (fedora devel) bugzilla if you want proper tracking.
There's no 'quick fix' but with a bit of effort dumpconfig could
cmirror is now implemented as a userspace component that uses a generic
upstream kernel module that allows you to write a mirror log in userspace.
I recently added it to Fedora as an lvm2 subpackage, so I suggest copying
something from there:
On Thu, Feb 11, 2010 at 01:17:06AM -0800, Kees Cook wrote:
Attached patch fixes the issue.
+ m0 = strncmp(path0, /dev/block/, 11);
+ m1 = strncmp(path1, /dev/block/, 11);
/dev should not be hard-coded. Use cmd-dev_dir so its location can
be changed through lvm.conf.
(The test suite
On Tue, Feb 09, 2010 at 07:39:10PM +0100, Michael Biebl wrote:
I guess only upstream can answer that sufficiently.
This is the first released version of the interface. The current intention is
to permit backwards-compatible extensions in subsequent upstream releases
without changing the version
The FHS does not cover the general situation adequately IMHO, so you have to
choose your own compromise.
If your root is read-only, then change your lvm.conf to place the default
backup location somewhere else that is writeable.
What you *should* do is backup those backups to a location
If Debian wants to have a go at moving these files about, there are
settings available in lvm.conf to do that.
But it's an unnecessary overhead, not trivial to get the scripts right,
introduces new failure modes (and recovery paths) and you might do
better discussing revising the FHS to cater
Upstream lvm2/dm continues to support systems that do not use udev and
we have no plans to change that at the moment. Even on a system with udev
installed, if it's not running, lvm2 is supposed to detect that and still
work like it did before. (There are also manual options - see udev_sync in
On Sat, Oct 24, 2009 at 11:52:36PM +0200, Vincent Fourmond wrote:
I'm unsure whether this should be attributed to cryptsetup or pmount:
maybe simply setting the real user ID to root before launching
cryptsetup would do the trick. In principle, the security risk is hardly
greater with UID =
On Sat, Sep 19, 2009 at 03:18:41PM +0200, Elrond wrote:
Moving inside the same PV (for example to reduce
fragmentation) does not seem to be supported at all. I
usually have to do that by moving the PEs first to another
PV and then back.
--alloc anywhere
Alasdair
--
a...@redhat.com
--
On Wed, Aug 19, 2009 at 05:15:13PM +0200, Bastian Blank wrote:
Alasdair: Does Red Hat solve that problem somehow?
This stuff is about to all change.
Apps with hard-coded naming logic (like mount?) may then need updating.
Alasdair
--
To UNSUBSCRIBE, email to
On Thu, Sep 03, 2009 at 01:53:02AM +0200, Cesare Leonardi wrote:
On boot LVM shows this error message:
Write locks are prohibited with --ignorelockingfailure.
Unable to obtain global lock.
That sounds like a known upstream regression - that restriction should not
apply to the global lock.
On Thu, Sep 03, 2009 at 01:51:24AM +0100, Alasdair G Kergon wrote:
That sounds like a known upstream regression - that restriction should not
apply to the global lock. However, I've been on holiday and a quick
check of WHATS_NEW suggests the fix has not yet been checked in.
I'll add
On Tue, Aug 04, 2009 at 04:13:56PM -0400, Frédéric Brière wrote:
2. The --minor lvcreate/lvchange option also requires --major, even
though this is undocumented. There's especially no information on what
would be an appropriate major number; I've seen 253 and 254 co-exist on
my machine for
On Wed, Jul 08, 2009 at 01:32:08PM +0200, Andras Korn wrote:
as far as I can tell, the File descriptor x left open message is just
telling the user about open file descriptors the lvm utility inherited and
successfully closed.
It's often an indication of a careless programming and can lead to
On Wed, Jul 08, 2009 at 04:37:09PM +0200, Andras Korn wrote:
I don't agree; surely, following the above argumentation, each and every
program should go out of its way to close any inherited file descriptor it
didn't expect, and warn the user about them.
Not every program, but ones that are
On Thu, Jul 09, 2009 at 12:19:21AM +0200, Andras Korn wrote:
I'm still not sure I understand why this is such a big deal that it's
unacceptable to just close them silently,
Because the cause needs investigating in case it's a security hole (or other
program bug). I believe every program has a
For pvmove completing when it hadn't actually moved, you need a bug fix:
Fix pvmove to revert operation if temporary mirror creation fails.
which is in 2.02.47 upstream that I'll be releasing in a few hours.
(It's actually in 2.02.46 I released the other day, but I've withdrawn that
release
Nah, it is implemented.
It probably doesn't behave the way you would expect.
All it does is override any verbose or debug settings.
It does not remove any other output issued by the program to stdout or stderr.
So you'll still get warning messages.
I'd reject that patch upstream, but instead
On Fri, Feb 27, 2009 at 12:27:47PM -0800, Ross Boylan wrote:
dmsetup table has an optional --show-keys argument.
The online help lists it, but the man page is silent.
Do you mean --showkeys?
Yup, missing from the man page...
Alasdair
--
a...@redhat.com
--
To UNSUBSCRIBE, email to
On Thu, Jan 29, 2009 at 08:27:02PM +0100, Frank Gevaerts wrote:
I wasn't aware of this limitation until I happened to see
http://sources.redhat.com/lvm2/wiki/FrequentlyAskedQuestions, so I previously
just thought pvmove to be unreliable.
That answer could be expressed better.
pvmove of root
Post the 'pvs -v' output and 'lvm version'.
Try the failing lvcreate with '-' arg and grep for the deptree lines and
look for 'Adding target'.
Alasdair
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
On Wed, Jan 07, 2009 at 08:23:36PM -0500, teh test3s wrote:
PVVG Fmt Attr PSize PFree DevSize PV UUID
/dev/cciss/c0d1p5 volgroup00 lvm2 a- 3.22T 2.22T 1.22T
wF9oyR-R0tf-bZeW-0es1-FhYK-f2g3-xS1Rd9
So that's what you need to explain:
How come LVM thinks
On Thu, Jan 08, 2009 at 01:35:23AM +, Alasdair G Kergon wrote:
IOW It's not an LVM issue. Check your cciss partitioning.
To be clearer, the device was 3.22T when you ran pvcreate and LVM
assigned it a uuid. But now the device that has that same uuid is
only 1.22T.
Alasdair
'lvm' binary should be present for use as prefix to other cmds e.g.
# lvm lvchange -ay vg1/lvol1
Alasdair
--
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Fri, Jun 27, 2008 at 06:59:30PM -0400, Stephen M. Benoit wrote:
Upgrading kernel to 2.6.25.9, the LVM utilities could not find any Volume
Groups. This is due to the new /sys/block layout and the LVM sysfs_scan
expecting the old layout. Two fixes until sysfs_scan gets updated:
(1)
On Thu, Jun 12, 2008 at 04:05:06PM +0100, James Westby wrote:
I have been told that .38 is more stable than the .35 that
we have currently.
It's early days, but 2.02.38 is looking promising. Other recent
releases contained serious regressions.
A device-mapper package update to 1.02.26 is
see scripts/fsadm.sh now in the tree
Alasdair
--
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Sat, Sep 29, 2007 at 02:11:13PM +0200, Christian Garbs wrote:
VGs must be backed up into different files. Use %s in filename for VG name.
Fascinating. I notice a %%d elsewhere too.
Alasdair
--
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
--alloc anywhere
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Fri, Jul 13, 2007 at 03:20:10PM +0100, Ian Jackson wrote:
The lvm utilities apparently whinge if they inherit any fds other than
0,1,2. This is quite unreasonable. There is nothing wrong with
executing a program with some inherited fd 2 and there are many
reasons why one might want to do
On Fri, Aug 27, 2004 at 11:40:49PM -0400, Joey Hess wrote:
Package: lvm2
Version: 2.00.16-2
Severity: wishlist
As an admin, I often run df, see a lvm device name in
/dev/mapper/foo-bar format (because that's the format the d-i puts them
in /etc/fstab), and forget that lvdisplay refuses to
On Sun, Jan 14, 2007 at 11:08:53PM +0100, David Härdeman wrote:
udev currently receives uevents from the kernel when a new device-mapper
device mapping is created and creates a /dev/dm-* node. libdevmapper
knows when devices are created/removed and creates the /dev/mapper/*
nodes.
On Fri, Dec 08, 2006 at 12:20:05PM +, Ian Jackson wrote:
This means that even if the vg is and remains active throughout, there
is a moment when the symlink is missing. Any other program on the
system which is referring to that lv may see this glitch and
misbehave.
Yep - vgmknodes looks
On Fri, Oct 20, 2006 at 07:28:57PM +0100, Paul LeoNerd Evans wrote:
# lvcreate --size 100M --mirrors 1 --name mirrorlv vg --alloc anywhere
/dev/sda2 /dev/sda3 /dev/sda3
Inconsistent length: 1 25
PV segment pe_alloc_count mismatch: 1 != 26
PV segment VG free_count mismatch: 47658 !=
The internal error is there upstream: I've checked a fix for that
into CVS. You'll have to wait for the later allocation patches
to get the log on the same device though - or grab (unfinished) patches
from linux-lvm mailing list, or edit your metadata by hand with
vgcfgbackup/restore.
Alasdair
On Mon, Sep 04, 2006 at 04:36:10PM -0400, Daniel Kahn Gillmor wrote:
However, if any of those predicates are untrue (i don't know lvm well
enough to know if this is the case),
Cache is required for speed - tools can be very slow without it.
Backup/archive are for recovery purposes - if you
On Tue, Aug 15, 2006 at 12:49:05AM +0200, R.J.G. wrote:
I have run each with 4 '-v' options. Log files are included.
They appear truncated - the important bit at the end is missing:-)
But it looks like you have 15 PVs in the same VG and are maintaining
15 copies of the metadata which all have
On Mon, Jul 10, 2006 at 06:52:59PM +0600, Alexander E. Patrakov wrote:
The persistent major/minor numbers are silently ignored. Here is
a state of the system before an attempt to create a LVM volume with
persistent major and minor:
Hmmm. And lvchange fails similarly...
Alasdair
--
[EMAIL
OK, I've found two separate problems here.
Firstly, the check that decides whether to apply the major/minor number
when activating the device was inverted so it never did anything.
Secondly, if changing the minor number of an existing active device,
the update sequence is wrong and the change
On Mon, Jul 10, 2006 at 04:20:30PM +0100, Alasdair G Kergon wrote:
OK, I've found two separate problems here.
Both changed in upstream CVS - see lvm commit list for patches.
Alasdair
--
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble
- Forwarded message from [EMAIL PROTECTED] -
Date: 14 Jun 2006 20:27:16 -
From: [EMAIL PROTECTED]
Subject: LVM2 ./WHATS_NEW tools/toollib.c
To: [EMAIL PROTECTED]
CVSROOT:/cvs/lvm2
Module name:LVM2
Changes by: [EMAIL PROTECTED] 2006-06-14 20:27:15
Modified
On Wed, Jun 14, 2006 at 09:06:05PM +0200, David Härdeman wrote:
lvm2 2.02.06-1 no longer reports correct exit codes which breaks
Yup - found the problem will fix upstream.
Alasdair
--
[EMAIL PROTECTED]
The next lvm2 release upstream (possibly later today, else middle of
next week) should handle the backwards compatibility.
Alasdair
--
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Wed, Dec 28, 2005 at 05:07:01PM +0100, Bastian Blank wrote:
This is not fixable without a kernel upgrade.
I've applied a workaround to device-mapper cvs today that I hope
will handle this.
For old kernels, libdevmapper detects if a device number is being
supplied to an ioctl without a name
On Tue, Dec 20, 2005 at 11:27:22AM +0100, Bastian Blank wrote:
Why? The kernel don't wait for the completion of events and the devices
are exported as dm-*.
Exactly - it's an asynchronous design prone to races - udev does not
offer an option for the kernel to wait for the completion. So by the
On Mon, Dec 19, 2005 at 04:33:39PM +0100, Filippo Giunchedi wrote:
Package: lvm2
Version: 2.02.01-1
Severity: normal
LV chroots/test1 in use: not deactivating
Couldn't deactivate new snapshot.
but sometimes I can successfully create snapshots..
What version of the udev package?
Try
On Mon, Dec 19, 2005 at 10:15:33PM +0100, Marco d'Itri wrote:
On Dec 19, Filippo Giunchedi [EMAIL PROTECTED] wrote:
apparently http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343671#msg20
has the
solution, works here. I'm not sure either why ignore_device has been removed
Because another
Also, what kernel are you running?
The debian kernel-image-2.4.27-2-k7 v2.4.27-11.
The feature the new code uses is not in the 2.4 patches.
Would be trivial to backport to 2.4, just hasn't been done.
ftp://sources.redhat.com/pub/dm/patches/2.6-unstable/2.6.9-rc3/2.6.9-rc3-udm1/4.patch
On Wed, Nov 30, 2005 at 06:47:12PM +0100, Wolfgang Weisselberg wrote:
After upgrading to lvm2 2.02.00-1 and the required
libdevmapper1.02, the system was unable to complete booting,
You should find that bug was fixed by libdevmapper 1.02.01 with lvm2 2.02.01.
Alasdair
--
[EMAIL PROTECTED]
On Wed, Nov 30, 2005 at 06:47:12PM +0100, Wolfgang Weisselberg wrote:
device-mapper: one of name or uuid must be supplied, cmd(9)
device-mapper ioctl cmd 9 failed: Invalid argument
Also, what kernel are you running?
The new code relies on a patch I sent upstream a year ago.
Date:
On Mon, Oct 03, 2005 at 04:12:19AM +0200, Barasz Mihaly wrote:
After a recent upgrade lvs and lvdisplay stopped to display snapshot
volumes. Example:
# lvs
LV VG Attr LSize Origin Snap% Move Log Copy%
data vg0 -wi-ao 84.00G
home vg0 owi-ao
On Thu, Sep 15, 2005 at 09:40:08PM +0100, Roger Leigh wrote:
Calling lvremove from a script run non-interactively (with run-parts)
causes it to consume nearly all the CPU time.
Already fixed in CVS upstream but not included in a release yet:
Fix yes_no_prompt() error handling.
Alasdair
device-mapper also has configure-time options which can be used
to control this:
--with-device-uid=UID Set the owner used for new device nodes [UID=0]
--with-device-gid=UID Set the group used for new device nodes [GID=0]
--with-device-mode=MODE Set the mode used for new device nodes
On Tue, Jun 21, 2005 at 08:27:00PM -0400, Michael Stone wrote:
After installing the latest lvm2 package I get the following error when
attempting any lvm-related operation (pvscan, vgdisplay, etc.):
PV segment VG free_count mismatch: 13 != 4294965183
Internal error: PV segments corrupted
On Sun, Apr 17, 2005 at 02:51:14PM +0200, Bastian Blank wrote:
This devices are managed by devmapper. And I don't see problems with
root:root 600 as sane default. devmapper don't have a mechanism to set
permissions.
Just configure-time settings to change the default.
I use that in Fedora to
1 - 100 of 105 matches
Mail list logo
