On Wednesday 15 August 2007 02:23:05 am Warren Stockton wrote: > > problem is). > > Try setting "PROMPT_FOR_CONFIRM=yes" in /etc/sysconfig/boot. You might > want to set CONFIRM_PROMPT_TIMEOUT to something longer than 5 seconds for > the first couple of boots. > > I had similar problems on a HP dv6400 with some of the 10.3alpha kernels. > In my case it turned out to be /etc/init.d/boot.clock and I could lock the > system at will by running hwclock --systohc or hwclock --hctosys > (I don't have the problem on the current 10.3beta1 kernel and could never > quite nail down the root cause when I was seeing the problem on earlier > kernels.) >
Thanks for the pointer, that worked but not for the reasons I expected. Once I set PROMPT_FOR_CONFIRM, I was able to step through the service startup and boot properly with both the -default kernel and my own custom kernel. I didn't need to use noapic. However, booting without PROMPT_FOR_CONFIRM and without noapic produces a total lock that occurs at some point between .localfs and .udev-retry, but there are no error messages thrown and nothing indicated in the logs that would point to where the issue is. Booting with noapic and without PROMPT_FOR_CONFIRM also allows a normal boot, though with the stability issues my system experiences with noapic. Bizarre. The only thing I can think is that the parallel booting of services is somehow causing an error condition in the kernel that doesn't occur when boot prompting forces a delay between service starts, or something along those lines? I'll do a round of trial and error, disabling each boot.xxx service one by one to see if I can narrow it down, and maybe disabling parallel services as well. As far as the issue with the clock, I do remember running into that with earlier kernels, I think it first cropped up in 2.6.20, there was some change made that involved acpi, the clock and hpet or something along those lines; I remember eliminating the problem by judiciously tweaking my .config settings, but the problem seemed to have disappeared for me in recent kernels. Any other pointers appreciated... Thanks, KV --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
