Hello, there is big issue. Please, see attached output of `(date,echo,stat /dev/*) ` command. Some times of some nodes in /dev is in feature. Difference is roughly of `date +%:::z`, i.e. my timezone (roughly because of difference ~13 minutes, which is time I need to login, and to do this output after some experiments). Some times is right. Please, help.
Created attachment 117013 [details] log Log, which was result of (date;echo;stat /dev/*)>~/log command
Created attachment 117015 [details] emerge --info emerge --info output
udev-104-r12
The issue is most likely with your hardware clock being off from your system clock because of some time synchronization that's happening during your boot process. verify your /etc/conf.d/clock file has CLOCK_SYSTOHC="yes", and that will cause your system clock to get sync'd to your hardware clock on shutdown. If you have the settings setup as I've described above and still continue to have an issue. Please let us know in this bug and reopen it.
Yes, of course my hardware clock is set to local time because of dual-boot. My /etc/conf.d/clock: CLOCK="local" TIMEZONE="Europe/Moscow" CLOCK_OPTS="" CLOCK_SYSTOHC="no" SRM="no" ARC="no" I didn't set CLOCK_SYSTOHC because I want to be sure that hardware clock is set to local time. And I think that this issue is because udev create some nodes before /etc/init.d/clock started and udev thinks that my localtime is current time. But /etc/init.d/clock adjusted system time to my timezone and previous nodes became in future.
As I stated previously, it's an issue with your hardware clock being off. Not setting CLOCK_SYSTOHC to yes is not the valid solution for that. You set the CLOCK variable to local and you can still set CLOCK_SYSTOHC. It's an issue contained entirely within your system localized to a clock issue on your system. The time of your hardware clock is ahead of real time however the nodes are created before you have internet access to properly sync your clock BACK to the proper time. Follow the instructions in comment #4.
No, it not helped. Now is 04:50 but /dev/zero times is 08:44 (I need ~6 minutes to login)
CLOCK_SYSTOHC="yes"
I found this because `emerge postgresql` shows me a bunch of warnings make[4]: warning: Clock skew detected. Your build may be incomplete. And it's not postgresql issue, it's in make. Please, help!
Well, we won't fix your system clock. As your postgresql issue shows, this clearly is not an udev bug.
Yes, you're right, it's not only udev issue, it's all-system bug, and I see the 4-hour difference without make or postgres. I think that it's because system clock on start is intended to be in UTC, so it's for example, 20:00 UTC (BIOS time is 20:00). And nodes created by udev is 20:00 UTC. Then, when /etc/init.d/clock set up the time, system time is 16:00 UTC (20:00 in Europe/Moscow TZ with DST). So, nodes created before /etc/init.d/clock (at 20:00 UTC) is in future!
clock not being started early enough isnt going to be addressed in baselayout-1.x it should be already addressed in baselayout-2.x
clock will still be adjusted after udev has created nodes even in baselayout-2 though. Although it's a bit of chicken and egg as clock could need some services up like checkroot which in turn relies on udev.
I forgot to add that it's not my timer issue because when I set my BIOS clock to UTC time and set CLOCK="UTC" in /etc/conf.d/clock, then all works properly
Could you please attach your kernel configuration. I assume you have enabled the new RTC driver with option "CONFIG_RTC_HCTOSYS" (Set system time from RTC on startup) enabled. The kernel does not handle timezones, and this option will only work correct if RTC contains the time in UTC.
Created attachment 120494 [details] config for my current kernel
Not a kernel bug. With a couple of exceptions, the kernel has no concept of timezone and will always initiate the wall clock by interpreting the hardware clock as UTC. If this interpretation is incorrect it is the responsibility of userspace to change it before anything time-critical reads the wall clock. The best approach is to set the hardware clock as universal. Apparently Microsoft disagree but I think there are unofficial patches available to fix this windows bug :P
OMG, so IMHO baselayout must be upgraded to obsolete CLOCK="local" option in /etc/conf.d/clock or there must be a warning about setting CLOCK to local
BTW, I resolve this issue as Daniel says (I double-boot in M$'s OS very rarely. It need only one modification - disabling automatic DST changes, so it will never change RTC clock)
i dont see how this could be a problem in any real sense
