If you dual boot windows, and fsck doesn't depend on hwclock, there's minor errors on the timestamps. Reproducible: Always Steps to Reproduce: /etc/conf.d/hwclock to "local"
There is not enough information in this bug for me to tell what is going on since hwclock always should run before fsck. Please re-open when you can provide the output from emerge --info and a copy of /var/log/rc.log of a reboot. That will allow me to see when hwclock is running in your boot sequence.
What? There's no "depends" in the rcs for hwclock. So if you dual boot windows, sometimes it causes minor errors in fsck.
There is a "use clock" in fsck, and hwclock has "provide clock". This means fsck will run hwclock before it does anything because of the use statement as long as fsck and hwclock are in the same runlevel.
I don't know. I'll check again today. Unless there was a recent change... well I mean its minor, but I definitely had to add "depends" for the hwclock. fsck was running first.
What about swclock?
swclock is also a provider for clock, so the same thing should happen. However, I do not recommend using swclock if your system has a rtc. That sets your system time based on the date/time of a file.
So you're saying I need to turn off the swclock? That that's the problem? I thought they were both supposed to be running.
Correct, if you have both hwclock and swclock in your boot runlevel, you should turn off swclock. The only time you should ever run swclock is if your computer does not have a clock.
I had no idea, I never turned it on certainly, it was on my default. I'll give that a try today.
It was on *by default.
We do not add swclock to the runlevels by default, so I am not sure how it would have gotten there.
Yeah, you're right, I checked, it wasn't swclock. I know adding rc_need fixed it... I'm not sure, I'll check a bit more.
