Bug 443466 - dmraid broken in kernel 2.6.25-1.fc9
dmraid broken in kernel 2.6.25-1.fc9
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: 453230 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2008-04-21 14:01 EDT by Faisal Malallah
Modified: 2009-07-14 11:45 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-14 11:45:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
grub.conf file from my PC (812 bytes, text/plain)
2008-07-29 12:34 EDT, Aram Agajanian
no flags Details

  None (edit)
Description Faisal Malallah 2008-04-21 14:01:19 EDT
Description of problem:
Booting F9PR with an updated kernel 2.6.25-1.fc9 on an ICH9R raid1 setup gives
individual disks /dev/sda & /dev/sdb. dmraid devices are not present at all.

I tried to boot F9PR using kernel from F8 and the dmraid devices
works perfectly. Something is broken in 2.6.25-1.fc9

Version-Release number of selected component (if applicable):

How reproducible:
Install F9PR on a mother board with ICH9R raid1

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Chuck Ebbert 2008-04-26 12:31:27 EDT
Is this happening when you boot the install disk?
Comment 2 Faisal Malallah 2008-04-29 13:35:39 EDT
The install disk recognizes the dmraid partition and install fedora on it. But
when I boot it from the hard disk after the install, no dmraid devices and only
the separate drives. 
Comment 3 Chuck Ebbert 2008-05-01 03:53:36 EDT
Can you upload the initrd file from the working and also the broken kernel? If
you know how to look inside an initrd (it is just a .cpio.gz file) you can just
compare the file '/init' from the working and broken ones.
Comment 4 Faisal Malallah 2008-05-10 06:07:30 EDT
from initrd- (dmraid works)

mount -t proc /proc /proc
echo Mounting proc filesystem
echo Mounting sysfs filesystem
mount -t sysfs /sys /sys
echo Creating /dev
mount -o mode=0755 -t tmpfs /dev /dev
mkdir /dev/pts
mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts
mkdir /dev/shm
mkdir /dev/mapper
echo Creating initial device nodes
mknod /dev/null c 1 3
mknod /dev/zero c 1 5
mknod /dev/systty c 4 0
mknod /dev/tty c 5 0
mknod /dev/console c 5 1
mknod /dev/ptmx c 5 2
mknod /dev/rtc c 10 135
mknod /dev/tty0 c 4 0
mknod /dev/tty1 c 4 1
mknod /dev/tty2 c 4 2
mknod /dev/tty3 c 4 3
mknod /dev/tty4 c 4 4
mknod /dev/tty5 c 4 5
mknod /dev/tty6 c 4 6
mknod /dev/tty7 c 4 7
mknod /dev/tty8 c 4 8
mknod /dev/tty9 c 4 9
mknod /dev/tty10 c 4 10
mknod /dev/tty11 c 4 11
mknod /dev/tty12 c 4 12
mknod /dev/ttyS0 c 4 64
mknod /dev/ttyS1 c 4 65
mknod /dev/ttyS2 c 4 66

from initrd-2.6.25-8.fc9.i686.img (dmraid doesn't work)

mount -t proc /proc /proc
echo Mounting proc filesystem
echo Mounting sysfs filesystem
mount -t sysfs /sys /sys
echo Creating /dev
mount -o mode=0755 -t tmpfs /dev /dev
mkdir /dev/pts
mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts
mkdir /dev/shm
mkdir /dev/mapper
echo Creating initial device nodes
mknod /dev/null c 1 3
mknod /dev/zero c 1 5
mknod /dev/systty c 4 0
mknod /dev/tty c 5 0
mknod /dev/console c 5 1
mknod /dev/ptmx c 5 2
mknod /dev/tty0 c 4 0
mknod /dev/tty1 c 4 1
mknod /dev/tty2 c 4 2
mknod /dev/tty3 c 4 3
mknod /dev/tty4 c 4 4
mknod /dev/tty5 c 4 5
mknod /dev/tty6 c 4 6
mknod /dev/tty7 c 4 7
mknod /dev/tty8 c 4 8
mknod /dev/tty9 c 4 9
mknod /dev/tty10 c 4 10
mknod /dev/tty11 c 4 11
mknod /dev/tty12 c 4 12
mknod /dev/ttyS0 c 4 64
mknod /dev/ttyS1 c 4 65
mknod /dev/ttyS2 c 4 66
mknod /dev/ttyS3 c 4 67
Comment 5 Bug Zapper 2008-05-14 05:52:36 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 6 Faisal Malallah 2008-05-14 08:37:19 EDT
I just tried the release F9; the installer was able to detect dmraid and
installed the distribution on it just fine. But on boot from hard disk, it fails
to recognize the dmraid partitions and fails to boot. kernel 2.6.25-14.fc9 still
have the same problem. This is a show stopper for me as it is preventing me from
using F9 right now. 
Comment 7 Ingo Schaefer 2008-05-21 17:26:53 EDT
Could you try to find out, if all needed modules are in the initrd?

On one system here I have the sd_mod.ko missing and get a similar failure. I
will try tomorrow with a new initrd I just created.
Comment 8 Ingo Schaefer 2008-05-22 03:49:18 EDT
Today I was able to boot my maschine with kernel 2.6.25-14 very well.

All I had to do was creating a new initrd with mkinitrd.

cd /boot
cp initrd-2.6.25-14.fc9.i686.img initrd-2.6.25-14.fc9.i686.img.fedora
mkinitrd -f initrd-2.6.25-14.fc9.i686.img 2.6.25-14.fc9.i686

reboot and pray ;-)
Comment 9 Aram Agajanian 2008-07-16 13:52:35 EDT
*** Bug 453230 has been marked as a duplicate of this bug. ***
Comment 10 Andris Pavenis 2008-07-29 10:39:52 EDT
With kernel dmraid works OK for me, but with only root
partition (on RAID1 volume) is mounted. After prompt about unability to mount
other ext3 filesystems I can see that directory /dev/mapper contains only node
control but not other device nodes (isw_*). With I'm getting

[root@ap ~]# ls -l /dev/mapper
total 0
crw-rw---- 1 root root  10, 60 2008-07-29 20:18 control
brw-rw---- 1 root disk 253,  0 2008-07-29 20:18 isw_ebiicjhfca_Volume_1
brw-rw---- 1 root disk 253,  1 2008-07-29 20:18 isw_ebiicjhfca_Volume_1p1
brw-rw---- 1 root disk 253,  8 2008-07-29 17:18 isw_ebiicjhfca_Volume_1p10
brw-rw---- 1 root disk 253,  2 2008-07-29 20:18 isw_ebiicjhfca_Volume_1p2
brw-rw---- 1 root disk 253,  3 2008-07-29 20:18 isw_ebiicjhfca_Volume_1p5
brw-rw---- 1 root disk 253,  4 2008-07-29 17:18 isw_ebiicjhfca_Volume_1p6
brw-rw---- 1 root disk 253,  5 2008-07-29 17:18 isw_ebiicjhfca_Volume_1p7
brw-rw---- 1 root disk 253,  6 2008-07-29 17:18 isw_ebiicjhfca_Volume_1p8
brw-rw---- 1 root disk 253,  7 2008-07-29 20:18 isw_ebiicjhfca_Volume_1p9

Other system related information:
Motherboard Abit IP35, Processor Intel Core 2 Quad 2.4Gb, 4Gb memory.

[root@ap ~]# yum list kernel*
Loaded plugins: refresh-packagekit, verify
Installed Packages
kernel.x86_64                          installed       
kernel.x86_64                         installed       
kernel-devel.x86_64                    installed       
kernel-devel.x86_64                   installed       
kernel-headers.x86_64                 installed       
kerneloops.x86_64                        0.11-1.fc9             installed       

Earlier I did not saw related problems with dmraid in Fedora-8 and Fedora-9.
Comment 11 Aram Agajanian 2008-07-29 11:10:37 EDT
My PC has the Intel Q35 Express Chipset w/ICH9DO.

On kernel, when I run the command "dmraid -s", I get the

[root@frogn ~]# dmraid -s
*** Group superset isw_bfaabafjcd
--> Subset
name   : isw_bfaabafjcd_Fedora
size   : 488276224
stride : 128
type   : mirror
status : ok
subsets: 0
devs   : 2
spares : 0

However, my /boot partition still is not mounted as a dm device.  I understand
that this has something to do with the initrd.  So, every time a new kernel is
installed, I use dd to copy /boot from one disk to the other.

Comment 12 Andris Pavenis 2008-07-29 11:28:49 EDT
Is the grup configuration OK? I took latest Fedora 8 respin and did upgrade when
changed to RAID1 (before release of Fedora 9). Later I installed Fedora 9 in
other partition so also all was OK with dm devices.

df shows that all partitions on that RAID1 volume are mounted as dm devices
(including /boot) when kernel is
Comment 13 Aram Agajanian 2008-07-29 12:34:17 EDT
Created attachment 312902 [details]
grub.conf file from my PC

Here is my grub.conf file.  I just uncommented the boot= line, but that didn't
have any effect on dmraid.

The first kernel that was installed (2.6.25-14) didn't seem to work with dmraid
at all.  I believe that it was the first update that I installed (
which got me to the present situation with initrd apparently not using dmraid. 
dmraid has functioned similarly on all kernels since then.
Comment 14 Andris Pavenis 2008-07-29 13:05:52 EDT
It looks rather similar except that I have root=UUID=... in kernel line of
grub.conf (e.g. kernel /vmlinuz- ro
Comment 15 Aram Agajanian 2008-07-29 18:40:25 EDT
I tried changing the grub.conf to use root=UUID=....  (I got the UUID
with the tune2fs command.)  This seemed to break the grub installation.  I
booted to a grub prompt even after changing grub.conf back to its original
contents.  So I re-installed grub on (hd0,2) and this seemed to bring back an
old version of the grub.conf.  That makes me wonder if RAID stopped working
after the 76 kernel like it was suggested.  Then, I re-installed the 76 kernel
and, on the next reboot, the grub.conf file looked better.  Now, I can boot with
the 76 or 97 kernel and I don't notice any difference.  The contents of the
/dev/mapper directories are the same and I get the same warning message about
duplicate UUIDs right after the Red Hat nash message.
Comment 16 Jukka Lehtonen 2008-08-11 04:45:02 EDT
Bugs #349161 and #446284 might be related.  The fakeraid volumes are activated in 'init' (within initrd) either by nash 'dm create' command or call to dmraid.  If that fails, the subsequent mounting (usually by LABEL) picks the filesystems directly from /dev/sda? (RAID1) or will fail (RAID0).
Comment 17 Andris Pavenis 2008-08-19 12:21:04 EDT
As far as I looked mkinitrd does not generate commands to initialize dmraid any more for new kernels. Additionally

'dmraid -ay -t' in this case does not found andy RAID volume,
'dmraid -ay -t -i' founds it.
Comment 18 Andris Pavenis 2008-08-19 14:20:32 EDT
One additional suspicious thing. After I had to replace one of RAID1 disks (second of RAID1 disks begun to fail) some settings in BIOS (perhaps) seems to
have changed:

[root@ap ~]# dmraid -r
/dev/sdc: isw, "isw_ebiicjiija", GROUP, ok, 976773166 sectors, data@ 0
/dev/sda: isw, "isw_ebiicjiija", GROUP, ok, 976773166 sectors, data@ 0
[root@ap ~]# dmraid -s
*** Group superset isw_ebiicjiija
--> Subset
name   : isw_ebiicjiija_Volume_1
size   : 976768896
stride : 128
type   : mirror
status : ok
subsets: 0
devs   : 2
spares : 0
[root@ap ~]# dmraid -ay -t
isw_ebiicjiija_Volume_1: 0 976768911 mirror core 2 131072 nosync 2 /dev/sda 0 /dev/sdc 0 1 handle_errors
[root@ap ~]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
                     148786884   9793908 131313108   7% /
Can that cause problems?
If so how can that be fixed?
Comment 19 Jukka Lehtonen 2008-08-20 02:35:18 EDT
Bug 432812 does explain why the dmraid method fails (on RHEL 5.[12]).

I have seen change of group superset string on kernel update (IIRC, on update from CentOS 5 to CentOS 5.1), with SiI3114 array.  SiI3114 has subset name identical to superset name.

But as said, the 'dm create' command of 'nash' used in F9 initrd (instead of dmraid) works differently.
Comment 20 Bug Zapper 2009-06-09 20:20:11 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 21 Bug Zapper 2009-07-14 11:45:21 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.