tldr; no BTRFS on dev, after a forced shutdown, help

tldr; no BTRFS on dev, after a forced shutdown, help

[André Isidro da Silva]

I might be in some panic, I'm sorry for the info I'm not experienced 
enough to give.

I was in a live iso trying really hard to repair my root btrfs from 
which I had used all the space avaiable.. I was trying to move a /usr 
partition into the btrfs system, but I didn't check the space available 
with the tool, instead used normal tools, because I didn't understand or 
actually thought about how the subvolumes would change... sorry this 
isn't even the issue anymore; to move /usr I had a temporary /usr copy 
in another btrfs system (my /home data partition) and so mounted both 
partitions. However this was done in a linux "boot fail console" from 
which I didn't know how to proper shutdown.. so I eventually forced the 
shutdown withou umounting stuff (...), I think that forced shutdown 
might have broken the second partition that now isn't recognized with 
btrfs check or mountable. It might also have happen when using the live 
iso, but the forced shutdown seemed more likely, since I did almost no 
operations but mount/cp. This partition was my data partition, I thought 
it was safe to use for this process, since I was just copying files from 
it. I do have a backup, but it's old so I'll still lose a lot.. help.

I ended up giving up on my system partition after this happens to my 
/home, I'm reinstalling in a ext4 for the time being, so I should have a 
system running to fill in logs missing from this mail written from my 
phone haha.

Regards,

André

Re: tldr; no BTRFS on dev, after a forced shutdown, help

[Chris Murphy]

On Sun, Jan 3, 2021 at 9:30 PM André Isidro da Silva
<andreisilva@tecnico.ulisboa.pt> wrote:
>
> I might be in some panic, I'm sorry for the info I'm not experienced
> enough to give.
>
> I was in a live iso trying really hard to repair my root btrfs from
> which I had used all the space avaiable.. I was trying to move a /usr
> partition into the btrfs system, but I didn't check the space available
> with the tool, instead used normal tools, because I didn't understand or
> actually thought about how the subvolumes would change... sorry this
> isn't even the issue anymore; to move /usr I had a temporary /usr copy
> in another btrfs system (my /home data partition) and so mounted both
> partitions. However this was done in a linux "boot fail console" from
> which I didn't know how to proper shutdown.. so I eventually forced the
> shutdown withou umounting stuff (...), I think that forced shutdown
> might have broken the second partition that now isn't recognized with
> btrfs check or mountable. It might also have happen when using the live
> iso, but the forced shutdown seemed more likely, since I did almost no
> operations but mount/cp. This partition was my data partition, I thought
> it was safe to use for this process, since I was just copying files from
> it. I do have a backup, but it's old so I'll still lose a lot.. help.

First, make no changes, attempt no repairs. Next save history of what you did.

A forced shutdown does not make Btrfs unreadable, although if writes
are happening at the time of the shutdown and the drive firmware
doesn't properly honor write order, then it might be 'btrfs restore'
territory.

What do you get for:

btrfs filesystem show
kernel messages (dmesg) that appear when you try to mount the volume
but it fails.



-- 
Chris Murphy

Re: tldr; no BTRFS on dev, after a forced shutdown, help

[André Isidro da Silva]

I'm sure it used to be one, but indeed it seems that a TYPE is missing 
in /dev/sda10; gparted says it's unknown.
It seems there is no trace of the fs. I'm trying to recall any other 
operations I might have done, but if it was something else I can't 
remember what could have been. I used cfdisk, to resize another 
partition, also tried to do a 'btrfs device add' with this missing one 
(to solve the no space left in another one), otherwise it was mount /, 
mount /home (/dev/sda10), umount, repeat. Oh well.

[sudo blkid]

/dev/sda1: UUID="03ff3132-dfc5-4dce-8add-cf5a6c854313" BLOCK_SIZE="4096" 
TYPE="ext4" PARTLABEL="LINUX" 
PARTUUID="a6042b9f-a3fe-49e2-8dc5-98a818454b6d"

/dev/sdb4: UUID="5c7201df-ff3e-4cb7-8691-8ef0c6c806ed" 
UUID_SUB="bb677c3a-6270-420f-94ce-f5b89f2c40d2" BLOCK_SIZE="4096" 
TYPE="btrfs" PARTUUID="be4190e4-8e09-4dfc-a901-463f3e162727"

/dev/sda10: PARTLABEL="HOME" 
PARTUUID="6045f3f0-47a7-4b38-a392-7bebb7f654bd"

[sudo btrfs insp dump-s -F /dev/sda10]

superblock: bytenr=65536, device=/dev/sda10
---------------------------------------------------------
csum_type               0 (crc32c)
csum_size               4
csum                    0x00000000 [DON'T MATCH]
bytenr                  0
flags                   0x0
magic                   ........ [DON'T MATCH]
fsid                    00000000-0000-0000-0000-000000000000
metadata_uuid           00000000-0000-0000-0000-000000000000
label
generation              0
root                    0
sys_array_size          0
chunk_root_generation   0
root_level              0
chunk_root              0
chunk_root_level        0
log_root                0
log_root_transid        0
log_root_level          0
total_bytes             0
bytes_used              0
sectorsize              0
nodesize                0
leafsize (deprecated)   0
stripesize              0
root_dir                0
num_devices             0
compat_flags            0x0
compat_ro_flags         0x0
incompat_flags          0x0
cache_generation        0
uuid_tree_generation    0
dev_item.uuid           00000000-0000-0000-0000-000000000000
dev_item.fsid           00000000-0000-0000-0000-000000000000 [match]
dev_item.type           0
dev_item.total_bytes    0
dev_item.bytes_used     0
dev_item.io_align       0
dev_item.io_width       0
dev_item.sector_size    0
dev_item.devid          0
dev_item.dev_group      0
dev_item.seek_speed     0
dev_item.bandwidth      0
dev_item.generation     0

This as nothing to do with btrfs anymore, but: do you think a tool like 
foremost can recover the files, it'll be a mess, but better then nothing 
and I've used it before in a ntfs.

Thanks

A 2021-01-04 17:36, Chris Murphy escreveu:
> On Mon, Jan 4, 2021 at 5:14 AM André Isidro da Silva
> <andreisilva@tecnico.ulisboa.pt> wrote:
>> 
>> Thankyou for helping,
>> 
>> I have already tried to run check, and.. check --repair. I bet that's
>> bad, yesterday snowballed downhill really quick haha.
>> 
>> ERROR: no btrfs on /dev/sda10
> 
> Are you sure there's a btrfs file system on /dev/sda10? What do you get 
> for:
> 
> sudo blkid
> sudo btrfs insp dump-s -F /dev/sda10
> 
> 
> 
>> 
>> dmesg reported nothing for a simple mount,
>> and for a 'mount -o subvolid':
>>       [  +3.754839] fuseblk: Unknown parameter 'subvolid'
> 
> subvol and subvolid need a parameter to work; but that you're getting
> back a message from fuseblk suggests this is not a btrfs file system
> (anymore) so without knowing the full history, it's just guessing.
> LIke, is it possible you accidentally reformatted with this partition?
> There's not much to go on.

Re: tldr; no BTRFS on dev, after a forced shutdown, help

[Chris Murphy]

On Mon, Jan 4, 2021 at 11:09 AM André Isidro da Silva
<andreisilva@tecnico.ulisboa.pt> wrote:
>
> I'm sure it used to be one, but indeed it seems that a TYPE is missing
> in /dev/sda10; gparted says it's unknown.
> It seems there is no trace of the fs. I'm trying to recall any other
> operations I might have done, but if it was something else I can't
> remember what could have been. I used cfdisk, to resize another
> partition, also tried to do a 'btrfs device add' with this missing one
> (to solve the no space left in another one), otherwise it was mount /,
> mount /home (/dev/sda10), umount, repeat. Oh well.
>
> [sudo blkid]
>
> /dev/sda1: UUID="03ff3132-dfc5-4dce-8add-cf5a6c854313" BLOCK_SIZE="4096"
> TYPE="ext4" PARTLABEL="LINUX"
> PARTUUID="a6042b9f-a3fe-49e2-8dc5-98a818454b6d"
>
> /dev/sdb4: UUID="5c7201df-ff3e-4cb7-8691-8ef0c6c806ed"
> UUID_SUB="bb677c3a-6270-420f-94ce-f5b89f2c40d2" BLOCK_SIZE="4096"
> TYPE="btrfs" PARTUUID="be4190e4-8e09-4dfc-a901-463f3e162727"
>
> /dev/sda10: PARTLABEL="HOME"
> PARTUUID="6045f3f0-47a7-4b38-a392-7bebb7f654bd"
>
> [sudo btrfs insp dump-s -F /dev/sda10]
>
> superblock: bytenr=65536, device=/dev/sda10
> ---------------------------------------------------------
> csum_type               0 (crc32c)
> csum_size               4
> csum                    0x00000000 [DON'T MATCH]
> bytenr                  0
> flags                   0x0
> magic                   ........ [DON'T MATCH]
> fsid                    00000000-0000-0000-0000-000000000000
> metadata_uuid           00000000-0000-0000-0000-000000000000
> label
> generation              0
> root                    0
> sys_array_size          0
> chunk_root_generation   0
> root_level              0
> chunk_root              0
> chunk_root_level        0
> log_root                0
> log_root_transid        0
> log_root_level          0
> total_bytes             0
> bytes_used              0
> sectorsize              0
> nodesize                0
> leafsize (deprecated)   0
> stripesize              0
> root_dir                0
> num_devices             0
> compat_flags            0x0
> compat_ro_flags         0x0
> incompat_flags          0x0
> cache_generation        0
> uuid_tree_generation    0
> dev_item.uuid           00000000-0000-0000-0000-000000000000
> dev_item.fsid           00000000-0000-0000-0000-000000000000 [match]
> dev_item.type           0
> dev_item.total_bytes    0
> dev_item.bytes_used     0
> dev_item.io_align       0
> dev_item.io_width       0
> dev_item.sector_size    0
> dev_item.devid          0
> dev_item.dev_group      0
> dev_item.seek_speed     0
> dev_item.bandwidth      0
> dev_item.generation     0
>
> This as nothing to do with btrfs anymore, but: do you think a tool like
> foremost can recover the files, it'll be a mess, but better then nothing
> and I've used it before in a ntfs.

No idea.

You could scan the entire drive for the Btrfs magic, which is inside
the superblock. It will self identify its offset, the first superblock
is the one you want, which is offset 65536 (64KiB) from the start of
the block device/partition. And that superblock also says the device
size.



-- 
Chris Murphy