On Thu, Jun 13, 2019 at 11:19:13PM +0200, Florian Zumbiehl wrote:
>
> That fixed versions are available in buster and as a backport is of no use
> to anyone walking into this trap who doesn't know that they are about to
> corrupt their files. As far as I am concerned, that is more than enough
> reason to not fix the conversion in stretch--but please, at least make
> e2fsck bail out with an error message when someone asks it to corrupt the
> file system. That should be an easy and low-risk fix, and if you had done
> that when the bug was discovered, you would at least have saved me a lot of
> time, as I amh still trying to figure out what's been corrupted--and as
> noone should be using this version of the code that is almost guaranteed to
> corrupt your data, replacing it with an error message is not a regression
> either.
I'm very sorry that you lost data.
The problem is not the difficulty in backporting the change --- the
fix is really just a one-line change. Most of the complexity in the
commit is in adding regression test.
The problem is actually making any kind of change to stretch at this
point. The release team strongly discourages package updates, unless
the bug is ***really*** serious. This is especially true for packages
like e2fsck which are built into the installer, since taking an
e2fsprogs package involves respinning the installer.
Given how niche the bmap2extent option is, and combine the judgement
that it's highly unlikely that people conservative enough to use
Debian Obsolete^H^H^H^H^H^H^H Stable would be using an exotic e2fsck
option with how many hoops the Debian Release Team makes people doing
stable updates (I feel actively discouraged from going down that
route) and I feel extremely demotatived towards trying to extract out
just the bug reports and backport them to ancient versions of
e2fsprogs. Red Hat pays masochists vast amounts money to do that.
It's just not sort of thing that volunteers are likely to do, and if
you look at the very small number of packages that are updated to
Debian stretch (not even all security fixes), compared to what Red Hat
releases in its updates, it's just the way life is.
In my mind, this is why Debian Backports exists. If you want the
latest bug fixes (including one whhich avoids data corruption when
doing off-line shrinks using resize2fs), and/or you are doing anything
at all exotic, my only recommendation is to use the Debian Backports
version of e2fsprogs.
Bottom line, for *this* particular bug (as opposed to the various
resize2fs shrink fixes) preparing an update to 1.43.4-2 is pretty
simple. And if I had any optimism that the Release Team would be
willing to take a very late update to Debian Stretch at the point when
it's just about become oldstable, I might even be willing to do the
upload. But it's not something where I'm feeling particularly
motivated to convince the release team that this is a change they
should be taking, and respinning the Stretch installer at this point.
Best regards,
- Ted
