Build and migrated to software raid (mdadm) on GPT disk, now can't assemble array
- by John H
mdadm, gpt issues, unrecognized partitions.
Simplified question: How do I get mdadm to recognize GPT partitions?
I have been attempting to convert/copy my Ubuntu 11.10 OS from a single drive to software raid 1. I have done similar in the past, but in this case, I was adding in a drive that has been configured for GPT and I tried to work with that without fully looking into the implications.
Currently, I have a non-booting mdadm RAID 1 array of /dev/md127 (the OS assigned that and it keeps picking up). I am booting off of live USB keys, currently System Rescue CD from sysresccd. While gdisk and parted can see all the partitions, most of the OS utilities do not, including mdadm. My main goal is just to make the raid array accessible so I can get pull the data and start fresh (without using GPT).
/dev/md127
/dev/sda
/dev/sda1 <- GPT type partition
/dev/sda1 <- exists within the GPT part, member of md127
/dev/sda2 <- exists within the GPT part, empty
/dev/sdb
/dev/sdb1 <- GPT type partition
/dev/sdb1 <- exists within the GPT part, member of md127
History:
POINT A:
The original OS was install on sda (actually /dev/sda6). I used a the Ubuntu live usb to add sdb. I got warning from fdisk about GPT so I used gdisk to create a raid partition (sdb1) and mdadm to create a raid1 mirror with a missing drive. I had many issues getting this working (including being unable to get grub to install) but I eventually got it to boot using grub on sda and /dev/md127 off of sdb. So at point A, I had copied my OS from sda6 to md127 on sdb. I then booted into a rescue mode and attempted to get a bootloader onto sdb, which failed. I then discovered my mistake: I had installed the raid onto sdb instead of sdb1, essentially overwriting the sdb1 partition.
POINT B:
I now had two copies of my data- one on md127/sdb, and one on sda. I destroyed data on sda and created a new GPT table on sda. I then created sda1 for the raid array, and sda2 for a scratch partition. I added sda1 into the raid array and let it rebuild. md127 now covered /dev/sdb and /dev/sda1 as fully active and synced.
POINT C:
I rebooted onto linux rescue again and was still able to access the raid array. I then removed /dev/sdb from the array and created /dev/sdb1 for the raid. I added sdb1 to the array and let it sync. I was able to mount and access /dev/md127 without issues. Once it completed, both /dev/sda1 and /dev/sdb1 were GPT partitions and actively syncing.
POINT D (current):
I rebooted again to test if the array would boot and grub failed to load. I booted off of my live thumb drive and found that I can no longer assemble the raid array. mdadm doesn't see the required partitions.
--
root@freshdesk /root % uname -a
Linux freshdesk 3.0.24-std251-amd64 #2 SMP Sat Mar 17 12:08:55 UTC 2012 x86_64 AMD Athlon(tm) II X4 645 Processor AuthenticAMD GNU/Linux
===
/proc/partitions and parted look good:
root@freshdesk /root % cat /proc/partitions
major minor #blocks name
7 0 301788 loop0
8 0 976762584 sda
8 1 732579840 sda1
8 2 244181703 sda2
8 16 732574584 sdb
8 17 732573543 sdb1
8 32 7876607 sdc
8 33 7873349 sdc1
(parted) print all
Model: ATA ST31000528AS (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1049kB 750GB 750GB ext4
2 750GB 1000GB 250GB Linux/Windows data
Model: ATA SAMSUNG HD753LJ (scsi)
Disk /dev/sdb: 750GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1049kB 750GB 750GB ext4 Linux RAID raid
Model: SanDisk SanDisk Cruzer (scsi)
Disk /dev/sdc: 8066MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 31.7kB 8062MB 8062MB primary fat32 boot, lba
===
# no sda2, and I double the sdb1 is the one shown in parted
root@freshdesk /root % blkid
/dev/loop0: TYPE="squashfs"
/dev/sda1: UUID="75dd6c2d-f0a8-4302-9da4-792cc7d72355" TYPE="ext4"
/dev/sdc1: LABEL="PENDRIVE" UUID="1102-3720" TYPE="vfat"
/dev/sdb1: UUID="2dd89f15-65bb-ff88-e368-bf24bd0fce41" TYPE="linux_raid_member"
root@freshdesk /root % mdadm -E /dev/sda1
mdadm: No md superblock detected on /dev/sda1.
# this is probably a result of me attempting to force the array up, putting superblocks on the GPT partition
root@freshdesk /root % mdadm -E /dev/sdb1
/dev/sdb1:
Magic : a92b4efc
Version : 0.90.00
UUID : 2dd89f15:65bbff88:e368bf24:bd0fce41
Creation Time : Fri Mar 30 19:25:30 2012
Raid Level : raid1
Used Dev Size : 732568320 (698.63 GiB 750.15 GB)
Array Size : 732568320 (698.63 GiB 750.15 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 127
Update Time : Sat Mar 31 12:39:38 2012
State : clean
Active Devices : 1
Working Devices : 2
Failed Devices : 1
Spare Devices : 1
Checksum : a7d038b3 - correct
Events : 20195
Number Major Minor RaidDevice State
this 2 8 17 2 spare /dev/sdb1
0 0 8 1 0 active sync /dev/sda1
1 1 0 0 1 faulty removed
2 2 8 17 2 spare /dev/sdb1
===
root@freshdesk /root % mdadm -A /dev/md127 /dev/sda1 /dev/sdb1
mdadm: no recogniseable superblock on /dev/sda1
mdadm: /dev/sda1 has no superblock - assembly aborted
root@freshdesk /root % mdadm -A /dev/md127 /dev/sdb1
mdadm: cannot open device /dev/sdb1: Device or resource busy
mdadm: /dev/sdb1 has no superblock - assembly aborted
