Intermittant software raid issues with rawhide, what component to file against?

[Bruno Wolff III]

I have been having some intermittant problems booting where a raid device
isn't usable and the boot halts. I have only gone through this twice,
but both times the first time it happened it referred to one of the
two mirrors, after rebooting it referred to the other such array and
then the third reboot worked. I have some other arrays with just one
device in the mirror and those weren't a problem either time I had to
go through that process.
In both cases the error message referred to a problem with the superblock,
but I expect the real problem was that the array wasn't set up properly.
I am not sure what component to file this under? (As of yesterday, a search
for rawhide bugs mentioning raid in the summary turned up zilch.)

[Bryn M. Reeves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bruno Wolff III wrote:
>  I have been having some intermittant problems booting where a raid
> device
>  isn't usable and the boot halts. I have only gone through this twice,
>  but both times the first time it happened it referred to one of the
>  two mirrors, after rebooting it referred to the other such array and
>  then the third reboot worked. I have some other arrays with just one
>  device in the mirror and those weren't a problem either time I had to
>  go through that process.
>  In both cases the error message referred to a problem with the superblock,
>  but I expect the real problem was that the array wasn't set up properly.
>  I am not sure what component to file this under? (As of yesterday, a search
>  for rawhide bugs mentioning raid in the summary turned up zilch.) 
I've had a problem with the initrd based array activation as well:

https://bugzilla.redhat.com/show_bug.cgi?id=431720

[ just edited the summary to include "RAID" as well as "MD" ]

Although, from your description these might be completely unrelated -
I've only seen the "mdadm: /dev/mdX not identified in config file."
message in my case.

Regards,
Bryn.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFHq1Vl6YSQoMYUY94RAughAKCVOrI8mCFaLqFy0XJSKOyrx2xa8gCgqa+F
> fBHIeAOJJFCVJ2pxOKIeoQc=
> =jecE
> -----END PGP SIGNATURE-----

[Clyde E. Kunkel]

----- Original Message ----- 
From: "Bruno Wolff III" <bruno(a)wolff.to&gt;
To: <fedora-test-list(a)redhat.com&gt;
Sent: Thursday, February 07, 2008 1:32 PM
Subject: Intermittant software raid issues with rawhide,what component to 
file against?


> I have been having some intermittant problems booting where a raid
> device
>  isn't usable and the boot halts. I have only gone through this twice,
>  but both times the first time it happened it referred to one of the
>  two mirrors, after rebooting it referred to the other such array and
>  then the third reboot worked. I have some other arrays with just one
>  device in the mirror and those weren't a problem either time I had to
>  go through that process.
>  In both cases the error message referred to a problem with the superblock,
>  but I expect the real problem was that the array wasn't set up properly.
>  I am not sure what component to file this under? (As of yesterday, a 
>  search
>  for rawhide bugs mentioning raid in the summary turned up zilch.)
>
>  -- 
>  fedora-test-list mailing list
>  fedora-test-list(a)redhat.com
>  To unsubscribe:
>  https://www.redhat.com/mailman/listinfo/fedora-test-list
>  

What version of fedora?  What kind of raid? raid0, raid1, raid5?  Are you 
using strictly software raid?  I.e, not a true hardware raid controller? 
What is in your /etc/mdadm.conf?

I have seen problems when mkinitrd did not include the proper kernel modules 
in the initrd.  If your system is up-to-date, then that should not be the 
problem.  Also, I have had problems with multipath and always use the kernel 
parm "nompath" when doing a Fedora install since anaconda seems to be 
confused by bios' with so-called raid controllers that are being used in ide 
only format.

Currently, I am having issues with a rawhide installation and software raid 
since the raidsets are no longer started by sysinit, but are supposedly 
started by udev.  I have to do a manual mdadm --assemble /dev/mdX --scan to 
get some of the arrays going.

There doesn't seem to be a lot of love in Fedora land for raid probs, but 
then, it just may be me.

[Bruno Wolff III]

On Thu, Feb 07, 2008 at 23:13:42 -0500,
  Clyde Kunkel <clydekunkel7734(a)cox.net&gt; wrote:
>  
>  What version of fedora?  What kind of raid? raid0, raid1, raid5?  Are you  
Rawhide.

Raid 1, but only arrays with 2 elements have been affected so far. I have
some arrays set up with only one element (so that I can easily add another
one later) and so far none of those have had a problem. But the sample size
is small.

>  using strictly software raid?  I.e, not a true hardware raid
> controller?  
I am using the md driver, pure software raid.

>  What is in your /etc/mdadm.conf? 
# mdadm.conf written out by anaconda
DEVICE partitions
MAILADDR root
ARRAY /dev/md1 level=raid1 num-devices=2 uuid=6cf47316:faf57853:754c4d69:9d0b9ccc
ARRAY /dev/md0 level=raid1 num-devices=2 uuid=7d0d1910:4b7868f2:bbeae172:e70451dc

Even though only two arrays are described there, the other arrays are being
correctly started. Probably the partition information is tipping whatever
off, since linux software raid partitions have their own partition type
code.

>  I have seen problems when mkinitrd did not include the proper kernel
>
>  modules in the initrd.  If your system is up-to-date, then that should not  
This seems unlikely since the same kernel module would be used for all of
the arrays, so it would be odd for only one to fail if it was a problem
with a module not being loaded.

>  be the problem.  Also, I have had problems with multipath and always
> use 
>  the kernel parm "nompath" when doing a Fedora install since anaconda seems 
>  to be confused by bios' with so-called raid controllers that are being used 
>  in ide only format. 
I am not using multipath.

>  Currently, I am having issues with a rawhide installation and
> software raid 
>  since the raidsets are no longer started by sysinit, but are supposedly 
>  started by udev.  I have to do a manual mdadm --assemble /dev/mdX --scan to 
>  get some of the arrays going. 
Does that mean udev is probably the correct component to file a bug in this
case?

[Bill Nottingham]

Bruno Wolff III (bruno(a)wolff.to) said: 
>  > Currently, I am having issues with a rawhide installation and
> software raid 
>  > since the raidsets are no longer started by sysinit, but are supposedly 
>  > started by udev.  I have to do a manual mdadm --assemble /dev/mdX --scan to 
>  > get some of the arrays going.
>  
>  Does that mean udev is probably the correct component to file a bug in this
>  case? 
The udev rules are designed (intentionally) to only assemble arrays that
are in the mdadm.conf file. Are these arrays listed there?

Bill

[Bruno Wolff III]

On Fri, Feb 08, 2008 at 11:06:23 -0500,
  Bill Nottingham <notting(a)redhat.com&gt; wrote:
>  Bruno Wolff III (bruno(a)wolff.to) said: 
>  > > Currently, I am having issues with a rawhide installation and software raid 
>  > > since the raidsets are no longer started by sysinit, but are supposedly 
>  > > started by udev.  I have to do a manual mdadm --assemble /dev/mdX --scan to 
>  > > get some of the arrays going.
>  > 
>  > Does that mean udev is probably the correct component to file a bug in this
>  > case?
>  
>  The udev rules are designed (intentionally) to only assemble arrays that
>  are in the mdadm.conf file. Are these arrays listed there? 
Yes. In fact those were the only ones I saw problems with. (But I haven't
seen the problem enough to know if that is by luck or not.)
The two arrays listed were my /boot and an alternate version I have mounted
as /otherboot .
My swap array also has two elements. / and /home only have one element.
None of those are in /etc/mdadm.conf, but something is setting up those arrays
or the system wouldn't be able to finish booting.

[Clyde E. Kunkel]

----- Original Message ----- 
From: "Bill Nottingham" <notting(a)redhat.com&gt;
To: "For testers of Fedora Core development releases" 
<fedora-test-list(a)redhat.com&gt;
Cc: "Clyde Kunkel" <clydekunkel7734(a)cox.net&gt;
Sent: Friday, February 08, 2008 11:06 AM
Subject: Re: Intermittant software raid issues with rawhide, what 
componentto file against?


>  Bruno Wolff III (bruno(a)wolff.to) said:
> > > Currently, I am having issues with a rawhide installation and software 
> > > raid
> > > since the raidsets are no longer started by sysinit, but are supposedly
> > > started by udev.  I have to do a manual mdadm --assemble 
> > > /dev/mdX --scan to
> > > get some of the arrays going.
> >
> > Does that mean udev is probably the correct component to file a bug in 
> > this
> > case?
>
>  The udev rules are designed (intentionally) to only assemble arrays that
>  are in the mdadm.conf file. Are these arrays listed there?
>
>  Bill 

Ahhhhhh....the arrays in one of my test machine's mdadm.conf file are NOT 
all being assembled.  Booting Fedora 8, to check the problem, they are all 
asembled--mdadm.conf files identical.  Unfortuneately, the machine with the 
prob is not on a network for awhile.  I could still open a BZ, but not sure 
what to put in it--udev not assembling all mdadm.conf arrays?   I could copy 
the file to a floppy and sneaker net it.

[Bill Nottingham]

Clyde Kunkel (clydekunkel7734(a)cox.net) said: 
>  Ahhhhhh....the arrays in one of my test machine's mdadm.conf file
> are NOT 
>  all being assembled.  Booting Fedora 8, to check the problem, they are all 
>  asembled--mdadm.conf files identical.  Unfortuneately, the machine with the 
>  prob is not on a network for awhile.  I could still open a BZ, but not sure 
>  what to put in it--udev not assembling all mdadm.conf arrays?   I could 
>  copy the file to a floppy and sneaker net it.  
Yeah, file a bug with the array configuration, as well as the mdadm.conf
file.

Bill