4

While I see that there are multiple other questions that seem to be about the same (or similar) issue, none of them have a difinitive answer. Hence, I ask it again.

I am following the guide here (external, Digital Ocean), specifically the "Raid 1" guide. I follow all the steps, yet when I reboot, mdadm seems to forget about the raid array created.

When recreated, it seems fine and the data on the drive seems to persist after recreation, though mdadm needs to re-sync and build the array all over again (which takes many hours). To clarify, all I need to do to get the raid drive back is to rerun the create command and remount the array.

I followed the "Save the Array Layout" section to a tee, yet this still happens. Can anyone offer guidance on how to make the array stick around?

If anyone wants to see the output of something, just ask.

/dev/sdb/ and /dev/sdc/ are the drives I am using for the array, /dev/md0 is the array.

Output of sudo blkid after reboot:

/dev/nvme0n1: PTUUID="a2ac4afb-a9fe-4c9c-aafd-ffe2e144b803" PTTYPE="gpt"
/dev/nvme0n1p1: UUID="f9b2e155-854d-4a5d-a67e-17bd15f38289" TYPE="ext4" PARTUUID="72fd637a-3f84-4c87-a1fc-6dd4d093ee1d"
/dev/sda1: LABEL="Recovery" UUID="56FEDCF2FEDCCAFF" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="ba0395b4-48a6-45b1-b340-cf4bfe1d29d2"
/dev/sda2: UUID="1ADD-CEB5" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="2024cdff-4b6f-460e-827d-7443180849e6"
/dev/sda3: PARTLABEL="Microsoft reserved partition" PARTUUID="b0475376-4a4c-4388-8c13-486587f441d9"
/dev/sda4: UUID="22D0E70AD0E6E2D1" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="e4d35323-a0b8-4a47-9722-193cc6cd1197"
/dev/sdb: PTUUID="aea84627-3e11-46a5-8a09-96510cae3a1a" PTTYPE="gpt"
/dev/sdc: PTUUID="76fce25c-b721-441b-b82e-b42d2d43d24b" PTTYPE="gpt"

Output of sudo blkid after re-creating raid array:

/dev/nvme0n1p1: UUID="f9b2e155-854d-4a5d-a67e-17bd15f38289" TYPE="ext4" PARTUUID="72fd637a-3f84-4c87-a1fc-6dd4d093ee1d"
/dev/sda1: LABEL="Recovery" UUID="56FEDCF2FEDCCAFF" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="ba0395b4-48a6-45b1-b340-cf4bfe1d29d2"
/dev/sda2: UUID="1ADD-CEB5" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="2024cdff-4b6f-460e-827d-7443180849e6"
/dev/sda4: UUID="22D0E70AD0E6E2D1" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="e4d35323-a0b8-4a47-9722-193cc6cd1197"
/dev/nvme0n1: PTUUID="a2ac4afb-a9fe-4c9c-aafd-ffe2e144b803" PTTYPE="gpt"
/dev/sda3: PARTLABEL="Microsoft reserved partition" PARTUUID="b0475376-4a4c-4388-8c13-486587f441d9"
/dev/sdb: UUID="f80520f0-6304-ccc5-0ec2-bd8f6a2af079" UUID_SUB="5a38cecf-4236-db6a-d369-a53271993698" LABEL="BATTLESTAR:0" TYPE="linux_raid_member"
/dev/md0: LABEL="DataStore" UUID="c5be481b-d487-4632-8594-7b0b847f327a" TYPE="ext4"
/dev/sdc: UUID="f80520f0-6304-ccc5-0ec2-bd8f6a2af079" UUID_SUB="cd27b6f9-d6e3-1c22-8746-3f2ebb3c5eb4" LABEL="BATTLESTAR:0" TYPE="linux_raid_member"

Contents of /etc/mdadm/mdadm.conf: (I make sure to update this on every recreate to ensure the UUID is updated)

# mdadm.conf
#
# !NB! Run update-initramfs -u after updating this file.
# !NB! This will ensure that initramfs has an uptodate copy.
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays

# This configuration was auto-generated on Mon, 05 Mar 2018 19:04:50 -0500 by mkconf

ARRAY /dev/md0 metadata=1.2 name=BATTLESTAR:0 UUID=f80520f0:6304ccc5:0ec2bd8f:6a2af079
Improve this question
9
  • How are you adding the entries to the /etc/fstab file? I recommend adding the arrays by using their UUID #s that you get from running sudo blkid. Looking on my system here with two different arrays on one system all my mounts are using the UUIDs and not the /dev/md info.
    – Terrance
    Mar 7, 2018 at 3:16
  • Good though, but did not fix the problem, it looks like the whole array is forgotten about after a reboot...
    – Snappawapa
    Mar 7, 2018 at 3:29
  • What type of drives are you using to create the array(s) on?
    – Terrance
    Mar 7, 2018 at 3:33
  • 4TB HDD's (two of exact same model), unsure of what else you might mean
    – Snappawapa
    Mar 7, 2018 at 3:34
  • I am sure that sdb and sdc are the HDD's that I am trying to use. I can see in the drives utility that they are the ones, and none of my other drives have been overwritten (they are both used for OS's, the Ubuntu install I am setting this up on and a windows install)
    – Snappawapa
    Mar 7, 2018 at 3:43

3 Answers 3

Reset to default
4

Allright, I figured it out, thanks to a tip from another question....

What ended up solving my problem was creating an ext4 partition on each drive, and pointing mdadm at the partitions and not the drives themselves. After that, the array was persistent after reboot.

I did not try this before this question because the other question had not marked the answer as accepted.

Improve this answer
1
  • this is a mistake that is very easy to do if you are in the rush... even because, if you do fakeRaid, using Intel RST, it will request the drives not the partitions, on the other hand, md is a software raid!
    – Thiago Conrado
    Apr 9, 2020 at 22:58
3

I too followed the advice here and found myself in the same situation following a reboot. The reason why this happens is because at least one of the HDDs was previously used and probably contains a partition table.

The solution is to remove the partition table prior to creating the RAID array.

I overwrote the first 4MB of data on my HDDs prior to creating the array:

dd if=/dev/zero of=/dev/sdb bs=4096 count=1000
dd if=/dev/zero of=/dev/sdc bs=4096 count=1000
mdadm --create --verbose /dev/md0 --level=0 --raid-devices=2 /dev/sdb /dev/sdc

Problem solved.

Improve this answer
0
1

I know it's an old post, but I was struggling with this issue and this is my result:

My disks were "frozen" - Seagate disks. You can check, if you have same issue by entering command:

hdparm -I /dev/sdb

Which showed:

Security: 
Master password revision code = 65534
    supported
not enabled
not locked
    frozen
not expired: security count
    supported: enhanced erase

I wasn't able to change this setting. The disks worked fine with regular partitions, but when I was formatting them as linux raid, they lost they partition table and were "empty" after reboot.

I created raid on partitions, not on devices:

mdadm --create --verbose /dev/md1 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1

And now they are fine after reboot and everything works as expected.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .