> So yes you can just run gdisk, go to expert menu with x, then verify > with v, and print the table with p, and post all of that and we'll > confirm before you use w to write out the fixed table. choices now: [root@lamachine ~]# gdisk /dev/sdc GPT fdisk (gdisk) version 1.0.1 Warning! Disk size is smaller than the main header indicates! Loading secondary header from the last sector of the disk! You should use 'v' to verify disk integrity, and perhaps options on the experts' menu to repair the disk. Caution: invalid backup GPT header, but valid main header; regenerating backup header from main header. Warning! One or more CRCs don't match. You should repair the disk! Partition table scan: MBR: not present BSD: not present APM: not present GPT: damaged Found invalid MBR and corrupt GPT. What do you want to do? (Using the GPT MAY permit recovery of GPT data.) 1 - Use current GPT 2 - Create blank GPT Your answer: On 14 September 2016 at 15:32, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > On Wed, Sep 14, 2016 at 4:36 AM, Daniel Sanabria <sanabria.d@xxxxxxxxx> wrote > >> 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' > > Huh, must be a bug. Works for me with util-linux-2.28.1-1.fc24.x86_64 > and I also get files in the user home. > > -rw-------. 1 root root 2 Sep 13 22:13 wipefs-sdb-0x000001fe.bak > -rw-------. 1 root root 8 Sep 13 22:13 wipefs-sdb-0x00000200.bak > -rw-------. 1 root root 8 Sep 13 22:13 wipefs-sdb-0x3ba7ffe00.bak > > Those are backups for the PMBR, primary GPT and backup GPT. > > > >> before proceeding with manually creating both partitions could you >> confirm the above is kind of expected? > > I expected that it would find the GPT's also and erase their signature > and write out backup files. Oh well. > > > >>> 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)? > > It actually does the fix in memory as soon as you run the command, and > v just elaborates on any problems that don't make sense like > overlapping partitions etc. > > So yes you can just run gdisk, go to expert menu with x, then verify > with v, and print the table with p, and post all of that and we'll > confirm before you use w to write out the fixed table. > > > >> >>> 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 ? > > Yes but let's just skip the fdisk stuff. There is already a primary > and backup GPT, and you even have a backup of the backup with the > good on on sdd that confirms all of the numbers. So, I think it's safe > to just move foward with the repair using gdisk. But post the verify, > and print command output first, before writing out the change. > > > -- > Chris Murphy -- 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
