Created attachment 329653 [details] output of 'blkid' command after booting DVD in recovery mode Description of problem: After installing FC10 from the i386 DVD, the system does not boot, due to the error, "unable to resolve UUID". This affects my /opt, /usr, /tmp and /var partitions. If I then boot from the DVD and select "Recover", I can edit the fstab and replace the "UUID=" references with "LABEL=" references but when booting from the installed system, the error "UNABLE to resolve LABEL" occurs for the same partitions. Looking at the output of 'blkid' when booting from the DVD lists all UUIDs and LABELs exactly as listed in the fstab, however, when booting the system normally and entering maintenance mode, several UUIDs and LABELs are not apparent. Version-Release number of selected component (if applicable): All available versions in FC10, including updates How reproducible: Always Steps to Reproduce: Boot system normally Please see attached files: blkid_cd.txt - output of 'blkid' command after booting DVD in recovery mode blkid_norm.txt - output of 'blkid' command after booting system normally lsmod_cd.txt - output of 'lsmod' command after booting DVD in recovery mode lsmod_norm.txt - output of 'lsmod' command after booting system normally fstab - copy of /etc/fstab showing UUIDs commented out and LABELs Actual results: Failure to boot as paritions are not available Expected results: Bootable system Additional info: I am running the following hardware configuration: System board - Asus P4C800E Deluxe with on-board Promise SATA RAID Disks - Two 150GB (identical) SATA disks mirrored using Promise This configuration worked perfectly under FC9 until I upgraded to FC10 - on 11th December 2008. I have since performed a fresh install of FC10 (even recreating the partitions - except /home) and the problem remains on the same partitions. (I have heard a suggestion that this problem may have been introduced to FC9 in an update after December 11th although I cannot confirm this.
Created attachment 329654 [details] output of 'blkid' command after booting system normally
Created attachment 329655 [details] output of 'lsmod' command when booting from DVD in recovery mode
Created attachment 329656 [details] output of 'lsmod' command when booting system normally
Created attachment 329657 [details] copy of fstab file
I can also provide a screenshot of the error if this would be helpful. I am willing to provide any information that can assist toward getting this resolved - creating a fresh initrd does not resolve the problem. The system is fully fully updated to 19th January 2009.
It's possible that this is identical to bug 476818.
Try booting with root=/dev/mapper/isw_beadbdgjge_ARRAY on the kernel cmdline (you can edit the root= argument in the grub boot menu, no need for rescue mode.
Unfortunately, I'm in the middle of moving house, so it could take several days before I get the opportunity to try anything more.
I think this probably is the same issue as bug 480667, so I'm closing this as a duplicate of that. Note that bug 480667 is currently closed with a resolution of rawhide, but I'll do an mkinitrd update for F-10 today containing the fix. It would be good if you (once the whole moving houses is done) could try regenerating your initrd with the new mkinitrd, and see if that fixes things. See bug 480667 for a link to the update. *** This bug has been marked as a duplicate of bug 480667 ***
Sorry it's taken so long to be able to feed-back on this bug. The house move went well but my chosen ISP was completely incompetent, so I eventually gave up and switched provider, it's taken months to get back on the internet. Anyway. I'm pleased to report that the answer to my problem has two parts and is now resolved. I didn't manage to get the suggestion at comment #7 working - maybe I was doing it wrong, never mind! Basically, the updated mkinitrd, nash, dmraid and libbdevid-python packages noted in bug 476818 resolved the problem with the partition UUIDs not being available for all partitions. However, this resulted in a segfault in nash (bug 476818 comment #43 is the same problem). I then performed the edit to the mkinitrd script referenced in bug 476818 comment #49 (except that the line to edit wasn't line 282, it's line 286 : mkinitrd-6.0.71-4.fc10.i386). Sorry the positive news comes only days before Fedora 11 is released. Thank you for all the help and support and for resolving the problem so effectively.