Red Hat Bugzilla – Bug 475832
System fails to boot - Volume Group not found - Unable to access resume device
Last modified: 2009-05-06 12:36:54 EDT
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.
Steps to Reproduce:
1.Start build using CDs
2.Select review & modify partition layout
3.Change VG and LV names
Boot fails as described about
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.
Checked the boot image - scsi driver is there ok.
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.
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.
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"
For me, this issue was fixed by mkinitrd-6.0.71-4.fc10 which ensures that scsi_wait_scan="yes".
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?
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.
The current version of mkinitrd in F10 updates and in the pipe for Fedora 11 fixes the scsi wait problems.