Bug 231544 - nash can't find device-mapper major/minor
Summary: nash can't find device-mapper major/minor
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: ia64
OS: Linux
high
urgent
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
Last Closed: 2007-07-07 00:48:22 UTC
Type: ---
Embargoed:


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 5.1.19.6 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):
  rawhide-20070306


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.