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   
(Show other bugs)
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:
Story Points: ---
Clone Of:
Last Closed: 2007-07-07 00:48:22 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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.