Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #182454 > unrolled thread

Superblock last write time is in the future.

Back to article view | Back to linux.debian.user

Contents

  Superblock last write time is in the future. Wellington Terumi Uemura <wellingtonuemura@gmail.com> - 2017-06-21 07:50 +0200
    Re: Superblock last write time is in the future. Michael Biebl <biebl@debian.org> - 2017-06-21 12:00 +0200
      Re: Superblock last write time is in the future. Wellington Terumi Uemura <wellingtonuemura@gmail.com> - 2017-07-02 18:00 +0200
        Re: Superblock last write time is in the future. Michael Biebl <biebl@debian.org> - 2017-07-02 19:30 +0200
          Re: Superblock last write time is in the future. Wellington Terumi Uemura <wellingtonuemura@gmail.com> - 2017-07-02 21:30 +0200
        Re: Superblock last write time is in the future. Siard <shiems146@kpnplanet.nl> - 2017-07-02 22:40 +0200
          Re: Superblock last write time is in the future. Wellington Terumi Uemura <wellingtonuemura@gmail.com> - 2017-07-02 23:10 +0200
            Re: Superblock last write time is in the future. <tomas@tuxteam.de> - 2017-07-03 09:40 +0200
              Re: Superblock last write time is in the future. Wellington Terumi Uemura <wellingtonuemura@gmail.com> - 2017-07-03 13:30 +0200
                Re: Superblock last write time is in the future. <tomas@tuxteam.de> - 2017-07-03 14:00 +0200
                  Re: Superblock last write time is in the future. Cindy-Sue Causey <butterflybytes@gmail.com> - 2017-07-03 15:30 +0200
                    Re: Superblock last write time is in the future. David Wright <deblis@lionunicorn.co.uk> - 2017-07-03 17:30 +0200
              Re: Superblock last write time is in the future. David Wright <deblis@lionunicorn.co.uk> - 2017-07-03 17:10 +0200
                Re: Superblock last write time is in the future. Wellington Terumi Uemura <wellingtonuemura@gmail.com> - 2017-07-03 18:10 +0200
                  Re: Superblock last write time is in the future. David Wright <deblis@lionunicorn.co.uk> - 2017-07-03 21:50 +0200
                    Re: Superblock last write time is in the future. Wellington Terumi Uemura <wellingtonuemura@gmail.com> - 2017-07-03 22:10 +0200
                      Re: Superblock last write time is in the future. Nicolas George <george@nsup.org> - 2017-07-03 22:20 +0200
                      Re: Superblock last write time is in the future. David Wright <deblis@lionunicorn.co.uk> - 2017-07-04 05:50 +0200
                Re: Superblock last write time is in the future. Gene Heskett <gheskett@shentel.net> - 2017-07-03 19:00 +0200
            Re: Superblock last write time is in the future. Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-07-03 21:10 +0200
              Re: Superblock last write time is in the future. Wellington Terumi Uemura <wellingtonuemura@gmail.com> - 2017-07-03 21:50 +0200
              Re: Superblock last write time is in the future. Felix Miata <mrmazda@earthlink.net> - 2017-07-03 23:40 +0200
                Re: Superblock last write time is in the future. Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-07-04 21:30 +0200
                  Re: Superblock last write time is in the future. Felix Miata <mrmazda@earthlink.net> - 2017-07-04 22:20 +0200
                    Re: Superblock last write time is in the future. Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-07-04 22:50 +0200

Page 1 of 2  [1] 2  Next page →

#182454 — Superblock last write time is in the future.

Since a fresh install from Debian 8 to 9, this started to happen. 
Looking in to the matter, I've found this so far.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755722
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767040

Looking over the net people with other Linux had the same issue, but is 
not my bios clock, the time is correct there. Cheking the clock it show 
a a few seconds of difference. Others suggest messing with ntp, 
/etc/adjtime and a dozen other "solutions" for different Linux distros, 
is there any effective?

hwclock -r; date
2017-06-21 02:35:40.894615-0300
qua jun 21 02:35:38 -03 2017

timedatectl status
       Local time: qua 2017-06-21 02:35:21 -03
   Universal time: qua 2017-06-21 05:35:21 UTC
         RTC time: qua 2017-06-21 02:35:23
        Time zone: America/Sao_Paulo (-03, -0300)
  Network time on: yes
NTP synchronized: no
  RTC in local TZ: yes

The bugreport show that this has been patched, anything else I could do 
to stop running system check/clean every time I boot?

Thanks

[toc] | [next] | [standalone]

#182462

[Multipart message — attachments visible in raw view] — view raw

Am 21.06.2017 um 07:43 schrieb Wellington Terumi Uemura:

>  RTC in local TZ: yes
> 
> The bugreport show that this has been patched, anything else I could do
> to stop running system check/clean every time I boot?

I would set the system clock from LOCAL to UTC (see /etc/adjtime)


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#182978

Just to give a feedback, this doesn't work if you have a second OS like 
Windows.

I've returned to LOCAL and installed a NTP client to make sure the clock 
is right, this still a BUG.

On 21-06-2017 06:50, Michael Biebl wrote:
> Am 21.06.2017 um 07:43 schrieb Wellington Terumi Uemura:
>
>>  RTC in local TZ: yes
>>
>> The bugreport show that this has been patched, anything else I could do
>> to stop running system check/clean every time I boot?
>
> I would set the system clock from LOCAL to UTC (see /etc/adjtime)
>
>

[toc] | [prev] | [next] | [standalone]

#182980

[Multipart message — attachments visible in raw view] — view raw

Am 02.07.2017 um 17:49 schrieb Wellington Terumi Uemura:
> Just to give a feedback, this doesn't work if you have a second OS like
> Windows.

Windows (since 7) works fine with UTC. There is a registry key you can set.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#182985

[Multipart message — attachments visible in raw view] — view raw

Debian, since 8.
Was doing just fine, all this mess started with 9.

Em 2 de jul de 2017 14:25, "Michael Biebl" <biebl@debian.org> escreveu:

> Am 02.07.2017 um 17:49 schrieb Wellington Terumi Uemura:
> > Just to give a feedback, this doesn't work if you have a second OS like
> > Windows.
>
> Windows (since 7) works fine with UTC. There is a registry key you can set.
>
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>

[toc] | [prev] | [next] | [standalone]

#182993

Wellington Terumi Uemura:
> Michael Biebl:
> > I would set the system clock from LOCAL to UTC (see /etc/adjtime)
>
> Just to give a feedback, this doesn't work if you have a second OS
> like Windows.

Did you follow this procedure?
https://wiki.archlinux.org/index.php/Time#UTC_in_Windows

"One reason users often set the RTC in localtime is to dual boot with
Windows (which uses localtime). However, Windows is able to deal with
the RTC being in UTC with a simple registry fix."

Works fine for me in both Debian 9 and 10.

[toc] | [prev] | [next] | [standalone]

#182996

I use Linux since Slackware 2.0, way before Windows 95. And up to Debian 
8, I've never, EVER, had to follow that procedure because it worked just 
fine before. I'm using Debian like what, 10 years now.

Why do I have to change a registry because something in Debian 9 is not 
syncing the time correctly with the hard drive before a reboot?

Just to make sure, I've reinstalled Debian 8 and the issue is gone, it 
happens again with 9 so, I'm not changing that registry.

This is a Debian 9 issue.


On 02-07-2017 17:30, Siard wrote:
> Wellington Terumi Uemura:
>> Michael Biebl:
>>> I would set the system clock from LOCAL to UTC (see /etc/adjtime)
>>
>> Just to give a feedback, this doesn't work if you have a second OS
>> like Windows.
>
> Did you follow this procedure?
> https://wiki.archlinux.org/index.php/Time#UTC_in_Windows
>
> "One reason users often set the RTC in localtime is to dual boot with
> Windows (which uses localtime). However, Windows is able to deal with
> the RTC being in UTC with a simple registry fix."
>
> Works fine for me in both Debian 9 and 10.
>

[toc] | [prev] | [next] | [standalone]

#183002

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Jul 02, 2017 at 06:08:31PM -0300, Wellington Terumi Uemura wrote:
> I use Linux since Slackware 2.0, way before Windows 95. And up to
> Debian 8, I've never, EVER, had to follow that procedure because it
> worked just fine before. I'm using Debian like what, 10 years now.
> 
> Why do I have to change a registry because something in Debian 9 is
> not syncing the time correctly with the hard drive before a reboot?
> 
> Just to make sure, I've reinstalled Debian 8 and the issue is gone,
> it happens again with 9 so, I'm not changing that registry.
> 
> This is a Debian 9 issue.

Yes, I agree that this doesn't look like a time initialization
issue or a hardware clock issue.

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAllZ9GQACgkQBcgs9XrR2kYGagCeJBmlBiqFPtlWrTP048xdoMBt
troAnRHIcQjbmsXV2L0zIKJ/MPfk5qic
=Lq0V
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#183005

Looks like people can't make up their minds, /etc/adjtime is missing 
from initramfs.

root@Dragon:/boot# lsinitramfs /boot/initrd.img-4.9.0-3-amd64|grep etc
etc
etc/ld.so.cache
etc/mtab
etc/ld.so.conf.d
etc/ld.so.conf.d/zz_i386-biarch-compat.conf
etc/ld.so.conf.d/libc.conf
etc/ld.so.conf.d/x86_64-linux-gnu.conf
etc/udev
etc/udev/udev.conf
etc/ld.so.conf
etc/fstab
etc/modprobe.d
etc/modprobe.d/cx23885.conf
etc/modprobe.d/amd64-microcode-blacklist.conf
etc/modprobe.d/sp5100_tco-blacklist.conf

And people say that this is the problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1198761

Looks like all we need to do is to add /etc/adjtime back to initramfs.

On 03-07-2017 04:38, tomas@tuxteam.de wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sun, Jul 02, 2017 at 06:08:31PM -0300, Wellington Terumi Uemura wrote:
>> I use Linux since Slackware 2.0, way before Windows 95. And up to
>> Debian 8, I've never, EVER, had to follow that procedure because it
>> worked just fine before. I'm using Debian like what, 10 years now.
>>
>> Why do I have to change a registry because something in Debian 9 is
>> not syncing the time correctly with the hard drive before a reboot?
>>
>> Just to make sure, I've reinstalled Debian 8 and the issue is gone,
>> it happens again with 9 so, I'm not changing that registry.
>>
>> This is a Debian 9 issue.
>
> Yes, I agree that this doesn't look like a time initialization
> issue or a hardware clock issue.
>
> Cheers
> - -- tomás
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iEYEARECAAYFAllZ9GQACgkQBcgs9XrR2kYGagCeJBmlBiqFPtlWrTP048xdoMBt
> troAnRHIcQjbmsXV2L0zIKJ/MPfk5qic
> =Lq0V
> -----END PGP SIGNATURE-----
>

[toc] | [prev] | [next] | [standalone]

#183007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Jul 03, 2017 at 08:25:58AM -0300, Wellington Terumi Uemura wrote:
> Looks like people can't make up their minds, /etc/adjtime is missing
> from initramfs.
> 
> root@Dragon:/boot# lsinitramfs /boot/initrd.img-4.9.0-3-amd64|grep etc
> etc
> etc/ld.so.cache
> etc/mtab
> etc/ld.so.conf.d
> etc/ld.so.conf.d/zz_i386-biarch-compat.conf
> etc/ld.so.conf.d/libc.conf
> etc/ld.so.conf.d/x86_64-linux-gnu.conf
> etc/udev
> etc/udev/udev.conf
> etc/ld.so.conf
> etc/fstab
> etc/modprobe.d
> etc/modprobe.d/cx23885.conf
> etc/modprobe.d/amd64-microcode-blacklist.conf
> etc/modprobe.d/sp5100_tco-blacklist.conf
> 
> And people say that this is the problem.
> https://bugzilla.redhat.com/show_bug.cgi?id=1198761
> 
> Looks like all we need to do is to add /etc/adjtime back to initramfs.

Hmm, yes -- initramfs and the "up and running" OS should agree on what
corrections to apply to the time read from the hwclock; if not, it
sounds plausible that initramfs (who is mounting root, and thus checking
the superblock) has a different notion of time than the OS, who has
synced out the superblock on last shutdown.

I can't work out the details, but what you say makes a lot of sense.

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAllaMGEACgkQBcgs9XrR2kbeFwCfXntl7ShEl0ea/YVsZklT+f8T
iOgAniBpUE6yABvzBoYf0kD0bL+j1rxE
=ngfH
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#183011

On 7/3/17, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, Jul 03, 2017 at 08:25:58AM -0300, Wellington Terumi Uemura wrote:
>> Looks like people can't make up their minds, /etc/adjtime is missing
>> from initramfs.
>>
>> root@Dragon:/boot# lsinitramfs /boot/initrd.img-4.9.0-3-amd64|grep etc
>> etc
>> etc/ld.so.cache
>> etc/mtab
>> etc/ld.so.conf.d
>> etc/ld.so.conf.d/zz_i386-biarch-compat.conf
>> etc/ld.so.conf.d/libc.conf
>> etc/ld.so.conf.d/x86_64-linux-gnu.conf
>> etc/udev
>> etc/udev/udev.conf
>> etc/ld.so.conf
>> etc/fstab
>> etc/modprobe.d
>> etc/modprobe.d/cx23885.conf
>> etc/modprobe.d/amd64-microcode-blacklist.conf
>> etc/modprobe.d/sp5100_tco-blacklist.conf
>>
>> And people say that this is the problem.
>> https://bugzilla.redhat.com/show_bug.cgi?id=1198761
>>
>> Looks like all we need to do is to add /etc/adjtime back to initramfs.
>
> Hmm, yes -- initramfs and the "up and running" OS should agree on what
> corrections to apply to the time read from the hwclock; if not, it
> sounds plausible that initramfs (who is mounting root, and thus checking
> the superblock) has a different notion of time than the OS, who has
> synced out the superblock on last shutdown.
>
> I can't work out the details, but what you say makes a lot of sense.


I don't know if this will help, but this topic is fresh in mind
because I am right in the middle of finishing out a successful (3 day
k/t dialup) debootstrap of Buster. Addressing /etc/adjtime is one of
the manual steps in the debootstrap process because that file doesn't
exist until it is manually created early on.

The process *for me* is to create a new file /etc/adjtime and add the
following 3 lines to it:

0.0 0 0.0

0
UTC

After that file is successfully saved, I next run "dpkg-reconfigure
tzdata". The package, tzdata, should be updated, should be the most
current just like any others.

That's for the settings within my desktop environment, etc. My
computers' clocks have always been set to UTC over the years after
having picked that up as a tip one time when my desktop environment's
clock kept resetting itself during every reboot.

Someone here on Debian-User was trying to fix something on their setup
a couple months ago. I couldn't (cognitively) bring the words together
to reply with a "me, too (kinda sorta)" along with providing the
details in my case.

Most of my files reflect the correct date in Thunar, Xfce4's file
manager, EXCEPT THAT.. For some reason, I have to mentally add 4 hours
to the time stamp attached to files downloaded from a Canon FS40 video
camera.

Seems like it might have been doing the same thing for a camera phone
I was using for a couple months. It was doing the same thing for
*something*, I just can't remember what.

Yes, I know it's not quite the same thing, but it does show something
is a little wonky in the time clock department.

If Debian appears to be becoming more insistent that the computer's
clock be set to universal UTC, that feels a little like what we
experienced during the last major release. I remember well the
momentary "upset" caused after that last release. As I "lurked" and
just took all the conversations in back then, it was apparent that
Debian is being developed to be more "strict", more precise, and thus
less forgiving of our old computing habits.

That UTC tip I garnered somewhere off the Net was that we're computing
in an international business and pleasure arena online. That's why
setting UTC for the most "base" of our clocks can almost become a
"critical" must-do to take part in that international arena in a
properly time synced manner. There are surely exceptions why not to go
UTC, but the rationale behind doing so made total sense to me at the
time. :)

So far, that UTC route has worked *for me* with the exception of that
Canon video camera's file time stamp anomaly...........

Just thinking out loud....... :)

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

[toc] | [prev] | [next] | [standalone]

#183024

On Mon 03 Jul 2017 at 09:28:36 (-0400), Cindy-Sue Causey wrote:
> On 7/3/17, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Mon, Jul 03, 2017 at 08:25:58AM -0300, Wellington Terumi Uemura wrote:
> >> Looks like people can't make up their minds, /etc/adjtime is missing
> >> from initramfs.
> >>
> >> root@Dragon:/boot# lsinitramfs /boot/initrd.img-4.9.0-3-amd64|grep etc
> >> etc
> >> etc/ld.so.cache
> >> etc/mtab
> >> etc/ld.so.conf.d
> >> etc/ld.so.conf.d/zz_i386-biarch-compat.conf
> >> etc/ld.so.conf.d/libc.conf
> >> etc/ld.so.conf.d/x86_64-linux-gnu.conf
> >> etc/udev
> >> etc/udev/udev.conf
> >> etc/ld.so.conf
> >> etc/fstab
> >> etc/modprobe.d
> >> etc/modprobe.d/cx23885.conf
> >> etc/modprobe.d/amd64-microcode-blacklist.conf
> >> etc/modprobe.d/sp5100_tco-blacklist.conf
> >>
> >> And people say that this is the problem.
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1198761
> >>
> >> Looks like all we need to do is to add /etc/adjtime back to initramfs.
> >
> > Hmm, yes -- initramfs and the "up and running" OS should agree on what
> > corrections to apply to the time read from the hwclock; if not, it
> > sounds plausible that initramfs (who is mounting root, and thus checking
> > the superblock) has a different notion of time than the OS, who has
> > synced out the superblock on last shutdown.
> >
> > I can't work out the details, but what you say makes a lot of sense.
> 
> 
> I don't know if this will help, but this topic is fresh in mind
> because I am right in the middle of finishing out a successful (3 day
> k/t dialup) debootstrap of Buster. Addressing /etc/adjtime is one of
> the manual steps in the debootstrap process because that file doesn't
> exist until it is manually created early on.
> 
> The process *for me* is to create a new file /etc/adjtime and add the
> following 3 lines to it:
> 
> 0.0 0 0.0
> 0
> UTC
> 
> After that file is successfully saved, I next run "dpkg-reconfigure
> tzdata". The package, tzdata, should be updated, should be the most
> current just like any others.
> 
> That's for the settings within my desktop environment, etc. My
> computers' clocks have always been set to UTC over the years after
> having picked that up as a tip one time when my desktop environment's
> clock kept resetting itself during every reboot.
> 
> Someone here on Debian-User was trying to fix something on their setup
> a couple months ago. I couldn't (cognitively) bring the words together
> to reply with a "me, too (kinda sorta)" along with providing the
> details in my case.
> 
> Most of my files reflect the correct date in Thunar, Xfce4's file
> manager, EXCEPT THAT.. For some reason, I have to mentally add 4 hours
> to the time stamp attached to files downloaded from a Canon FS40 video
> camera.
> 
> Seems like it might have been doing the same thing for a camera phone
> I was using for a couple months. It was doing the same thing for
> *something*, I just can't remember what.
> 
> Yes, I know it's not quite the same thing, but it does show something
> is a little wonky in the time clock department.
> 
> If Debian appears to be becoming more insistent that the computer's
> clock be set to universal UTC, that feels a little like what we
> experienced during the last major release. I remember well the
> momentary "upset" caused after that last release. As I "lurked" and
> just took all the conversations in back then, it was apparent that
> Debian is being developed to be more "strict", more precise, and thus
> less forgiving of our old computing habits.
> 
> That UTC tip I garnered somewhere off the Net was that we're computing
> in an international business and pleasure arena online. That's why
> setting UTC for the most "base" of our clocks can almost become a
> "critical" must-do to take part in that international arena in a
> properly time synced manner. There are surely exceptions why not to go
> UTC, but the rationale behind doing so made total sense to me at the
> time. :)
> 
> So far, that UTC route has worked *for me* with the exception of that
> Canon video camera's file time stamp anomaly...........

Which filesystem does your camera use? How do you transfer the files?
What timezone do you set on the camera? Does the camera clock support
timezones?

For example:

FAT, physically via SD card, UTC, No.
That combination works for both my digital cameras.

Unknown, bluetooth, Local (automatic), Yes.
That combination doesn't work as bluetooth stamps the files with
the time of transfer, so I run a script that renames and touches
them using with the embedded UTC timestamp (the $10 mobile names
them in US format with one minute resolution so I ignore them).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#183020

On Mon 03 Jul 2017 at 09:38:12 (+0200), tomas@tuxteam.de wrote:
> On Sun, Jul 02, 2017 at 06:08:31PM -0300, Wellington Terumi Uemura wrote:
> > I use Linux since Slackware 2.0, way before Windows 95. And up to
> > Debian 8, I've never, EVER, had to follow that procedure because it
> > worked just fine before. I'm using Debian like what, 10 years now.
> > 
> > Why do I have to change a registry because something in Debian 9 is
> > not syncing the time correctly with the hard drive before a reboot?
> > 
> > Just to make sure, I've reinstalled Debian 8 and the issue is gone,
> > it happens again with 9 so, I'm not changing that registry.
> > 
> > This is a Debian 9 issue.
> 
> Yes, I agree that this doesn't look like a time initialization
> issue or a hardware clock issue.

The future could get complicated for people not running on UTC
if time offsets of a few seconds start to arise. AIUI timezones
as presently implemented can't handle that.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#183029

[Multipart message — attachments visible in raw view] — view raw

I could say the same for for US not using a metric system, you don't change
this by force even if it is right.

I don't need UTC, many people around the world doesn't neither, leave UTC
for those who need it.

We can avoid a lot of mess with that.

Em 3 de jul de 2017 12:03, "David Wright" <deblis@lionunicorn.co.uk>
escreveu:


The future could get complicated for people not running on UTC
if time offsets of a few seconds start to arise. AIUI timezones
as presently implemented can't handle that.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#183045

On Mon 03 Jul 2017 at 13:00:24 (-0300), Wellington Terumi Uemura wrote:
> I could say the same for for US not using a metric system, you don't change
> this by force even if it is right.

The discussion is not about units, but about reference points.¹

> I don't need UTC, many people around the world doesn't neither, leave UTC
> for those who need it.

True; before the dawn of railways, everyone lived on local time.

> We can avoid a lot of mess with that.

I have no idea what the mess is that you're trying to avoid
by using local time.

> Em 3 de jul de 2017 12:03, "David Wright" <deblis@lionunicorn.co.uk>
> escreveu:
> 
> 
> The future could get complicated for people not running on UTC
> if time offsets of a few seconds start to arise. AIUI timezones
> as presently implemented can't handle that.

¹ personally, the most inconvenient thing about US units is
the chaotic paper size system as there's no real way round it.
The reason that _does_ involve the units is of course that the
physical paper sizes are derived _from_ the units.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#183046

On 03-07-2017 16:42, David Wright wrote:
> The discussion is not about units, but about reference points.¹
The discussion also is not about reference points, but what is right to do.

>> I don't need UTC, many people around the world doesn't neither, leave UTC
>> for those who need it.
>
> True; before the dawn of railways, everyone lived on local time.
It was working.

>> We can avoid a lot of mess with that.
>
> I have no idea what the mess is that you're trying to avoid
> by using local time.
I have no idea why they are forcing the use o UTC, local time was doing 
just fine. My TV doesn't use UTC, my router (OpenWRT) doesn't use UTC, 
my phone (Samsung S7 Edge) doesn't use UTC, it doesn't even has settings 
for UTC, my printer (Brother HL4150CDN) it doesn't use UTC.

Why create all this trouble?

All I'm trying to avoid is to prevent fsck from scanning my discs every 
single time I boot the computer and because some one removed 
/etc/adjtime from initramfs.

>> Em 3 de jul de 2017 12:03, "David Wright" <deblis@lionunicorn.co.uk>
>> escreveu:
>>
>>
>> The future could get complicated for people not running on UTC
>> if time offsets of a few seconds start to arise. AIUI timezones
>> as presently implemented can't handle that.
>
> ¹ personally, the most inconvenient thing about US units is
> the chaotic paper size system as there's no real way round it.
> The reason that _does_ involve the units is of course that the
> physical paper sizes are derived _from_ the units.
>
> Cheers,
> David.
>

[toc] | [prev] | [next] | [standalone]

#183047

[Multipart message — attachments visible in raw view] — view raw

Le quintidi 15 messidor, an CCXXV, Wellington Terumi Uemura a écrit :
> I have no idea why they are forcing the use o UTC, local time was doing just
> fine. My TV doesn't use UTC, my router (OpenWRT) doesn't use UTC, my phone
> (Samsung S7 Edge) doesn't use UTC, it doesn't even has settings for UTC, my
> printer (Brother HL4150CDN) it doesn't use UTC.

You are wrong, they all use UTC, you just did not know it because you
behave as a simple customer, not bothering to look at the innards.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#183076

On Mon 03 Jul 2017 at 17:05:51 (-0300), Wellington Terumi Uemura wrote:
> On 03-07-2017 16:42, David Wright wrote:
> >The discussion is not about units, but about reference points.¹
> The discussion also is not about reference points,

I disagree. The RTC is a reference point for setting the system
clock from when the machine has no other reference (no network
connection).

> but what is right to do.

There's no "right" answer, just options which introduce differing
amounts of complexity.

> >>I don't need UTC, many people around the world doesn't neither, leave UTC
> >>for those who need it.
> >
> >True; before the dawn of railways, everyone lived on local time.
> It was working.

… until the railways started moving accurate clocks about the place.

> >>We can avoid a lot of mess with that.
> >
> >I have no idea what the mess is that you're trying to avoid
> >by using local time.
> I have no idea why they are forcing the use o UTC, local time was
> doing just fine. My TV doesn't use UTC, my router (OpenWRT) doesn't
> use UTC, my phone (Samsung S7 Edge) doesn't use UTC, it doesn't even
> has settings for UTC, my printer (Brother HL4150CDN) it doesn't use
> UTC.
> 
> Why create all this trouble?

What trouble; again, what mess?

I can't see the point of having an RTC that is wrong much of the
time (ie when you travel across timezones or the seasons change)
and needs an OS to sort it out; unnecessary complication IMO.

> All I'm trying to avoid is to prevent fsck from scanning my discs
> every single time I boot the computer and because some one removed
> /etc/adjtime from initramfs.

I thought you'd now managed to do that.

> >>Em 3 de jul de 2017 12:03, "David Wright" <deblis@lionunicorn.co.uk>
> >>escreveu:
> >>
> >>
> >>The future could get complicated for people not running on UTC
> >>if time offsets of a few seconds start to arise. AIUI timezones
> >>as presently implemented can't handle that.
> >
> >¹ personally, the most inconvenient thing about US units is
> >the chaotic paper size system as there's no real way round it.
> >The reason that _does_ involve the units is of course that the
> >physical paper sizes are derived _from_ the units.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#183033

On Monday 03 July 2017 11:02:56 David Wright wrote:

> On Mon 03 Jul 2017 at 09:38:12 (+0200), tomas@tuxteam.de wrote:
> > On Sun, Jul 02, 2017 at 06:08:31PM -0300, Wellington Terumi Uemura 
wrote:
> > > I use Linux since Slackware 2.0, way before Windows 95. And up to
> > > Debian 8, I've never, EVER, had to follow that procedure because
> > > it worked just fine before. I'm using Debian like what, 10 years
> > > now.
> > >
> > > Why do I have to change a registry because something in Debian 9
> > > is not syncing the time correctly with the hard drive before a
> > > reboot?
> > >
> > > Just to make sure, I've reinstalled Debian 8 and the issue is
> > > gone, it happens again with 9 so, I'm not changing that registry.
> > >
> > > This is a Debian 9 issue.
> >
> > Yes, I agree that this doesn't look like a time initialization
> > issue or a hardware clock issue.
>
> The future could get complicated for people not running on UTC
> if time offsets of a few seconds start to arise. AIUI timezones
> as presently implemented can't handle that.
>
> Cheers,
> David.

I put my hdwe clocks on UCT 18 years ago with my first redhat 5.0 
install. The tz files have kept pace for me, so its  not been a problem 
other that one install in 2002 set it to local but didn't set the hdwe 
clock, so on the next reboot, it set the arrival times of 6 messages 
before I noticed it, to sometime in 2020. Its a mailing list I do not 
expire but even if I did set one, those 6 msgs would still be there.  
Shrug....

Lesson #10 for linux, put the hardware clock on UCT, set /your/ time zone 
in the locale, and forget about it.  It Just Works(TM)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#183040

Le 02/07/2017 à 23:08, Wellington Terumi Uemura a écrit :
> I use Linux since Slackware 2.0, way before Windows 95. And up to Debian
> 8, I've never, EVER, had to follow that procedure because it worked just
> fine before.

Really ?
Setting the RTC with local time does not work with dual boot because 
when daylight saving time comes, both systems will do the shift, 
resulting in a 2 hour shift unless some time synchronization corrects it.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web