Description of problem: errors while booting FC10 after upgrading to plymouth-0.6.0-0.2008.11.10.5.fc10.i386 Version-Release number of selected component (if applicable): plymouth-0.6.0-0.2008.11.10.5.fc10.i386 How reproducible: for me on my system 100% of the time Steps to Reproduce: 1. Install FC10 (Using FC 10 Preview net install) 2. Reboot Receive the error from https://bugzilla.redhat.com/show_bug.cgi?id=470367 3. boot into a rescue mode and yum upgrade plymouth 4. after installing the new plymouth yum upgrade 5. Reboot and receive the below error Actual results: unable to access resume device (UUID=364892e7-9dda-4634-befd-22629c6ccfa2) mount: error mounting /dev/root on /sysroot as ext3: No such file or directory Expected results: system should boot normally Additional info: [root@fedora10 ~]# lshw -short H/W path Device Class Description ========================================================= system To Be Filled By O.E.M. /0 bus K8VSEDX /0/0 memory 64KiB BIOS /0/4 processor AMD Athlon(tm) 64 Processor 3200+ /0/4/5 memory 128KiB L1 cache /0/4/6 memory 512KiB L2 cache /0/3a memory 3GiB System Memory /0/3a/0 memory 1GiB DIMM DDR Synchronous 266 MHz (3.8 ns) /0/3a/1 memory 1GiB DIMM DDR Synchronous 266 MHz (3.8 ns) /0/3a/2 memory 1GiB DIMM DDR Synchronous 266 MHz (3.8 ns) /0/100 bridge VT8385 [K8T800 AGP] Host Bridge /0/100/1 bridge VT8237 PCI bridge [K8T800/K8T890 South] /0/100/1/0 display Radeon R350 [Radeon 9800 Pro] /0/100/1/0.1 display Radeon R350 [Radeon 9800 Pro] (Secondary) /0/100/7 bus IEEE 1394 Host Controller /0/100/9 multimedia SB Live! EMU10k1 /0/100/9.1 input SB Live! Game Port /0/100/a eth0 network 88E8001 Gigabit Ethernet Controller /0/100/d scsi0 storage 9xxx-series SATA-RAID /0/100/d/0.0.0 /dev/sda disk 499GB SCSI Disk /0/100/d/0.0.0/1 /dev/sda1 volume 196MiB EXT3 volume /0/100/d/0.0.0/2 /dev/sda2 volume 4094MiB Linux swap volume /0/100/d/0.0.0/3 /dev/sda3 volume 461GiB EXT3 volume /0/100/d/0.1.0 /dev/sdb disk 999GB SCSI Disk /0/100/d/0.1.0/1 /dev/sdb1 volume 931GiB EXT3 volume /0/100/f storage VIA VT6420 SATA RAID Controller /0/100/f.1 scsi4 storage VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE /0/100/f.1/0.0.0 /dev/scd0 disk DVD-ROM DVD-115 /0/100/f.1/0.1.0 /dev/scd1 disk DX162D-A /0/100/f.1/0.1.0/0 /dev/scd1 disk /0/100/10 bus VT82xxxxx UHCI USB 1.1 Controller /0/100/10.1 bus VT82xxxxx UHCI USB 1.1 Controller /0/100/10.2 bus VT82xxxxx UHCI USB 1.1 Controller /0/100/10.3 bus VT82xxxxx UHCI USB 1.1 Controller /0/100/10.4 bus USB 2.0 /0/100/11 bridge VT8237 ISA bridge [KT600/K8T800/K8T890 South] /0/100/11.5 multimedia VT8233/A/8235/8237 AC97 Audio Controller /0/100/11.6 communication AC'97 Modem Controller /0/101 bridge K8 [Athlon64/Opteron] HyperTransport Technology Configuration /0/102 bridge K8 [Athlon64/Opteron] Address Map /0/103 bridge K8 [Athlon64/Opteron] DRAM Controller /0/104 bridge K8 [Athlon64/Opteron] Miscellaneous Control [root@fedora10 ~]# [root@fedora10 ~]# rpm -qa | grep plymouth plymouth-plugin-label-0.6.0-0.2008.11.10.5.fc10.i386 plymouth-0.6.0-0.2008.11.10.5.fc10.i386 plymouth-scripts-0.6.0-0.2008.11.10.5.fc10.i386 plymouth-libs-0.6.0-0.2008.11.10.5.fc10.i386 plymouth-utils-0.6.0-0.2008.11.10.5.fc10.i386 plymouth-gdm-hooks-0.6.0-0.2008.11.10.5.fc10.i386 plymouth-plugin-solar-0.6.0-0.2008.11.10.5.fc10.i386 [root@fedora10 ~]# rpm -qa | grep kernel kerneloops-0.12-1.fc10.i386 kernel-firmware-2.6.27.5-94.fc10.noarch kernel-devel-2.6.27.5-94.fc10.i686 kernel-2.6.27.5-94.fc10.i686 kernel-headers-2.6.27.5-94.fc10.i386 [root@fedora10 ~]#
not a plymouth issue. Moving to mkinitrd because that might be the source of the problem (but it might get moved to a different component still) Were there any other messages before the ones you showed?
That was the only message that displayed on the screen. I am planning on recreating the initrd when i get back in front of that machine. I will post the progress later on.
after pulling the initrd apart and adding this to the init file I am in business echo Waiting for driver initialization. stabilized --hash --interval 250 /proc/scsi/scsi not sure how i would make this appear using the mkinitrd command but manually adding it to the init seems to have solved the problem for me.
(In reply to comment #3) > not sure how i would make this appear using the mkinitrd command but manually > adding it to the init seems to have solved the problem for me. You can either use the workaround in bug #466607 comment #24, or edit your mkinitrd to add your scsi module to the set of special cases, around line 1490 or so (it sets 'wait_for_scsi'). Then you won't have to remember to hand-edit init every time you install a new kernel. The first method causes init to insmod scsi_wait_scan, while the second method causes init to call stabilized(). Please add your experience to bug #466607, and close this one as a duplicate if the workaround(s) work for you.
*** This bug has been marked as a duplicate of bug 466607 ***