fsck_ufs dumps core

[Dmitry Sivachenko]

> On 12 Aug 2016, at 08:51, Konstantin Belousov <kostikbel at gmail.com> wrote:
> 
> On Wed, Aug 10, 2016 at 06:11:39PM +0300, Dmitry Sivachenko wrote:
>> 
>>> 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] 
> 
> Well, it seems that your beginning of the volume got obliterated.
> Fsck_ffs cannot convert random sequence of bytes into the valid FFS
> volume.
> 
> The only other way to try is to restore content of the cylinder groups
> which are farther away from the start.  Create a scratch volume of the
> same size, newfs it with the same parameters.  Then dd from the broken
> volume to the new one, with some offset.  Offset should be large enough
> to not include initial superblock, and if the zero cg is damaged, skip
> it as well.  You should use seek=n skip=n (i.e. the same initial offsets
> both for input and output).


Okay, then it was simpler for me to backup vital data from this volume and do newfs on it (rather that dd 145TB of data).

But fsck_ufs -b still does not work (after fresh newfs):

# fsck_ufs -b 343748128704 /dev/mfid0p1 
Alternate super block location: 150745024
** /dev/mfid0p1
150745024 is not a file system superblock


343748128704 was taken from freshly made newfs.