On Fri, Mar 8, 2019 at 9:02 PM <no_spam@xxxxxxxxxxxx> wrote: > > <<$ sudo dd if=/dev/sda1 count=2048 2>/dev/null | hexdump -C>> > > https://pastebin.com/ReEvXhK4 > > This is very curious... I'm now wondering if it wasn't a full 1M wipe. > But instead something more like > # dd if=/dev/zero of=/dev/md3 bs=446 count=1 > or maybe the Synology Nas tried to restore some of the boot sector > when it I tried to do the repair on it? This is extensive damage because it wiped multiple signatures for multiple layers of the storage stack. And repair tools frequently are too simplistic, intending to repair specific things, rather than the reconstruction required in this case; but then further, repair tools are opaque and don't apply their fixes in a reversible manner. Anyway, the hexdump from the /dev/md3 copy just adds to the confusion... line 3 is a protective MBR, line 7 is a GPT, so the previous `blkid` output showing a GPT appears to be real. And that just makes reconstruction more complicated because it's yet another layer that has to be fixed before moving to the next step. line 9 contains the backup LBA 17581481471 which is withing 1 sector of the array size from an earlier `mdadm -E /dev/sda6` command. The first problem I see at line 14 & 15, no partition entries. Line 15 is the start of a Btrfs super block. There is no LVM information first. If the /etc/lvm backup information is credible and I think it is, then LVM metadata needs to appear before a Btrfs superblock. So something is wrong... there's no way for the normal (standard) means of discovering the Btrfs super block to happen. My understanding of how this storage stack is created and assembled is incomplete. Maybe the end of /dev/md3 can provide a clue. # dd if=/dev/copyofmd3 skip=17581481438 count=33 2>/dev/null | hexdump -C So that's going to show the 33 sectors from the last usable LBA to the GPT backup header which will also include the backup tables; at least according to the primary GPT at the start of the copyofmd3. The thing is, the LVM backup information suggests /dev/md3 itself, not a partition of it, is the LVM PV. I'm hoping this GPT information is somehow bogus. > > Regardless; I just booted the NAS and did a quick 'history' to see if > it would find the real command. Of course because /dev/md3 is gone... > there's no history for my user account. > > On a whim; I did the same command for the "Safe" 4TB drive that didn't > receive the wipe. Not sure if it's of any value but here it is: > https://pastebin.com/hrHwkHyk Is this from the start of the drive? It definitely suggests some proprietary way of assembling the storage stack. -- Chris Murphy
