Bug 231544 - nash can't find device-mapper major/minor
nash can't find device-mapper major/minor
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
ia64 Linux
high Severity urgent
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-08 16:46 EST by George Beshers
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: F7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-06 20:48:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description George Beshers 2007-03-08 16:46:21 EST
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 16:53:06 EST
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 12:22:17 EDT
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.