Missing RAID-10 after shutdown/restart

DerPhil31 · 5. März 2024

Hi,

I had to shutdown my NAS, did this via power btn as usual. NAS shut down after a while. So far everything went as normal (pwer btn is configured to "shut down")

Now I am missing my RAID 10, 4 x ST8000VN0022-2EL112 (8TB SATA drives). The single drives are listed properly. They appear as sdc...sdf and are all connected directly to the onboard SATA controller.

A simple

Code

root@omv5:~# mdadm --assemble --scan
mdadm: Fail to create md0 when using /sys/module/md_mod/parameters/new_array, fallback to creation via node
mdadm: /dev/md0 is already in use.

did not work.

Code

root@omv5:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [ra                                             id10]
md0 : active raid1 sdb[1] sda[0]
      19531693056 blocks super 1.2 [2/2] [UU]
      bitmap: 0/146 pages [0KB], 65536KB chunk

unused devices: <none>

Code

root@omv5:~# blkid
/dev/sdf: UUID="7880e29c-7e10-8585-07a7-de53a0202f0c" UUID_SUB="2eddf677-d864-09f8-fb32-28e93a182907" LABEL="omv5:0" TYPE="linux_raid_member"
/dev/sdd: UUID="7880e29c-7e10-8585-07a7-de53a0202f0c" UUID_SUB="56f2ca3e-b755-4b2b-4a86-e5a0ef8b3132" LABEL="omv5:0" TYPE="linux_raid_member"
/dev/sdb: UUID="37da4029-f22c-71a8-60e4-374a0a6da7fb" UUID_SUB="5b845c85-a1a5-12dd-0a07-1c5002a3d95d" LABEL="omv3:0" TYPE="linux_raid_member"
/dev/md0: UUID="5afbf069-9b76-484d-91f2-724406af67b8" BLOCK_SIZE="4096" TYPE="xfs"
/dev/sdg5: UUID="000e208b-d3cc-44bd-9882-23b227df94e4" TYPE="swap" PARTUUID="17e4cf92-05"
/dev/sdg1: UUID="13ca13fc-8bad-4071-8a5a-4af9b7ee456d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="17e4cf92-01"
/dev/sde: UUID="7880e29c-7e10-8585-07a7-de53a0202f0c" UUID_SUB="9b02534d-1767-a1db-6fd3-63be8a982169" LABEL="omv5:0" TYPE="linux_raid_member"
/dev/sdc: UUID="7880e29c-7e10-8585-07a7-de53a0202f0c" UUID_SUB="46df13e0-d1f3-af87-92c8-f253c4a624ac" LABEL="omv5:0" TYPE="linux_raid_member"
/dev/sda: UUID="37da4029-f22c-71a8-60e4-374a0a6da7fb" UUID_SUB="ce47e707-988f-78ea-14f2-367bef1c6a75" LABEL="omv3:0" TYPE="linux_raid_member"

Code

root@omv5:~# cat /etc/mdadm/mdadm.conf
# This file is auto-generated by openmediavault (https://www.openmediavault.org)
# WARNING: Do not edit this file, your changes will get lost.

# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
# Note, if no DEVICE line is present, then "DEVICE partitions" is assumed.
# To avoid the auto-assembly of RAID devices a pattern that CAN'T match is
# used if no RAID devices are configured.
DEVICE partitions

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR alex@masked.z
MAILFROM root

# definitions of existing MD arrays
ARRAY /dev/md0 metadata=1.2 name=omv5:0 UUID=7880e29c:7e108585:07a7de53:a0202f0c
ARRAY /dev/md/omv3:0 metadata=1.2 name=omv3:0 UUID=37da4029:f22c71a8:60e4374a:0a6da7fb

Alles anzeigen

Code

root@omv5:~# mdadm --detail --scan --verbose
ARRAY /dev/md/omv3:0 level=raid1 num-devices=2 metadata=1.2 name=omv3:0 UUID=37da4029:f22c71a8:60e4374a:0a6da7fb
   devices=/dev/sda,/dev/sdb

I'd really appreciate if you could help me with that!

Krisbee · 5. März 2024

Have you done an examine of the 4 drives that were in the RAiD10 to check events count/update time?

E.g. mdadm -E /dev/sd[cf] | grep -E "Event|Update" and check which drives are in which mirror pair.

Next to try is mdadm --assemble /dev/mdXXX --force /dev/sd[cf] which will give some feedback if it fails. The mdXXX number will be in the past boot logs if you don't remember it.

It one or more drives will not rebuild, just cross fingers it's not from the same mirror pair.

DerPhil31 · 5. März 2024

Hi, thanks for your response. All drives ran their weekly SMART test a few days ago and there where no probs announced.

Following your recommendation

Code

mdadm -E /dev/sd[cf] | grep -E "Event|Update"
    Update Time : Mon Mar  4 07:36:51 2024
         Events : 25342
    Update Time : Mon Mar  4 07:36:51 2024
         Events : 25342

Do I need to specify the recently used MDxxx number or can I use any number except for md0 which is in use?

DerPhil31 · 5. März 2024

A bit strange but the boot log mentions a Hitachi disc drive (2TB) which is definitely not connected to the system

Code

2024-03-05T17:41:44+0100 omv5 run-parts[747]: /dev/disk/by-id/ata-Hitachi_HDS5C3020ALA632_ML0230FA0U3H7D: Unable to detect device type
2024-03-05T17:41:44+0100 omv5 run-parts[747]: Please specify device type with the -d option.
2024-03-05T17:41:44+0100 omv5 run-parts[747]: Use smartctl -h to get a usage summary
2024-03-05T17:41:44+0100 omv5 smartd[744]: smartd 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-18-amd64] (local build)
2024-03-05T17:41:44+0100 omv5 smartd[744]: Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org
2024-03-05T17:41:44+0100 omv5 smartd[744]: Opened configuration file /etc/smartd.conf
2024-03-05T17:41:44+0100 omv5 run-parts[742]: run-parts: /etc/smartmontools/hdparm.d//openmediavault-dev-disk-by-id-ata-Hitachi_HDS5C302

DerPhil31 · 5. März 2024

OK I've tried that, because it seems to persist until the next reboot only

Code

root@omv5:~# mdadm --assemble /dev/md127 --force /dev/sdc /dev/sdd /dev/sdf /dev/sdg
mdadm: /dev/md127 has been started with 4 drives.

Code

root@omv5:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md127 : active (auto-read-only) raid10 sdg[0] sdf[3] sdc[2] sdd[1]
      15627788288 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 0/117 pages [0KB], 65536KB chunk

md0 : active raid1 sdb[1] sda[0]
      19531693056 blocks super 1.2 [2/2] [UU]
      bitmap: 0/146 pages [0KB], 65536KB chunk

unused devices: <none>

Alles anzeigen

It looks like the RAID is up and running again but I can't access the data - I assume because the file system is not initialized properly?

Krisbee · 5. März 2024

Zitat von DerPhil31
Hi, thanks for your response. All drives ran their weekly SMART test a few days ago and there where no probs announced.

Following your recommendation
Code
mdadm -E /dev/sd[cf] | grep -E "Event|Update"
    Update Time : Mon Mar  4 07:36:51 2024
         Events : 25342
    Update Time : Mon Mar  4 07:36:51 2024
         Events : 25342
Do I need to specify the recently used MDxxx number or can I use any number except for md0 which is in use?

Only two out four disks? Check the full output of mdadm -E /dev/sd[cf] Which two disk show up and are they in the same or different mirror pair?

Krisbee · 5. März 2024

A cross post. So ignore the last one. md127 is in auto-read-only which should clear. If it remains in that state after re-sync is finished, then use

mdadm --readwrite /deb/md127

DerPhil31 · 5. März 2024

Hi, thanks for taking your time! I see that we newbiews are keeping you busy today

When I look at the shared folders configuration I can see that the expected device (the missing RAID) is referenced as

Code

/dev/disk/by-uuid/71c1090c-fc3f-4ecf-b159-b30036a53704

whereas the shard folders on the other RAID show

Code

/dev/md0

So should I try to repeat the assembly by using the device name given above?:

Code

root@omv5:~# mdadm --assemble /dev/disk/by-uuid/71c1090c-fc3f-4ecf-b159-b30036a53704 --force /dev/sdc /dev/sdd /dev/sdf /dev/sdg

[Edit]

Of course, this didn't work. Sorry for confusion.

Question is how can I access the data on the reassembled RAID volume? The configured file system is shown as "online" but does not show any information about available/used space.

DerPhil31 · 5. März 2024

Zitat

Check the full output of mdadm -E /dev/sd[cf]

It seems that [cf] is not interpreted properly, it actually show the information of the two drives, only. [cefg] is looking more complete

Code

root@omv5:/srv# mdadm -E /dev/sd[cefg]
/dev/sdc:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 7880e29c:7e108585:07a7de53:a0202f0c
           Name : omv5:0  (local to host omv5)
  Creation Time : Mon Jul  3 22:09:02 2023
     Raid Level : raid10
   Raid Devices : 4

 Avail Dev Size : 15627788976 sectors (7.28 TiB 8.00 TB)
     Array Size : 15627788288 KiB (14.55 TiB 16.00 TB)
  Used Dev Size : 15627788288 sectors (7.28 TiB 8.00 TB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264104 sectors, after=688 sectors
          State : clean
    Device UUID : 46df13e0:d1f3af87:92c8f253:c4a624ac

Internal Bitmap : 8 sectors from superblock
    Update Time : Tue Mar  5 20:21:46 2024
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : da87d700 - correct
         Events : 25343

         Layout : near=2
     Chunk Size : 512K

   Device Role : Active device 2
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sde:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 7880e29c:7e108585:07a7de53:a0202f0c
           Name : omv5:0  (local to host omv5)
  Creation Time : Mon Jul  3 22:09:02 2023
     Raid Level : raid10
   Raid Devices : 4

 Avail Dev Size : 15627788976 sectors (7.28 TiB 8.00 TB)
     Array Size : 15627788288 KiB (14.55 TiB 16.00 TB)
  Used Dev Size : 15627788288 sectors (7.28 TiB 8.00 TB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264104 sectors, after=688 sectors
          State : clean
    Device UUID : 56f2ca3e:b7554b2b:4a86e5a0:ef8b3132

Internal Bitmap : 8 sectors from superblock
    Update Time : Tue Mar  5 20:21:46 2024
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : afd9eed7 - correct
         Events : 25343

         Layout : near=2
     Chunk Size : 512K

   Device Role : Active device 1
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdf:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 7880e29c:7e108585:07a7de53:a0202f0c
           Name : omv5:0  (local to host omv5)
  Creation Time : Mon Jul  3 22:09:02 2023
     Raid Level : raid10
   Raid Devices : 4

 Avail Dev Size : 15627788976 sectors (7.28 TiB 8.00 TB)
     Array Size : 15627788288 KiB (14.55 TiB 16.00 TB)
  Used Dev Size : 15627788288 sectors (7.28 TiB 8.00 TB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264104 sectors, after=688 sectors
          State : clean
    Device UUID : 9b02534d:1767a1db:6fd363be:8a982169

Internal Bitmap : 8 sectors from superblock
    Update Time : Tue Mar  5 20:21:46 2024
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : c3266a3f - correct
         Events : 25343

         Layout : near=2
     Chunk Size : 512K

   Device Role : Active device 3
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdg:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 7880e29c:7e108585:07a7de53:a0202f0c
           Name : omv5:0  (local to host omv5)
  Creation Time : Mon Jul  3 22:09:02 2023
     Raid Level : raid10
   Raid Devices : 4

 Avail Dev Size : 15627788976 sectors (7.28 TiB 8.00 TB)
     Array Size : 15627788288 KiB (14.55 TiB 16.00 TB)
  Used Dev Size : 15627788288 sectors (7.28 TiB 8.00 TB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264104 sectors, after=688 sectors
          State : clean
    Device UUID : 2eddf677:d86409f8:fb3228e9:3a182907

Internal Bitmap : 8 sectors from superblock
    Update Time : Tue Mar  5 20:21:46 2024
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : d2fe21cc - correct
         Events : 25343

         Layout : near=2
     Chunk Size : 512K

   Device Role : Active device 0
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)

Alles anzeigen

I can see it here (last line) but how to continue?

Code

root@omv5:/srv# blkid
/dev/sdf: UUID="7880e29c-7e10-8585-07a7-de53a0202f0c" UUID_SUB="9b02534d-1767-a1db-6fd3-63be8a982169" LABEL="omv5:0" TYPE="li                                            nux_raid_member"
/dev/sdd5: UUID="000e208b-d3cc-44bd-9882-23b227df94e4" TYPE="swap" PARTUUID="17e4cf92-05"
/dev/sdd1: UUID="13ca13fc-8bad-4071-8a5a-4af9b7ee456d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="17e4cf92-01"
/dev/sdb: UUID="37da4029-f22c-71a8-60e4-374a0a6da7fb" UUID_SUB="5b845c85-a1a5-12dd-0a07-1c5002a3d95d" LABEL="omv3:0" TYPE="li                                            nux_raid_member"
/dev/md0: UUID="5afbf069-9b76-484d-91f2-724406af67b8" BLOCK_SIZE="4096" TYPE="xfs"
/dev/sdg: UUID="7880e29c-7e10-8585-07a7-de53a0202f0c" UUID_SUB="2eddf677-d864-09f8-fb32-28e93a182907" LABEL="omv5:0" TYPE="li                                            nux_raid_member"
/dev/sde: UUID="7880e29c-7e10-8585-07a7-de53a0202f0c" UUID_SUB="56f2ca3e-b755-4b2b-4a86-e5a0ef8b3132" LABEL="omv5:0" TYPE="li                                            nux_raid_member"
/dev/sdc: UUID="7880e29c-7e10-8585-07a7-de53a0202f0c" UUID_SUB="46df13e0-d1f3-af87-92c8-f253c4a624ac" LABEL="omv5:0" TYPE="li                                            nux_raid_member"
/dev/sda: UUID="37da4029-f22c-71a8-60e4-374a0a6da7fb" UUID_SUB="ce47e707-988f-78ea-14f2-367bef1c6a75" LABEL="omv3:0" TYPE="li                                            nux_raid_member"
/dev/md127: UUID="71c1090c-fc3f-4ecf-b159-b30036a53704" BLOCK_SIZE="4096" TYPE="xfs"

Alles anzeigen

Krisbee · 5. März 2024

The [cf] thing was my error, thinking your 4 drives were consecutively lettered cdef. The question is do the current fstab contents marry with the

/dev/md127 fs UUID. If so, then mount -a should mount the xfs fs on the RAID10.

DerPhil31 · 5. März 2024

Great!

mount mount -a did the job. Thank you so much.

How can I make sure that this will happen automatically again on next reboot?

Krisbee · 5. März 2024

There's no action to take if the fiIesystem now appears in the Webui and there's no pendng config change to apply. So, it should be all OK on the next boot

DerPhil31 · 5. März 2024

I've just tried that. The RAID10 is not available after reboot.

A quick

Code

mdadm --assemble
mdadm --readwrite /dev/md127
mount -a

worked of course, even without --force but I am a bit confused now. One thing that I have mentioned is that the boot drive has repeatedly changed the device name after reboot. It is now dev/sdf and was dev/sde before rebooting.

Perhaps this is what confuses the system on startup?

Krisbee · 5. März 2024

OK, let' re-check the basics. This is OMV5, which by the way is long long overdue for upgrade to OMV6 and them OMV7, so does cat/etc/fstab need changing? Post output of cat /etc/fstab , blkid, and cat /proc/mdstat I'll be back tomorrow.

DerPhil31 · 6. März 2024

Thanks again! I'll be back around 19:00h Berlin Time.

The name is misleading, it is actually Version 7.0-32 (Sandworm). I've built this as OMV v6 and upgraded to v7 a while a go.

Shutting down / restarting has never been a problem (until yesterday).

Even when I've tried to improve performance by using a PCI host controller everything appeared at the right place after connecting the drives from the onboard controller to the dedicated controller. Finally I've moved back to the onboard controller because there was only little performance improvement and the host controller took a lot of extra power, getting quite hot as well. But this back and forth was done many days before the incident.

Code

root@omv5:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=13ca13fc-8bad-4071-8a5a-4af9b7ee456d /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=000e208b-d3cc-44bd-9882-23b227df94e4 none            swap    sw              0       0
# >>> [openmediavault]
/dev/disk/by-uuid/71c1090c-fc3f-4ecf-b159-b30036a53704          /srv/dev-disk-by-uuid-71c1090c-fc3f-4ecf-b159-b30036a53704      xfs     defaults,nofail,usrquota,grpquota,inode64       0 2
/dev/disk/by-uuid/5afbf069-9b76-484d-91f2-724406af67b8          /srv/dev-disk-by-uuid-5afbf069-9b76-484d-91f2-724406af67b8      xfs     defaults,nofail,usrquota,grpquota,inode64       0 2
# <<< [openmediavault]

Alles anzeigen

Code

root@omv5:~# blkid
/dev/sdf5: UUID="000e208b-d3cc-44bd-9882-23b227df94e4" TYPE="swap" PARTUUID="17e4cf92-05"
/dev/sdf1: UUID="13ca13fc-8bad-4071-8a5a-4af9b7ee456d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="17e4cf92-01"
/dev/sdd: UUID="7880e29c-7e10-8585-07a7-de53a0202f0c" UUID_SUB="9b02534d-1767-a1db-6fd3-63be8a982169" LABEL="omv5:0" TYPE="linux_raid_member"
/dev/sdb: UUID="37da4029-f22c-71a8-60e4-374a0a6da7fb" UUID_SUB="5b845c85-a1a5-12dd-0a07-1c5002a3d95d" LABEL="omv3:0" TYPE="linux_raid_member"
/dev/md0: UUID="5afbf069-9b76-484d-91f2-724406af67b8" BLOCK_SIZE="4096" TYPE="xfs"
/dev/sdg: UUID="7880e29c-7e10-8585-07a7-de53a0202f0c" UUID_SUB="2eddf677-d864-09f8-fb32-28e93a182907" LABEL="omv5:0" TYPE="linux_raid_member"
/dev/sde: UUID="7880e29c-7e10-8585-07a7-de53a0202f0c" UUID_SUB="56f2ca3e-b755-4b2b-4a86-e5a0ef8b3132" LABEL="omv5:0" TYPE="linux_raid_member"
/dev/sdc: UUID="7880e29c-7e10-8585-07a7-de53a0202f0c" UUID_SUB="46df13e0-d1f3-af87-92c8-f253c4a624ac" LABEL="omv5:0" TYPE="linux_raid_member"
/dev/sda: UUID="37da4029-f22c-71a8-60e4-374a0a6da7fb" UUID_SUB="ce47e707-988f-78ea-14f2-367bef1c6a75" LABEL="omv3:0" TYPE="linux_raid_member"
/dev/md127: UUID="71c1090c-fc3f-4ecf-b159-b30036a53704" BLOCK_SIZE="4096" TYPE="xfs"
/dev/sdh1: LABEL="Toshiba3" BLOCK_SIZE="512" UUID="6C4C479D4C4760C6" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="0000eed5-7390-24fb-aead-d301aadd0100"

Alles anzeigen

/dev/sdh1 is only temporarily connected

Code

root@omv5:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md127 : active raid10 sdg[0] sdd[3] sdc[2] sde[1]
      15627788288 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 0/117 pages [0KB], 65536KB chunk

md0 : active raid1 sdb[1] sda[0]
      19531693056 blocks super 1.2 [2/2] [UU]
      bitmap: 0/146 pages [0KB], 65536KB chunk

unused devices: <none>

Alles anzeigen

Krisbee · 6. März 2024

Bit of a late night post yesterday which should have read "If this is omv5". Anyway, looking back to your first post I'd forgotten your mdadm.conf file only had the details of one array. So I don't know if you'd over-written it at some stage. A copy of the mdadm.conf is part of the system initrd and should match the current /etc/mdadm/mdadm.conf file.

Can you please post the output of:

mdadm --detail --scan

cat /etc/mdadm/mdadm.conf

DerPhil31 · 6. März 2024

Hey there, sorry for letting you wait

Code

root@omv5:~# mdadm --detail --scan
ARRAY /dev/md/omv3:0 metadata=1.2 name=omv3:0 UUID=37da4029:f22c71a8:60e4374a:0a6da7fb
ARRAY /dev/md127 metadata=1.2 name=omv5:0 UUID=7880e29c:7e108585:07a7de53:a0202f0c

Code

root@omv5:~# cat /etc/mdadm/mdadm.conf
# This file is auto-generated by openmediavault (https://www.openmediavault.org)
# WARNING: Do not edit this file, your changes will get lost.

# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
# Note, if no DEVICE line is present, then "DEVICE partitions" is assumed.
# To avoid the auto-assembly of RAID devices a pattern that CAN'T match is
# used if no RAID devices are configured.
DEVICE partitions

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR xxx
MAILFROM root

# definitions of existing MD arrays
ARRAY /dev/md0 metadata=1.2 name=omv5:0 UUID=7880e29c:7e108585:07a7de53:a0202f0c
ARRAY /dev/md/omv3:0 metadata=1.2 name=omv3:0 UUID=37da4029:f22c71a8:60e4374a:0a6da7fb

Alles anzeigen

Krisbee · 6. März 2024

The ARRAY defs in the /etc/mdadm/mdadm.conf and the results of mdadm --detail --scan should match. Using this command at the CLI should fix that:

Code

omv-salt deploy run initramfs mdadm

DerPhil31 · 6. März 2024

Code

root@omv5:~# omv-salt deploy run initramfs mdadm
debian:
----------
          ID: update_initramfs_nop
    Function: test.nop
      Result: True
     Comment: Success!
     Started: 21:31:12.958022
    Duration: 0.382 ms
     Changes:
----------
          ID: update_initramfs
    Function: cmd.run
        Name: update-initramfs -u
      Result: True
     Comment: Command "update-initramfs -u" run
     Started: 21:31:12.959200
    Duration: 14667.686 ms
     Changes:
              ----------
              pid:
                  367928
              retcode:
                  0
              stderr:
              stdout:
                  update-initramfs: Generating /boot/initrd.img-6.1.0-18-amd64
----------
          ID: remove_cron_daily_mdadm
    Function: file.absent
        Name: /etc/cron.daily/mdadm
      Result: True
     Comment: File /etc/cron.daily/mdadm is not present
     Started: 21:31:27.632520
    Duration: 1.334 ms
     Changes:
----------
          ID: divert_cron_daily_mdadm
    Function: omv_dpkg.divert_add
        Name: /etc/cron.daily/mdadm
      Result: True
     Comment: Leaving 'local diversion of /etc/cron.daily/mdadm to /etc/cron.daily/mdadm.distrib'
     Started: 21:31:27.635093
    Duration: 15.888 ms
     Changes:
----------
          ID: configure_default_mdadm
    Function: file.managed
        Name: /etc/default/mdadm
      Result: True
     Comment: File /etc/default/mdadm is in the correct state
     Started: 21:31:27.651224
    Duration: 147.129 ms
     Changes:
----------
          ID: configure_mdadm_conf
    Function: file.managed
        Name: /etc/mdadm/mdadm.conf
      Result: True
     Comment: File /etc/mdadm/mdadm.conf updated
     Started: 21:31:27.798451
    Duration: 92.509 ms
     Changes:
              ----------
              diff:
                  ---
                  +++
                  @@ -23,5 +23,3 @@
                   MAILFROM root

                   # definitions of existing MD arrays
                  -ARRAY /dev/md0 metadata=1.2 name=omv5:0 UUID=7880e29c:7e108585:07a7de53:a0202f0c
                  -ARRAY /dev/md/omv3:0 metadata=1.2 name=omv3:0 UUID=37da4029:f22c71a8:60e4374a:0a6da7fb
----------
          ID: mdadm_save_config
    Function: cmd.run
        Name: mdadm --detail --scan >> /etc/mdadm/mdadm.conf
      Result: True
     Comment: Command "mdadm --detail --scan >> /etc/mdadm/mdadm.conf" run
     Started: 21:31:27.891055
    Duration: 13.467 ms
     Changes:
              ----------
              pid:
                  372280
              retcode:
                  0
              stderr:
              stdout:

Summary for debian
------------
Succeeded: 7 (changed=3)
Failed:    0
------------
Total states run:     7
Total run time:  14.938 s

Alles anzeigen

DerPhil31 · 6. März 2024

Now it seems to be identical

Code

root@omv5:~# mdadm --detail --scan
ARRAY /dev/md/omv3:0 metadata=1.2 name=omv3:0 UUID=37da4029:f22c71a8:60e4374a:0a6da7fb
ARRAY /dev/md127 metadata=1.2 name=omv5:0 UUID=7880e29c:7e108585:07a7de53:a0202f0c

Code

root@omv5:~# cat /etc/mdadm/mdadm.conf
# This file is auto-generated by openmediavault (https://www.openmediavault.org)
#
...
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR xxx
MAILFROM root

# definitions of existing MD arrays
ARRAY /dev/md/omv3:0 metadata=1.2 name=omv3:0 UUID=37da4029:f22c71a8:60e4374a:0a6da7fb
ARRAY /dev/md127 metadata=1.2 name=omv5:0 UUID=7880e29c:7e108585:07a7de53:a0202f0c

Alles anzeigen

Missing RAID-10 after shutdown/restart

Jetzt mitmachen!

Tags