10:48 a.m.
Since about mkinitrd-5.0.11, software raidsets are being created in /dev
during initrd with the name /dev/md_dn where n is the number of the
raidset instead of /dev/mdn. This is causing all sorts of problems from
the worst being kernel panics and the least being raidsets not being
mounted in fstab.
Does anyone know why this is happening and does it mean we have to make
some changes to the way we use raid?
--
Regards,
Old Fart
11:37 a.m.
On Tue, 2005-12-20 at 11:48 -0500, Clyde E. Kunkel wrote:
Since about mkinitrd-5.0.11, software raidsets are being created in
/dev
during initrd with the name /dev/md_dn where n is the number of the
raidset instead of /dev/mdn. This is causing all sorts of problems from
the worst being kernel panics and the least being raidsets not being
mounted in fstab.
You're still the *only* person I've seen reporting this. Are you sure
something else in your environment hasn't changed?
(Also, you're sending mail with reply-to: clydekunkel7734(a)redhat.com,
which is certainly broken.)
--
Peter
12:37 p.m.
Peter Jones wrote:
You're still the *only* person I've seen reporting this. Are
you sure
something else in your environment hasn't changed?
<panto>Oh no he's isn't!</panto>
I logged this https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176179
as I didn't spot Clydes' longer running entry
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169059
I've got a un-bootable machine sitting here with 1770 smp kernel on
software raid waiting and ready to follow/test any suggestions ...
12:57 p.m.
Peter Jones wrote:
On Tue, 2005-12-20 at 11:48 -0500, Clyde E. Kunkel wrote:
> Since about mkinitrd-5.0.11, software raidsets are being created in /dev
> during initrd with the name /dev/md_dn where n is the number of the
> raidset instead of /dev/mdn. This is causing all sorts of problems from
> the worst being kernel panics and the least being raidsets not being
> mounted in fstab.
>
You're still the *only* person I've seen reporting this. Are you sure
something else in your environment hasn't changed?
Not so. And I can reproduce the bug on 4 software raid boxes - 3 i686
and 1 x86_64.
See bug# 169059
John
2:46 p.m.
Peter Jones wrote:
You're still the *only* person I've seen reporting this. Are
you sure
something else in your environment hasn't changed?
Finally I built a working initrd for 1770_FC5smp using
mkinitrd-5.0.10-1, and a manually tweaked init script.
I then updated to today's rawhide mkinitrd-5.0.15-1 and 1776_FC5smp (in
that order) and software raid *DEFINITELY* reverts to using the names
md_d0 and md_d1, which scares the horses, full commentary on BZ#169059
6:39 p.m.
Didn't "reply all" originally....my original reply to Mr. Jones is
below. Sorry for the confusion....
Peter Jones wrote:
On Tue, 2005-12-20 at 11:48 -0500, Clyde E. Kunkel wrote:
> Since about mkinitrd-5.0.11, software raidsets are being created in /dev
> during initrd with the name /dev/md_dn where n is the number of the
> raidset instead of /dev/mdn. This is causing all sorts of problems from
> the worst being kernel panics and the least being raidsets not being
> mounted in fstab.
You're still the *only* person I've seen reporting this. Are you sure
something else in your environment hasn't changed?
(Also, you're sending mail with reply-to: clydekunkel7734(a)redhat.com,
which is certainly broken.)
Other folks have seen this also. I believe they have reported in
169059. The only thing that I can think that may be influencing this
besides religious updating with rawhide is that the two systems I am
having trouble with are multi-boot. I have tried very hard to keep the
different distros separate. Could they possibly write something to the
disks that is foreign to FC? Also, why would reverting mkinitrd back to
5.0.10 eliminate the problem? There must be a clue there. I am sorry
that I am not better at troubleshooting. I have been studying the nash
code best I can, but not being a programmer, it is hard going even using
some C books that I have. I would like to help resolve this and am
doing the best I can to provide information.
My mail reply to address is deliberately broken to avoid spambots from
using it. Just remove "munged" from the @cox.mungednet.
--
Regards,
Old Fart
6:07 a.m.
Clyde E. Kunkel wrote:
Didn't "reply all" originally....my original reply to
Mr. Jones is
below. Sorry for the confusion....
Peter Jones wrote:
> On Tue, 2005-12-20 at 11:48 -0500, Clyde E. Kunkel wrote:
>> Since about mkinitrd-5.0.11, software raidsets are being created in
>> /dev during initrd with the name /dev/md_dn where n is the number of
>> the raidset instead of /dev/mdn. This is causing all sorts of
>> problems from the worst being kernel panics and the least being
>> raidsets not being mounted in fstab.
>
> You're still the *only* person I've seen reporting this. Are you sure
> something else in your environment hasn't changed?
>
> (Also, you're sending mail with reply-to: clydekunkel7734(a)redhat.com,
> which is certainly broken.)
Other folks have seen this also. I believe they have reported in
169059. The only thing that I can think that may be influencing this
besides religious updating with rawhide is that the two systems I am
having trouble with are multi-boot.
None of the systems that I have with the problem are multiboot.
John
10:08 a.m.
Peter Jones wrote:
On Wed, 2005-12-21 at 07:07 -0500, John Ellson wrote:
> None of the systems that I have with the problem are multiboot.
Are you rebuilding the initrd from a rescue image when it's
miss-created, or from an actual running system?
FWIW, to get the 16 Dec rawhide tree to boot, I rebuilt the initrd from
an updated FC5T1 that I have separately installed on the same system.
See comment #65 in bz 169059.
--
Regards,
Old Fart
(my reply-to address may be "munged")
11 a.m.
Peter Jones wrote:
On Wed, 2005-12-21 at 07:07 -0500, John Ellson wrote:
> None of the systems that I have with the problem are multiboot.
>
Are you rebuilding the initrd from a rescue image when it's
miss-created, or from an actual running system?
No, from a running system.
I'm running kernel-2.6.14-1.1777_FC5.x86_64.rpm
and I upgrade initrd using:
rpm -Uvh mkinitrd-5.0.15-1.x86_64.rpm
then rebuild the initrd using:
cd /boot
mv initrd-2.6.14-1.1777_FC5.img initrd-2.6.14-1.1777_FC5.img.old
mkinitrd initrd-2.6.14-1.1777_FC5.img 2.6.14-1.1777_FC5
then reboot. (With 1777 I reboot with "acpi=off irqpoll" because of
other bugs #176284, but the mkintrd problem occurs with all recent kernels)
John
1:35 p.m.
On Dec 20, 2005, Peter Jones <pjones(a)redhat.com> wrote:
On Tue, 2005-12-20 at 11:48 -0500, Clyde E. Kunkel wrote:
> Since about mkinitrd-5.0.11, software raidsets are being created in /dev
> during initrd with the name /dev/md_dn where n is the number of the
> raidset instead of /dev/mdn. This is causing all sorts of problems from
> the worst being kernel panics and the least being raidsets not being
> mounted in fstab.
You're still the *only* person I've seen reporting this.
Not true. It's even been a while since I narrowed the problem I've
got myself on 5 different boxes to some change in nash.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
3:49 p.m.
On Wed, 2005-12-21 at 17:35 -0200, Alexandre Oliva wrote:
> You're still the *only* person I've seen reporting
this.
Not true.
Indeed, I missed your report in the middle of another bug.
It's even been a while since I narrowed the problem I've
got myself on 5 different boxes to some change in nash.
You have? When? The closest I've seen of that was when you said it was
happening with one version but not another. That doesn't actually even
narrow it down to nash actually being the culprit, much less to a
specific change. If you've actually narrowed it down in some way,
please, do tell me your findings?
--
Peter
4:08 p.m.
Peter Jones wrote:
On Wed, 2005-12-21 at 17:35 -0200, Alexandre Oliva wrote:
>> You're still the *only* person I've seen reporting this.
> Not true.
Indeed, I missed your report in the middle of another bug.
> It's even been a while since I narrowed the problem I've
> got myself on 5 different boxes to some change in nash.
You have? When? The closest I've seen of that was when you said it was
happening with one version but not another. That doesn't actually even
narrow it down to nash actually being the culprit, much less to a
specific change. If you've actually narrowed it down in some way,
please, do tell me your findings?
Don't want to beat a dead horse, especially when you have the problem
identified as a kernel problem (thank you BTW), but, the change in nash
from mkinitrd-5.0.10 to -5.0.11 which changed the various open type
statements to various coeOpen statements was when the raid renaming
problem started for me. Look at comments #39 and #40 of 11/24/05 on 169059.
--
Regards,
Old Fart
4:59 p.m.
On Wed, 2005-12-21 at 17:08 -0500, Clyde E. Kunkel wrote:
Don't want to beat a dead horse, especially when you have the
problem
identified as a kernel problem (thank you BTW), but, the change in nash
from mkinitrd-5.0.10 to -5.0.11 which changed the various open type
statements to various coeOpen statements was when the raid renaming
problem started for me. Look at comments #39 and #40 of 11/24/05 on 169059.
If the file descriptor being set "close on exec" makes any difference
with what the ioctl that scans raids does, then there's something
really, really broken in that ioctl.
--
Peter
6:03 p.m.
Peter Jones wrote:
On Wed, 2005-12-21 at 17:08 -0500, Clyde E. Kunkel wrote:
> Don't want to beat a dead horse, especially when you have the problem
> identified as a kernel problem (thank you BTW), but, the change in nash
> from mkinitrd-5.0.10 to -5.0.11 which changed the various open type
> statements to various coeOpen statements was when the raid renaming
> problem started for me. Look at comments #39 and #40 of 11/24/05 on 169059.
If the file descriptor being set "close on exec" makes any difference
with what the ioctl that scans raids does, then there's something
really, really broken in that ioctl.
You do have to talk nice to ioctl. :-)
Alls well that ends well.
--
Regards,
Old Fart
(my reply-to address is "munged" to defeat spambots)
7:02 a.m.
On Dec 21, 2005, Peter Jones <pjones(a)redhat.com> wrote:
On Wed, 2005-12-21 at 17:35 -0200, Alexandre Oliva wrote:
> > You're still the *only* person I've seen reporting this.
>
> Not true.
Indeed, I missed your report in the middle of another bug.
> It's even been a while since I narrowed the problem I've
> got myself on 5 different boxes to some change in nash.
You have? When?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169059#c47
If you've actually narrowed it down in some way, please, do tell
me
your findings?
I did, back on Nov 30. I compared the full contents of a working
initrd.img, created with mkinitrd-5.1.10, with those of one created
with mkinitrd-5.1.12. The scripts were identical, the device nodes
were identical, everything was the same, except for the nash binary.
And, as the comment says, that's as far as I got then.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
6680
days inactive
6695
days old
16 comments
5 participants
participants (5)
-
Alexandre Oliva -
Andy Burns -
Clyde E. Kunkel -
John Ellson -
Peter Jones