fsck_ufs dumps core

[Dmitry Sivachenko]

> On 10 Aug 2016, at 17:55, Konstantin Belousov <kostikbel at gmail.com> wrote:
> 
> On Wed, Aug 10, 2016 at 05:29:31PM +0300, Dmitry Sivachenko wrote:
>> Hello,
>> 
>> I am running FreeBSD 10.3-STABLE #0 r299261M
>> 
>> After unclean reboot I am unable to fsck my UFS filesystem:
>> 
>> # fsck  /dev/mfid0p1
>> ** /dev/mfid0p1
>> ** Last Mounted on /opt
>> ** Phase 1 - Check Blocks and Sizes
>> fsck: /dev/mfid0p1: Segmentation fault
>> 
>> pid 482 (fsck_ufs), uid 0: exited on signal 11 (core dumped)
>> 
>> # gdb -c fsck_ufs.482 /sbin/fsck_ufs 
>> GNU gdb 6.1.1 [FreeBSD]
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB.  Type "show warranty" for details.
>> This GDB was configured as "amd64-marcel-freebsd"...
>> Core was generated by `fsck_ufs'.
>> Program terminated with signal 11, Segmentation fault.
>> Reading symbols from /lib/libufs.so.6...done.
>> Loaded symbols for /lib/libufs.so.6
>> Reading symbols from /lib/libc.so.7...done.
>> Loaded symbols for /lib/libc.so.7
>> Reading symbols from /libexec/ld-elf.so.1...done.
>> Loaded symbols for /libexec/ld-elf.so.1
>> #0  0x0000000000409a8b in pass1 () at /place/WRK/src/sbin/fsck_ffs/pass1.c:83
>> 83                              setbmap(i);
>> (gdb) bt
>> #0  0x0000000000409a8b in pass1 () at /place/WRK/src/sbin/fsck_ffs/pass1.c:83
>> #1  0x0000000000409050 in main (argc=<value optimized out>, 
>>    argv=<value optimized out>) at /place/WRK/src/sbin/fsck_ffs/main.c:447
>> Current language:  auto; currently minimal
>> (gdb) 
>> 
> 
> Try to use alternative superblock (-b switch).  You can get the list of
> the possible values for -b by 'newfs -N' invocation, but you have to know
> the parameters which were used for formatting.


Yes, I tried several different backup superblocks, with the same result.  (I created this FS few years ago so I can't be 100% sure about the parameters, but I usually only use larger -i NN for big filesystems, and I can guess the exact value examining df -ik).


BTW I just noticed that when I use larger values for backup superblock, it reports an error which looks like overflow:

# fsck_ufs -b 7437746112 /dev/mfid0p1
Alternate super block location: -1152188480
** /dev/mfid0p1

CANNOT SEEK BLK: -1152188480
CONTINUE? [yn]