Bug#409435: linux-image-2.6.18-4-amd64: old version of libdevmapper1.02 installed == eat filesystem on pvmove
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.
> > 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.
To put it otherwise, a broken libdevmapper (thta happens to work with
older kernels) may easily eat my data, but processes in uninterruptible
sleep is still a kernel bug.
> 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 mean, it eats data, and users did nothing wrong, except using debian
testing at some point in the past. You can only win by helping that case,
especially as upgrading to the current lvm2 version does not fix that.
(Maybe lvm2 needs a dependency on a newer libdevmapper, but as this only
happens with 2.6.18 and not 2.6.16, it would probably make sense for the
kernel).
Are you really telling me that destroying data just because the version of
libdevmapper that once was in debian was never part of a debian release?
Thats really a poor excuse.
I cna understand your point of "its not a kernel bug" (even if there is
some bug), but is it really too much to ask? I mean, lets repeat it, it
_eats_ data because some obscure, not directly user-visible version of
libdevmapper which usually gets installed as an dependency only fails to
work with 2.6.18.
Even if accoridng to policy this is correct behaviour, I cannot accept
such a position at all. Turning your back to such a serious bug is really
unfair.
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ pcg@goof.com
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
Reply to: