On Sun, Jun 26, 2016 at 07:55:39AM +0200, Ulrich Möhrke wrote:
> Package: e2fsprogs
> Version: 1.43.1-1
> Severity: normal
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
> * What led up to the situation?
> call of resize2fs -p /dev/sda6 162336768K as root to reduce size of file
> system by 4G
>
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
> * What was the outcome of this action?
>
> I've got german output:
> resize2fs 1.43.1 (08-Jun-2016)
> Die Größe des Dateisystems auf /dev/sda6 wird auf 40584192 (4k) Blöcke
> geändert.
> Start von Durchgang 3 (max = 1271)
> Die Inode-Tabelle wird
> gelesenXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXSpeicherzugriffsfehler
>
> should be something like the following in english:
> resize2fs 1.43.1 (08-Jun-2016)
> The size of the file system at /dev/sda6 will be changed to 40584192 (4k)
> blocks.
> Start of run/track 3 (max = 1271)
> Reading inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXsegmentation fault
OK, first of all, please run fsck on the /dev/sda6 to make sure it's
consistent. Please save the output of fsck and attach it to the bug.
Next, run dumpe2fs on the output, and attach it to the bug as well.
What I would suggest doing next is to use e2image -r to create a raw
image dump of the file system metadata blocks, and then try running
resize2fs on the raw image dump. If it crases, then we've got a
reproduction case, and this would be most helpful. Ideally I'd like
to get a compressed copy of the raw image file. If you don't want me
seeing the filenames, you can create the image dump using e2image -rs,
which will scramble the file names. (Either way, this omits the data
blocks, both for size and privacy reasons.)
If you don't want to send me the image file, it would be great if you
could enable core dumps, and get a stack trace. Or you can install
the dbgsym package and then run resize2fs under gdb, and get the stack
trace that way.....
- Ted
