Bug 242256 - 2.6.21-1.3194.fc7 fails to boot
Summary: 2.6.21-1.3194.fc7 fails to boot
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 7
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-02 19:40 UTC by Jonathan Smith
Modified: 2008-08-02 23:40 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2007-08-30 14:04:27 UTC

Attachments (Terms of Use)

Description Jonathan Smith 2007-06-02 19:40:08 UTC
Description of problem:

It has been discussed extensively on Fedora Forum, but developers continue to
ignore the problems because no bug report get through and approved

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. yum upgrade
Actual results:

endless loop trying to load drive

Expected results:

as with the last version that has worked for me .3175, a normal startup

Additional info:

Problem appeared with .3189 and has persisted

Comment 1 Dave Jones 2007-06-05 17:29:37 UTC
probably a dupe of 241249
can you try some of the workarounds listed there?

Comment 2 Jonathan Smith 2007-06-06 13:56:49 UTC
No, I don't think it is a dupe of 241249. It probably is a dupe of some other 
bug report that I have been unable to find relative to all of the problems that 
people are reporting on Fedora Forum about usb drives.

I say that for two reasons:

1) I tried clocksource=acpi_pm , that is, I appended the statement before 
booting .3194, it made no difference. I didn't try the other suggested 
workarounds because they seem specific to dual core problems and seemed less of 
a solution for some who tried them.

2) The reporting during the boot, similar to problems with earlier kernel 
versions after .3175 which works for me, is "usb 2-1 configuration #2 chosen 
from 1 choice"

Comment 3 Hans de Goede 2007-06-10 11:33:13 UTC
There is an F7 kernel-update candidate available here:

Which contains various fixes maybe this fixes your problem too, please try this
kernel and report back how it works for you.

Always be carefull when testing new kernels. Use rpm -ivh to install the new
kernel besides your current one so that you can always boot back into the old

Comment 4 Jonathan Smith 2007-06-10 15:48:38 UTC
Yes, I try to be careful although I lost .3175 and it took an extensive search
to find it, again. 

Of course, if one uses yum, then it wipes out the older kernel, (the one that
works) for two consecutive ones that don't. 

But thanks for the caution.

Comment 5 Jonathan Smith 2007-06-10 16:11:28 UTC
Same problem with .3226 as with .3194, (was there a .3190?) and .3189

To wit, SCSI Device: sda yadda yadda enabled yadda disabled yadda yadda doesn't 
support DPO or FUA

Whereas shut off (not restart because for some reason choosing the working kernel 
doesn't matter with a restart, it has to be a cold boot) then reboot with .3175, 
which works and the cryptic message that a kernel guru might understand saying 
"Attached SCSI Disk sda"

Gawd knows what the diff is, I surely don't

Comment 6 Jonathan Smith 2007-06-14 23:39:23 UTC
Similar problem with .3228 as with most recent series. Freezes. Requires cold boot to 
get back to working kernel. 

Thankfully, I had deleted the prior non-working kernel, so that my working kernel was 
not removed by the yum update.

Is it simply a matter that the older kernel waits while the new ones do not?

Comment 7 Dave Jones 2007-08-29 19:13:32 UTC
can you make sure you have the latest mkinitrd update installed, and then
recreate the initrd for the latest kernel you have installed.

(run mkinitrd as root for example usage, or you can just rpm -e the kernel, and
reinstall it, and it'll recreate it for you).

Comment 8 Jonathan Smith 2007-08-30 14:04:27 UTC
I gave up and installed Ubuntu 6.06-LTS. 

Disappointing since I had used Redhat / Fedora since rh-7.3. 

I did install fc-7 on a VMware appliance on a different machine 
to track progress, but figured that there was a rule out old machines 
since the money is with rich RHEL business customers and 
Fedora developers that need not worry about architecture. Stopped
hoping that I could use the same machine on which I always had

Better to close this out, rather than reminding me further of the 

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