Tjyylli

I'm learning raids, so maybe this is some basic question, but it's not covered anywhere...

When I create raid 1, update /etc/mdadm/mdadm.conf as[1], run update-initramfs -u, I can reboot and mount it. Everything is fine. Now I remove one drive, and reboot, to simulate critical failure. raid will be wrongly detected as raid 0 (WHY?), inactive (WHY? because we "just have half of raid0?) and as such cannot be used. What I expected to see was active, degraded drive, not this fatal. What's wrong? See [2] for error state description.

Related question: why mdadm.conf [1] contains devices=/dev/sdb1,/dev/sdc1 if allegedly all partitions (resp. ones defined in DEVICE variable) should be scanned for raid UUID? So why is this part generated? What is its use and why isn't there partition UUID used instead? Could it even be used here?

[1] mdadm.conf

cat /etc/mdadm/mdadm.conf 

# 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 alfonz19gmail.com



MAILFROM vboxSystem



# definitions of existing MD arrays



# This configuration was auto-generated on Sun, 10 Feb 2019 09:57:56 +0100 by mkconf

ARRAY /dev/md0 level=raid1 num-devices=2 metadata=1.2 name=mmucha-VirtualBox1:0 UUID=16624299:11ed3af5:3a8acd02:cd24d4d0

   devices=/dev/sdb1,/dev/sdc1

root@mmucha-VirtualBox1:~# cat /etc/mdadm/mdadm.conf 

[2] errorneous state:

root@mmucha-VirtualBox1:~# cat /proc/mdstat

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 

md0 : inactive sdb1[0](S)

      5236719 blocks super 1.2



unused devices: <none>

root@mmucha-VirtualBox1:~# mdadm --detail /dev/md0

/dev/md0:

           Version : 1.2

        Raid Level : raid0

     Total Devices : 1

       Persistence : Superblock is persistent



             State : inactive

   Working Devices : 1



              Name : mmucha-VirtualBox1:0  (local to host mmucha-VirtualBox1)

              UUID : 16624299:11ed3af5:3a8acd02:cd24d4d0

            Events : 19



    Number   Major   Minor   RaidDevice



       -       8       17        -        /dev/sdb1

UPDATE creation steps

I'd wanted to share something non-interactive, but 'sfdisk' interface and functionality does not work for me; When I ask it to create gpt disklabel type and write, it 'says' it's ok, but did nothing. Ehm. So sorry, you're getting fdisk commands here.

Description: I created 2 new disks for existing VM ubuntu 18.04, set gpt partition table for both, create 1 partition for both, create raid 1, create ext4fs, mount, create some test file, update mdadm.conf, run update-initramfs -u. Reboot, verify, works. Poweroff, remove sde drive, boot. Same failure.

ubuntu release:

lsb_release -a

No LSB modules are available.

Distributor ID: Ubuntu

Description:    Ubuntu 18.04.2 LTS

Release:    18.04

Codename:   bionic

fdisk:

fdisk /dev/sdd

g

n

1





t

29

p

w

Prints:

VDisk /dev/sdd: 5 GiB, 5368709120 bytes, 10485760 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: gpt

Disk identifier: E16A3CCE-1EF7-3D45-8AEF-A70B45B047CC



Device     Start      End  Sectors Size Type

/dev/sdd1   2048 10485726 10483679   5G Linux filesystem

same for /dev/sde:

Disk /dev/sde: 5 GiB, 5368709120 bytes, 10485760 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: gpt

Disk identifier: AEE480EE-DFA8-C245-8405-658B52C7DC0A



Device     Start      End  Sectors Size Type

/dev/sde1   2048 10485726 10483679   5G Linux filesystem

raid creation:

mdadm --create /dev/md0 --level=mirror --raid-devices=2 /dev/sd[d-e]1



 mdadm --detail /dev/md1

/dev/md1:

           Version : 1.2

     Creation Time : Thu Feb 21 08:54:50 2019

        Raid Level : raid1

        Array Size : 5236672 (4.99 GiB 5.36 GB)

     Used Dev Size : 5236672 (4.99 GiB 5.36 GB)

      Raid Devices : 2

     Total Devices : 2

       Persistence : Superblock is persistent



       Update Time : Thu Feb 21 08:55:16 2019

             State : clean 

    Active Devices : 2

   Working Devices : 2

    Failed Devices : 0

     Spare Devices : 0



Consistency Policy : resync



              Name : mmucha-VirtualBox1:1  (local to host mmucha-VirtualBox1)

              UUID : 1c873dd9:87220378:fc4de07a:99db62ae

            Events : 17



    Number   Major   Minor   RaidDevice State

       0       8       49        0      active sync   /dev/sdd1

       1       8       65        1      active sync   /dev/sde1

formatting and mounting:

mkfs.ext4 /dev/md1 

mkdir /media/raid1

mount /dev/md1 /media/raid1/



mdadm --detail --scan --verbose >> /etc/mdadm.conf



update-initramfs -u



cat /etc/mdadm/mdadm.conf 

# 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 alfonz19gmail.com



MAILFROM vboxSystem



# definitions of existing MD arrays



# This configuration was auto-generated on Sun, 10 Feb 2019 09:57:56 +0100 by mkconf

ARRAY /dev/md0 level=raid1 num-devices=2 metadata=1.2 name=mmucha-VirtualBox1:0 UUID=16624299:11ed3af5:3a8acd02:cd24d4d0

   devices=/dev/sdb1,/dev/sdc1

ARRAY /dev/md1 level=raid1 num-devices=2 metadata=1.2 name=mmucha-VirtualBox1:1 UUID=1c873dd9:87220378:fc4de07a:99db62ae

   devices=/dev/sdd1,/dev/sde1

And that's it. As aforementioned, if you remove 1 hdd now, you won't be able to mount the raid:

sudo mdadm --detail /dev/md1

/dev/md1:

           Version : 1.2

        Raid Level : raid0

     Total Devices : 1

       Persistence : Superblock is persistent



             State : inactive

   Working Devices : 1



              Name : mmucha-VirtualBox1:1  (local to host mmucha-VirtualBox1)

              UUID : 1c873dd9:87220378:fc4de07a:99db62ae

            Events : 23



    Number   Major   Minor   RaidDevice



       -       8       49        -        /dev/sdd1

UPDATE 2: I tested the same commands (minus update-initramfs -u) on arch and it worked without hickup. I booted back to ubuntu VM, where I had 2 sets of 2-drive raids of level 1. I removed again one drive, and it worked: clean degraded. I did not even run that VM single time since last time. Ok, so then I removed one drive from another set. So now I should have 2 clean degraded drives on md0 and md1. But I have 2 clean degraded on md0 and md127. But I know that, so I know that I have to stop md127, run mdadm --assemble --scan to get it back on md1, run update-initramfs -u, and after reboot it should be good. But surprisingly it's not. I have md0 and md1 as expected, but each set is missing 1 drive, while 1 is in state clean degraded and other in inactive with bad level. But stopping & reassebling fix that again. All of that happened without single modification of mdadm.conf.

It's deep magic.

I had the same problem with inactive raid1 array reported as raid0. Not sure why but this fixed it for me

mdadm --stop /dev/md0

mdadm --assemble /dev/md0 --run

You must have done something bad.
Try the procedure from the beginning and send all the steps you have done.
It must work.