Hello,

some additional information as far as I could gather.

I put some echo lines into hwclockfirst.sh so I could see that hwclockfirst.sh is called *before* the fsck complains and seems to work properly: Because /dev/.udev exists no actual call to hwclock is made in the script, anyway. When I forced the call of hwclock by uncommenting the #if nothing changed.

So it appears to me that the problem could be with the population of /dev which starts before hwclockfirst.sh: The population of /dev could be with misinterpreted time which in my case would be to consider the system time to be UTC, which it is not at all. Applying the correct time zone to this wrong assumption correctly would lead to the 2 hours in the future. As hwclockfirst.sh is doing everything as it should the following fsck just finds a mess and reacts, again correctly. Furthermore this would explain the completely correct behaviour on my UTC desktop computer.

I hope my brilliant musing ;-) doesn't obstruct you from finding the true cause of the problem.


Best regards, Alexander.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to