4

I have recently upgraded the hardware in my home server (Mainboard, CPU, RAM) from an old i3-540 (Clarkdale) to a new i5-7400 (Kaby Lake).

I'm running Linux Mint 18 and had configured a software RAID6 with 5 drives with mdadm. I read up on the procedure of moving the raid to the new system and was assured that I just had to run

mdadm --assemble --scan

and the drives would be detected.

Unfortunately this was not the case. After upgrading the hardware and booting up the old OS with the new hardware, everything seemed to run fine, but after I connected the RAID drives, not a single one of them was detected by mdadm.

$ mdadm --assemble --scan --verbose
mdadm: looking for devices for further assembly
mdadm: Cannot assemble mbr metadata on /dev/sdf
mdadm: Cannot assemble mbr metadata on /dev/sde
mdadm: Cannot assemble mbr metadata on /dev/sdd
mdadm: Cannot assemble mbr metadata on /dev/sdc
mdadm: Cannot assemble mbr metadata on /dev/sdb
mdadm: No arrays found in config file or automatically

As far as I remember, the RAID was created directly on the disks (no partitions). All drives are now detected with 100% free space and no partitions.

GDisk shows the protective MBR on all drives as this:

Disk size is 15628053168 sectors (7.3 TiB)
MBR disk identifier: 0x00000000
MBR partitions:

Number  Boot  Start Sector   End Sector   Status      Code
   1                     1   4294967295   primary     0xEE

The drives themselves seem to be fine, there are no S.M.A.R.T. errors on any of them.

Is it possible that the superblocks got overwritten somehow when upgrading? Could it be that the UEFI bios on the new MB somehow scrambled them (old MB: Gigabyte GA-H55N-USB3, new MB: ASRock Z270M-ITX/ac)?

I read that it might be possible to "just recreate" the array by running

mdadm --create ...

with the same settings again, but since all drives are connected to new SATA ports I don't know any kind of order they were in (which seems to be important) and I'm very hesitant to just trial and error this.

I'd appreciate any kind of help you can give or pointers how to solve this.


Maybe these outputs are helpful:

$ mdadm --assemble --run --force /dev/md0 /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf
mdadm: Cannot assemble mbr metadata on /dev/sdb
mdadm: /dev/sdb has no superblock - assembly aborted

$ sudo fdisk -l /dev/sdb
Medium /dev/sdb: 7,3 TiB, 8001563222016 Bytes, 15628053168 Sektoren
Einheiten: sectors von 1 * 512 = 512 Bytes
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Typ der Medienbezeichnung: gpt
Medienkennung: 06B4B33D-1857-4745-8A54-86B65E5244D5

$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
unused devices: <none>

$ parted /dev/sdb --align optimal unit MiB print
Modell: ATA ST8000VN0022-2EL (scsi)
Festplatte  /dev/sdb:  7630885MiB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang  Ende  Größe  Dateisystem  Name  Flags
  • You say that RAID was created directly on a disks with no partitions. However, gdisk shows there is a partition. How was it created? What if you get rid of the partition? (at least temporarily, you may recreate it later if necessary). – xhienne Aug 15 '17 at 13:32
  • What do you get with mdadm --examine /dev/sdb and mdadm --examine /dev/sdb1? – roaima Aug 15 '17 at 13:40
  • Hm, that's a good point. Just double checked with GParted and the mint disk utility. There are actually no partitions on the drives. I assume what is shown there is an entry in the MBR that directs to an (empty) GPT partition table. Apparently the 0xEE is for a "Legacy MBR with following EFI-Header". I don't know what code was there in the old system. Apparently there is a "0xFD" for "Linux RAID", but I don't know how to (and if I should) set this. – Martin Fobian Aug 15 '17 at 13:42
  • Don't change anything on the disks just now. – roaima Aug 15 '17 at 13:43
  • 1
    I have ordered new drives to create clones. I know not to change anything before that's done. – Martin Fobian Aug 15 '17 at 13:46
1

So apparently the only thing that was broken were the superblocks. I cloned three of the five drives and reworked (this old script) to try and reassemble the array with mdadm --create and mount the underlying filesystem. After that I only had to re-sync the other two drives.

  • Did you fix the problem on the old or new mainboard? I believe this is a misfeature of ASRock mainboards. I just upgraded from a Gigabyte H97-HD3 to an ASRock Z97 Extreme 6 and found, just like you, that the mdraid superblocks on 3 of my 4 disks had been zeroed (in the offsets [0x1000-0x4000)). I also used whole disks for the RAID. I could recover the data by just recreating the RAID. But I can confirm that the mainboard zeroes the superblocks on every reboot; I can reproduce this reliably. I'll write more about it later. Can you confirm whether your ASRock mainboard does this every boot? – nh2 Nov 14 '18 at 21:59
  • I have posted a question and details about this on the ASRock forum: forum.asrock.com/… – nh2 Nov 14 '18 at 22:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.