Michael Bonert wrote:
> On shutdown I was getting something like this:
> -
> Shorewall:net2all:DROP:IN=eth0
> OUT=MAC=ff:ff:ff:ff:ff:ff:00:06:25:f0:a9:d3:08:026369 PROTO=UDP SPT=29943
> DPT=152 LEN=128
> -
> I couldn't do anything about it. It seemed to be stuck in a loop... where
> the n
dged by Shields Up -- https://grc.com/x/ne.dll?bh0bkyd2
> If I shutdown shorewall and run the sequence at Shields Up --- I get all
> green. With the config I copied from Mandrake-- I get one blue port (closed
> (green) vs. hidden (blue)).
this is misleading. grc.com is geared to Window
On Tue, 07 Mar 2006, Michael Bonert wrote:
> With the recent upgrade there is some sort of universal time eastern
> standard time conflict. My computer when I boot-up has the clock turned
> back 5 hours (the difference between Greenwich and where I live --with DST
> compensation).
That's a real b
the above problem, I have the impression shorewall makes me
more insecure-- as judged by Shields Up -- https://grc.com/x/ne.dll?bh0bkyd2
If I shutdown shorewall and run the sequence at Shields Up --- I get all
green. With the config I copied from Mandrake-- I get one blue port (closed
(green) vs. hidd
Glenn English wrote:
The only thing I can think of is that something got bent in the power
failure -- something that the Debian boot process doesn't look at and
set, but BSD does. But I don't quite believe it, and I have no suspects
for the "something."
One thing a power failure (or possibly runnin
Bob Freemer wrote:
> Wrong. NTP will fail to update the clock if the hardware clock skew is
> too large. NTP cannot operate without a reasonably stable internal
> hardware clock.
Although there is an option to force ntp to set the clock, however large
the difference is.
--
Stephen Patterson [E
On Sat, 2005-05-14 at 02:25 -0400, Marty wrote:
> I don't want to argue if you are happy, but it doesn't sound fixed
> to me. NTP should keep your clock on time to within a few miliseconds.
> If you notice any abrupt changes that means NTP is definitely not
> working.
That's what I was trying t
Bob Freemer wrote:
Marty wrote:
Glenn English wrote:
Many thanks for all the suggestions, especially the ones pointing me
away from the soldering iron.
I still don't understand this at all. But booting a FreeBSD install disk
seems to have fixed my clock. The prospect of being replaced scared
Sarge
Marty wrote:
Glenn English wrote:
Many thanks for all the suggestions, especially the ones pointing me
away from the soldering iron.
I still don't understand this at all. But booting a FreeBSD install disk
seems to have fixed my clock. The prospect of being replaced scared
Sarge into getting it's a
Glenn English wrote:
Many thanks for all the suggestions, especially the ones pointing me
away from the soldering iron.
I still don't understand this at all. But booting a FreeBSD install disk
seems to have fixed my clock. The prospect of being replaced scared
Sarge into getting it's act together
Many thanks for all the suggestions, especially the ones pointing me
away from the soldering iron.
I still don't understand this at all. But booting a FreeBSD install disk
seems to have fixed my clock. The prospect of being replaced scared
Sarge into getting it's act together, I guess. Earlier to
On Thu, 12 May 2005, Glenn English wrote:
> The system clock on one of my machines is running way slow. If I
> repeatedly run 'date' the second changes once every 3 or 4 seconds.
> ntpdate will bring it into line, but ntpd can't keep it there.
are you using the same ntp server for ntpdate and n
Marty writes:
> I have not yet reported this as a bug.
It isn't a bug. You need to recompile your kernel with HZ defined as
something less than the default 1000.
--
John Hasler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On (13/05/05 00:04), Clive Menzies wrote:
> On (12/05/05 16:59), Glenn English wrote:
> > The system clock on one of my machines is running way slow. If I
> > repeatedly run 'date' the second changes once every 3 or 4 seconds.
> > ntpdate will bring it into line, but ntpd can't keep it there.
> >
Glenn English wrote:
The system clock on one of my machines is running way slow. If I
repeatedly run 'date' the second changes once every 3 or 4 seconds.
ntpdate will bring it into line, but ntpd can't keep it there.
I don't understand how this can happen. My experience with digital
electronics say
On Thursday 12 May 2005 23:59, Glenn English wrote:
> I don't understand how this can happen. My experience with digital
> electronics says that things almost never work half-way; they're fine,
> or they're dead. Anybody know what the system clock actually is? A
> counter counting the line frequenc
On (12/05/05 16:59), Glenn English wrote:
> The system clock on one of my machines is running way slow. If I
> repeatedly run 'date' the second changes once every 3 or 4 seconds.
> ntpdate will bring it into line, but ntpd can't keep it there.
>
> I don't understand how this can happen. My experie
The system clock on one of my machines is running way slow. If I
repeatedly run 'date' the second changes once every 3 or 4 seconds.
ntpdate will bring it into line, but ntpd can't keep it there.
I don't understand how this can happen. My experience with digital
electronics says that things almost
George Bonser hat gesagt: // George Bonser wrote:
> Sorry, I could not help but laugh. Every morning my clock also troubles me
> unexpectedly too.
Yeah, I know this "boot time" trouble as well. Especially on sunday mornings
when I have reached my "maximum mount count" the evening before and
e2fs
Hello list,
somehow the time settings on my machine are messed up. The reason is:
/sbin/hwclock does not work anymore. Instead it gives this error message:
$ hwclock --test --debug
Open of /dev/rtc failed, errno = No such file or directory (2). falling back
to more primitive clock access method
20 matches
Mail list logo
