Time Problems in Debian

Time problem in Debian: the time in Debian is always incorrect, 8 hours faster than the actual time, and the time in BIOS is correct. If you use the tzselect command to select the correct time zone (Asia/Shanghai), it is still incorrect. Run the hwclock -- show command to check whether the hardware time is correct. Cause: The time in Debian is incorrect. it is 8 hours faster than the actual time in Debian, and the time in BIOS is correct. If you use the tzselect command to select the correct time zone (Asia/Shanghai), it is still incorrect. Run the hwclock -- show command to check whether the hardware time is correct. Cause: In Linux, the system time is determined by hardware Time, UTC (/etc/default/rcS), and Timezone. The UTC option in/etc/default/rcS tells the Linux system whether the hardware time is UTC time. the Timezone is used to set the UTC time zone of the system (we usually set it to Asia/Shanghai ). When the system starts, it reads the hardware Time and calculates the system Localtime based on whether it is UTC time and the Timezone in which the system is located. Debian considers the BIOS time as World Time (UTC) by default, so the system time is 8 hours faster than the actual time. Solution: 1. modify it in/etc/default/rcS and set UTC = no 2. install ntpdate and execute time synchronization: apt-get install ntpdate-debian first. In the past, Debian had a better time zone configuration tool called tzconfig, and now it does not exist. However, it is easy to configure the time zone, mainly because the two files:/etc/localtime/etc/timezone are texts, and only one line of your own time zone is required, we are here in Shanghai, Asia/Shanghai (who knows why it is not Beijing ?). The type of the localtime file is unclear, and some timezone data is written in it. it can be copied from the system's built-in time zone file, and the bit is set: /usr/share/zoneinfo find the localtime copied from the Shanghai directory to the/etc directory. Some people say that a connection is also possible, which can ensure that the system data does not need to be managed when there is a change. Set the time zone and determine the Linux time scheme. Linux supports UTC Time, Coordinated Universal Time, that is, the Time on the primary meridian in the world coordination, and GMT) the difference seems to be that it is averaged by multiple atomic clocks. In the/etc/default/rcS file, whether or not the system uses UTC is set, and UTC = yes is used. The computer has its own time, that is, the hardware time, hard clock, that is, the time in the BIOS, and the shutdown will not be lost. This time will be read when the computer starts. If the time is set to UTC (GMT), that is, the time in London, it is required to set UTC = yes in the rcS file, and vice versa. In short, there are two correct settings: BIOS = local time, UTC = no BIOS = UTC time, and UTC = yes. Generally, the BIOS is set to local time, this is because if a dual system is installed, Windows may not understand utc, and a problem may occur. At this time, UTC = no. If everything goes well, the time displayed after entering Linux should be correct. However, many machines, including this 640 m instance, are still incorrect. Instead, they ran eight hours ahead of the correct time. The problem lies in the hardware reading time in Linux. Linux uses the hwclock command to read the hardware Time: hwclock -- show: Display the hardware time hwclock -- systohc: write the system time to the hardware hwclock -- hctosys: when a problem occurs when writing hardware time to the system, hwclock commands cannot be run successfully. errors are often as follows: select () to/dev/rtc to wait for clock tick timed out, that is, it cannot read/dev/rtc, that is, the hardware time. This is because of the problem between the BIOS processing method of some machines and the rtc kernel module of Linux. Linux has three other such modules, rtc/genrtc/rtc_dev, which seems to be a newer one, and debian usually uses the old rtc module; however, Dell, ibm, acer, and other vendors may all use new BIOS. such BIOS and rtc may not be used. If the above timeout problem occurs, there are two solutions: 1. add a parameter to hwclock, -- directisa, that is, hwclock -- directisa -- show. if the operation is successful, this method is feasible. Add this parameter as the default hwclock parameter. After debian 4.0, you can directly add a line in/etc/default/rcS: HWCLOCKPARS = "-- directisa". before 4.0, you may only add a line in the hwclock startup script, /etc/init. d/hwclock. sh, replace "/sbin/hwclock" with "/sbin/hwclock -- directisa ". In the debian sid, the first line of this script is actually HWCLOCKPARS =. you can also add parameters like that in the rfms. 2. for other kernel rtc modules, use the following method to test which module is easy to use: modprobe rtchwclock -- showrmmod rtcmodprobe kernel -- showrmmod genrtcmodprobe kernel -- showrmmod rtc_dev is easy to use, then, you can block the useless ones in the blacklist, and add the useful ones in the modules. After using these two methods, hwclock should be able to work directly, that is, it can read the hardware time. The configuration in utc is correct, and the restart time is correct. In order to make the BIOS time more accurate, in addition to finding a precise time source, such as a CDMA mobile phone or GPS, you can use your fingers to accurately set the BIOS time, you can also use hwclock to write accurate time to the BIOS. The previous method can be used with a few seconds of error, and the other method is less than one second. Install the ntpdate package. it can read the correct time from the time server. the precision is still very high: aptitude install ntpdate pool.ntp.org at this time, the system time is already ntp time, very accurate. write it into the hardware: hwclock -- systohc so that the BIOS time is very accurate. No network is available after the instance is started, and ntpdate cannot be run properly.