Improve boot process -- project update (SoC 2006)
Henrique de Moraes Holschuh
hmh at debian.org
Fri Aug 4 14:57:03 UTC 2006
On Fri, 04 Aug 2006, Carlos Villegas wrote:
> were: Use dash, Use networking in background, use hwclock in
> background, reorder with insserv. The time reduction for
Running hwclockfirst in background may be quite hazardous. It is not a
problem at all for most users, because the kernel manages to get the system
clock right by itself when people are using the local clock in GMT in most
mainstream architectures -- we should actually improve the setup to do away
with hwclock* during system startup (not shutdown!) in that case.
For all other cases (RTC not in GMT, kernel doesn't know how to read the RTC
by itself), hwclockfirst must be run in syncronous mode, it must be run as
early as possible in the init sequence, and it needs to be a chokepoint on
the early userspace setup. Getting the system clock right is a critical
operation in the bootstrap process. We had a lot of issues with fsck
because of braindamage in that area, already.
I really recommend that you leave the invocation of hwclockfirst alone
(well, other than moving it to its proper place, which is "as soon as
/dev/rtc is available for reading"), and I'd be very careful with the very
early userspace setup.
While typing this mail, I noticed that hwclockfirst.sh is again being called
at the wrong point (S18 is too late, it should be at around S04). That is a
bug, and gives one the impression that hwclockfirst is not that important...
which is true only for RTC in GMT, and is arch-dependant.
Anyway, hwclockfirst at S18 is util-linux' problem, but I still recommend
not messing with hwclockfirst.
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
More information about the initscripts-ng-devel