Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 231544 - nash can't find device-mapper major/minor
Summary: nash can't find device-mapper major/minor
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: ia64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-08 21:46 UTC by George Beshers
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version: F7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-07-07 00:48:22 UTC

Attachments (Terms of Use)

Description George Beshers 2007-03-08 21:46:21 UTC
Description of problem:
  I was testing the patch for BZ#230552
  Booting on Altix4 (dual 330) gets into nash but the fails with the message:

Red Hat nash version starting
Unable to find device-mapper major/minor
  Reading all physical volumes.  This may take a while...
  No volume groups found
  Volume group "VolGroup00" not found
mount: could not find filesystem '/dev/root'
setuproot: moving /dev failed: No such file or directory
setuproot: error mounting /proc: No such file or directory
setuproot: error mounting /sys: No such file or directory
switchroot: mount failed: No such file or directory
Kernel panic - not syncing: Attempted to kill init!                             

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

How reproducible:
  both times tried

Steps to Reproduce:
1.  Boot to RHEL5
2.  Patch rawhide kernel and install
3.  Boot rawhide kernel w/ patch
Actual results:
  Kernel panic

Expected results:
  Login prompt

Additional info:

Comment 1 Jarod Wilson 2007-03-08 21:53:06 UTC
Best guess offhand is that this has to do with the big libata overhaul. Quite a
few systems are failing to boot recent rawhide kernels, especially if scsi disks
are involved, because the driver/drives aren't ready yet by the time we try to
access them. Previously, the old ata code introduced enough latency in the
module load process, that the drives were up by the time we tried prodding them.
(See bug #220470 for reference). As detailed there, you may be able to add a
5-10 second delay in the init script in your initrd to get things working...

Comment 2 Dave Jones 2007-04-23 16:22:17 UTC
How's this looking with the current tree ?

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