On Thu, Aug 14, 2008 at 07:30:22PM -0000, ingo wrote:
> If you do not want to propose upgrade of e2fsprogs in Hardy, we will
> have to wait till I can create an untouched/spoiled filesystem to
> use for tracing.
That's really not up to me. I'm just the upstream maintainer here.
It's up to the Ubuntu release team to decide whether they want to
upgrade to e2fsprogs 1.41, and/or a kernel that's new enough to
support ext4.
My guess is that e2fsck crashing on a filesystem which is not
supported by Ubuntu Hardy is low priority to the Ubuntu release team,
but that's not my call to make.
As far as the QNAS is concerned, if they have the code which I suspect
they do, I have a feeling that even a correctly working filesystem
from QNAS may end up generating complaints from e2fsck, but it should
*hopefully* be the case that after e2fsck fixes those corruptions so
that a modern Linux kernel is happy with it, that it will still be OK
to put that disk back in a QNAS box and it will still work correctly.
So you might want to be careful and keep lots of backups until we know
for sure that it's safe.
It is true that I'm testing on an x86 box; I don't run a 64-bit
Ubuntu, so I can't test there easily. So maybe that's why you are
seeing the problem and I am not. Unfortunately, short of running
"valgrind" or recompiling from source and running e2fsck under a
debugger with debugging symbols and without the binary being stripped,
I'm not sure I can really take this much farther.
Regards,
- Ted
--
e2fsck crashed with SIGSEGV in strlen()
https://bugs.launchpad.net/bugs/257048
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
