Le 04/07/2017 à 22:17, Felix Miata a écrit :
Pascal Hambourg composed on 2017-07-04 21:28 (UTC+0200):
Felix Miata composed:
Pascal Hambourg composed on 2017-07-03 21:06 (UTC+0200):
Setting the RTC with local time does not work with dual boot because
when daylight saving time comes, both syst
Pascal Hambourg composed on 2017-07-04 21:28 (UTC+0200):
> Felix Miata composed:
>> Pascal Hambourg composed on 2017-07-03 21:06 (UTC+0200):
>>> 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
Le 03/07/2017 à 23:37, Felix Miata a écrit :
Pascal Hambourg composed on 2017-07-03 21:06 (UTC+0200):
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 synchronizatio
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
Pascal Hambourg composed on 2017-07-03 21:06 (UTC+0200):
> Wellington Terumi Uemura composed:
>> 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
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
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 t
We already know that information, Pascal. That is not the issue.
On 03-07-2017 16:06, Pascal Hambourg wrote:
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 becau
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 wor
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
On Monday 03 July 2017 11:02:56 David Wright wrote:
> On Mon 03 Jul 2017 at 09:38:12 (+0200), to...@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, E
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"
escreve
On Mon 03 Jul 2017 at 09:28:36 (-0400), Cindy-Sue Causey wrote:
> On 7/3/17, to...@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/adjtim
On Mon 03 Jul 2017 at 09:38:12 (+0200), to...@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 f
On 7/3/17, to...@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/i
-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/l
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
-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 Deb
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 corr
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 reas
Debian, since 8.
Was doing just fine, all this mess started with 9.
Em 2 de jul de 2017 14:25, "Michael Biebl" 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
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
uni
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 l
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 t
The problem is that the newest version of e2fsprogs fixed some problems
which revealed new ones. It has to do with the fact that the local time
is set after the disk is mounted. So if you clock is not on UT, you are
in
trouble. Thre possibilities to fix:
1. downgrade e2fsprogs (and e2fslibs)
2.
On Sat, 07 Jan 2006, David E. Fox wrote:
> 'date -u' is correct (UTC), dates are set coorectly in the filesystem
> for instance but the log entries are in UTC. That doesn't match the
> behavior in sarge.
It doesn't match the behaviour in my sid system either (where it logs in
local time).
It is
On Fri, 6 Jan 2006 19:20:52 -0200
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
>
> "date -u" will tell you what the system thinks is the UTC time. If the
> output is different from plain "date", then it certainly thinks it is in
> some timezone.
I'm also running testing. I've noted that
On Fri, 06 Jan 2006, Kent West wrote:
[ root fsck problem caused by time skew ]
> It seems like I had this on a newly-installed Sid box the other day.
> After I installed "ntpdate" the problem went away (but I was fighting
> several problems at once, so no guarantees that this had any relevance).
Henrique de Moraes Holschuh wrote:
On Fri, 06 Jan 2006, Ray Lanza wrote:
Is using UTC the last word for this problem? I must dual-boot with windows on
my machine.
No, of course not. It is the _easiest_ fix. It is becoming aparent that we
can do a much better fix in glibc, but I ne
On Fri, 06 Jan 2006, Ray Lanza wrote:
> Is using UTC the last word for this problem? I must dual-boot with windows
> on my machine.
No, of course not. It is the _easiest_ fix. It is becoming aparent that we
can do a much better fix in glibc, but I need to investigate more. And
there is always
Is using UTC the last word for this problem? I must dual-boot with windows on
my machine.
My linux configuration is relatively simple with everything on a single
partition. Time zone is set properly, is not a symbolic link and is in the same
filesystem as root.
I've noticed that when I have t
On Thu, 5 Jan 2006 08:59:24 -0200
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> On Wed, 04 Jan 2006, Andrew Sackville-West wrote:
> > I submitted a bug against e2fsprogs a couple weeks ago due to similar
> > issues on boot up. the developer got right on it and apparently fixed it.
> > S
On Wed, 04 Jan 2006, Lei Kong wrote:
> hardware clock store UTC time (UTF=yes in /etc/default/rcS).
> Now, my question is, any drawback in doing so? besides possbile windows
> problem
> on a dual boot machine and confusion when looking at bios.
None whatsoever, other than now your system is that
On Wed, 04 Jan 2006, Andrew Sackville-West wrote:
> I submitted a bug against e2fsprogs a couple weeks ago due to similar
> issues on boot up. the developer got right on it and apparently fixed it.
> Something to do with when debian sets the system clock as it relates to
> the fsck portion of boot.
> > > On Tue, 03 Jan 2006, Brandon Simmons wrote:
> > > > boot. According to the Debian changelog for the e2fsprogs package, the
> > > > newest
> > > > version checks for this, so I don't know whether e2fsprogs is mistaken
> > > > or
> > > > whether there really is a problem. How would I go abou
On Wed, 4 Jan 2006 22:28:15 -0200
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> On Wed, 04 Jan 2006, Lei Kong wrote:
> > > On Tue, 03 Jan 2006, Brandon Simmons wrote:
> > > > boot. According to the Debian changelog for the e2fsprogs package, the
> > > > newest
> > > > version checks fo
On Wed, 04 Jan 2006, Lei Kong wrote:
> > On Tue, 03 Jan 2006, Brandon Simmons wrote:
> > > boot. According to the Debian changelog for the e2fsprogs package, the
> > > newest
> > > version checks for this, so I don't know whether e2fsprogs is mistaken or
> > > whether there really is a problem. Ho
> On Tue, 03 Jan 2006, Brandon Simmons wrote:
> > boot. According to the Debian changelog for the e2fsprogs package, the
> > newest
> > version checks for this, so I don't know whether e2fsprogs is mistaken or
> > whether there really is a problem. How would I go about checking this?
>
> Short a
Brandon Simmons <[EMAIL PROTECTED]> writes:
> After upgrading my system to 'testing', on bootup I am getting the
> error above after "checking root filesystem..."; it then forces a
> reboot and fsck on the next boot.
FWIW I found the error went away once I ran 'fsck -y' (more
specifically, when I
On Tue, 03 Jan 2006, Brandon Simmons wrote:
> boot. According to the Debian changelog for the e2fsprogs package, the newest
> version checks for this, so I don't know whether e2fsprogs is mistaken or
> whether there really is a problem. How would I go about checking this?
Short and to the point: s
40 matches
Mail list logo
