Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 620901 - dracut not assembling raid 10 sets
dracut not assembling raid 10 sets
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-08-03 14:14 EDT by Clyde E. Kunkel
Modified: 2010-08-05 10:07 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-08-05 10:07:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
screenshot of segfault in initramfs (466.51 KB, image/jpeg)
2010-08-04 10:16 EDT, Clyde E. Kunkel
no flags Details

  None (edit)
Description Clyde E. Kunkel 2010-08-03 14:14:59 EDT
Description of problem:
dracut not assembling raid 10 sets

Version-Release number of selected component (if applicable):
dracut-006-2.fc14.noarch or kernels after 2.6.35-0.49.rc5.git2.fc14.x86_64

How reproducible:
Every time with each kernel update after 2.6.35-0.49.rc5.git2.fc14.x86_64

Steps to Reproduce:
1. boot system
Actual results:
Boot starts, dracut cuts in but drops to shell with Root partition not found

Expected results:
Normal boot

Additional info:
Root partition is on an LV on a raid10 PV.  With kernels 2.6.35-0.49.rc5.git2.fc14.x86_64 and earlier, can see the creation of the pv during boot, but do not see the creation after 2.6.35-0.49.rc5.git2.fc14.x86_64.  When dropped into a shell, no arrays in dev, so PVSCAN can't find it tho it does find other non-raid PVs.  In the shell, I can mdadm --assemble /dev/md127 --uuid=....
and trick a boot, but this is really awkward and I do not consider it a valid workaround when a normal boot should occur.

Currently booted into rawhide with 2.6.35-0.49.rc5.git2.fc14.x86_64.
[kunkelc@P5K-EWIFI ~]$ sudo pvscan
  PV /dev/md127   VG VolGroup00    lvm2 [78.12 GiB / 0    free]
  PV /dev/md126   VG vg_p5kewifi   lvm2 [19.50 GiB / 0    free]
  PV /dev/sde2    VG VolGroup03    lvm2 [97.62 GiB / 82.97 GiB free]
  PV /dev/sde1    VG VolGroup01    lvm2 [97.65 GiB / 78.12 GiB free]
  PV /dev/sda2    VG VolGroup02    lvm2 [48.82 GiB / 20.07 GiB free]
  PV /dev/sdb6    VG VolGroup02    lvm2 [48.82 GiB / 556.00 MiB free]
  PV /dev/sdc2    VG VolGroup02    lvm2 [48.82 GiB / 20.07 GiB free]
  PV /dev/sdd2    VG VolGroup02    lvm2 [48.82 GiB / 20.07 GiB free]
  Total: 8 [488.17 GiB] / in use: 8 [488.17 GiB] / in no VG: 0 [0   ]

A failing kernel line:
	kernel /vmlinuz-2.6.35-0.57.rc6.git5.fc15.x86_64 ro root=/dev/mapper/VolGroup00-rawhide LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rdshell init=/sbin/upstart
Comment 1 Harald Hoyer 2010-08-04 03:56:36 EDT
Does this fix your issue?


# rpm -Fvh dracut-007-0.4.gite0c1d4e*.rpm
# dracut -f
# reboot
Comment 2 Clyde E. Kunkel 2010-08-04 10:16:42 EDT
Created attachment 436551 [details]
screenshot of segfault in initramfs

segfaults, tho I did see that the md array was assembled just before the segfault.

Comment 3 Harald Hoyer 2010-08-04 10:31:20 EDT
ah.. nice.. looks like a solid kernel issue
Comment 4 Clyde E. Kunkel 2010-08-05 10:07:10 EDT
Fixed with one of the following:



* Wed Aug 04 2010 Doug Ledford <dledford@redhat.com> - 3.1.3-0.git20100804.2
- Add udev patch to not have incremental assembly in two rules files

* Wed Aug 04 2010 Doug Ledford <dledford@redhat.com> - 3.1.3-0.git20100804.1
- Update to latest upstream release (resolves an issue with stale lock
  files on the md device map file)


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