Fedora core 2.6.10.1.771_FC2 updated kernel gets stuck at boot!
 

Hi i recently installed FC2 on a dell machine and ran up2date.. the kernel etc got updated ..to most recent being Fedora core 2.6.10.1.771_FC2.. I installed FC2 after removing Win XP completely :D

when irestarted the machine and selected the above version on boot.....the machine gets stuck at "setting up system clock" and it would stay there forever!..


I had to do a hard restart and get into 2.6.5 FC2 kernel to get the machine started..

how do i solve this problem?.. please help..

-spaceman


anyone?

No idea, but which Intel processor is in you Dell box? If its a "Pentiun 4," you should probably be using an I686, smp, core version. And why the older FC2 release instead of FC3?

So I suggest you try downloading 2.6.10-1.770_FC3smp (if you have a P4) and installing it.

But, as I said, I have no idea if this would help.

Oh, I do recall that there was a post similar to yours where the boot seemed to "hang" when it was, in fact, just waiting for keyboard input. Try booting without the "rhgb" and "quiet" options to see what the boot loader is actually doing. (You can select the "edit" option at the GRUB prompt to change your boot options.)

What is smp?.. tIts a P4 3.2 Ghz. I sort of fixed the problem.. but i dunno what it means..

i restarted in the 2.6.5 version and went to /etc/sysconfig/clock and changed the UTC=false and ARC=false values to UTC=true and ARC=true.. and now the computer restarts just fine ( although the clock time in the lower right corner is at some weird time)

Please tell me what i did.. I h ave no idea.


Thanks,
Shiva.

Well, again I can't help there. Except to say that those setting should have been set correctly if you had installed a build for your hardware. (See below.)

The SMP stands for "symetric multi-processor" and the I686 means "P4." The point is that Intel implemented "hyper-thread" as, essentially, a dual-processor chip. So when you install FC3 for I686, smp, you're installing software that will use the "hyper-threading" and the full P4 instruction set. This, generally speaking, is a "good thing."

Well, you got me courious, so I "googled" ARC. This stands fro "Adaptive Replacement Cache," and I think what you did was, in essence, tell the CPU to use it L1 (or, perhaps, L2 -- I'm somewhat quessing here) cache differently.

Anyhow, FYI, I'm running a "3.06Gh, P4, Hyperthread" processor using 2.6.10-1.770_FC3smp, and I get this for my clock configuration.

By the way, I think UTC means "Universal Time Code," which used to be "GMT" before it was foune to not be PC to refer to "Grenwitch, England, GB" as the standard for time references. Setting UTC to "true" probably just set your time to 8 hours ahead of LA time.

Hmm interesting.... I wonder if I should set ARC back to false?

its quite strange..i can acess multiple redhat/fedora installations around my workplance ..and checked the /ets/sysconfig/clock settings.. all of them have UTC and ARC values set to false.


I wonder if its got to do something with the system clock (in the bios) that has not been set right initially..

I forgot to mention that the dell machins (3.2Ghz P4) was new!..

i did a date on the command prompt..the time is 3 hrs ahead of PST (LA time) which is not exactly the GMT time..

so UTC may not necessarily mean GMT standard?
-Spaceman

Hmm...again i found this in /usr/share/doc/initscripts-7.55.2/sysconfig.txt of my system

/etc/sysconfig/clock:

deprecated values from earlier releases:

CLOCKMODE=GMT indicates that the clock is set to UTC
CLOCKMODE=ARC on alpha only indicates the ARC console's
42-year time offset is in effect

currently correct values:

UTC=true,yes
Indicates that the hardware clock is set to UTC.
UTC=no,false
Indicates that the hardware clock is set to Local Time.

Not having UTC set defaults to the last used (if recorded
in the adjtime file), or to localtime, if not adjtime file
exists.

ARC=true on alpha only indicates the ARC console's
42-year time offset is in effect; otherwise the normal
Unix epoch is assumed.

SRM=true on alpha only indicates the SRM 1900 epoch is in
effect; otherwise the normal Unix epoch is assumed.

ZONE="filename" indicates the zonefile under /usr/share/zoneinfo
that /etc/localtime is a copy of, for example:
ZONE="US/Eastern"

although i still don't understand why when the UTC and ARC values are set to false ,the system doesn't work??...am i missing something obvious?

i strongly suspect the culprit is the BIOS clock that needs to be set manually (since the system in new)

any comments?


and thanks all for the smp i686 details.

-spaceman

Well, unless someone put an Alpha processor into your Dell box, I can't see how the ARC (which, I see, is NOT what I found on Goggle -- thanks for the correct information) setting would make any difference.

And I can't see how ANY clock setting would effect your booting.

My guess -- and it's only a guess -- is that the system was attempting to install a new driver, or access some hardware, when it hung, and that device or hardware was marked as "unavailable" or "not installed" so the next boot skipped that step. (If I'm correct, you could set you clock settings back to "off," and still boot with no problem.)

My recollection is that there are two more steps in the boot after the clock is initialized. Perhaps there was a problem there.

Oh, you know, I think the clock initialization may attempt to access an Internet or network time server for a time check. Perhaps it wasn't "hung," but just waiting for a connection time-out. And then it marked that connection as unavailable, so it no longer waits for it. (When I installed FC3, there was an active time server on our local network, and the proxy server was running and available, so -- if that's what's happening -- I didn't see any "hang." Although the "time" initialization does seem to take a while.)

Fedora FC2 2.6.10 fix for Dell PowerEdge SC420
 

As far as I can make out, the hardware RTC (realtime clock) interface on the SC420 is not 100% standard. It's got to be a v-e-r-y subtle difference, since FC2 2.6.9 boots just fine on an SC420, and 2.6.10 chokes on RTC set.

This problem was the subject of a very long thread in a Debian Bug Report (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=277298).

It's a long thread so I'll skip to the good part.

You can thank Geert Stappers for this delightfully simple workaround:

http://people.debian.org/~stappers/w/277298.sh

(basically it renames /sbin/hwclock and puts a sh-script wrapper around it that adds the --directisa parameter)

Just wget that script and run it -- it will do the rename and create the wrapper script as /sbin/hwclock.

/sbin/hwclock is invoked from /etc/rc.sysinit -- with Geert's patch in place it runs the sh-script instead of the original binary and presto! no more hang on setting system clock.

I can confirm FC2 2.6.10-771 boots just fine with this workaround in place. In fact I'm writing this post in FireFox 1.02 running on the box in question:
I'm so happy with this fix, because it lets me keep 'yum upgrade' functionality intact -- I'm still running a stock kernel!

Hopes this helps others prevent unnecessary hair loss.

d.