Re: how to recover unmountable partition (crash while resizing)?

Re: how to recover unmountable partition (crash while resizing)?

[Antonio Muci]

Yes, that same one.On May 18, 2020 5:33 PM, Nikolay Borisov <nborisov@suse.com> wrote:
>
>
>
> On 18.05.20 г. 17:11 ч., a.mux@inwind.it wrote: 
> > Hi, 
> > 
> > due to a crash while resizing my / btrfs partition with gparted, my HD was left in a unmountable state. 
> > 
> > This is on me: resizing a partition moving it to the right via gparted is a risky operation per se. 
> > 
> > I am confident that all my data is still in the HD, and with proper guidance from the tools it will be possible to mount back the fs. The UI of the tools is a bit hard for me to understand. 
>
> So what kernel version were you running when the crash happened, is it 
> the same as from LiveUSB? 

Re: how to recover unmountable partition (crash while resizing)?

[Nikolay Borisov]

On 18.05.20 г. 19:06 ч., Antonio Muci wrote:
> Yes, that same one.On May 18, 2020 5:33 PM, Nikolay Borisov <nborisov@suse.com> wrote:
>>
>>
>>
>> On 18.05.20 г. 17:11 ч., a.mux@inwind.it wrote: 
>>> Hi, 
>>>
>>> due to a crash while resizing my / btrfs partition with gparted, my HD was left in a unmountable state. 
>>>
>>> This is on me: resizing a partition moving it to the right via gparted is a risky operation per se. 
>>>
>>> I am confident that all my data is still in the HD, and with proper guidance from the tools it will be possible to mount back the fs. The UI of the tools is a bit hard for me to understand. 
>>
>> So what kernel version were you running when the crash happened, is it 
>> the same as from LiveUSB? 

Can you check if your distro kernel has upstream commit
18dfa7117a3f379862dcd3f67cadd678013bb9dd - it did land in the upstream
5.3 kernel so you should have it but better safe than sorry. Also,
provide the output of btrfs check /dev/broken-device. But recompile to
the latest version of btrfs-progs. This command is read only so it can't
cause more harm than is already done. Also what kind of disk is the one
you tried to resize - i.e a usb drive or normal SATA ? Is it ssd or hdd?

Re: how to recover unmountable partition (crash while resizing)?

[Chris Murphy]

On Mon, May 18, 2020 at 8:12 AM <a.mux@inwind.it> wrote:
>
> Hi,
>
> due to a crash while resizing my / btrfs partition with gparted, my HD was left in a unmountable state.
>
> This is on me: resizing a partition moving it to the right via gparted is a risky operation per se.

"to the right" means you were moving the starting point of the file
system? Was the size changing too?

What is the nature of the crash? Gparted crashed? The whole
environment crashed? Power failure? Is there a dmesg or gparted log?

Do you have a backup of the GPT before the resize? By comparing the
GPT before it was changed, to its current state, and that of the super
block found (or not) at the expected locations for both GPT states, it
might be possible to infer where in the resize things went wrong.

It's important to look at the GPT and *not* repair it if it's damaged.
Any damage to the GPT might preserve useful information about the
prior state.

# gdisk/fdisk -l /dev
# btrfs insp dump-s -a /dev

> I am confident that all my data is still in the HD, and with proper guidance from the tools it will be possible to mount back the fs. The UI of the tools is a bit hard for me to understand.

If this was moving the starting point of the file system, it's
possibly difficult to recover if the crash happened while moving the
partition. This copies the file system in sections - it's basically
broken for the duration of the move and isn't atomic.


-- 
Chris Murphy

Re: how to recover unmountable partition (crash while resizing)?

[Nikolay Borisov]

On 18.05.20 г. 17:11 ч., a.mux@inwind.it wrote:
> Hi,
> 
> due to a crash while resizing my / btrfs partition with gparted, my HD was left in a unmountable state.
> 
> This is on me: resizing a partition moving it to the right via gparted is a risky operation per se.
> 
> I am confident that all my data is still in the HD, and with proper guidance from the tools it will be possible to mount back the fs. The UI of the tools is a bit hard for me to understand.

So what kernel version were you running when the crash happened, is it
the same as from LiveUSB?

how to recover unmountable partition (crash while resizing)?

[a.mux]

Hi,

due to a crash while resizing my / btrfs partition with gparted, my HD was left in a unmountable state.

This is on me: resizing a partition moving it to the right via gparted is a risky operation per se.

I am confident that all my data is still in the HD, and with proper guidance from the tools it will be possible to mount back the fs. The UI of the tools is a bit hard for me to understand.


```
# mount -t btrfs /dev/sda7 /mnt/
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sda7, missing codepage or helper program, or other error.

dmesg output:
[ 3417.869264] BTRFS info (device sda7): disk space caching is enabled
[ 3417.869268] BTRFS info (device sda7): has skinny extents
[ 3417.882863] BTRFS error (device sda7): bad tree block start, want 83301548032 have 83284770816
[ 3417.882873] BTRFS error (device sda7): failed to read block groups: -5
[ 3417.953867] BTRFS error (device sda7): open_ctree failed
```

Find root maybe complains and maybe not:
```
# btrfs-find-root /dev/sda7 
Superblock thinks the generation is 107621
Superblock thinks the level is 1
Found tree root at 25657344 gen 107621 level 1
Well block 22315008(gen: 107620 level: 1) seems good, but generation/level doesn't match, want gen: 107621 level: 1
```

What is the most reasonable next step?

Many thanks!
Antonio


===============

This is the current sw versions on my LiveUSB.
I could upgrade to ubuntu it 20.04 (kernel 5.4), and I am comfortable in recompiling btrfs-progs if needed.

# uname -a
Linux kubuntu 5.3.0-18-generic #19-Ubuntu SMP Tue Oct 8 20:14:06 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

# btrfs --version
btrfs-progs v5.2.1