On 2018年01月15日 00:36, evan d wrote: > I removed two partitionless Btrfs formatted drives from an Arch Linux > based PC and installed them in another Linux based PC also running > Arch. The drives are independent of one another, each containing its > own Btrfs filesystem. Both machines are running recent kernels and > the original host would be running whatever kernel was current in Arch > on 1 Jan 2018. > > lsblk shows the two drives as partitionless as I'd expect, but > attempting to mount them returns an error saying they're not > recognised and btrfs filesystem show /dev/sdX also returns that the > devices do not contain a Brtfs partition. 1 Jan 2018 was the last > time I accessed these drives, which were mounted via the first > machine's fstab. > > blkid returns PTTYPE="PMBR" for both. > > For the current machine: > uname -a returns: > Linux ryzen 4.14.13-1-ARCH #1 SMP PREEMPT Wed Jan 10 11:14:50 UTC 2018 > x86_64 GNU/Linux
Nice to see another Ryzen system. :) > > btrfs --version returns: > btrfs-progs v4.14 > > > Any ideas what could have gone wrong here? I'm hoping that > reinserting them in the original machine may allow me to access the > underlying data again, but that machine is in another country at > present. btrfs inspect dump-super -Ffa will help us to determine if it's still a btrfs filesystem. And it's also recommended to use grep to find the btrfs magic in the beginning several MB range to ensure there is no offset screwing up fs detection: dd if=<device> of=/tmp/output bs=1M count=128 grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" /tmp/output Thanks, Qu > > Any help much appreciated. > > Thanks > Evan > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
signature.asc
Description: OpenPGP digital signature
