Red Hat Bugzilla – Bug 125607
Kernel makes a long pause at the very begin
Last modified: 2015-01-04 17:06:52 EST
Description of problem:
When booting, there is along pause ( 1 and half minute ) before
starting the kernel.
Version-Release number of selected component (if applicable):
- select fedora in the grub boot menu ( by pressing the ENTER key )
- the gfx screen is wiped and in text mode the boot command list
appears ( with their results ) : root , kernel, initrd
- then it stops there, "Uncompressing linux ..." should appear, but
I did some testing, by manualy entering grub commands :
- root (hd0,0) ; kernel /vmlinuz-2.x.x.x ; initrd /initrd-2.x.x.x
This hangs as described for 10 seconds, then boots normally.
- root (hd0,0) ; kernel /vmlinuz-2.x.x.x ro ; initrd /initrd-2.x.x.x
same as before ( 10 sec hang )
- root (hd0,0) ; kernel /vmlinuz-2.x.x.x root=LABEL=/ ; initrd
The hang now takes 1 minute and 32 seconds, then it goes on normally.
- kernel /vmlinuz ro rhgb -> 10 seconds hang
- kernel /vmlinuz ro rhgb quiet -> 1:32 hang
- kernel /vmlinuz ro root=LABEL=1 rhgb -> 1:33
- kernel /vmlinuz ro root=LABEL=1 rhgb quiet -> 1:33
Another thing: if I switch in BIOS the IDE mode to RAID ( it is a
single HD, so there is no "real world" change ), then GTUB loads, it
loads the kernel, initrd, but after the "boot" command it hangs
forever ( I waited 8 hours ).
It there a way to see what is grub doing ?
I tried the "debug on" command, but saw no effect.
I tried an older grub ( 0.93-something ) and it was the same.
Then I tried to boot an older 2.4.x redhat kernel, and it did not have
Switching component to "kernel".
The kernel that has no problems is : kernel-2.4.22-1.2061.nptl-athlon
Probably timeouts probing the devices to find the right label.
The label for the root FS ?
Isn't that done _after_ the kernel is uncompressed ?
I also teste more :
no delay : 2.6.0-test10
delay : 2.6.7 , 2.6.6 , 2.6.6-1.435
Aha, the CONFIG_EDD option is the culprit.
I tried linux-2.6.7 with the 2.6.6-1.435 config file and it has the
delay, but after turning CONFIG_EDD off it has no delay at boot.
I don't know if this is related, but I did some searching on EDD and
was interested when I saw Dell have some information since I am seeing
something similar with my Dell. Note I don't know if mine is ever
booting because I haven't waited the 1.5 minutes or so to see (I will
While searching around dell's site, I found this patch:
Which just by your previous information in this bugzilla and by the
name of the patch make me suspect that this will fix the issue w/o
having to disable EDD. Though disabling EDD doesn't seem to be a bad
idea unless you are going to use it.
I already tried that patch, no change. See
Well, sadly that did not help me at all... My system doesn't boot.
I've waited as long as five minutes and still nothing happens. It's
very sad and very disheartening. I've had more problems this week
with FC2 than any previous release.
I'm going to try a few things like checking on BIOS upgrades and the
like. Maybe I'll get lucky, who knows. :)
My BIOS is up-to-date. I've tried reinstalling from ISOs off of my
second hard drive (thinking maybe the burn was bad). That still
failed to boot.
I then double checked the md5sum output for the .iso files and they
Thinking maybe a newer kernel might help, I reinstalled FC2 from
scratch, booted into rescue mode and installed
kernel-2.6.7-1.494.2.2.i686.rpm. Still nothing.
I'm running out of things to try. There's not much to the Dell
Dimension XPS T500 BIOS in the way of advanced settings. I'm at my
wits end. Anything else I can try?
Okay, moved the hard drive I installed FC2 onto into a Dimension XPS
R450 (P2 450) system and it had the same problem. Putting that same
hard drive in my home grown P4 system (Intel mobo D845PESV) the system
boots up just fine.
Got with a friend of mine who has an XPS T600 (same as my T500 only he
has a faster processor) and compared BIOS settings. He is running FC2
without any problems. I made my BIOS settings match his, no go. I
even DOWNGRADED my BIOS by one revision to match his, no go.
However, I found that if I enter the grub command line and issue the
commands by hand, the system DOES timeout and eventually boot within 5
minutes or so (I haven't sat next to it to see it boot yet).
I am downloading the latest kernel source and am going to recompile it
with the EDD disabled to see if that clears up my problem. Strange
that it won't timeout and boot when I select the item in the grub menu
-- but does when I enter it by hand. Coincidence? Probably.
I will post here the results of my disabling EDD shortly.
Recompiled without CONFIG_EDD and I still get the hangup. Mine is so
very different though. I've seen the system actually boot twice (no
idea the length of pause since that's usually when I throw my hands up
and just leave it sit there). I know that I've waited 15-20 minutes
before and not seen any progress on booting. (Thankfully I have a
second system so waiting 15-20 minutes isn't that painful.)
So to recap I have a Dell XPS T___ and a Dell XPS R___ with the same
hang problem. However, I'm beginning to believe it is something
different from yours -- should I branch out and make a separate bug
Yes, if CONFIG_EDD=n, please file yours as a different bug.
I've seen two BIOSes reported which don't like EDD's read sector zero
functionality. I'm open to suggestions, as I don't have a way to
know which BIOSes will behave badly (i.e. pause for a while) and
which won't. In one instance, using a different version of the BIOS
solved it. I'm inclined to say it's a BIOS problem and to take it up
with your BIOS manufacturer in each case, but that isn't very
I see now that GRUB uses int13 fn42 (Read LBA) if the BIOS claims to
support LBA, and falls back to fn2 (Read CHS) if not. The BIOSes
that all have this problem are very new, and likely all support LBA.
Anyone want to help code this up for EDD? :-)
"take it up with your BIOS manufacturer"
You think it's worth it ? ( Will they listen at all to an end user ? )
"Anyone want to help code this up for EDD?"
C'mon, it's only a few lines of code ! ;-)
David, Alan, and Jeff:
each of you have reported to me separate controllers which either
pause (Jeff, David), or hang completely with CONFIG_EDD=[ym].
I'll attach a patch I'd like you to try if possible. This causes EDD
to use int13 fn42 EXTENDED READ rather that int13 fn02 READ SECTORS if
the BIOS reports it can do so. There's also a Kconfig addition (which
will likely clash with Alan's recent patch) for CONFIG_EDD_SKIP_MBR
which *should* allow the use of the fn41 and fn48 aspects, without
causing disk sector reads. Hopefully that won't be necessary to set
to y, but I think the option may be helpful.
Please post test results in this bugzilla.
Created attachment 104683 [details]
and you can skip the Makefile hunk, it's redundant.
Created attachment 104753 [details]
Attached is what I'm sending to akpm. It fixes a few bugs in the previous patch
I had posted. In particular, it decides when to issue int13 fn48 correctly
now, it zeros out the edd_info block just in case, and it stops using the
zero-page for the device address parameter buffer, using the stack instead.
Works for me on x86, code path is identical for x86-64.
David B - I posted a patch to lkml last week which provides two new
command line options: edd=off disables EDD completely, edd=skipmbr
disables the MBR probing (which is what affects you). I expect akpm
to include this after 2.6.10 is out.
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat. The Fedora legacy project will be producing further kernel
updates for security problems only.
If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.