[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#409435: linux-image-2.6.18-4-amd64: old version of libdevmapper1.02 installed == eat filesystem on pvmove



On Mon, Feb 05, 2007 at 04:44:23PM +0100, Marc Lehmann wrote:
> On Fri, Feb 02, 2007 at 08:16:38PM -0800, Steve Langasek <vorlon@debian.org> wrote:
> > According to #383418, this bug only affects versions of libdevmapper1.02
> > previous to the version currently in etch, and there is no libdevmapper1.02
> > in sarge.  There is a libdevmapper1.01, but it's not clear that version of
> > the lib is also affected.

> Thats fine, the bug still eats disks, and while I don't know anything
> about the chances of this happening I would still assume its a pretty
> common occurence as upgrading both lvm2 and dmsetup didn't upgrade the
> library used by them, leaving the broken one in place.

Keeping old, unreleased versions of packages around on your system is always
unsupported.

> > > indeed, upgrading it made pvmove seemingly work (neither upgrading dmsetup
> > > nor lvm2 upgrades this library to the required version). I think I had
> > > 1.02.06-1 and upgraded to 1.02.12-1.

> > > Please, I urge you, add an antidependency to the kernel against old and
> > > incompatible versions of libdevmapper. This problem is *severe*, causes
> > > serious data loss, is a known issue, and is so easily avoidable and so
> > > hard to diagnose.

> > But it's not a bug in the kernel -- it's a bug in an obsolete,

> First of all, while the data corruption can be conceivably be a userspace
> bug, remember that the lvm2 commands went into uninterruptible sleep
> (no kill -9), which cannot be a userspace problem unless you assume
> libdevmapper opens /dev/mem and pokes into the kernel directly.

Ok, that's fair, it's a kernel bug for allowing such a deadlock to occur;
but it's also a userspace bug for doing something that deadlocks the kernel,
and I don't think the kernel should bear the greater responsibility here.

> > never released, and unsupported version of devmapper.

> Right, but just for the sake of helping people who used the never released
> and unsupported version of devmapper that likely many people using unstable
> or testing still have installed and doesn't get upgraded it would make sense
> to do that, won't you think?

I think it's a fair request; it's just not release-critical, as you
suggested in your bug severity.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Reply to: