The bug has expired, without the requested information.
Assuming that this is not a bug with the karmic e2fsprogs, I feel that
we should close it.
** Changed in: e2fsprogs (Ubuntu)
Status: Incomplete => Won't Fix
--
e2fsck crashed with SIGSEGV in strlen()
https://bugs.launchpad.net/bugs/
Marking incomplete; waiting for details with valgrind.
** Changed in: e2fsprogs (Ubuntu)
Status: New => Incomplete
--
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 subscri
On Thu, Aug 14, 2008 at 07:30:22PM -, 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 Ubu
what me just came up to check the posssibility of other parts of Hardy
interferring with e2fsck:
I do upload here the broken /var/cash/_usr_bin_nautilus.1000.crash
which was createt at the very same time when e2fsck crashed - does it help you
further?
Ingo
** Attachment added: "_usr_bin_nautil
Ted,
one more thing I did not mention up to now: my system is Hardy-amd64.
My personal guess now is that it is not e2fsck itself, but in co-
operation with some other part of the system (gvfs, nautilus, hal ??
whatever). And as v1.41.0 of e2fsprogs seems to handle the matter
smoothly at least und
On Thu, Aug 14, 2008 at 05:57:20PM -, ingo wrote:
>
> Now to your recent request regarding the image:
> it still crashes on Hardy, see this output:
>
> # /sbin/e2fsck ./qnap-sdc3.img
> e2fsck 1.40.8 (13-Mar-2008)
> ./qnap-sdc3.img has unsupported feature(s):Segmentation fault (core dumped)
>
Congratulations Ted!
You were right with your asumption regardind early alpha ext4. I did try to
follow your recommendations on Lenny, where e2fsprogs 1.41.0 is currently
standard. Issued followig commands:
---
[EMAIL PROTECTED]:~$ tune2fs -E test_fs /dev/sdc3
bash: tune2fs: comm
On Thu, Aug 14, 2008 at 02:48:08PM -, ingo wrote:
> one more information:
>
> when trying to mount /dev/sdc3 I get following message:
>
> mount -t ext3 /dev/sdc3 /mnt
> mount: wrong fs type, bad option, bad superblock on /dev/sdc3,
>missing codepage or helper program, or other error
>
On Thu, Aug 14, 2008 at 11:00:44AM -, ingo wrote:
>
> 1. partly image of current sda3 (dd if=/dev/sdc3 of=qnap-sdc3.img bs=4k
> count=200) -> attached!
So I just tried downgrading to e2fsprogs 1.40.8-2ubuntu2 (and all of
its associated libraries), and I can't reproduce the crash. What I
get
one more information:
when trying to mount /dev/sdc3 I get following message:
mount -t ext3 /dev/sdc3 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/sdc3,
missing codepage or helper program, or other error
checking 'dmesg' afterwards tells me:
[ 7905.568588] EXT3-fs: sdc3
Hi Ted,
many thanks for dealing with this matter! Unfortunately I cannot produce such a
'dirty' partitition/filesystem, as my QNAP-NAS heavily crashed during rebuild
of that partitition sdc3 onto another disk and finally died (it is away for
warranty repair ;-). The disk I have here is the disk
On Wed, Aug 13, 2008 at 09:21:20PM -, ingo wrote:
> Many thanks Ted,
>
> So I now know where to go and I discard the unusable partitition. But I
> will get my NAS back and repaired soon (I hope) and then be able to
> create a 'virgin QNAP ext3' and check with Lenny or even Intrepid
> whether i
Many thanks Ted,
I think you hit the point!
For sure lenny did not 'repair' the file system, but left it in an unusable
condition. I was able to even recover some of the filesystem (root directories9
by using 'debugfs' 'open /dev/sdc3' ...
So I now know where to go and I discard the unusable pa
On Wed, Aug 13, 2008 at 07:38:25PM -, ingo wrote:
> If said in my first post, that the file system was created by QNAP
> TS-209 NAS. It is an ext3 file system, but with some patches from
> QNAP applied (as far as I know to speed up RAID1).
Actually, it looks like it's an ext4 filesystem --- o
So, forgot to mention:
if you want to reproduce the crash, you need a corrupted filesystem like
I have it here.
That neiter e2fsck can repair it - its my fault (don't need the data anyhow)
But that e2fsck in Hardy crashes instead of displaying a message and exits, is
a bug!
The filesystem still
If said in my first post, that the file system was created by QNAP TS-209 NAS.
It is an ext3 file system, but with some patches from QNAP applied (as far as I
know to speed up RAID1).
This filesystem cannot be mounted on standard Linux PC's - but it is
definitely ext3!
And that's why I have run
This sounds like a different problem, right? You've already blown away
the original contents of the disk, so it's going to be impossible for us
to try to reproduce what was going on on the Ubuntu e2fpsrogs version
1.40.8.
As for the "device or resource is busy", that means something else has
the
Probably some other usefull information: trying with an older version
of e2fstools (under openSUSE 10.2) resulted in following error-message
(no crash!):
fsck.ext3 -n /dev/sdc3
e2fsck 1.39 (29-May-2006)
fsck.ext3: Das Gerät oder die Ressource ist belegt beim Versuch,
/dev/sdc3 zu öffnen
Filesyste
[EMAIL PROTECTED]:/home/ingo# dumpe2fs -h /dev/sdc3
dumpe2fs 1.40.8 (13-Mar-2008)
Filesystem volume name:
Last mounted on:
Filesystem UUID: 2854e675-ba59-4084-b530-759a967b4ac2
Filesystem magic number: 0xEF53
Filesystem revision #:1 (dynamic)
Filesystem features: has
Can you send the output of "dumpe2fs -h /dev/sdc3"?
Thanks!!
--
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@list
StacktraceTop:strlen () from /lib/libc.so.6
vfprintf () from /lib/libc.so.6
buffered_vfprintf () from /lib/libc.so.6
vfprintf () from /lib/libc.so.6
fprintf () from /lib/libc.so.6
** Tags removed: need-amd64-retrace
** Attachment removed: "CoreDump.gz"
http://launchpadlibrarian.net/16710719/
Found a quick solution - will call it patch:
just use e2fsprogs 1.41.0 from Debian-Lenny and all is fine - see Output
of handling and correcting
Result see in attached file QNAP-fsck.txt
** Attachment added: "QNAP-fsck.txt"
http://launchpadlibrarian.net/16712071/QNAP-fsck.txt
** Visibility c
22 matches
Mail list logo
