Re: Inactive arrays

[Daniel Sanabria <sanabria.d@gmail.com>]

> 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 ?