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
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.
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
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. Many regards Don
The current version of mkinitrd in F10 updates and in the pipe for Fedora 11 fixes the scsi wait problems.