> Pretty weird. Any ideas how that happened? My guess is sdd was > partitioned first, and its partition was copied to sdc and sde, and > the tool blindly did not recompute the last usable sector LBA, it used > the value from sdd. I have no solid idea but my money is on a human screwing up. While trying to boot the server after the move I have no clear record of what actions were taken, however I think it was during this time when the disks were probably messed. > sdd1 is 2TB > sdd2 is 500MB > > And it looks like sdc and sde, if we believe the backup GPT, have the > same exact partition scheme. yes from the original build that was the idea > wipefs -a -n /dev/sdc > wipefs -a -n /dev/sde > > So what do you get for that? [root@lamachine ~]# wipefs -a -n /dev/sdc /dev/sdc: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa /dev/sdc: calling ioctl to re-read partition table: Success [root@lamachine ~]# wipefs -a -n /dev/sde /dev/sde: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa /dev/sde: calling ioctl to re-read partition table: Success it didn't give me any indication that it was in no-act mode but I decided to carry on with the backup flag and got this: [root@lamachine ~]# wipefs -a -b /dev/sdc wipefs: invalid option -- 'b' Usage: wipefs [options] <device> Wipe signatures from a device. Options: -a, --all wipe all magic strings (BE CAREFUL!) -b, --backup create a signature backup in $HOME -f, --force force erasure -h, --help show this help text -n, --no-act do everything except the actual write() call -o, --offset <num> offset to erase, in bytes -p, --parsable print out in parsable instead of printable format -q, --quiet suppress output messages -t, --types <list> limit the set of filesystem, RAIDs or partition tables -V, --version output version information and exit For more details see wipefs(8). [root@lamachine ~]# wipefs -V wipefs from util-linux 2.27.1 [root@lamachine ~]# wipefs -a --backup /dev/sdc /dev/sdc: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa /dev/sdc: calling ioctl to re-read partition table: Success [root@lamachine ~]# wipefs -a --backup /dev/sde /dev/sde: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa /dev/sde: calling ioctl to re-read partition table: Success [root@lamachine ~]# before proceeding with manually creating both partitions could you confirm the above is kind of expected? > Chances are you could just use gdisk to verify and fix the primary and > backup GPTs on sdc and sde Will the fix be offered as part of the verify command in gdisk (command: v)? > When it's all done and working with the new MBR you can either leave > it alone, or you can run gdisk on it and it will immediately convert > it (in memory) and you can commit it to disk with the w command to go > back to GPT so just running the w command after running the verify command while on the same session ? -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
