Bug#465733: marked as done (xfsprogs: xfs_check SEGV)

["Debian Bug Tracking System" <owner@bugs.debian.org>]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

Your message dated Thu, 4 Feb 2021 23:11:43 +0100
with message-id <b41ca82b-6f60-acda-6c6b-0f4e209d8c23@fishpost.de>
and subject line Re: Updating bug status
has caused the Debian Bug report #465733,
regarding xfsprogs: xfs_check SEGV
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
465733: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465733
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[-- Attachment #2: Type: message/rfc822, Size: 4058 bytes --]

From: Russell Coker <russell@coker.com.au>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: xfsprogs: xfs_check SEGV
Date: Thu, 14 Feb 2008 22:42:28 +1100
Message-ID: <20080214114228.9734.77682.reportbug@aeon.coker.com.au>

Package: xfsprogs
Version: 2.8.11-1
Severity: critical
Justification: breaks the whole system

I have a filesystem which causes a SEGV when I try to check it.

The problem started when I unexpectedly powered the machine down causing some
data loss.  When I booted it up again the kernel gave errors about corrupted
data structures (which I unfortunately didn't make a note of).  Now when I
try to check it (on another machine) it gives the following.

NB The filesystem has no secret data, I would be happy to give you a copy, I
could put it on a machine on the net that you can access or give you an IDE
disk with a copy if you are in Melbourne.

# xfs_check /dev/sda5
agi unlinked bucket 59 is 891 in ag 2 (inode=8389499)
agi unlinked bucket 6 is 134 in ag 3 (inode=12583046)
agi unlinked bucket 18 is 338 in ag 3 (inode=12583250)
agi unlinked bucket 51 is 179 in ag 3 (inode=12583091)
agi unlinked bucket 8 is 136 in ag 5 (inode=20971656)
agi unlinked bucket 10 is 138 in ag 5 (inode=20971658)
agi unlinked bucket 11 is 139 in ag 5 (inode=20971659)
agi unlinked bucket 14 is 142 in ag 5 (inode=20971662)
agi unlinked bucket 15 is 143 in ag 5 (inode=20971663)
agi unlinked bucket 16 is 144 in ag 5 (inode=20971664)
agi unlinked bucket 17 is 145 in ag 5 (inode=20971665)
agi unlinked bucket 19 is 147 in ag 5 (inode=20971667)
agi unlinked bucket 23 is 151 in ag 5 (inode=20971671)
agi unlinked bucket 27 is 155 in ag 5 (inode=20971675)
can't seek in filesystem at bb 20002504712
can't read btree block 16384/1
extent count for ino 50332175 data fork too low (0) for file format
bad nblocks 12 for inode 50332175, counted 1
bad nextents 9 for inode 50332175, counted 0
no . entry for directory 50332175
no .. entry for directory 50332175
/usr/sbin/xfs_check: line 28:  9686 Segmentation fault      xfs_db$DBOPTS -i -p xfs_check -c "check$OPTS" $1


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-686
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)

Versions of packages xfsprogs depends on:
ii  lib 2.3.6.ds1-13etch4                    GNU C Library: Shared libraries
ii  lib 5.2-2                                GNU readline and history libraries
ii  lib 1.39+1.40-WIP-2006.11.14+dfsg-2etch1 universally unique id library

xfsprogs recommends no packages.

-- no debconf information



[-- Attachment #3: Type: message/rfc822, Size: 4468 bytes --]

From: Bastian Germann <bastiangermann@fishpost.de>
To: 465733-done@bugs.debian.org
Subject: Re: Updating bug status
Date: Thu, 4 Feb 2021 23:11:43 +0100
Message-ID: <b41ca82b-6f60-acda-6c6b-0f4e209d8c23@fishpost.de>

Version: 3.2.1

On Sat, 1 Mar 2008 07:01:45 +1100 (EST) nscott@aconex.com wrote:
> In the long
> run, theres also discussion (upstream) of replacing xfs_check entirely by an
> "xfs_repair -n" wrapper, which would resolve this issue entirely (xfs_check
> has other issues beyond this one, in particular its memory footprint can be
> extreme compared to current xfs_repair).   But, thats not on the immediate
> horizon as yet.

xfs_check was replaced by xfs_repair long ago.