Bug 1201978 - dracut assumes BIOS time is UTC
Summary: dracut assumes BIOS time is UTC
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: dracut-maint-list
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1198761 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-14 07:12 UTC by Till Maas
Modified: 2015-04-24 09:02 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-24 09:02:01 UTC
Type: Bug


Attachments (Terms of Use)

Description Till Maas 2015-03-14 07:12:58 UTC
Description of problem:
dracut seems to assume that BIOS time is UTC, causing fsck on every boot due to the last check time being in the future in the second fsck run after dracut:

https://bugzilla.redhat.com/show_bug.cgi?id=963283#c20

Comment 1 Zbigniew Jędrzejewski-Szmek 2015-03-14 13:48:55 UTC
Yes, RTC time can reasonably only be in UTC, since it carries no timezone information. Anything else is broken.

That notwithstanding, fsck should not be run twice — so there's a bug here, but not in the time handling.

Comment 2 Till Maas 2015-03-15 07:19:29 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #1)
> Yes, RTC time can reasonably only be in UTC, since it carries no timezone
> information. Anything else is broken.

Please reconsider this, since this is needed for dual-boot environments. Fedora itselfs supports it with a setting in /etc/adjtime (the third line is LOCAL instead of UTC). Maybe it is enought to just copy /etc/adjtime into the dracut initramfs to address this, if only tools that support it already are used in the dracut initramfs.

Comment 3 Harald Hoyer 2015-03-16 11:05:26 UTC
Better change your other OS to use UTC!

https://www.google.com/search?q=configure+windows+to+use+utc

Comment 4 Ricardo Garcia 2015-03-16 22:41:11 UTC
As I commented on https://bugzilla.redhat.com/show_bug.cgi?id=1198761, it seems simply including /etc/adjtime when creating the initrd fixes the problem. There's no reason the supported option of running the system clock in local time (which is set that way if the installer detects Windows, by the way) will cause the fsck problem, in my humble opinion.

Comment 5 Eric Sandeen 2015-03-16 23:52:45 UTC
FWIW:

There is, as far as I can tell, a bug in e2fsck where even though docs sound like it will ignore a time off by up to 24h, it actually doesn't ignore it at all, and forces a full fsck anyway.  I'm trying to get clarification on the list about expected behavior, and will fix that (separate) bug as well.

(if fsck is really being run twice, though, I can't explain that one)

-Eric

Comment 6 Ricardo Garcia 2015-03-17 11:07:12 UTC
Sorry, I hadn't read the original comments in
https://bugzilla.redhat.com/show_bug.cgi?id=963283

So it seems there is the workaround of using broken_system_clock = 1, which is lying because the system clock is actually fine, in local time.

You can also include /etc/adjtime in the initrd and the problem stops appearing too, at least for me as I reported in the Fedora forums.

Even this could be considered a workaround because the actual problem could be fsck being run twice when it shouldn't.

And there's also the way e2fsck fixes the superblock last write time, maybe doing a full check which takes too much time when it shouldn't be doing that.

:(

Comment 7 Till Maas 2015-03-18 22:09:25 UTC
*** Bug 1198761 has been marked as a duplicate of this bug. ***

Comment 8 deadrat 2015-04-07 16:31:22 UTC
I have this issue too. Related post in Ask Fedora forum is : https://ask.fedoraproject.org/en/question/66041/fedora-21-is-very-slow-on-startup

Comment 9 Harald Hoyer 2015-04-24 09:02:01 UTC
There was a time, when dracut included adjtime.

But this was reverted
http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=d27cd4dfdd51c7f5178c5f4cb8f5bf4668228995

Having adjtime in the initramfs causes bugs like bug 981617


Note You need to log in before you can comment on or make changes to this bug.