Red Hat Bugzilla – Bug 443466
dmraid broken in kernel 2.6.25-1.fc9
Last modified: 2009-07-14 11:45:21 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 2.6.24.4-64.fc8 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: 1. 2. 3. Actual results: Expected results: Additional info:
Is this happening when you boot the install disk?
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.
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.
========================================= from initrd-2.6.24.4-64.fc8PAE.img (dmraid works) ========================================= #!/bin/nash mount -t proc /proc /proc setquiet 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) =========================================== #!/bin/nash mount -t proc /proc /proc setquiet 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
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.
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.
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 ;-)
*** Bug 453230 has been marked as a duplicate of this bug. ***
With kernel 2.6.25.9-76 dmraid works OK for me, but with 2.6.25.11-97 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 2.6.25.9-76 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 2.6.25.9-76.fc9 installed kernel.x86_64 2.6.25.11-97.fc9 installed kernel-devel.x86_64 2.6.25.9-76.fc9 installed kernel-devel.x86_64 2.6.25.11-97.fc9 installed kernel-headers.x86_64 2.6.25.11-97.fc9 installed kerneloops.x86_64 0.11-1.fc9 installed Earlier I did not saw related problems with dmraid in Fedora-8 and Fedora-9.
My PC has the Intel Q35 Express Chipset w/ICH9DO. On kernel 2.6.25.11-97.fc9.x86_64, when I run the command "dmraid -s", I get the following: [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.
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 2.6.25.9-76.
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 (2.6.25.6-55) which got me to the present situation with initrd apparently not using dmraid. dmraid has functioned similarly on all kernels since then.
It looks rather similar except that I have root=UUID=... in kernel line of grub.conf (e.g. kernel /vmlinuz-2.6.25.11-97.fc9.x86_64 ro root=UUID=d18094f8-1c53-4cef-ed98-02288b219635)
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.
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).
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.
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 /dev/mapper/isw_ebiicjhfca_Volume_1p7 148786884 9793908 131313108 7% / Can that cause problems? If so how can that be fixed?
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.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.