Your message dated Thu, 4 Feb 2021 23:11:43 +0100
with message-id <b41ca82b-6f60-acda-6c6b-0f4e209d8c23@xxxxxxxxxxx>
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@xxxxxxxxxxxxxxx
immediately.)
--
465733: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465733
Debian Bug Tracking System
Contact owner@xxxxxxxxxxxxxxx with problems
--- Begin Message ---
- Subject: xfsprogs: xfs_check SEGV
- From: Russell Coker <russell@xxxxxxxxxxxx>
- Date: Thu, 14 Feb 2008 22:42:28 +1100
- Delivered-to: submit@xxxxxxxxxxxxxxx
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
--- End Message ---
--- Begin Message ---
- Subject: Re: Updating bug status
- From: Bastian Germann <bastiangermann@xxxxxxxxxxx>
- Date: Thu, 4 Feb 2021 23:11:43 +0100
- In-reply-to: <56230.192.168.3.1.1204315305.squirrel@mail.aconex.com>
- References: <200802212158.01744.russell@coker.com.au> <56230.192.168.3.1.1204315305.squirrel@mail.aconex.com> <56230.192.168.3.1.1204315305.squirrel@mail.aconex.com>
- User-agent: Mozilla/5.0 (X11; Linux i686; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
Version: 3.2.1
On Sat, 1 Mar 2008 07:01:45 +1100 (EST) nscott@xxxxxxxxxx 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.
--- End Message ---
