Bug 475832 - System fails to boot - Volume Group not found - Unable to access resume device
System fails to boot - Volume Group not found - Unable to access resume device
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
10
i686 Linux
low Severity low
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-10 13:17 EST by Don Scales
Modified: 2009-05-06 12:36 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-06 12:36:54 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 Don Scales 2008-12-10 13:17:47 EST
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Building a new FC10 system from CDs. During the install I selected review and modify partition layout. 
I then changed the default volume group to FC10VG00 and the logical volumes to FC10LV00 and FC10LV01.
When the system trys the first boot it fails -
Reading all physical volumes. This may take a while ....
Volume group "FC10VG00" not found
Unable to access resume device (/dev/FC10VG00/FC10LV01)
mount: error mounting /dev/root on /sysroot as ext3: no such file or directory.

Running the CD Repair, system looks ok and volume groups look ok.

Now building a system without changing the VG or LVs. 

Reproducible: Always

Steps to Reproduce:
1.Start build using CDs
2.Select review & modify partition layout
3.Change VG and LV names
Actual Results:  
Boot fails as described about

Expected Results:  
Boot
Comment 1 Don Scales 2008-12-10 13:52:36 EST
Built system without changing VG or LV name.
Boot still fails.

Now looks like the scsi driver is not being built into the .img file.
Tried mkinitrd using the repair CD - boot still fails.
FC9 builds and works fine on this system - something changed in fc10

Looks like I need to do more research to find out just what is happening.
Comment 2 Don Scales 2008-12-12 05:36:23 EST
Checked the boot image - scsi driver is there ok.
Comment 3 Don Scales 2008-12-12 06:03:50 EST
Checked the boot image - scsi driver is there ok.
Comment 4 Don Scales 2008-12-12 07:00:08 EST
Just found a fix for a similar problem by Michael H. Warfield.
His analysis of the problem suggests that the boot needs to wait for
the scsi driver to complete initialization before looking for the
volume group. He suggested changing mkinitrd by changing 
"wait_for_scsi="no"" to "wait_for_scsi="yes"".

Tried this - did not fix the problem.

Had a closer look at the mkinitrd script.
Seems to include attempts to fix this problem !
Then found "scsi_wait_scan="no"" at line 141
Changed this to "yes" and the system now boots ok !!

For information - the scsi adapter is made by LSI and
uses the sym53c8xx driver.
Comment 5 Michael Price 2009-03-04 15:06:38 EST
Thank you for taking the time to report this bug and helping to make Fedora better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you.
Comment 6 Don Scales 2009-03-04 15:31:44 EST
Hi Michael,
In my comment #4, my analysis of the problem suggests there is a problem
with the mkinitrd script and scsi disks. It would seem there have been several
similar problems with this script and several attempts to fix them.
I fixed my problem by changing scsi_wait_scan="no" to "yes".
I have a working system but the fix is not easy for everyone to implement.

I suspect more work needs to be done with the mkinitrd script - it may just
need to include the LSI sym53c8xx as one that sets SCSI_wait_scan="yes"

Many regards
Don
Comment 7 Joachim Frieben 2009-03-04 16:54:39 EST
For me, this issue was fixed by mkinitrd-6.0.71-4.fc10 which ensures that scsi_wait_scan="yes".
Comment 8 Chris Lumens 2009-04-28 13:44:24 EDT
Don - comment #7 indicates this is a problem in mkinitrd that has since been fixed.  Are you still seeing this problem with the version given in that comment?
Comment 9 Don Scales 2009-04-28 16:38:05 EDT
I will test mkinitrd-6.0.71-4.fc10 as soon as possible for you.

I have one slight reservation.
My limited study of the mkinitrd script suggests the "wait_for_scsi"
and "scsi_wait_scan" parameters are in the script to try to
speed up the boot time of Fedora.
Setting either/both of these parameters to "yes" will slow up
the boot of systems with more up to date scsi adapters.
I suspect that the script is automatically modified based on
which scsi adapters are found in the system. This suggests that,
in my case, adding the LSI sym53c8xx to the list of slow 
scsi adapters might fix my problem.

Many regards
Don
Comment 10 Jeremy Katz 2009-05-06 12:36:54 EDT
The current version of mkinitrd in F10 updates and in the pipe for Fedora 11 fixes the scsi wait problems.

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