Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On Sun, May 03, 2015 at 03:23:24PM +, 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_released.29 Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On Mon, May 04, 2015 at 12:00:31PM +0200, Till Maas wrote:
On Sun, May 03, 2015 at 03:23:24PM +, 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_released.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?
Zbyszek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On Mon, 04.05.15 13:24, Zbigniew Jędrzejewski-Szmek (zbys...@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 +, 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_released.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?
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On Mon, 2015-05-04 at 13:24 +, 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 +, 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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On Sat, 02.05.15 18:03, Zbigniew Jędrzejewski-Szmek (zbys...@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 kpa...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On Sun, May 03, 2015 at 03:55:38PM +0200, Lennart Poettering wrote: On Sat, 02.05.15 18:03, Zbigniew Jędrzejewski-Szmek (zbys...@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 kpa...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On Tue, Apr 28, 2015 at 02:21:48PM +0200, Ahmad Samir wrote: On 28 April 2015 at 13:40, Kamil Paral kpa...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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* signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On Thu, Apr 30, 2015 at 5:11 PM, Adam Williamson adamw...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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=f096708126412c0569e40cfbd5740729976bf12a I'll get that pushed to testing tonight, sorry for being slow with it. -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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 sand...@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 sand...@redhat.com Signed-off-by: Theodore Ts'o ty...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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 mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
Once upon a time, Eric Sandeen sand...@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 li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On Wed, 2015-04-29 at 18:46 +0200, Lennart Poettering wrote: On Wed, 29.04.15 11:48, Przemek Klosowski (przemek.klosow...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On 04/29/2015 11:14 AM, Lennart Poettering wrote: On Wed, 29.04.15 16:46, Lubomir Rintel (lkund...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On Wed, 29.04.15 11:48, Przemek Klosowski (przemek.klosow...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On Wed, 29.04.15 16:46, Lubomir Rintel (lkund...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On 28 April 2015 at 13:40, Kamil Paral kpa...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On Tue, 28.04.15 14:50, Michael Schwendt (mschwe...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On 27 April 2015 at 21:36, Chris Murphy li...@colorremedies.com wrote: On Mon, Apr 27, 2015 at 10:52 AM, Simon Farnsworth si...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On Monday 27 April 2015 14:36:53 Chris Murphy wrote: On Mon, Apr 27, 2015 at 10:52 AM, Simon Farnsworth si...@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
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On Mon, Apr 27, 2015 at 10:52 AM, Simon Farnsworth si...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On 27 April 2015 at 06:47, Chris Murphy li...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On 04/27/2015 09:34 AM, Ian Malone wrote: On 27 April 2015 at 06:47, Chris Murphy li...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On 27 April 2015 at 09:54, Ralf Corsepius rc040...@freenet.de wrote: On 04/27/2015 09:34 AM, Ian Malone wrote: On 27 April 2015 at 06:47, Chris Murphy li...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On 04/27/2015 06:39 PM, Chris Murphy wrote: On Mon, Apr 27, 2015 at 6:54 AM, Zbigniew Jędrzejewski-Szmek zbys...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On 04/27/2015 06:52 PM, Simon Farnsworth wrote: Come to that, how is Linux supposed to find and read the registry, It doesn't have to. Just do it as it had been done in Linux for ages: Let the user set a configuration item RTC runs in local time Y/N. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On Mon, Apr 27, 2015 at 6:54 AM, Zbigniew Jędrzejewski-Szmek zbys...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On Monday 27 April 2015 10:39:40 Chris Murphy wrote: On Mon, Apr 27, 2015 at 6:54 AM, Zbigniew Jędrzejewski-Szmek zbys...@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 signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [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-os2.html 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
