Skip to contentSkip to conversation

Raid array is not automatically detected.

DISCUSSION Bryan Christ 7 participants 17 messages Jul 13, 2007 – Jul 18, 2007 MD RAID

lore
Share & tools
lore
#0 lore raw

My apologies if this is not the right place to ask this question. Hopefully it is.

I created a RAID5 array with:

mdadm --create /dev/md0 --level=5 --raid-devices=5 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

mdadm -D /dev/md0 verifies the devices has a persistent super-block, but upon reboot, /dev/md0 does not get automatically assembled (an hence is not a installable/bootable device).

I have created several raid1 arrays and one raid5 array this way and have never had this problem. In all fairness, this is the first time I have used mdadm for the job. Usually, I boot to something like SysRescueCD, used raidtools to create my array and then reboot with my Slackware install CD.

Anyone know why this might be happening?

Bryan

#1 lore raw
Quoted 12 lines · Bryan Christ

My apologies if this is not the right place to ask this question. Hopefully it is.

I created a RAID5 array with:

mdadm --create /dev/md0 --level=5 --raid-devices=5 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

mdadm -D /dev/md0 verifies the devices has a persistent super-block, but upon reboot, /dev/md0 does not get automatically assembled (an hence is not a installable/bootable device).

Quoted 7 lines

I have created several raid1 arrays and one raid5 array this way and have never had this problem. In all fairness, this is the first time I have used mdadm for the job. Usually, I boot to something like SysRescueCD, used raidtools to create my array and then reboot with my Slackware install CD.

Anyone know why this might be happening?

Are you trying to boot on this raid device? I believe there is a limitation as what raid type you can boot off of (IIRC. only raid0 and raid1).

Signature · 1 line
Zivago Lee <[email protected]>
#2 lore raw

I would like for it to be the boot device. I have setup a raid5 mdraid array before and it was automatically accessible as /dev/md0 after every reboot. In this peculiar case, I am having to assemble the array manually before I can access it...

mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

Unless I do the above, I cannot access /dev/md0. I've never had this happen before. Usually a cursory glance through dmesg will show that the array was detected, but not so in this case.

Quoted 17 lines · Zivago Lee
Quoted 11 lines · Bryan Christ

My apologies if this is not the right place to ask this question. Hopefully it is.

I created a RAID5 array with:

mdadm --create /dev/md0 --level=5 --raid-devices=5 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

mdadm -D /dev/md0 verifies the devices has a persistent super-block, but upon reboot, /dev/md0 does not get automatically assembled (an hence is not a installable/bootable device).

I have created several raid1 arrays and one raid5 array this way and have never had this problem. In all fairness, this is the first time I have used mdadm for the job. Usually, I boot to something like SysRescueCD, used raidtools to create my array and then reboot with my Slackware install CD.

Anyone know why this might be happening?

Are you trying to boot on this raid device? I believe there is a limitation as what raid type you can boot off of (IIRC. only raid0 and raid1).

#3 lore raw
In reply to Bryan Christ
Quoted 11 lines · Bryan Christ

My apologies if this is not the right place to ask this question. Hopefully it is.

I created a RAID5 array with:

mdadm --create /dev/md0 --level=5 --raid-devices=5 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

mdadm -D /dev/md0 verifies the devices has a persistent super-block, but upon reboot, /dev/md0 does not get automatically assembled (an hence is not a installable/bootable device).

I have created several raid1 arrays and one raid5 array this way and have never had this problem. In all fairness, this is the first time I have used mdadm for the job. Usually, I boot to something like SysRescueCD, used raidtools to create my array and then reboot with my Slackware install CD.

Anyone know why this might be happening?

Old type arrays are assembled due to having the proper partition type, 0xfd "Linux auto RAID" and are assembled by the kernel. All others are assembled by mdadm running out of initrd or similar, and failures there result from not having a proper config file in the initrd image.

IIRC raidtools does set the array partitions to the auto-assemble partition type. Hope that points you in the right direction. Running
"fdisk -l"
as root will let you see all the partitions, types, etc, for everything on your system.

I may be wrong, I thought auto-assemble only worked with type 0 or 1.

Signature · 3 lines
bill davidsen <[email protected]>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979
#4 lore raw
Quoted 13 lines · Bill Davidsen
Quoted 11 lines · Bryan Christ

My apologies if this is not the right place to ask this question. Hopefully it is.

I created a RAID5 array with:

mdadm --create /dev/md0 --level=5 --raid-devices=5 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

mdadm -D /dev/md0 verifies the devices has a persistent super-block, but upon reboot, /dev/md0 does not get automatically assembled (an hence is not a installable/bootable device).

I have created several raid1 arrays and one raid5 array this way and have never had this problem. In all fairness, this is the first time I have used mdadm for the job. Usually, I boot to something like SysRescueCD, used raidtools to create my array and then reboot with my Slackware install CD.

Anyone know why this might be happening?

Quoted 18 lines

Old type arrays are assembled due to having the proper partition type, 0xfd "Linux auto RAID" and are assembled by the kernel. All others are assembled by mdadm running out of initrd or similar, and failures there result from not having a proper config file in the initrd image.

IIRC raidtools does set the array partitions to the auto-assemble partition type. Hope that points you in the right direction. Running
"fdisk -l"
as root will let you see all the partitions, types, etc, for everything on your system.

I may be wrong, I thought auto-assemble only worked with type 0 or 1.

Signature · 8 lines
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

I use auto-assemble (in conjunction with Debian's own startup scripts) and for my root RAID1 device,swap and /boot, it is automatically taken care of by the kernel. For RAID5, it seems to work the same:

[   58.919378] RAID5 conf printout:
[   58.919418]  --- rd:10 wd:10
[   58.919457]  disk 0, o:1, dev:sdc1
[   58.919498]  disk 1, o:1, dev:sdd1
[   58.919539]  disk 2, o:1, dev:sde1
[   58.919579]  disk 3, o:1, dev:sdf1
[   58.919619]  disk 4, o:1, dev:sdg1
[   58.919659]  disk 5, o:1, dev:sdh1
[   58.919719]  disk 6, o:1, dev:sdi1
[   58.919759]  disk 7, o:1, dev:sdj1
[   58.919799]  disk 8, o:1, dev:sdk1
[   58.919839]  disk 9, o:1, dev:sdl1

Justin.

#5 lore raw
Quoted 30 lines · Justin Piszcz
Quoted 26 lines · Bill Davidsen
Quoted 11 lines · Bryan Christ

My apologies if this is not the right place to ask this question. Hopefully it is.

I created a RAID5 array with:

mdadm --create /dev/md0 --level=5 --raid-devices=5 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

mdadm -D /dev/md0 verifies the devices has a persistent super-block, but upon reboot, /dev/md0 does not get automatically assembled (an hence is not a installable/bootable device).

I have created several raid1 arrays and one raid5 array this way and have never had this problem. In all fairness, this is the first time I have used mdadm for the job. Usually, I boot to something like SysRescueCD, used raidtools to create my array and then reboot with my Slackware install CD.

Anyone know why this might be happening?

Old type arrays are assembled due to having the proper partition type, 0xfd "Linux auto RAID" and are assembled by the kernel. All others are assembled by mdadm running out of initrd or similar, and failures there result from not having a proper config file in the initrd image.

IIRC raidtools does set the array partitions to the auto-assemble partition type. Hope that points you in the right direction. Running
"fdisk -l"
as root will let you see all the partitions, types, etc, for everything on your system.

I may be wrong, I thought auto-assemble only worked with type 0 or 1.

Signature · 3 lines
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
Quoted 8 lines
Quoted 5 lines

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

I use auto-assemble (in conjunction with Debian's own startup scripts) and for my root RAID1 device,swap and /boot, it is automatically taken care of by the kernel. For RAID5, it seems to work the same:

Are those partitions type "Linux RAID" or is the assemble being run from the init scripts? I suspect the latter.

Quoted 15 lines
[   58.919378] RAID5 conf printout:
[   58.919418]  --- rd:10 wd:10
[   58.919457]  disk 0, o:1, dev:sdc1
[   58.919498]  disk 1, o:1, dev:sdd1
[   58.919539]  disk 2, o:1, dev:sde1
[   58.919579]  disk 3, o:1, dev:sdf1
[   58.919619]  disk 4, o:1, dev:sdg1
[   58.919659]  disk 5, o:1, dev:sdh1
[   58.919719]  disk 6, o:1, dev:sdi1
[   58.919759]  disk 7, o:1, dev:sdj1
[   58.919799]  disk 8, o:1, dev:sdk1
[   58.919839]  disk 9, o:1, dev:sdl1

Justin.

Signature · 3 lines
bill davidsen <[email protected]>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979
#6 lore raw
Quoted 37 lines · Bill Davidsen
Quoted 36 lines · Justin Piszcz
Quoted 31 lines · Bill Davidsen
Quoted 11 lines · Bryan Christ

My apologies if this is not the right place to ask this question. Hopefully it is.

I created a RAID5 array with:

mdadm --create /dev/md0 --level=5 --raid-devices=5 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

mdadm -D /dev/md0 verifies the devices has a persistent super-block, but upon reboot, /dev/md0 does not get automatically assembled (an hence is not a installable/bootable device).

I have created several raid1 arrays and one raid5 array this way and have never had this problem. In all fairness, this is the first time I have used mdadm for the job. Usually, I boot to something like SysRescueCD, used raidtools to create my array and then reboot with my Slackware install CD.

Anyone know why this might be happening?

Old type arrays are assembled due to having the proper partition type, 0xfd "Linux auto RAID" and are assembled by the kernel. All others are assembled by mdadm running out of initrd or similar, and failures there result from not having a proper config file in the initrd image.

IIRC raidtools does set the array partitions to the auto-assemble partition type. Hope that points you in the right direction. Running
"fdisk -l"
as root will let you see all the partitions, types, etc, for everything on your system.

I may be wrong, I thought auto-assemble only worked with type 0 or 1.

Signature · 8 lines
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Quoted 17 lines
Quoted 2 lines

I use auto-assemble (in conjunction with Debian's own startup scripts) and for my root RAID1 device,swap and /boot, it is automatically taken care of by the kernel. For RAID5, it seems to work the same:

Are those partitions type "Linux RAID" or is the assemble being run from the init scripts? I suspect the latter.

Quoted 14 lines
[   58.919378] RAID5 conf printout:
[   58.919418]  --- rd:10 wd:10
[   58.919457]  disk 0, o:1, dev:sdc1
[   58.919498]  disk 1, o:1, dev:sdd1
[   58.919539]  disk 2, o:1, dev:sde1
[   58.919579]  disk 3, o:1, dev:sdf1
[   58.919619]  disk 4, o:1, dev:sdg1
[   58.919659]  disk 5, o:1, dev:sdh1
[   58.919719]  disk 6, o:1, dev:sdi1
[   58.919759]  disk 7, o:1, dev:sdj1
[   58.919799]  disk 8, o:1, dev:sdk1
[   58.919839]  disk 9, o:1, dev:sdl1

Justin.

The partitions are 0xfd: Auto-detect:

/dev/sdc1               1       18241   146520801   fd  Linux raid autodetect
/dev/sdd1               1       18241   146520801   fd  Linux raid autodetect
/dev/sde1               1       18241   146520801   fd  Linux raid autodetect
/dev/sdf1               1       18241   146520801   fd  Linux raid autodetect
/dev/sdg1               1       18241   146520801   fd  Linux raid autodetect
/dev/sdh1               1       18241   146520801   fd  Linux raid autodetect
/dev/sdi1               1       18241   146520801   fd  Linux raid autodetect
/dev/sdj1               1       18241   146520801   fd  Linux raid autodetect
/dev/sdk1               1       18241   146520801   fd  Linux raid autodetect
/dev/sdl1               1       18241   146520801   fd  Linux raid autodetect
#7 lore raw
In reply to Justin Piszcz

I do have the type set to 0xfd. Others have said that auto-assemble only works on RAID 0 and 1, but just as Justin mentioned, I too have another box with RAID5 that gets auto assembled by the kernel (also no initrd). I expected the same behavior when I built this array--again using mdadm instead of raidtools.

Quoted 52 lines · Justin Piszcz
Quoted 13 lines · Bill Davidsen
Quoted 11 lines · Bryan Christ

My apologies if this is not the right place to ask this question. Hopefully it is.

I created a RAID5 array with:

mdadm --create /dev/md0 --level=5 --raid-devices=5 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

mdadm -D /dev/md0 verifies the devices has a persistent super-block, but upon reboot, /dev/md0 does not get automatically assembled (an hence is not a installable/bootable device).

I have created several raid1 arrays and one raid5 array this way and have never had this problem. In all fairness, this is the first time I have used mdadm for the job. Usually, I boot to something like SysRescueCD, used raidtools to create my array and then reboot with my Slackware install CD.

Anyone know why this might be happening?

Quoted 18 lines

Old type arrays are assembled due to having the proper partition type, 0xfd "Linux auto RAID" and are assembled by the kernel. All others are assembled by mdadm running out of initrd or similar, and failures there result from not having a proper config file in the initrd image.

IIRC raidtools does set the array partitions to the auto-assemble partition type. Hope that points you in the right direction. Running
"fdisk -l"
as root will let you see all the partitions, types, etc, for everything on your system.

I may be wrong, I thought auto-assemble only worked with type 0 or 1.

Signature · 8 lines
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

I use auto-assemble (in conjunction with Debian's own startup scripts) and for my root RAID1 device,swap and /boot, it is automatically taken care of by the kernel. For RAID5, it seems to work the same:

[   58.919378] RAID5 conf printout:
[   58.919418]  --- rd:10 wd:10
[   58.919457]  disk 0, o:1, dev:sdc1
[   58.919498]  disk 1, o:1, dev:sdd1
[   58.919539]  disk 2, o:1, dev:sde1
[   58.919579]  disk 3, o:1, dev:sdf1
[   58.919619]  disk 4, o:1, dev:sdg1
[   58.919659]  disk 5, o:1, dev:sdh1
[   58.919719]  disk 6, o:1, dev:sdi1
[   58.919759]  disk 7, o:1, dev:sdj1
[   58.919799]  disk 8, o:1, dev:sdk1
[   58.919839]  disk 9, o:1, dev:sdl1

Justin.

#8 lore raw
Quoted 1 line · Bryan Christ

I do have the type set to 0xfd. Others have said that auto-assemble only works on RAID 0 and 1, but just as Justin mentioned, I too have another box with RAID5 that gets auto assembled by the kernel (also no initrd). I expected the same behavior when I built this array--again using mdadm instead of raidtools.

Any md arrays with partition type 0xfd using a 0.9 superblock should be auto-assembled by a standard kernel.

If you want to boot from them you must ensure the kernel image is on a partition that the bootloader can read - ie RAID 0. This is nothing to do with auto-assembly.

So some questions:
* are the partitions 0xfd ? yes.
* is the kernel standard?
* are the superblocks version 0.9? (mdadm --examine /dev/component)

David

#9 lore raw
Quoted 9 lines · David Greaves
Quoted 5 lines · Bryan Christ

I do have the type set to 0xfd. Others have said that auto-assemble only works on RAID 0 and 1, but just as Justin mentioned, I too have another box with RAID5 that gets auto assembled by the kernel (also no initrd). I expected the same behavior when I built this array--again using mdadm instead of raidtools.

Any md arrays with partition type 0xfd using a 0.9 superblock should be auto-assembled by a standard kernel.

no... debian (and probably ubuntu) do not build md into the kernel, they build it as a module, and the module does not auto-detect 0xfd. i don't know anything about slackware, but i just felt it worth commenting that "a standard kernel" is not really descriptive enough.

-dean

#10 lore raw
Quoted 14 lines · dean gaudet
Quoted 9 lines · David Greaves
Quoted 5 lines · Bryan Christ

I do have the type set to 0xfd. Others have said that auto-assemble only works on RAID 0 and 1, but just as Justin mentioned, I too have another box with RAID5 that gets auto assembled by the kernel (also no initrd). I expected the same behavior when I built this array--again using mdadm instead of raidtools.

Any md arrays with partition type 0xfd using a 0.9 superblock should be auto-assembled by a standard kernel.

Quoted 7 lines

no... debian (and probably ubuntu) do not build md into the kernel, they build it as a module, and the module does not auto-detect 0xfd. i don't know anything about slackware, but i just felt it worth commenting that "a standard kernel" is not really descriptive enough.

-dean

You're correct-- however, I build out my own kernel.

Justin.

#11 lore raw
In reply to dean gaudet
Quoted 9 lines · dean gaudet
Quoted 6 lines · David Greaves
Quoted 5 lines · Bryan Christ

I do have the type set to 0xfd. Others have said that auto-assemble only works on RAID 0 and 1, but just as Justin mentioned, I too have another box with RAID5 that gets auto assembled by the kernel (also no initrd). I expected the same behavior when I built this array--again using mdadm instead of raidtools.

Quoted 4 lines
Quoted 2 lines

Any md arrays with partition type 0xfd using a 0.9 superblock should be auto-assembled by a standard kernel.

no... debian (and probably ubuntu) do not build md into the kernel, they build it as a module, and the module does not auto-detect 0xfd. i don't know anything about slackware, but i just felt it worth commenting that "a standard kernel" is not really descriptive enough.

Good point - I should have mentioned the non-module bit!

http://linux-raid.osdl.org/index.php/Autodetect

David

#12 lore raw
In reply to David Greaves

I'm now very confused...

When I run mdadm --examine /dev/md0 I get the error message: No superblock detected on /dev/md0

However, when I run mdadm -D /dev/md0 the report clearly states "Superblock is persistent"

/dev/md0:

        Version : 00.90.03

Creation Time : Tue Jul 17 10:17:37 2007
Raid Level : raid5
Array Size : 1953535744 (1863.04 GiB 2000.42 GB)
Used Dev Size : 488383936 (465.76 GiB 500.11 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Wed Jul 18 10:17:34 2007
State : clean
Active Devices : 5
Working Devices : 5
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 64K

UUID : ea6c5a9f:021b4ff8:fc5a08c4:23fc5c4b
Events : 0.4

Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
2 8 33 2 active sync /dev/sdc1
3 8 49 3 active sync /dev/sdd1
4 8 65 4 active sync /dev/sde1

Quoted 14 lines · David Greaves
Quoted 1 line · Bryan Christ

I do have the type set to 0xfd. Others have said that auto-assemble only works on RAID 0 and 1, but just as Justin mentioned, I too have another box with RAID5 that gets auto assembled by the kernel (also no initrd). I expected the same behavior when I built this array--again using mdadm instead of raidtools.

Any md arrays with partition type 0xfd using a 0.9 superblock should be auto-assembled by a standard kernel.

If you want to boot from them you must ensure the kernel image is on a partition that the bootloader can read - ie RAID 0. This is nothing to do with auto-assembly.

So some questions:
* are the partitions 0xfd ? yes.
* is the kernel standard?
* are the superblocks version 0.9? (mdadm --examine /dev/component)

David

#13 lore raw
Quoted 1 line · Bryan Christ

I'm now very confused...

It's all that top-posting...

Quoted 6 lines

When I run mdadm --examine /dev/md0 I get the error message: No superblock detected on /dev/md0

However, when I run mdadm -D /dev/md0 the report clearly states "Superblock is persistent"

Quoted 1 line · David Greaves

* are the superblocks version 0.9? (mdadm --examine /dev/component)

See where it says 'component' ? :)

I wish mdadm --detail and --examine were just aliases and the output varied according to whether you looked at a component (eg /dev/sda1) or an md device (/dev/md0)

I get that wrong *all* the time...

David

#14 lore raw

Ya. I saw my mistake just a little while ago and running --examine on the component worked fine. I didn't see anything suspicious.

Quoted 19 lines · David Greaves
Quoted 1 line · Bryan Christ

I'm now very confused...

It's all that top-posting...

Quoted 6 lines

When I run mdadm --examine /dev/md0 I get the error message: No superblock detected on /dev/md0

However, when I run mdadm -D /dev/md0 the report clearly states "Superblock is persistent"

Quoted 1 line · David Greaves

* are the superblocks version 0.9? (mdadm --examine /dev/component)

See where it says 'component' ? :)

I wish mdadm --detail and --examine were just aliases and the output varied according to whether you looked at a component (eg /dev/sda1) or an md device (/dev/md0)

I get that wrong *all* the time...

David

#15 lore raw
In reply to David Greaves
Quoted 6 lines · David Greaves

See where it says 'component' ? :)

I wish mdadm --detail and --examine were just aliases and the output varied according to whether you looked at a component (eg /dev/sda1) or an md device (/dev/md0)

I get that wrong *all* the time...

Neil, if you will take that as a suggestion, you can take this as a second. While I have learned to use the correct option most of the time, this is a case where the software can make an unambiguous decision to avoid the human having to stop and think which option is appropriate.

Signature · 3 lines
bill davidsen <[email protected]>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979
#16 lore raw
Quoted 8 lines · On Wednesday July 18, [email protected] wrote:
Quoted 7 lines · David Greaves

See where it says 'component' ? :)

I wish mdadm --detail and --examine were just aliases and the output varied according to whether you looked at a component (eg /dev/sda1) or an md device (/dev/md0)

Quoted 6 lines
Quoted 1 line

I get that wrong *all* the time...

Neil, if you will take that as a suggestion, you can take this as a second. While I have learned to use the correct option most of the time, this is a case where the software can make an unambiguous decision to avoid the human having to stop and think which option is appropriate.

The software cannot make an unambiguous decision. It is quite possible for one md device to be a component of another md device. In that case, --examine and --detail are both very meaningful and very different.

If you have trouble remembering the difference, train yourself to use --query instead.

I am willing to consider suggestions for improving the error message when -D or -E don't find what they expect.
I am willing to add aliases that might make it easier to remember the difference (I confess that I chose 'detail' and 'examine' largely because they start with 'd' and 'e', to go with assemble, build, and create)
I am willing to make --query more useful if anyone has any suggestions.
But I am not willing to make --detail and --examine behave identically.

NeilBrown