4:14 a.m.
Why does this bug exist only in Fedora, not in openSUSE or Mageia or *buntu?
All my systems are multiboot, so only a select very few are on UTC. None that
are on UTC have Fedora installed. This means every Fedora boot takes about
twice as long or longer than anything else takes, waiting on all the
unnecessary FS checks.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
2:44 p.m.
New subject: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
Felix Miata <mrmazda <at> earthlink.net> writes:
Why does this bug exist only in Fedora, not in openSUSE or Mageia or
*buntu?
All my systems are multiboot, so only a select very few are on UTC. None that
are on UTC have Fedora installed. This means every Fedora boot takes about
twice as long or longer than anything else takes, waiting on all the
unnecessary FS checks.
Just as a workaround, you CAN make a Windows box use UTC for the RTC,
there's a registry hack. Google "RealTimeIsUniversal". I've done this on
all
my Windows/Fedora machines. There are some minor issues in Windows (which
you'll read about in doing the above search), but if you only use Windows
rarely, it's nothing serious.
3:20 p.m.
Andre Robatino composed on 2015-04-24 19:44 (UTC):
Felix Miata wrote:
> Why does this bug exist only in Fedora, not in openSUSE or Mageia
or *buntu?
> All my systems are multiboot, so only a select very few are on UTC. None that
> are on UTC have Fedora installed. This means every Fedora boot takes about
> twice as long or longer than anything else takes, waiting on all the
> unnecessary FS checks.
Just as a workaround, you CAN make a Windows box use UTC for the
RTC...
Multiboot is not a universe limited to Windows and Linux, and certainly not
only the latest version of either. And, there's a whole LAN to consider, not
one PC in isolation.
When I acquire a new PC or motherboard, I set its clock to match the rest of
the clocks in the building, neighborhood and city, so the sun is overhead
somewhere around noon. That's how time is supposed to be. It's up to a PC to
adjust to me and my environment, not vice versa, and when I boot a floppy I
don't need to look at a watch, TV or wall clock to see what time it really is.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
7:25 p.m.
New subject: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
Felix Miata <mrmazda <at> earthlink.net> writes:
> Just as a workaround, you CAN make a Windows box use UTC for the
RTC...
Multiboot is not a universe limited to Windows and Linux, and certainly not
only the latest version of either. And, there's a whole LAN to consider, not
one PC in isolation.
AFAIK, Windows is the only OS that has trouble using UTC for the RTC.
When I acquire a new PC or motherboard, I set its clock to match the
rest of
the clocks in the building, neighborhood and city, so the sun is overhead
somewhere around noon. That's how time is supposed to be. It's up to a PC to
adjust to me and my environment, not vice versa, and when I boot a floppy I
don't need to look at a watch, TV or wall clock to see what time it really is.
If you're using a laptop and travel between time zones, there is no
permanent local time. And even if you stay in one place, if your local time
is subject to Daylight Saving, the fact that it can go backwards when
changing from DT to ST causes problems for the OS. See
https://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html . To avoid that, the time
used by the RTC should increase monotonically. Also, when people share
files, if their RTCs are in different time zones, it's impossible to know
exactly how to interpret a file's timestamps, since they depend on the
originating PC's time zone. The only way to avoid these problems is for
everyone to have their RTC set on the same monotonically increasing time,
and UTC is the natural choice.
8:06 p.m.
Andre Robatino composed on 2015-04-25 00:25 (UTC):
Felix Miata composed:
> > Just as a workaround, you CAN make a Windows box use UTC for
the RTC...
> Multiboot is not a universe limited to Windows and Linux, and
certainly not
> only the latest version of either. And, there's a whole LAN to consider, not
> one PC in isolation.
AFAIK, Windows is the only OS that has trouble using UTC for the RTC.
Have you ever used DOS or OS/2? I don't remember ever seeing options at
installation time to choose anything other than local in either one. Same for
W95, W98, WXP & W7. How they were set up initially is how they will remain.
> When I acquire a new PC or motherboard, I set its clock to match
the rest of
> the clocks in the building, neighborhood and city, so the sun is overhead
> somewhere around noon. That's how time is supposed to be. It's up to a PC to
> adjust to me and my environment, not vice versa, and when I boot a floppy I
> don't need to look at a watch, TV or wall clock to see what time it really is.
If you're using a laptop and travel between time zones,
No laptop, no cell phone, no traveling among time zones.
there is no
permanent local time. And even if you stay in one place, if your local time
is subject to Daylight Saving, the fact that it can go backwards when
changing from DT to ST causes problems for the OS. See
Bigger problems trying to retrofit, assuming the possibility even exists for
any in particular, loads of diverse installations to UTC, or track which have
been converted or didn't need to be or can't be, and which not, than to have
them reboot after or shut down while the clocks change.
https://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html . To avoid that,
the time
used by the RTC should increase monotonically. Also, when people share
files, if their RTCs are in different time zones, it's impossible to know
exactly how to interpret a file's timestamps, since they depend on the
originating PC's time zone. The only way to avoid these problems is for
everyone to have their RTC set on the same monotonically increasing time,
and UTC is the natural choice.
That UTC is the ideal choice for most use cases does not justify making it
the only choice for all installations. This is still FOSS, home of choice and
multiple ways to get things done. All your base are not belong to us yet.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
8:55 p.m.
New subject: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
Felix Miata <mrmazda <at> earthlink.net> writes:
> AFAIK, Windows is the only OS that has trouble using UTC for the
RTC.
Have you ever used DOS or OS/2? I don't remember ever seeing options at
installation time to choose anything other than local in either one. Same for
W95, W98, WXP & W7. How they were set up initially is how they will remain.
The last four are Windows and DOS is the predecessor to Windows. I'm not
familiar with OS/2, but from
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/keeping-time-in-...
it looks like OS/2 is capable of keeping its RTC in TAI (which AIUI is
basically the same as UTC except that TAI doesn't have leap seconds, so TAI
is "real time", and UTC is TAI interspersed with leap seconds, so both
increase monotonically, but UTC has "jumps").
> https://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html . To avoid
that, the time
> used by the RTC should increase monotonically. Also, when people share
> files, if their RTCs are in different time zones, it's impossible to know
> exactly how to interpret a file's timestamps, since they depend on the
> originating PC's time zone. The only way to avoid these problems is for
> everyone to have their RTC set on the same monotonically increasing time,
> and UTC is the natural choice.
That UTC is the ideal choice for most use cases does not justify making it
the only choice for all installations. This is still FOSS, home of choice and
multiple ways to get things done. All your base are not belong to us yet.
UTC (or maybe TAI which some have argued is better) should be ideal for all
use cases, if Microsoft ever gets around to fixing Windows. All OSes I know
of, even Windows, know how to display local time to the user, who wouldn't
have to know or care what the RTC is set to, if Windows wasn't broken. You'd
tell it what your local time zone is, it gets either UTC or TAI via NTP,
sets the RTC to that, converts from that to your local time, and displays
that to you. And as long as you multiboot only between non-Microsoft OSes,
it works fine and in that case there is no advantage to having the RTC on
local time. The only reason Linux or any other OS needs to support having
the RTC on local time for now is as a workaround to coexist with broken Windows.
9:11 p.m.
Andre Robatino composed on 2015-04-25 01:55 (UTC):
The only reason Linux or any other OS needs to support having
the RTC on local time for now is as a workaround to coexist with broken Windows.
Not investing resources in disturbing sleeping dogs is a reason that is
always important to some people.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
9:26 p.m.
New subject: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
Andre Robatino <robatino <at> fedoraproject.org> writes:
it looks like OS/2 is capable of keeping its RTC in TAI (which AIUI
is
basically the same as UTC except that TAI doesn't have leap seconds, so TAI
is "real time", and UTC is TAI interspersed with leap seconds, so both
increase monotonically, but UTC has "jumps").
Actually, I have that backwards, after a little reading it appears that UTC
basically pauses during each leap second (but doesn't go backwards). TAI is
currently 35 seconds ahead of UTC and that increases by one each time
there's a leap second.
12:47 a.m.
There's no point in this being ideological, Fedora should tolerate the
RTC being in local time. Since the dawn of Windows, it's behaved very
consistently with respect to RTC time being local time. This is even
acknowledged in the UEFI spec as well, which permits local time plus
timezone plus daylight savings time metadata. There's just no excuse
for any distribution basically being a jerk and punishing the user
over Microsoft's ancient decisions.
The last time I tested this, it was on a UEFI laptop with Windows 8.1
and either Fedora 21 and 22 pre-alpha. I don't recall the details
partly because it was confusing at the time and a non-priority to
track down. Since the RTC clearly indicated local time and the
timezone, there was absolutely no reason for Fedora to flip out but it
was consistently changing the RTC every boot. Window would do the same
thing but would be delayed by an hour or so before it figured things
out. But in the midst of doing piles of clean installs of Windows and
Fedora, at some point Fedora settled on the idea of honoring the RTC
in local time while timedatectl warned of this and that it might cause
problems because it wasn't entirely supported.
Time in UTC is just as absurd and arbitrary as time in a local
timezone, so if Windows is going to get berated for not dealing with
UTC properly, then Fedora can be berated for not dealing with local
time properly.
--
Chris Murphy
2:34 a.m.
On 27 April 2015 at 06:47, Chris Murphy <lists(a)colorremedies.com> wrote:
Time in UTC is just as absurd and arbitrary as time in a local
timezone, so if Windows is going to get berated for not dealing with
UTC properly, then Fedora can be berated for not dealing with local
time properly.
Not really, as multiboot systems need to be able to handle DST and
timezone change.
--
imalone
http://ibmalone.blogspot.co.uk
3:54 a.m.
On 04/27/2015 09:34 AM, Ian Malone wrote:
On 27 April 2015 at 06:47, Chris Murphy
<lists(a)colorremedies.com> wrote:
> Time in UTC is just as absurd and arbitrary as time in a local
> timezone, so if Windows is going to get berated for not dealing with
> UTC properly, then Fedora can be berated for not dealing with local
> time properly.
>
Not really, as multiboot systems need to be able to handle DST and
timezone change.
They have been able to do so for many years with one
exception: Recent Fedora releases.
7:26 a.m.
On 27 April 2015 at 09:54, Ralf Corsepius <rc040203(a)freenet.de> wrote:
On 04/27/2015 09:34 AM, Ian Malone wrote:
>
> On 27 April 2015 at 06:47, Chris Murphy <lists(a)colorremedies.com> wrote:
>
>> Time in UTC is just as absurd and arbitrary as time in a local
>> timezone, so if Windows is going to get berated for not dealing with
>> UTC properly, then Fedora can be berated for not dealing with local
>> time properly.
>>
>
> Not really, as multiboot systems need to be able to handle DST and
> timezone change.
They have been able to do so for many years with one
exception: Recent Fedora releases.
I have at least once had a multiboot system two hours out because two
OS both decided they should be updating the BIOS clock. Since when
running the system clock on UTC has seemed the rational thing to do.
--
imalone
http://ibmalone.blogspot.co.uk
7:54 a.m.
On Sun, Apr 26, 2015 at 11:47:18PM -0600, Chris Murphy wrote:
Time in UTC is just as absurd and arbitrary as time in a local
timezone,
No, it's not. This has been written about many times, but in short:
- the information about the timezone used is not stored in RTC,
so all users of RTC need to be configured to use the same timezone
externally
- the offset that was actually used when setting RTC is not stored,
so around the DST transitions, there's no way to know if the clock
was already updated or not.
When we all had nice big tower computers, this wasn't as much of a
problem: a machine could spend its entire useful life in the same
timezone. But now people lug their laptops around, and even expect
the timezone to be updated automatically from geoinfo.
In this specific case, the problem is that the *initramfs* needs an
up-to-date copy of this information. We used to check the root
filesystem after mounting it read-only. Now we check filestems either
in the kernel (btrfs, xfs), or from the initramfs (ext[234] and most
others). This makes the checking more robust, but it means that we
need timezone info even earlier if RTC is in localtime.
In this specific case, not only all systems in the multi-boot setup,
but also the *initramfs* needs an up-to-date copy of this
information. So first, your generic initramfs distributed with the
system cannot be used anymore, and second, you need to rewrite your
initramfs'es when you change the timezone.
A very similar issue happens with portable storage devices: if you
store timestamps as localtime on them, when you move them to a
different machine, there's no way to know if the same timezone (and in
the same DST phase) was used. We are starting to follow Android here,
and using UTC timestamps instead, and only doing conversions locally.
[This is a tradeoff: we pick to display the information about how long
ago the file was written (e.g. 2 days, 3 hours, 5 minutes ago), and
possibly lose the information what the clock was displaying at the
time (e.g. 11:05). In *some* circumstances the second would be useful too,
but in majority of cases the first is what we actually care about.]
We could try to build an infrastructure to store tz information, and
rebuild initramfses, etc, or we can just rip of the bandaid. This is a
game of whack-a-mole which accelerates are systems get more dynamic
and mobile that we cannot really hope to win.
Zbyszek
so if Windows is going to get berated for not dealing with
UTC properly, then Fedora can be berated for not dealing with local
time properly.
11:39 a.m.
On Mon, Apr 27, 2015 at 6:54 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Sun, Apr 26, 2015 at 11:47:18PM -0600, Chris Murphy wrote:
> Time in UTC is just as absurd and arbitrary as time in a local
> timezone,
No, it's not. This has been written about many times, but in short:
None of what you wrote explains a.) Why RTC in local works fine on
Windows; b.) why two users in this thread, including the original
poster, had problems with a stable timezone set.
I don't know about Felix's hardware, but in my case it was UEFI
hardware, so RTC in local time does also include timezone and daylight
time status.
- the information about the timezone used is not stored in RTC,
so all users of RTC need to be configured to use the same timezone
externally
- the offset that was actually used when setting RTC is not stored,
so around the DST transitions, there's no way to know if the clock
was already updated or not.
When we all had nice big tower computers, this wasn't as much of
a
problem: a machine could spend its entire useful life in the same
timezone. But now people lug their laptops around, and even expect
the timezone to be updated automatically from geoinfo.
In this specific case, the problem is that the *initramfs* needs an
up-to-date copy of this information. We used to check the root
filesystem after mounting it read-only. Now we check filestems either
in the kernel (btrfs, xfs), or from the initramfs (ext[234] and most
others). This makes the checking more robust, but it means that we
need timezone info even earlier if RTC is in localtime.
Since day 1 NTFS encodes time as UTC. It's really only the RTC that's
expected to be in local time and the reason claimed is that users
freak out when they go exploring in BIOS configuration and see time
other than wall clock time (local time).
FAT meanwhile is expected to be encoded in local time, while also
lacking any sort of timezone field so all bets are off (at least
forensically, at which point why does anyone really care?)
A very similar issue happens with portable storage devices: if you
store timestamps as localtime on them, when you move them to a
different machine, there's no way to know if the same timezone (and in
the same DST phase) was used. We are starting to follow Android here,
and using UTC timestamps instead, and only doing conversions locally.
[This is a tradeoff: we pick to display the information about how long
ago the file was written (e.g. 2 days, 3 hours, 5 minutes ago), and
possibly lose the information what the clock was displaying at the
time (e.g. 11:05). In *some* circumstances the second would be useful too,
but in majority of cases the first is what we actually care about.]
Seeing as NTFS and HFS+ since ancient times encode timestamps in UTC,
I'm flummoxed that this may not be the case on Linux distros for the
past 20 years? Really? The filesystem timestamp could be local time?
If so, that's hilarious.
We could try to build an infrastructure to store tz information, and
rebuild initramfses, etc, or we can just rip of the bandaid. This is a
game of whack-a-mole which accelerates are systems get more dynamic
and mobile that we cannot really hope to win.
Hindsight being 20/20, obviously around 13 years ago Linux (and
friends) should have agreed to not fight the RTC being in local time
on multiboot systems, in particular dual boot ones with Windows.
Windows figures out what timezone the RTC is in by reading the
registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
which a Linux OS service could also defer to by default rather than
the adversarial relationship that's been chosen.
--
Chris Murphy
11:52 a.m.
On Monday 27 April 2015 10:39:40 Chris Murphy wrote:
On Mon, Apr 27, 2015 at 6:54 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
> On Sun, Apr 26, 2015 at 11:47:18PM -0600, Chris Murphy wrote:
>> Time in UTC is just as absurd and arbitrary as time in a local
>> timezone,
> No, it's not. This has been written about many times, but in short:
None of what you wrote explains a.) Why RTC in local works fine on
Windows; b.) why two users in this thread, including the original
poster, had problems with a stable timezone set.
Windows doesn't work fine with RTC in local time, unless you have one and
only one Windows install on the system. If you (say) dual-boot Windows 95
and Windows NT 4.0 (I've done this in a work environment), and boot back and
forth between them on a DST change flag day, then both OSes expect to change
the RTC to reflect current local time. You then have to pull the RTC time
back to reality manually, as it's now out by one hour.
IOW, Windows works with RTC in local time if (and only if) it's the one and
only OS on the system that writes to the RTC. Fedora also writes to the RTC,
and thus we have to somehow co-ordinate changes with Windows in such a way
that DST adjustments only get applied once; I've not looked at UEFI to find
out whether UEFI solves this.
<snip>
> We could try to build an infrastructure to store tz information,
and
> rebuild initramfses, etc, or we can just rip of the bandaid. This is a
> game of whack-a-mole which accelerates are systems get more dynamic
> and mobile that we cannot really hope to win.
Hindsight being 20/20, obviously around 13 years ago Linux (and
friends) should have agreed to not fight the RTC being in local time
on multiboot systems, in particular dual boot ones with Windows.
Windows figures out what timezone the RTC is in by reading the
registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
which a Linux OS service could also defer to by default rather than
the adversarial relationship that's been chosen.
Which registry entry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation?
The one in my Windows 95 install, or the one in my Windows NT 4.0 install?
Come to that, how is Linux supposed to find and read the registry, given
that it may not be allowed by administrator policy to mount the filesystem
that contains the registry? In the worst case, you dual boot the way I did
at work, where the machine's disk is in a cold swap caddy, and you cannot
physically get at the disk.
--
Simon Farnsworth
3:36 p.m.
On Mon, Apr 27, 2015 at 10:52 AM, Simon Farnsworth <simon(a)farnz.org.uk> wrote:
Windows doesn't work fine with RTC in local time, unless you have
one and
only one Windows install on the system. If you (say) dual-boot Windows 95
and Windows NT 4.0 (I've done this in a work environment), and boot back and
forth between them on a DST change flag day, then both OSes expect to change
the RTC to reflect current local time. You then have to pull the RTC time
back to reality manually, as it's now out by one hour.
The point is that systemd gets fussy when RTC is in local time even if
it's a single boot system. I don't know what the full consequence of
its complaint is, but it complains nevertheless (via timedatectl)
basically saying it's unsupported.
Windows 95 and NT are completely different lineages and never
supported dual-boot. Maybe Windows 95 followed by 98, or Windows NT
3.5 followed by 4.0 would have; just as it's possible to dual boot
Windows 7 followed by 8.
IOW, Windows works with RTC in local time if (and only if) it's
the one and
only OS on the system that writes to the RTC. Fedora also writes to the RTC,
and thus we have to somehow co-ordinate changes with Windows in such a way
that DST adjustments only get applied once
If there's evidence of another system present, maybe don't change the
RTC? Just use it as a guide absent an Internet connect, and with one
chrony can set system time without changing the RTC which only causes
problems.
Apple's boot camp package patches Windows to deal with this problem, FWIW.
; I've not looked at UEFI to find
out whether UEFI solves this.
It's solved there, I have no idea if this is honored by the kernel or
systemd though.
http://wiki.phoenix.com/wiki/index.php/EFI_TIME
<snip>
> > We could try to build an infrastructure to store tz information, and
> > rebuild initramfses, etc, or we can just rip of the bandaid. This is a
> > game of whack-a-mole which accelerates are systems get more dynamic
> > and mobile that we cannot really hope to win.
>
> Hindsight being 20/20, obviously around 13 years ago Linux (and
> friends) should have agreed to not fight the RTC being in local time
> on multiboot systems, in particular dual boot ones with Windows.
> Windows figures out what timezone the RTC is in by reading the
> registry entry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
> which a Linux OS service could also defer to by default rather than
> the adversarial relationship that's been chosen.
>
Which registry entry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation?
The one in my Windows 95 install, or the one in my Windows NT 4.0 install?
Seeing as Microsoft doesn't support either one of those for something
like 20 years now, I'd say neither but still possible to infer another
OS is already present and to leave the RTC alone and just adapt to a
local setting and time service rather than insisting on changing the
clock.
Come to that, how is Linux supposed to find and read the registry,
given
that it may not be allowed by administrator policy to mount the filesystem
that contains the registry? In the worst case, you dual boot the way I did
at work, where the machine's disk is in a cold swap caddy, and you cannot
physically get at the disk.
If it seems like a mono OS installation, then its reasonable for the
OS to assume it can assume complete ownership of the RTC.
But just like a VM doesn't assert control over the real hardware RTC,
a guest OS in a dual boot situation shouldn't either. If that guest is
intending to be friendly, it ought to adapt rather than enforce a
whole new policy the primary OS can't deal with.
--
Chris Murphy
4 a.m.
On Monday 27 April 2015 14:36:53 Chris Murphy wrote:
On Mon, Apr 27, 2015 at 10:52 AM, Simon Farnsworth
<simon(a)farnz.org.uk> wrote:
> Windows doesn't work fine with RTC in local time, unless you have one and
> only one Windows install on the system. If you (say) dual-boot Windows 95
> and Windows NT 4.0 (I've done this in a work environment), and boot back and
> forth between them on a DST change flag day, then both OSes expect to change
> the RTC to reflect current local time. You then have to pull the RTC time
> back to reality manually, as it's now out by one hour.
The point is that systemd gets fussy when RTC is in local time even if
it's a single boot system. I don't know what the full consequence of
its complaint is, but it complains nevertheless (via timedatectl)
basically saying it's unsupported.
The full consequence on the complaint from timedatectl is that if you aren't
careful around DST change time, you will either face no DST adjustment, or
DST adjustment applied twice. If you're lucky, it just works (as it has for
me when running RTC in local time), but why shouldn't systemd warn you that
you've got to be lucky?
This is exactly the same problem you face when you multiboot Windows on a
BIOS system, FWIW. I've not looked to see if the problem still exists in an
EFI world.
Windows 95 and NT are completely different lineages and never
supported dual-boot. Maybe Windows 95 followed by 98, or Windows NT
3.5 followed by 4.0 would have; just as it's possible to dual boot
Windows 7 followed by 8.
Same issues happened on the machines that triple-booted Windows 95, 98 and
Me, only worse as they got adjusted three times on DST change, not just
twice.
The machine that dual-booted Windows 2000 Server and Windows 2000
Workstation also had the same issue, as did a later system that dual-booted
Windows 2000 Workstation and Windows XP. Note that these two systems were
dual-booting on a single disk, and Windows still couldn't get it
right. Microsoft's advice was to manually check the clock on the first boot
of each OS after a DST change.
> IOW, Windows works with RTC in local time if (and only if)
it's the one and
> only OS on the system that writes to the RTC. Fedora also writes to the RTC,
> and thus we have to somehow co-ordinate changes with Windows in such a way
> that DST adjustments only get applied once
If there's evidence of another system present, maybe don't change the
RTC? Just use it as a guide absent an Internet connect, and with one
chrony can set system time without changing the RTC which only causes
problems.
Apple's boot camp package patches Windows to deal with this problem, FWIW.
>; I've not looked at UEFI to find
> out whether UEFI solves this.
It's solved there, I have no idea if this is honored by the kernel or
systemd though.
http://wiki.phoenix.com/wiki/index.php/EFI_TIME
Can you check that? If it's solved on EFI systems, then this becomes largely
a historic artefact - we aim to trust EFI, and BIOS boot users need to apply
the same caution they've always had to apply around a DST change.
>
> <snip>
>> > We could try to build an infrastructure to store tz information, and
>> > rebuild initramfses, etc, or we can just rip of the bandaid. This is a
>> > game of whack-a-mole which accelerates are systems get more dynamic
>> > and mobile that we cannot really hope to win.
>>
>> Hindsight being 20/20, obviously around 13 years ago Linux (and
>> friends) should have agreed to not fight the RTC being in local time
>> on multiboot systems, in particular dual boot ones with Windows.
>> Windows figures out what timezone the RTC is in by reading the
>> registry entry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
>> which a Linux OS service could also defer to by default rather than
>> the adversarial relationship that's been chosen.
>>
> Which registry entry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation?
> The one in my Windows 95 install, or the one in my Windows NT 4.0 install?
Seeing as Microsoft doesn't support either one of those for something
like 20 years now, I'd say neither but still possible to infer another
OS is already present and to leave the RTC alone and just adapt to a
local setting and time service rather than insisting on changing the
clock.
And if the other OS isn't Windows? What if it's FreeBSD, or OpenBSD, or
VxWorks, or QNX, all of which default to UTC in the RTC? What about Android?
> Come to that, how is Linux supposed to find and read the
registry, given
> that it may not be allowed by administrator policy to mount the filesystem
> that contains the registry? In the worst case, you dual boot the way I did
> at work, where the machine's disk is in a cold swap caddy, and you cannot
> physically get at the disk.
If it seems like a mono OS installation, then its reasonable for the
OS to assume it can assume complete ownership of the RTC.
So now I've got different behaviour depending on whether Windows was on the
system before or after Fedora? Worse, if I install FreeBSD first, Fedora
enters a Windows compatibility state and has to be coaxed into getting it
right.
But just like a VM doesn't assert control over the real hardware
RTC,
a guest OS in a dual boot situation shouldn't either. If that guest is
intending to be friendly, it ought to adapt rather than enforce a
whole new policy the primary OS can't deal with.
You're assuming here that Linux is a guest OS on the system; on my dual-boot
system, Linux is the primary OS, and Windows is the guest. How is Linux
supposed to detect which way round this system is?
--
Simon Farnsworth
4:26 a.m.
Simon Farnsworth composed on 2015-04-28 10:00 (UTC+0100):
Same issues happened on the machines that triple-booted Windows 95,
98 and
Me, only worse as they got adjusted three times on DST change, not just
twice.
I learned early on how to avoid that. Just tell Windows there is no DST to
adjust for, and let Linux handle it.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
7:10 a.m.
On 27 April 2015 at 21:36, Chris Murphy <lists(a)colorremedies.com> wrote:
On Mon, Apr 27, 2015 at 10:52 AM, Simon Farnsworth
<simon(a)farnz.org.uk> wrote:
> Windows doesn't work fine with RTC in local time, unless you have one and
> only one Windows install on the system. If you (say) dual-boot Windows 95
> and Windows NT 4.0 (I've done this in a work environment), and boot back and
> forth between them on a DST change flag day, then both OSes expect to change
> the RTC to reflect current local time. You then have to pull the RTC time
> back to reality manually, as it's now out by one hour.
The point is that systemd gets fussy when RTC is in local time even if
it's a single boot system. I don't know what the full consequence of
its complaint is, but it complains nevertheless (via timedatectl)
basically saying it's unsupported.
Windows 95 and NT are completely different lineages and never
supported dual-boot. Maybe Windows 95 followed by 98, or Windows NT
3.5 followed by 4.0 would have; just as it's possible to dual boot
Windows 7 followed by 8.
> IOW, Windows works with RTC in local time if (and only if) it's the one and
> only OS on the system that writes to the RTC. Fedora also writes to the RTC,
> and thus we have to somehow co-ordinate changes with Windows in such a way
> that DST adjustments only get applied once
If there's evidence of another system present, maybe don't change the
RTC? Just use it as a guide absent an Internet connect, and with one
chrony can set system time without changing the RTC which only causes
problems.
Why doesn't Windows follow this strategy then (not changing RTC)? Why
change RTC for daylight savings?
Actually, Fedora (most OSes) update the RTC to deal with drift
compared to the more accurate time available from NTP, not to twiddle
daylight savings. Updating the BIOS time is not primarily for DST
Apple's boot camp package patches Windows to deal with this
problem, FWIW.
Which sounds like Apple got fed up with it too.
>; I've not looked at UEFI to find
> out whether UEFI solves this.
It's solved there, I have no idea if this is honored by the kernel or
systemd though.
http://wiki.phoenix.com/wiki/index.php/EFI_TIME
Worth noting the bug being discussed and reasons for closing
https://bugzilla.redhat.com/show_bug.cgi?id=1201978 refer to /BIOS/
time and the fact it does not have time zones.
>
> <snip>
>> > We could try to build an infrastructure to store tz information, and
>> > rebuild initramfses, etc, or we can just rip of the bandaid. This is a
>> > game of whack-a-mole which accelerates are systems get more dynamic
>> > and mobile that we cannot really hope to win.
>>
>> Hindsight being 20/20, obviously around 13 years ago Linux (and
>> friends) should have agreed to not fight the RTC being in local time
>> on multiboot systems, in particular dual boot ones with Windows.
>> Windows figures out what timezone the RTC is in by reading the
>> registry entry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
>> which a Linux OS service could also defer to by default rather than
>> the adversarial relationship that's been chosen.
>>
> Which registry entry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation?
> The one in my Windows 95 install, or the one in my Windows NT 4.0 install?
Seeing as Microsoft doesn't support either one of those for something
like 20 years now, I'd say neither but still possible to infer another
OS is already present and to leave the RTC alone and just adapt to a
local setting and time service rather than insisting on changing the
clock.
Basically the Windows approach (keep shuffling the BIOS clock and use
flags to remember whether you've done it or not) is broken, or at
least inherently fragile. Multi-boot shows this up.
> Come to that, how is Linux supposed to find and read the registry, given
> that it may not be allowed by administrator policy to mount the filesystem
> that contains the registry? In the worst case, you dual boot the way I did
> at work, where the machine's disk is in a cold swap caddy, and you cannot
> physically get at the disk.
If it seems like a mono OS installation, then its reasonable for the
OS to assume it can assume complete ownership of the RTC.
But just like a VM doesn't assert control over the real hardware RTC,
a guest OS in a dual boot situation shouldn't either. If that guest is
intending to be friendly, it ought to adapt rather than enforce a
whole new policy the primary OS can't deal with.
No OS in a dual boot situation is a 'guest'. Unlike a VM guest the OS
running on hardware is expected to be responsible for that hardware. I
use Fedora daily and Windows less than once a week. Which is the
'primary' OS? Apparently Windows, since it wants to mess with the RTC.
--
imalone
http://ibmalone.blogspot.co.uk
noon
On 04/27/2015 06:39 PM, Chris Murphy wrote:
On Mon, Apr 27, 2015 at 6:54 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
> On Sun, Apr 26, 2015 at 11:47:18PM -0600, Chris Murphy wrote:
>> Time in UTC is just as absurd and arbitrary as time in a local
>> timezone,
> No, it's not. This has been written about many times, but in short:
None of what you wrote explains a.) Why RTC in local works fine on
Windows;
... and other Linux Distros ... and Fedora before systemd.
b.) why two users in this thread, including the original
poster, had problems with a stable timezone set.
FYI: AFAICT, the issues should determinististically reproducable with
f21/f22 in all Fedora/Win-Multiboot configurations by everybody.
I guess, many people are not seeing them due to them using fast SSDs
instead of HDDs and them having using a graphical plymouth.
Folks, check your boot logs - I guess many of you aren't aware, Fedora
is performing a full disk-check upon each reboot in multiboot configuations.
Ralf
6:40 a.m.
On Sun, Apr 26, 2015 at 11:47:18PM -0600, Chris Murphy wrote:
> Time in UTC is just as absurd and arbitrary as time in a local
> timezone,
No, it's not. This has been written about many times, but in short:
- the information about the timezone used is not stored in RTC,
so all users of RTC need to be configured to use the same timezone
externally
It surprises me that we see these issues even with UEFI, which seems to include support
for timezone and DST information [1]. I can confirm this myself, I have UEFI with Fedora
21 and Win7 at home, and I noticed that there seems to be a fsck running on every Fedora
boot. I haven't had time to debug it properly yet, but it doesn't seem to work
properly out of the box. Moreover, if I look into `journalctl -b`, I see time shifted
during the boot process (which kind of messes up the history whenever I search in it). I
haven't reported any bug yet, but there's certainly something not working out of
the box there.
Zbigniew, do you have any idea why this wouldn't work well with UEFI firmware?
Shouldn't the whole problem become obsolete with UEFI? Thanks.
[1] http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Services
7:21 a.m.
On 28 April 2015 at 13:40, Kamil Paral <kparal(a)redhat.com> wrote:
> On Sun, Apr 26, 2015 at 11:47:18PM -0600, Chris Murphy wrote:
> > Time in UTC is just as absurd and arbitrary as time in a local
> > timezone,
> No, it's not. This has been written about many times, but in short:
> - the information about the timezone used is not stored in RTC,
> so all users of RTC need to be configured to use the same timezone
> externally
It surprises me that we see these issues even with UEFI, which seems to
include support for timezone and DST information [1]. I can confirm this
myself, I have UEFI with Fedora 21 and Win7 at home, and I noticed that
there seems to be a fsck running on every Fedora boot. I haven't had time
to debug it properly yet, but it doesn't seem to work properly out of the
box. Moreover, if I look into `journalctl -b`, I see time shifted during
the boot process (which kind of messes up the history whenever I search in
it). I haven't reported any bug yet, but there's certainly something not
working out of the box there.
This is the bug that started this thread:
https://bugzilla.redhat.com/show_bug.cgi?id=1201978
[...]
--
Ahmad Samir
1:03 p.m.
On Tue, Apr 28, 2015 at 02:21:48PM +0200, Ahmad Samir wrote:
On 28 April 2015 at 13:40, Kamil Paral <kparal(a)redhat.com>
wrote:
> > On Sun, Apr 26, 2015 at 11:47:18PM -0600, Chris Murphy wrote:
> > > Time in UTC is just as absurd and arbitrary as time in a local
> > > timezone,
> > No, it's not. This has been written about many times, but in short:
> > - the information about the timezone used is not stored in RTC,
> > so all users of RTC need to be configured to use the same timezone
> > externally
>
> It surprises me that we see these issues even with UEFI, which seems to
> include support for timezone and DST information [1]. I can confirm this
> myself, I have UEFI with Fedora 21 and Win7 at home, and I noticed that
> there seems to be a fsck running on every Fedora boot. I haven't had time
> to debug it properly yet, but it doesn't seem to work properly out of the
> box. Moreover, if I look into `journalctl -b`, I see time shifted during
> the boot process (which kind of messes up the history whenever I search in
> it). I haven't reported any bug yet, but there's certainly something not
> working out of the box there.
>
>
This is the bug that started this thread:
https://bugzilla.redhat.com/show_bug.cgi?id=1201978
This not the right bug.
The problem is a combination of two bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1202024 is about fsck.ext4
running full check when the date was off by less then 24h. I is now
changed to only print a warning. Eric Sandeen mentioned this commit
in the other part of the thread, and made an update with that patch
which is now in updates-testing.
https://bugzilla.redhat.com/show_bug.cgi?id=1201979 is about systemd
being stupid and rerunning root fsck, which sometimes triggered the
first issue. I just posted a patch upstream:
http://lists.freedesktop.org/archives/systemd-devel/2015-May/031445.html
Hopefully those bugs will be closed soon. It doesn't change the fact that
RTC-in-localtime is wrong in general, but at least this aspect will be fixed.
Zbyszek
8:55 a.m.
On Sat, 02.05.15 18:03, Zbigniew Jędrzejewski-Szmek (zbyszek(a)in.waw.pl) wrote:
On Tue, Apr 28, 2015 at 02:21:48PM +0200, Ahmad Samir wrote:
> On 28 April 2015 at 13:40, Kamil Paral <kparal(a)redhat.com> wrote:
>
> > > On Sun, Apr 26, 2015 at 11:47:18PM -0600, Chris Murphy wrote:
> > > > Time in UTC is just as absurd and arbitrary as time in a local
> > > > timezone,
> > > No, it's not. This has been written about many times, but in short:
> > > - the information about the timezone used is not stored in RTC,
> > > so all users of RTC need to be configured to use the same timezone
> > > externally
> >
> > It surprises me that we see these issues even with UEFI, which seems to
> > include support for timezone and DST information [1]. I can confirm this
> > myself, I have UEFI with Fedora 21 and Win7 at home, and I noticed that
> > there seems to be a fsck running on every Fedora boot. I haven't had time
> > to debug it properly yet, but it doesn't seem to work properly out of the
> > box. Moreover, if I look into `journalctl -b`, I see time shifted during
> > the boot process (which kind of messes up the history whenever I search in
> > it). I haven't reported any bug yet, but there's certainly something
not
> > working out of the box there.
> >
> >
> This is the bug that started this thread:
> https://bugzilla.redhat.com/show_bug.cgi?id=1201978
This not the right bug.
The problem is a combination of two bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1202024 is about fsck.ext4
running full check when the date was off by less then 24h. I is now
changed to only print a warning. Eric Sandeen mentioned this commit
in the other part of the thread, and made an update with that patch
which is now in updates-testing.
https://bugzilla.redhat.com/show_bug.cgi?id=1201979 is about systemd
being stupid and rerunning root fsck, which sometimes triggered the
first issue. I just posted a patch upstream:
http://lists.freedesktop.org/archives/systemd-devel/2015-May/031445.html
Well, note that this one is triggered if the system boots up with
read-only root, which is not how Fedora sets things up by default...
Lennart
--
Lennart Poettering, Red Hat
10:23 a.m.
On Sun, May 03, 2015 at 03:55:38PM +0200, Lennart Poettering wrote:
On Sat, 02.05.15 18:03, Zbigniew Jędrzejewski-Szmek
(zbyszek(a)in.waw.pl) wrote:
> On Tue, Apr 28, 2015 at 02:21:48PM +0200, Ahmad Samir wrote:
> > On 28 April 2015 at 13:40, Kamil Paral <kparal(a)redhat.com> wrote:
> >
> > > > On Sun, Apr 26, 2015 at 11:47:18PM -0600, Chris Murphy wrote:
> > > > > Time in UTC is just as absurd and arbitrary as time in a local
> > > > > timezone,
> > > > No, it's not. This has been written about many times, but in
short:
> > > > - the information about the timezone used is not stored in RTC,
> > > > so all users of RTC need to be configured to use the same timezone
> > > > externally
> > >
> > > It surprises me that we see these issues even with UEFI, which seems to
> > > include support for timezone and DST information [1]. I can confirm this
> > > myself, I have UEFI with Fedora 21 and Win7 at home, and I noticed that
> > > there seems to be a fsck running on every Fedora boot. I haven't had
time
> > > to debug it properly yet, but it doesn't seem to work properly out of
the
> > > box. Moreover, if I look into `journalctl -b`, I see time shifted during
> > > the boot process (which kind of messes up the history whenever I search
in
> > > it). I haven't reported any bug yet, but there's certainly
something not
> > > working out of the box there.
> > >
> > >
> > This is the bug that started this thread:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1201978
> This not the right bug.
>
> The problem is a combination of two bugs:
> https://bugzilla.redhat.com/show_bug.cgi?id=1202024 is about fsck.ext4
> running full check when the date was off by less then 24h. I is now
> changed to only print a warning. Eric Sandeen mentioned this commit
> in the other part of the thread, and made an update with that patch
> which is now in updates-testing.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1201979 is about systemd
> being stupid and rerunning root fsck, which sometimes triggered the
> first issue. I just posted a patch upstream:
> http://lists.freedesktop.org/archives/systemd-devel/2015-May/031445.html
Well, note that this one is triggered if the system boots up with
read-only root, which is not how Fedora sets things up by default...
Yeah. There
are legitimate setups with ro root, but they certainly are a monority.
Incidentally, since ro-at-boot is used mostly on old installations, a large
number have big slow drives, which exacerbates the problem.
For majority of ro-at-boot setups, changing to rw would be the best and the simplest
solution. I don't think we should do that automatically (e.g. through rpm macro),
but instead encourage people to switch manually. I have no idea what would
be a good place to put this information though.
Zbyszek
5 a.m.
On Sun, May 03, 2015 at 03:23:24PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
For majority of ro-at-boot setups, changing to rw would be the best
and the simplest
solution. I don't think we should do that automatically (e.g. through rpm macro),
but instead encourage people to switch manually. I have no idea what would
be a good place to put this information though.
Good places would be the release notes and:
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_21_-.3E_...
Regards
Till
8:24 a.m.
On Mon, May 04, 2015 at 12:00:31PM +0200, Till Maas wrote:
On Sun, May 03, 2015 at 03:23:24PM +0000, Zbigniew Jędrzejewski-Szmek
wrote:
> For majority of ro-at-boot setups, changing to rw would be the best and the
simplest
> solution. I don't think we should do that automatically (e.g. through rpm
macro),
> but instead encourage people to switch manually. I have no idea what would
> be a good place to put this information though.
Good places would be the release notes and:
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_21_-.3E_...
On second though, where exactly is 'ro' coming from?
On my system it comes from:
$ sudo grep ' ro ' /etc/grub.d/10_linux
${linuxefi} ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro
${args}
linux${sixteenbit} ${rel_dirname}/${basename}
root=${linux_root_device_thisversion} ro ${args}
$ rpm -q grub2-tools
grub2-tools-2.02-0.15.fc22.x86_64
Maybe it's enough to change it there?
Zbyszek
12:05 p.m.
On Mon, 04.05.15 13:24, Zbigniew Jędrzejewski-Szmek (zbyszek(a)in.waw.pl) wrote:
On Mon, May 04, 2015 at 12:00:31PM +0200, Till Maas wrote:
> On Sun, May 03, 2015 at 03:23:24PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>
> > For majority of ro-at-boot setups, changing to rw would be the best and the
simplest
> > solution. I don't think we should do that automatically (e.g. through rpm
macro),
> > but instead encourage people to switch manually. I have no idea what would
> > be a good place to put this information though.
>
> Good places would be the release notes and:
>
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_21_-.3E_...
On second though, where exactly is 'ro' coming from?
On my system it comes from:
$ sudo grep ' ro ' /etc/grub.d/10_linux
${linuxefi} ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro
${args}
linux${sixteenbit} ${rel_dirname}/${basename}
root=${linux_root_device_thisversion} ro ${args}
$ rpm -q grub2-tools
grub2-tools-2.02-0.15.fc22.x86_64
Maybe it's enough to change it there?
Nah, I am pretty sure it should just stay, as that's what has been
done always and is what makes initrd-less boots work
correctly, as we actually need a read-only root initially then, that
is remounted rw only after fsck ran. The rw setting is applied based
on the settings from /etc/fstab for the root fs.
The kernel should initially boot with the root file system read-only,
and then remount it writable during early boot. This is also essential
for systems where the root file system shall stay read-only during
runtime, since booting ro and then remounting rw makes sense, but
booting rw and then remounting ro certainly doesn't...
Hence I think FEdora is fine as it is.
Lennart
--
Lennart Poettering, Red Hat
3:28 p.m.
On Mon, 2015-05-04 at 13:24 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, May 04, 2015 at 12:00:31PM +0200, Till Maas wrote:
> On Sun, May 03, 2015 at 03:23:24PM +0000, Zbigniew Jędrzejewski
> -Szmek wrote:
>
> > For majority of ro-at-boot setups, changing to rw would be the
> > best and the simplest
> > solution. I don't think we should do that automatically (e.g.
> > through rpm macro),
> > but instead encourage people to switch manually. I have no idea
> > what would
> > be a good place to put this information though.
>
> Good places would be the release notes and:
> https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_21_-
> .3E_Fedora_22_.28not_yet_relea
> sed.29
On second though, where exactly is 'ro' coming from?
On my system it comes from:
$ sudo grep ' ro ' /etc/grub.d/10_linux
${linuxefi} ${rel_dirname}/${basename}
root=${linux_root_device_thisversion} ro ${args}
linux${sixteenbit} ${rel_dirname}/${basename}
root=${linux_root_device_thisversion} ro ${args}
$ rpm -q grub2-tools
grub2-tools-2.02-0.15.fc22.x86_64
Maybe it's enough to change it there?
That would only take effect when someone manually ran a grub2-mkconfig
. Fedora kernel updates only add a new entry to the file with grubby,
which does not pull in changes to the kernel parameters from the grub2
-mkconfig config files.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
10 a.m.
> https://bugzilla.redhat.com/show_bug.cgi?id=1201979 is about
systemd
> being stupid and rerunning root fsck, which sometimes triggered the
> first issue. I just posted a patch upstream:
> http://lists.freedesktop.org/archives/systemd-devel/2015-May/031445.html
Well, note that this one is triggered if the system boots up with
read-only root, which is not how Fedora sets things up by default...
Lennart
On a clean F22 install, I see "ro" on the kernel cmdline, so IIUIC it is the
default.
10:05 a.m.
Am 04.05.2015 um 17:00 schrieb Kamil Paral:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1201979 is about
systemd
>> being stupid and rerunning root fsck, which sometimes triggered the
>> first issue. I just posted a patch upstream:
>> http://lists.freedesktop.org/archives/systemd-devel/2015-May/031445.html
>
> Well, note that this one is triggered if the system boots up with
> read-only root, which is not how Fedora sets things up by default...
>
> Lennart
On a clean F22 install, I see "ro" on the kernel cmdline, so IIUIC it is the
default
it was *always* default, at least the last 11 years
7:50 a.m.
On Fri, 24 Apr 2015 05:14:27 -0400, Felix Miata wrote:
Why does this bug exist only in Fedora, not in openSUSE or Mageia or
*buntu?
All my systems are multiboot, so only a select very few are on UTC. None that
are on UTC have Fedora installed. This means every Fedora boot takes about
twice as long or longer than anything else takes, waiting on all the
unnecessary FS checks.
Me too. It's on my growing list of breakage to observe. Haven't spent any
time on it yet. Logical volumes getting checked nearly at every reboot.
journalctl shows entries which are two hours in the future at boot time,
then it returns to the correct time afterwards. I remember there have
been issues like that years ago - I don't think I've had to do anything
special to work around it, but perhaps I'm wrong and need to search in
my notes. Currently, it's broken again.
8:52 a.m.
On Tue, 28.04.15 14:50, Michael Schwendt (mschwendt(a)gmail.com) wrote:
On Fri, 24 Apr 2015 05:14:27 -0400, Felix Miata wrote:
> Why does this bug exist only in Fedora, not in openSUSE or Mageia or *buntu?
> All my systems are multiboot, so only a select very few are on UTC. None that
> are on UTC have Fedora installed. This means every Fedora boot takes about
> twice as long or longer than anything else takes, waiting on all the
> unnecessary FS checks.
Me too. It's on my growing list of breakage to observe. Haven't spent any
time on it yet. Logical volumes getting checked nearly at every reboot.
journalctl shows entries which are two hours in the future at boot time,
then it returns to the correct time afterwards. I remember there have
been issues like that years ago - I don't think I've had to do anything
special to work around it, but perhaps I'm wrong and need to search in
my notes. Currently, it's broken again.
Fedora doesn't use time-based fsck for a reason, the concept is simply
broken.
UEFI doesn't solve anything with the rtc-in-local stuff windows is
doing there.
rtc-in-local is really broken but that's hardly Linux' fault, that's
windows' fault. it is inherently incompatible with multi-boot setups,
since the algorithm to adjust for DST requires knowing whether the RTC
was already set to DST or not, and that is saved by windows on the
windows partition, and linux does not have generic access to
that. also, if you'd do multiboot with multiple windows versions this
breaks even on windows, since each windows version stores that flag on
their own partition.
It's a simple fact that rtc-in-local is broken, there is no way around
that, and we cannot support this in linux in full since not even
windows supports in in full...
we do offer a minimal somehwat compatible mode for linux, in which
case DST adjustments don#t work and early boot doesn't get the right
time, but that's exactly how much you will get, and we are willing to
support.
And yes, I am sorry that MS-DOS and Windows cannot handle this, but
that's something to fix in DOS and Windows, because we simply *cannot*
fix this fully on Linux.
And asking for rtc-in-local together with time-based fsck is something
we simply cannot support at all. Either get your RTC set to UTC like
everybody else, or disable time-based fsck like everybody else, but
if you enable both then you are purely on your own.
Essentially you are asking us to support multi-boot with windows, but
you ignore that it's windows that doesn't support it in the first
place...
And no, this *never* worked fully on Linux, and it never will, sorry.
Lennart
--
Lennart Poettering, Red Hat
7 a.m.
On 04/28/2015 03:52 PM, Lennart Poettering wrote:
And no, this *never* worked fully on Linux, and it never will, sorry.
But it worked sufficentily most of the time ... ever since!
The current situation means,
- Fedora does not support multiboot'ing at all,
- Fedora is preferring to be militant against Windows
- Fedora is hostile and ignorant against its users.
9:46 a.m.
On Wed, 2015-04-29 at 14:00 +0200, Ralf Corsepius wrote:
On 04/28/2015 03:52 PM, Lennart Poettering wrote:
> And no, this *never* worked fully on Linux, and it never will,
> sorry.
But it worked sufficentily most of the time ... ever since!
The current situation means,
- Fedora does not support multiboot'ing at all,
- Fedora is preferring to be militant against Windows
- Fedora is hostile and ignorant against its users.
It seems to be that either way this gets solved it leaves unhappy
users and developers behind. Given the scope of the issue is wider
than just a package maintenance issue, I'm wondering if FESCO could
help getting it settled?
Would it make sense to create a FESCO ticket and let it vote on the
matter? (Work around in Fedora vs. hardcode UTC and encourage the fix
in Windows NT?)
Lubo
10:14 a.m.
On Wed, 29.04.15 16:46, Lubomir Rintel (lkundrak(a)v3.sk) wrote:
On Wed, 2015-04-29 at 14:00 +0200, Ralf Corsepius wrote:
> On 04/28/2015 03:52 PM, Lennart Poettering wrote:
>
> > And no, this *never* worked fully on Linux, and it never will,
> > sorry.
>
> But it worked sufficentily most of the time ... ever since!
>
> The current situation means,
> - Fedora does not support multiboot'ing at all,
> - Fedora is preferring to be militant against Windows
> - Fedora is hostile and ignorant against its users.
It seems to be that either way this gets solved it leaves unhappy
users and developers behind. Given the scope of the issue is wider
than just a package maintenance issue, I'm wondering if FESCO could
help getting it settled?
Would it make sense to create a FESCO ticket and let it vote on the
matter? (Work around in Fedora vs. hardcode UTC and encourage the fix
in Windows NT?)
Hmmm?
This is unfixable, FESCO can decide what it wants. You cannot fix RTC
management, since you cannot change Windows...
Lennart
--
Lennart Poettering, Red Hat
10:48 a.m.
On 04/29/2015 11:14 AM, Lennart Poettering wrote:
On Wed, 29.04.15 16:46, Lubomir Rintel (lkundrak(a)v3.sk) wrote:
> On Wed, 2015-04-29 at 14:00 +0200, Ralf Corsepius wrote:
>> On 04/28/2015 03:52 PM, Lennart Poettering wrote:
>>
>>> And no, this *never* worked fully on Linux, and it never will,
>>> sorry.
>> But it worked sufficentily most of the time ... ever since!
>>
>> The current situation means,
>> - Fedora does not support multiboot'ing at all,
>> - Fedora is preferring to be militant against Windows
>> - Fedora is hostile and ignorant against its users.
> It seems to be that either way this gets solved it leaves unhappy
> users and developers behind. Given the scope of the issue is wider
> than just a package maintenance issue, I'm wondering if FESCO could
> help getting it settled?
>
> Would it make sense to create a FESCO ticket and let it vote on the
> matter? (Work around in Fedora vs. hardcode UTC and encourage the fix
> in Windows NT?)
Hmmm?
This is unfixable, FESCO can decide what it wants. You cannot fix RTC
management, since you cannot change Windows...
I agree that it's not possible
to make this work under every
circumstance, but a compromise existed that worked well enough so that
most people were not complaining. I propose that a system that possibly
hiccups every year or two is better than a system that misbehaves all
the time. Why can't the startup just treat the RTC as if it was GMT with
an unexplained offset? e.g. measure that offset when time syncing with
reliable sources, write it down and use it on the next boot?
By the way, it'd be nice if the startup dealt gracefully with all kinds
of clock problems. Many embedded systems have no persistent realtime
clock at all; I seem to remember that Beaglebone uses a hack that
initializes clock from a fixed value from a file.
11:46 a.m.
On Wed, 29.04.15 11:48, Przemek Klosowski (przemek.klosowski(a)nist.gov) wrote:
I agree that it's not possible to make this work under every
circumstance,
but a compromise existed that worked well enough so that most people were
not complaining. I propose that a system that possibly hiccups every year or
two is better than a system that misbehaves all the time. Why can't the
startup just treat the RTC as if it was GMT with an unexplained offset? e.g.
measure that offset when time syncing with reliable sources, write it down
and use it on the next boot?
Hmm? we *do* support rtc-in-local at a basic level already
(i.e. without DST handling).
What doesn't work is rtc-in-local in early-boot, that's all. And that
doesn't matter really, except if you are crazy enough to manually
enable time-based fsck in ext234, which has been turned off by default
in fedora since time begain, and even has been turned off upstream
now, because it's simply a crazy feature.
I am not sure it is worth discussing this any further. This only trips
you up if you combine two known broken settings, and I am pretty sure
we have much bigger problems to fix than this.
By the way, it'd be nice if the startup dealt gracefully with all
kinds of
clock problems. Many embedded systems have no persistent realtime clock at
all; I seem to remember that Beaglebone uses a hack that initializes clock
from a fixed value from a file.
systemd-timesyncd implements this, too, it will ensure that the clock
is monotonic at least. It will save the local clock to disk at
shutdown and each time it acquires an NTP fix.
fedora doesn't use timesyncd by default however.
Lennart
--
Lennart Poettering, Red Hat
5:49 p.m.
On Wed, 2015-04-29 at 18:46 +0200, Lennart Poettering wrote:
On Wed, 29.04.15 11:48, Przemek Klosowski
(przemek.klosowski(a)nist.gov
) wrote:
> I agree that it's not possible to make this work under every
> circumstance,
> but a compromise existed that worked well enough so that most
> people were
> not complaining. I propose that a system that possibly hiccups
> every year or
> two is better than a system that misbehaves all the time. Why
> can't the
> startup just treat the RTC as if it was GMT with an unexplained
> offset? e.g.
> measure that offset when time syncing with reliable sources, write
> it down
> and use it on the next boot?
Hmm? we *do* support rtc-in-local at a basic level already
(i.e. without DST handling).
What doesn't work is rtc-in-local in early-boot, that's all. And that
doesn't matter really, except if you are crazy enough to manually
enable time-based fsck in ext234, which has been turned off by
default
in fedora since time begain, and even has been turned off upstream
now, because it's simply a crazy feature.
We seem to have two sides saying two fundamentally different things
here: one claiming that all Windows/Fedora multiboot systems (that
haven't had the hardware clock set to UTC and Windows adjusted to know
about that) are doing fsck on boot all the time, one claiming that
"This only trips you up if you combine two known broken settings".
Who's correct? It seems like we should at least be able to reasonably
establish that.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6:13 p.m.
Adam Williamson composed on 2015-04-30 15:49 (UTC-0700):
We seem to have two sides saying two fundamentally different things
here: one claiming that all Windows/Fedora multiboot systems (that
haven't had the hardware clock set to UTC and Windows adjusted to know
about that) are doing fsck on boot all the time, one claiming that
"This only trips you up if you combine two known broken settings".
Who's correct? It seems like we should at least be able to
reasonably
establish that.
All my Fedora 21/22/23 (20+) installations are on multiboot PCs with RTC set
to local, and /etc/adjtime set to LOCAL. I can't recall if any are *not* now
taking 3 minutes or more to boot due to fsck delays that were not occurring
as recently as 3-4 months ago. Maybe kernel 3.18.3 or so was good, 3.19rc
started the fsck delays? Cauldron and Tumbleweed booting 3.19.4 kernels on
same PCs are not producing any similar delays, some booting in under 40s
without benefit of SSD or more than 2 cores.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
6:37 p.m.
On Thu, 2015-04-30 at 19:13 -0400, Felix Miata wrote:
Adam Williamson composed on 2015-04-30 15:49 (UTC-0700):
> We seem to have two sides saying two fundamentally different things
> here: one claiming that all Windows/Fedora multiboot systems (that
> haven't had the hardware clock set to UTC and Windows adjusted to
> know
> about that) are doing fsck on boot all the time, one claiming that
> "This only trips you up if you combine two known broken settings".
> Who's correct? It seems like we should at least be able to
> reasonably
> establish that.
All my Fedora 21/22/23 (20+) installations are on multiboot PCs with
RTC set
to local, and /etc/adjtime set to LOCAL. I can't recall if any are
*not* now
taking 3 minutes or more to boot due to fsck delays that were not
occurring
as recently as 3-4 months ago. Maybe kernel 3.18.3 or so was good,
3.19rc
started the fsck delays? Cauldron and Tumbleweed booting 3.19.4
kernels on
same PCs are not producing any similar delays, some booting in under
40s
without benefit of SSD or more than 2 cores.
I'd prefer objective analysis over anecdata. poettering's contention
is :
i) there is only a problem if you have time-based fsck enabled
ii) this is not the default
your anecdote does not provide enough information to prove or disprove
his contention.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6:45 p.m.
Adam Williamson composed on 2015-04-30 16:37 (UTC-0700):
I'd prefer objective analysis over anecdata. poettering's
contention
is :
i) there is only a problem if you have time-based fsck enabled
ii) this is not the default
your anecdote does not provide enough information to prove or
disprove
his contention.
He never mentioned what time-based fsck is that I saw, and I neither know
what it is, nor have any reason to think I changed anything related to
whatever it is in recent months. If any change was announced here in recent
months, I missed it.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
7:11 p.m.
On Thu, 2015-04-30 at 19:45 -0400, Felix Miata wrote:
Adam Williamson composed on 2015-04-30 16:37 (UTC-0700):
> I'd prefer objective analysis over anecdata. poettering's
> contention
> is :
> i) there is only a problem if you have time-based fsck enabled
> ii) this is not the default
> your anecdote does not provide enough information to prove or
> disprove
> his contention.
He never mentioned what time-based fsck is that I saw,
"What doesn't work is rtc-in-local in early-boot, that's all. And that
doesn't matter really, except if you are crazy enough to manually
enable time-based fsck in ext234, which has been turned off by default
in fedora since time begain, and even has been turned off upstream
now, because it's simply a crazy feature." - Lennart, yesterday:
https://lists.fedoraproject.org/pipermail/devel/2015-April/210282.html
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin .
net
http://www.happyassassin.net
7:22 p.m.
On Thu, Apr 30, 2015 at 5:11 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Thu, 2015-04-30 at 19:45 -0400, Felix Miata wrote:
> Adam Williamson composed on 2015-04-30 16:37 (UTC-0700):
>
> > I'd prefer objective analysis over anecdata. poettering's
> > contention
> > is :
>
> > i) there is only a problem if you have time-based fsck enabled
> > ii) this is not the default
>
> > your anecdote does not provide enough information to prove or
> > disprove
> > his contention.
>
> He never mentioned what time-based fsck is that I saw,
"What doesn't work is rtc-in-local in early-boot, that's all. And that
doesn't matter really, except if you are crazy enough to manually
enable time-based fsck in ext234, which has been turned off by default
in fedora since time begain, and even has been turned off upstream
now, because it's simply a crazy feature." - Lennart, yesterday:
https://lists.fedoraproject.org/pipermail/devel/2015-April/210282.html
$ sudo tune2fs -l [my ext4 root device]
...
Mount count: 7
Maximum mount count: 21
Last checked: Mon Apr 6 10:42:37 2015
Check interval: 15552000 (6 months)
Next check after: Sat Oct 3 10:42:37 2015
...
This filesystem has survived several Fedora upgrades, but I'm pretty
sure I created it with mke2fs on some Fedora version. This suggests
that time-based fsck is or was default-enabled at some point.
--Andy
7:58 p.m.
On Thu, Apr 30, 2015 at 05:22:20PM -0700, Andrew Lutomirski wrote:
Maximum mount count: 21
Last checked: Mon Apr 6 10:42:37 2015
Check interval: 15552000 (6 months)
The default is definely now 0, but you're right, if you've upgraded for
a long time, it won't be changed. (You can change it now with tune2fs,
though, if you want.)
Also, the e2fsck.conf man page suggests that the program has "some
heuristics that assume that the system clock is correct" — I'm not sure
without checking the code if the check interval is really the only one.
But you might consider setting the `broken_system_clock` option in
/etc/e2fsck.conf.
Hmmm, in fact, maybe we should consider this the _default_ (at least
for workstation and desktop spins).
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8:01 p.m.
On 4/30/15 7:58 PM, Matthew Miller wrote:
On Thu, Apr 30, 2015 at 05:22:20PM -0700, Andrew Lutomirski wrote:
> Maximum mount count: 21
> Last checked: Mon Apr 6 10:42:37 2015
> Check interval: 15552000 (6 months)
The default is definely now 0, but you're right, if you've upgraded for
a long time, it won't be changed. (You can change it now with tune2fs,
though, if you want.)
Also, the e2fsck.conf man page suggests that the program has "some
heuristics that assume that the system clock is correct" — I'm not sure
without checking the code if the check interval is really the only one.
But you might consider setting the `broken_system_clock` option in
/etc/e2fsck.conf.
Hmmm, in fact, maybe we should consider this the _default_ (at least
for workstation and desktop spins).
It was/is set as default, and then time-based checks never fired.
So we un-defaulted it, and then hit this stuff.
Such a mess. :(
I need to get 1202024 resolved, ted checked in a version of a patch
I proposed to try to resolve some of this.
http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=f096708126412...
I'll get that pushed to testing tonight, sorry for being slow with it.
-Eric
7:35 p.m.
Adam Williamson composed on 2015-04-30 17:11 (UTC-0700):
> He never mentioned what time-based fsck is that I saw,
"What doesn't work is rtc-in-local in early-boot, that's
all. And that
doesn't matter really, except if you are crazy enough to manually
enable time-based fsck in ext234, which has been turned off by default
in fedora since time begain, and even has been turned off upstream
now, because it's simply a crazy feature." - Lennart, yesterday:
https://lists.fedoraproject.org/pipermail/devel/2015-April/210282.html
I saw that. It didn't tell me anything I understood, since I don't know what
time-based fsck is, or more particularly, what enables or disables it, and so
unlikely myself made any changes in recent weeks or months to cause the
current boot delays these fscks consistently impose.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
8:15 p.m.
On 4/30/15 7:35 PM, Felix Miata wrote:
Adam Williamson composed on 2015-04-30 17:11 (UTC-0700):
>> He never mentioned what time-based fsck is that I saw,
> "What doesn't work is rtc-in-local in early-boot, that's all. And that
> doesn't matter really, except if you are crazy enough to manually
> enable time-based fsck in ext234, which has been turned off by default
> in fedora since time begain, and even has been turned off upstream
> now, because it's simply a crazy feature." - Lennart, yesterday:
> https://lists.fedoraproject.org/pipermail/devel/2015-April/210282.html
I saw that. It didn't tell me anything I understood, since I don't know what
time-based fsck is, or more particularly, what enables or disables it, and so
unlikely myself made any changes in recent weeks or months to cause the
current boot delays these fscks consistently impose.
well, not since time began; it was 1.42-ish:
commit 3daf592646b668133079e2200c1e776085f2ffaf
Author: Eric Sandeen <sandeen(a)redhat.com>
Date: Thu Feb 17 15:55:15 2011 -0600
e2fsprogs: turn off enforced fsck intervals by default
The forced fsck often comes at unexpected and inopportune moments,
and even enterprise customers are often caught by surprise when
this happens. Because a filesystem with an error condition will
be marked as requiring fsck anyway, I submit that the time-based
and mount-based checks are not particularly useful, and that
administrators can schedule fscks on their own time, or tune2fs
the enforced intervals if they so choose. This patch disables the
intervals by default, and I've added a new mkfs.conf option to
turn on the old behavior of random, unexpected, time-consuming
fscks at boot time. ;)
Signed-off-by: Eric Sandeen <sandeen(a)redhat.com>
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
(some of us are old enough that our time began before 2011) ;)
Time-based check is ext234's (old default) behavior of forcing a full
fsck just because X days or Y mounts have gone by.
Any filesystem created prior to the above would have these time-based
or mount-based checks enabled by default.
You can see if it's set on your fs by looking at dumpe2fs, i.e.:
# dumpe2fs -h /dev/md0 | grep -i "mount count\|Check interval\|check after"
dumpe2fs 1.41.12 (17-May-2010)
Mount count: 24
Maximum mount count: 21
Check interval: 15552000 (6 months)
Next check after: Fri Aug 2 15:55:32 2013
-Eric
8:19 p.m.
Once upon a time, Eric Sandeen <sandeen(a)redhat.com> said:
Time-based check is ext234's (old default) behavior of forcing a
full
fsck just because X days or Y mounts have gone by.
Yeah, but since the early days of defaulting to ext3, Red Hat Linux (and
so Fedora after that) disabled that on filesystems created by the
installer.
--
Chris Adams <linux(a)cmadams.net>
2:18 a.m.
On Thu, Apr 30, 2015 at 05:11:20PM -0700, Adam Williamson wrote:
"What doesn't work is rtc-in-local in early-boot, that's
all. And that
doesn't matter really, except if you are crazy enough to manually
enable time-based fsck in ext234, which has been turned off by default
in fedora since time begain, and even has been turned off upstream
now, because it's simply a crazy feature." - Lennart, yesterday:
https://lists.fedoraproject.org/pipermail/devel/2015-April/210282.html
Why is this a crazy feature? Since Fedora 21 tends to corrupt the root
filesystem during resume from hibernation, regular full fsck runs make a
lot of sense to me.
Regards
Till
2:22 a.m.
Am 01.05.2015 um 09:18 schrieb Till Maas:
On Thu, Apr 30, 2015 at 05:11:20PM -0700, Adam Williamson wrote:
> "What doesn't work is rtc-in-local in early-boot, that's all. And that
> doesn't matter really, except if you are crazy enough to manually
> enable time-based fsck in ext234, which has been turned off by default
> in fedora since time begain, and even has been turned off upstream
> now, because it's simply a crazy feature." - Lennart, yesterday:
> https://lists.fedoraproject.org/pipermail/devel/2015-April/210282.html
Why is this a crazy feature? Since Fedora 21 tends to corrupt the root
filesystem during resume from hibernation, regular full fsck runs make a
lot of sense to me
and what has *that* to do with a full fsck just because *time changed*
9:51 a.m.
On 5/1/15 2:18 AM, Till Maas wrote:
On Thu, Apr 30, 2015 at 05:11:20PM -0700, Adam Williamson wrote:
> "What doesn't work is rtc-in-local in early-boot, that's all. And that
> doesn't matter really, except if you are crazy enough to manually
> enable time-based fsck in ext234, which has been turned off by default
> in fedora since time begain, and even has been turned off upstream
> now, because it's simply a crazy feature." - Lennart, yesterday:
> https://lists.fedoraproject.org/pipermail/devel/2015-April/210282.html
Why is this a crazy feature? Since Fedora 21 tends to corrupt the root
filesystem during resume from hibernation, regular full fsck runs make a
lot of sense to me.
Is there a bug open for that?
Thanks,
-Eric
Regards
Till
4:20 a.m.
On 05/01/2015 02:11 AM, Adam Williamson wrote:
On Thu, 2015-04-30 at 19:45 -0400, Felix Miata wrote:
> Adam Williamson composed on 2015-04-30 16:37 (UTC-0700):
>
>> I'd prefer objective analysis over anecdata. poettering's
>> contention
>> is :
>
>> i) there is only a problem if you have time-based fsck enabled
>> ii) this is not the default
>
>> your anecdote does not provide enough information to prove or
>> disprove
>> his contention.
>
> He never mentioned what time-based fsck is that I saw,
"What doesn't work is rtc-in-local in early-boot, that's all. And that
doesn't matter really, except if you are crazy enough to manually
enable time-based fsck in ext234, which has been turned off by default
Wrong.
Even on f21, setting the "The sixth field" of the line referring to
"/"
(root) to "!= 0" in /etc/fstab is sufficient to provoke this bug in
"rtc-in-local" configuration.
May-be you (testing) should add a release blocking testsuite for
"rtc-in-local"?
Ralf
2:17 p.m.
On Fri, 2015-05-01 at 11:20 +0200, Ralf Corsepius wrote:
On 05/01/2015 02:11 AM, Adam Williamson wrote:
> On Thu, 2015-04-30 at 19:45 -0400, Felix Miata wrote:
> > Adam Williamson composed on 2015-04-30 16:37 (UTC-0700):
> >
> > > I'd prefer objective analysis over anecdata. poettering's
> > > contention
> > > is :
> >
> > > i) there is only a problem if you have time-based fsck enabled
> > > ii) this is not the default
> >
> > > your anecdote does not provide enough information to prove or
> > > disprove
> > > his contention.
> >
> > He never mentioned what time-based fsck is that I saw,
>
> "What doesn't work is rtc-in-local in early-boot, that's all. And
> that
> doesn't matter really, except if you are crazy enough to manually
> enable time-based fsck in ext234, which has been turned off by
> default
Wrong.
Even on f21, setting the "The sixth field" of the line referring to
"/"
(root) to "!= 0" in /etc/fstab is sufficient to provoke this bug in
"rtc-in-local" configuration.
May-be you (testing) should add a release blocking testsuite for
"rtc-in-local"?
As described, this does not constitute a release-blocking bug. We
already have a test for 'clean default install alongside Windows',
which is what the release criteria require to work.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9:25 a.m.
On 04/30/2015 06:37 PM, Adam Williamson wrote:
I'd prefer objective analysis over anecdata. poettering's
contention
is :
i) there is only a problem if you have time-based fsck enabled
ii) this is not the default
In addition, it's only going to be a problem when fsck is run during
early boot, before the kernel's clock has been adjusted for having
been initially set to local time from the RTC. And even then, it
depends on whether your time zone offset is positive or negative.
In the goode olde days, fsck was performed from rc.sysinit long
after the kernel's clock was set correctly, so the effect of RTC
in local time was just some bogus timestamps in the boot log. Now,
with more tasks performed in early boot, the effect of a large
positive or negative shift in the kernel's clock can be more severe.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
12:56 p.m.
UEFI doesn't solve anything with the rtc-in-local stuff windows
is
doing there.
Sorry for being slow, but could you please explain this a bit more? I don't want to
nitpick this to death (I've just set Windows to use UTC and it seems to work great),
but I'm really interested in learning why UEFI isn't the magical cure I thought it
to be.
Assuming Windows sets RTC into local time, but also correctly fills in timezone and DST
fields in UEFI, isn't it easy to compute UTC from it, even in early boot? You take the
time, subtract the timezone and DST and you have UTC time (the same approach works if the
RTC is already in UTC, because timezone and DST are zero). What am I missing?
Thanks for info.
What doesn't work is rtc-in-local in early-boot, that's all.
And that
doesn't matter really, ...
It screws up the logs :/ It's somewhat confusing when reading them (especially when
you have a large timezone offset, I imagine), or when searching in them using journalctl
--since/--until.
3277
days inactive
3287
days old
56 comments
21 participants
participants (21)
-
Adam Williamson -
Ahmad Samir -
Andre Robatino -
Andrew Lutomirski -
Chris Adams -
Chris Murphy -
Eric Sandeen -
Felix Miata -
Ian Malone -
Kamil Paral -
Lennart Poettering -
Lubomir Rintel -
Matthew Miller -
Michael Schwendt -
Przemek Klosowski -
Ralf Corsepius -
Reindl Harald -
Robert Nichols -
Simon Farnsworth -
Till Maas -
Zbigniew Jędrzejewski-Szmek