> 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]