RPI 4B.
Rebooted. Clock wrong.
1hr later, clock still wrong?

WTF?


--
“People believe certain stories because everyone important tells them,
and people tell those stories because everyone important believes them.
Indeed, when a conventional wisdom is at its fullest strength, one’s agreement with that conventional wisdom becomes almost a litmus test of
one’s suitability to be taken seriously.”

Paul Krugman

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 09/04/2024 17:00, The Natural Philosopher wrote:

RPI 4B.
Rebooted. Clock wrong.
1hr later, clock still wrong?

Probably due to using systemd-timesyncd which I've never seen actuall
working. Install the ntp service and it will work.

It's one of the many parts of Bookworm I've had to junk and restore the
way I did things in Bullseye.

---druck

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 4/9/24 15:47, druck wrote:

On 09/04/2024 17:00, The Natural Philosopher wrote:

RPI 4B.
Rebooted. Clock wrong.
1hr later, clock still wrong?

Probably due to using systemd-timesyncd which I've never seen actuall working. Install the ntp service and it will work.

It's one of the many parts of Bookworm I've had to junk and restore the
way I did things in Bullseye.

---druck

timesyncd works fine. Make sure that the route to the internet isn't
blocked. Use the command timedatectl show-timesync --all to see where timesyncd is looking for time. You can always specify NTP servers in /etc/systemd/timesyncd.conf. Use timedatectl status to see what it is
doing.

--

Knute Johnson

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 9.4.2024 19.00, The Natural Philosopher wrote:

RPI 4B.
Rebooted. Clock wrong.
1hr later, clock still wrong?

WTF?

Raspberry has no RTC chip, so it will lose time when
powered off.

If there is a decent NTP server in the network the Pi
is connected to, it will synchronize to the server.

The undesirable characteristic of systemd-timesyncd
is that it is not willing to pass the time to the local
network.

Just install the ntpsec package and let it take care of
the time. There is a top -type utility ntpmon included.

--

-TV

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

druck <news@druck.org.uk> wrote:

On 09/04/2024 17:00, The Natural Philosopher wrote:

RPI 4B.
Rebooted. Clock wrong.
1hr later, clock still wrong?

Probably due to using systemd-timesyncd which I've never seen actuall working. Install the ntp service and it will work.

It's one of the many parts of Bookworm I've had to junk and restore the
way I did things in Bullseye.

I have bookworm running on two systems, one is a 2Gb Pi 4B and the
other is an ancient Beaglebone Black. Both show the right time
without any intervention from me. I checked and the Pi 4B is running systemd-timesyncd. ...., and the BBB is also running systemd-timesyncd.

--
Chris Green
·

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 09/04/2024 21:47, druck wrote:

On 09/04/2024 17:00, The Natural Philosopher wrote:

RPI 4B.
Rebooted. Clock wrong.
1hr later, clock still wrong?

Probably due to using systemd-timesyncd which I've never seen actuall working. Install the ntp service and it will work.

Its very very weird.

It is systemd.timesyncd, and it sometimes says it cant connect, and very
very occasionally seems to connect.

Apr 09 20:45:51 Coriolanus systemd-timesyncd[547]: Network configuration changed, trying to establish connection.
Apr 09 20:45:53 Coriolanus systemd-timesyncd[547]: No network
connectivity, watching for changes.
Apr 09 20:45:58 Coriolanus systemd-timesyncd[547]: Network configuration changed, trying to establish connection.
Apr 09 20:46:08 Coriolanus systemd-timesyncd[547]: Timed out waiting for
reply from 193.150.34.2:123 (2.debian.pool.ntp.org).
Apr 09 20:46:18 Coriolanus systemd-timesyncd[547]: Timed out waiting for
reply from 77.104.162.218:123 (2.debian.pool.ntp.org).
Apr 09 20:46:28 Coriolanus systemd-timesyncd[547]: Timed out waiting for
reply from 95.215.175.2:123 (2.debian.pool.ntp.org).
Apr 09 20:55:54 Coriolanus systemd-timesyncd[547]: Network configuration changed, trying to establish connection.
Apr 09 20:55:55 Coriolanus systemd-timesyncd[547]: No network
connectivity, watching for changes.
Apr 09 20:56:00 Coriolanus systemd-timesyncd[547]: Network configuration changed, trying to establish connection.
Apr 09 21:30:38 Coriolanus systemd-timesyncd[547]: Contacted time server 51.89.151.183:123 (0.debian.pool.ntp.org).

That is, it hasn't actually contacted a time server in 12 hours.

And the clock is about 2 seconds out.

It's one of the many parts of Bookworm I've had to junk and restore the
way I did things in Bullseye.

Yes, bookworm is surpisingly unstable.

If possible Id like to get systemd working properly

---druck

--
"I am inclined to tell the truth and dislike people who lie consistently.
This makes me unfit for the company of people of a Left persuasion, and
all women"

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 10/04/2024 09:30, Chris Green wrote:

druck <news@druck.org.uk> wrote:

On 09/04/2024 17:00, The Natural Philosopher wrote:

RPI 4B.
Rebooted. Clock wrong.
1hr later, clock still wrong?

Probably due to using systemd-timesyncd which I've never seen actuall
working. Install the ntp service and it will work.

It's one of the many parts of Bookworm I've had to junk and restore the
way I did things in Bullseye.

I have bookworm running on two systems, one is a 2Gb Pi 4B and the
other is an ancient Beaglebone Black. Both show the right time
without any intervention from me. I checked and the Pi 4B is running systemd-timesyncd. ...., and the BBB is also running systemd-timesyncd.

All I know is that I powered the pi4B off for around 15 hours, and when
I rebooted it, it had an incorrect clock for at least two hours after
reboot.

That is unacceptable for an 'out of the box' OS install.

systemd-timesyncd may be fine, but whatever it was supposed to do, it
wasn't doing it.

And none of this is well documented. As someone remarked about CMAKE,
"software that cannot be used because *no one knows how it works*, is
useless"






--
"When a true genius appears in the world, you may know him by this sign,
that the dunces are all in confederacy against him."

Jonathan Swift.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 09/04/2024 23:32, Knute Johnson wrote:

On 4/9/24 15:47, druck wrote:

On 09/04/2024 17:00, The Natural Philosopher wrote:

RPI 4B.
Rebooted. Clock wrong.
1hr later, clock still wrong?

Probably due to using systemd-timesyncd which I've never seen actuall
working. Install the ntp service and it will work.

It's one of the many parts of Bookworm I've had to junk and restore
the way I did things in Bullseye.

---druck

timesyncd works fine.

No, it does not

Make sure that the route to the internet isn't
blocked.

Its fine


Use the command timedatectl show-timesync --all to see where

timesyncd is looking for time.

LinkNTPServers=
SystemNTPServers=
RuntimeNTPServers=
FallbackNTPServers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
ServerName=0.debian.pool.ntp.org
ServerAddress=51.89.151.183
RootDistanceMaxUSec=5s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=34min 8s
PollIntervalUSec=34min 8s
NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=2, Precision=-25, RootDelay=3.021ms, RootDispersion=106us, Reference=55C7D665, OriginateTimestamp=Wed 2024-04-10 10:01:40 BST, ReceiveTimestamp=Wed
2024-04-10 10:01:40 BST, TransmitTimestamp=Wed 2024-04-10 10:01:40 BST, DestinationTimestamp=Wed 2024-04-10 10:01:40 BST, Ignored=no,
PacketCount=36, Jitter=684us }
Frequency=-804732

You can always specify NTP servers in

/etc/systemd/timesyncd.conf.

I basically uncommented everything that was commented out


Use timedatectl status to see what it is

doing.

timedatectl status
Local time: Wed 2024-04-10 10:29:13 BST
Universal time: Wed 2024-04-10 09:29:13 UTC
RTC time: n/a
Time zone: Europe/London (BST, +0100)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

In order to get this far I had to edit that file and I disabled wlan0 on
the Pi 4.
At some point it started working but doesn't seem to be *regularly*
contacting anything last entry from

$systemctl status systemd-timesyncd.service

Apr 09 21:30:38 Coriolanus systemd-timesyncd[547]: Contacted time server 51.89.151.183:123 (0.debian.pool.ntp.org)


--
“I know that most men, including those at ease with problems of the greatest complexity, can seldom accept even the simplest and most
obvious truth if it be such as would oblige them to admit the falsity of conclusions which they have delighted in explaining to colleagues, which
they have proudly taught to others, and which they have woven, thread by thread, into the fabric of their lives.”

― Leo Tolstoy

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

The Natural Philosopher <tnp@invalid.invalid> wrote:

On 09/04/2024 21:47, druck wrote:

On 09/04/2024 17:00, The Natural Philosopher wrote:

RPI 4B.
Rebooted. Clock wrong.
1hr later, clock still wrong?

Probably due to using systemd-timesyncd which I've never seen actuall working. Install the ntp service and it will work.

Its very very weird.

It is systemd.timesyncd, and it sometimes says it cant connect, and very
very occasionally seems to connect.

Apr 09 20:45:51 Coriolanus systemd-timesyncd[547]: Network configuration changed, trying to establish connection.
Apr 09 20:45:53 Coriolanus systemd-timesyncd[547]: No network
connectivity, watching for changes.
Apr 09 20:45:58 Coriolanus systemd-timesyncd[547]: Network configuration changed, trying to establish connection.
Apr 09 20:46:08 Coriolanus systemd-timesyncd[547]: Timed out waiting for reply from 193.150.34.2:123 (2.debian.pool.ntp.org).
Apr 09 20:46:18 Coriolanus systemd-timesyncd[547]: Timed out waiting for reply from 77.104.162.218:123 (2.debian.pool.ntp.org).
Apr 09 20:46:28 Coriolanus systemd-timesyncd[547]: Timed out waiting for reply from 95.215.175.2:123 (2.debian.pool.ntp.org).
Apr 09 20:55:54 Coriolanus systemd-timesyncd[547]: Network configuration changed, trying to establish connection.
Apr 09 20:55:55 Coriolanus systemd-timesyncd[547]: No network
connectivity, watching for changes.
Apr 09 20:56:00 Coriolanus systemd-timesyncd[547]: Network configuration changed, trying to establish connection.
Apr 09 21:30:38 Coriolanus systemd-timesyncd[547]: Contacted time server 51.89.151.183:123 (0.debian.pool.ntp.org).

That is, it hasn't actually contacted a time server in 12 hours.

And the clock is about 2 seconds out.

I don't think your poblem is with systemd-timesyncd, it's with the
network. You appear to have an unstable connection which is why it
keeps saying "Network configuration changed, trying to establish
connection."

Also that IP address doesn't work for me either:-

chris@bbb$ host 2.debian.pool.ntp.org
2.debian.pool.ntp.org has address 162.159.200.123
2.debian.pool.ntp.org has address 80.87.128.222
2.debian.pool.ntp.org has address 178.62.68.79
2.debian.pool.ntp.org has address 134.0.16.1
2.debian.pool.ntp.org has IPv6 address 2a00:2381:19c6::200
2.debian.pool.ntp.org has IPv6 address 2603:c020:c00d:af00:195:242:99:71
2.debian.pool.ntp.org has IPv6 address 2a0f:85c0::50
2.debian.pool.ntp.org has IPv6 address 2a00:fd80:aaaa:ffff::eeee:ff1
chris@bbb$ host 193.150.34.2
2.34.150.193.in-addr.arpa domain name pointer time.rdg.uk.as44574.net.
chris@bbb$ ping 193.150.34.2
PING 193.150.34.2 (193.150.34.2) 56(84) bytes of data.
^C
--- 193.150.34.2 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8172ms

chris@bbb$

I don't know why your system is trying 162.159.200.123 and not the alternatives, mine seem to find a working IP OK. Is your DNS good?

--
Chris Green
·

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 10/04/2024 at 10:27, The Natural Philosopher wrote:

On 09/04/2024 21:47, druck wrote:

On 09/04/2024 17:00, The Natural Philosopher wrote:

RPI 4B.
Rebooted. Clock wrong.
1hr later, clock still wrong?

Probably due to using systemd-timesyncd which I've never seen actuall
working. Install the ntp service and it will work.

Its very very weird.

It is systemd.timesyncd, and it sometimes says it cant connect, and very
very occasionally seems to connect.

Apr 09 20:45:51 Coriolanus systemd-timesyncd[547]: Network configuration changed, trying to establish connection.
Apr 09 20:45:53 Coriolanus systemd-timesyncd[547]: No network
connectivity, watching for changes.
Apr 09 20:45:58 Coriolanus systemd-timesyncd[547]: Network configuration changed, trying to establish connection.
Apr 09 20:46:08 Coriolanus systemd-timesyncd[547]: Timed out waiting for reply from 193.150.34.2:123 (2.debian.pool.ntp.org).
Apr 09 20:46:18 Coriolanus systemd-timesyncd[547]: Timed out waiting for reply from 77.104.162.218:123 (2.debian.pool.ntp.org).
Apr 09 20:46:28 Coriolanus systemd-timesyncd[547]: Timed out waiting for reply from 95.215.175.2:123 (2.debian.pool.ntp.org).
Apr 09 20:55:54 Coriolanus systemd-timesyncd[547]: Network configuration changed, trying to establish connection.
Apr 09 20:55:55 Coriolanus systemd-timesyncd[547]: No network
connectivity, watching for changes.
Apr 09 20:56:00 Coriolanus systemd-timesyncd[547]: Network configuration changed, trying to establish connection.
Apr 09 21:30:38 Coriolanus systemd-timesyncd[547]: Contacted time server 51.89.151.183:123 (0.debian.pool.ntp.org).

That is, it hasn't actually contacted a time server in 12 hours.

And the clock is about 2 seconds out.

It's one of the many parts of Bookworm I've had to junk and restore
the way I did things in Bullseye.

Yes, bookworm is surpisingly unstable.

If possible Id like to get systemd working properly

---druck

I'd tend to agree with Chris Green - it's a network problem. What's the
default route? Do you have >1 network on the box?

The clock will stay "correct" without time syncronisation for some time.
One thing I do with every new box is run 'fake-hwclock save' every
minute (root crontab) so a reboot gets the nearly correct time immediately.

I've got bookworm running on a Model B Plus Rev 1.2 with no problems
(yet <g>).



--
Chris Elvidge, England
TEACHER IS NOT A LEPER

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

The Natural Philosopher <tnp@invalid.invalid> writes:

And none of this is well documented. As someone remarked about CMAKE, "software that cannot be used because *no one knows how it works*, is useless"

Who remarked that and why? I fairly like cmake but I can't say I've used
it a lot.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 10/04/2024 10:27, The Natural Philosopher wrote:

Yes, bookworm is surpisingly unstable.

The way Bookworm has been set up by default in Raspbian might be, I
certainly don't like it. If you upgrade in place from Bullseye, despite
the warnings, it is rock solid.

If possible Id like to get systemd working properly

The only way systemd will work properly is when the last vestiges of
Linux have been replaced and you boot straight in to SystemD OS.

The best thing to do you don't want to use an alternative init system,
is just use systemd *just* as init system, and turn off all of it's
other tendrils.

---druck

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

T24gMDkvMDQvMjAyNCAyMzozMiwgS251dGUgSm9obnNvbiB3cm90ZToNCj4gT24gNC85LzI0 IDE1OjQ3LCBkcnVjayB3cm90ZToNCj4+IE9uIDA5LzA0LzIwMjQgMTc6MDAsIFRoZSBOYXR1 cmFsIFBoaWxvc29waGVyIHdyb3RlOg0KPj4+IFJQSSA0Qi4NCj4+PiBSZWJvb3RlZC4gQ2xv Y2sgd3JvbmcuDQo+Pj4gMWhyIGxhdGVyLCBjbG9jayBzdGlsbCB3cm9uZz8NCj4+DQo+PiBQ cm9iYWJseSBkdWUgdG8gdXNpbmcgc3lzdGVtZC10aW1lc3luY2Qgd2hpY2ggSSd2ZSBuZXZl ciBzZWVuIGFjdHVhbGwgDQo+PiB3b3JraW5nLiBJbnN0YWxsIHRoZSBudHAgc2VydmljZSBh bmQgaXQgd2lsbCB3b3JrLg0KPj4NCj4+IEl0J3Mgb25lIG9mIHRoZSBtYW55IHBhcnRzIG9m IEJvb2t3b3JtIEkndmUgaGFkIHRvIGp1bmsgYW5kIHJlc3RvcmUgDQo+PiB0aGUgd2F5IEkg ZGlkIHRoaW5ncyBpbiBCdWxsc2V5ZS4NCj4gDQo+IHRpbWVzeW5jZCB3b3JrcyBmaW5lLsKg IE1ha2Ugc3VyZSB0aGF0IHRoZSByb3V0ZSB0byB0aGUgaW50ZXJuZXQgaXNuJ3QgDQo+IGJs b2NrZWQuwqAgVXNlIHRoZSBjb21tYW5kIHRpbWVkYXRlY3RsIHNob3ctdGltZXN5bmMgLS1h bGwgdG8gc2VlIHdoZXJlIA0KPiB0aW1lc3luY2QgaXMgbG9va2luZyBmb3IgdGltZS7CoCBZ b3UgY2FuIGFsd2F5cyBzcGVjaWZ5IE5UUCBzZXJ2ZXJzIGluIA0KPiAvZXRjL3N5c3RlbWQv dGltZXN5bmNkLmNvbmYuwqAgVXNlIHRpbWVkYXRlY3RsIHN0YXR1cyB0byBzZWUgd2hhdCBp dCBpcyANCj4gZG9pbmcuDQoNCk9mIGNvdXJzZSB0aGUgcm91dGUgdG8gdGhlIGludGVybmV0 IGlzbid0IGJsb2NrZWQsIG50cCBhbmQgZXZlcnl0aGluZyANCmVsc2Ugd29ya3MgZmluZS4N Cg0KRXZlbiBpZiBzeXN0ZW1kLXRpbWVzeW5jZCBkaWQgd29yayB0aGVyZSBpcyBubyBnb29k IHJlYXNvbiB0byBoYW5kIG92ZXIgDQpldmVuIG1vcmUgY29udHJvbCBvZiB0aGUgbWFjaGlu ZSB0byB0aGUgaW5zaWRpb3VzIGV4cGFuZGluZyBtZXNzIG9mIA0Kc3lzdGVtZC4gVGhlcmUg YXJlIGFsdGVybmF0aXZlcyB3aGljaCBkbyBvbmUgdGhpbmcgYW5kIG9uZSB0aGluZyB3ZWxs LCANCnN5c3RlbWQgc2hvdWxkIGp1c3Qgc3RpY2sgdG8gYmVpbmcgYW4gaW5pdCBzeXN0ZW0u DQoNCi0tLWRydWNrDQo=

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 4/10/24 15:04, druck wrote:

systemd should just stick to being an init system.

---druck

I don't disagree with that!

--

Knute Johnson

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:

The Natural Philosopher <tnp@invalid.invalid> writes:

And none of this is well documented. As someone remarked about CMAKE,
"software that cannot be used because *no one knows how it works*, is
useless"

Who remarked that and why? I fairly like cmake but I can't say I've used
it a lot.

In my deliberately limited experience building software with CMake,
much of the trouble is that program developers are expected to
write detailed documentation for the build options they use, but
for the software I've compiled they simply haven't. You've got a
wall of options, and usually nothing short of reading source code
to decide what they do and which are important to you. Then it's
more awkward (than with a configure script) to reproduce those
settings if you want to compile a later version the same way.

--
__ __
#_ < |\| |< _#

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 10/04/2024 21:13, druck wrote:

If you upgrade in place from Bullseye, despite the warnings, it is rock solid.

This is my experience on an x86-64 desktop, 2x VMs using x86-64 and 2x
RPi Zero W.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 10/04/2024 11:14, Chris Green wrote:

I don't know why your system is trying 162.159.200.123 and not the alternatives, mine seem to find a working IP OK. Is your DNS good?

No, it wasn't and I am not sure why.

I installed BIND which normally works out of the box.

Its the usual mess of network manager/systemd all fighting to control
something probably.

Yesterday I was getting connection refused on port 53, using the pi's
own IP address in resolv.conf - that is 192.168.0.101


I added a working server on the network, and it sprang to life but when
I tested it with its own address it now seems to work as well.

I just rebooted it and once again, DNS now works???





--
It is the folly of too many to mistake the echo of a London coffee-house
for the voice of the kingdom.

Jonathan Swift

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 09/04/2024 23:32, Knute Johnson wrote:

timesyncd works fine.

Perhaps, but I prefer to run NTP everywhere, even on my Windows PCs.
One management UI, not several. I've seen other issues with bookworm, too.

--
Cheers,
David
Web: https://www.satsignal.eu

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 4/11/24 04:10, The Natural Philosopher wrote:

I installed BIND which normally works out of the box.

I'm curious why you did that and why you didn't mention it in your first
post?

--

Knute Johnson

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 4/11/24 04:36, David Taylor wrote:

On 09/04/2024 23:32, Knute Johnson wrote:

timesyncd works fine.

Perhaps, but I prefer to run NTP everywhere, even on my Windows PCs.
One management UI, not several.  I've seen other issues with bookworm, too.

You can do whatever you want.

--

Knute Johnson

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 11/04/2024 14:46, Knute Johnson wrote:

On 4/11/24 04:10, The Natural Philosopher wrote:

I installed BIND which normally works out of the box.

I'm curious why you did that and why you didn't mention it in your first post?

I had no idea thåt there was a DNS issue. I haven't modified BINDS configuration, but now its *working*.

???

--
Of what good are dead warriors? … Warriors are those who desire battle
more than peace. Those who seek battle despite peace. Those who thump
their spears on the ground and talk of honor. Those who leap high the
battle dance and dream of glory … The good of dead warriors, Mother, is
that they are dead.
Sheri S Tepper: The Awakeners.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 4/11/24 11:21, The Natural Philosopher wrote:

On 11/04/2024 14:46, Knute Johnson wrote:

On 4/11/24 04:10, The Natural Philosopher wrote:

I installed BIND which normally works out of the box.

I'm curious why you did that and why you didn't mention it in your
first post?

I had no idea thåt there was a DNS issue. I haven't modified BINDS configuration, but now its *working*.

???

So I'm still curious, why did you install bind?

--

Knute Johnson

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 11/04/2024 21:49, Knute Johnson wrote:

On 4/11/24 11:21, The Natural Philosopher wrote:

On 11/04/2024 14:46, Knute Johnson wrote:

On 4/11/24 04:10, The Natural Philosopher wrote:

I installed BIND which normally works out of the box.

I'm curious why you did that and why you didn't mention it in your
first post?

I had no idea thåt there was a DNS issue. I haven't modified BINDS
configuration, but now its *working*.

???

So I'm still curious, why did you install bind?

I wanted a proper caching DNS server on my home network. One that I
could use to put local machines on. This PI is to be the house server.
Storage. Media. DNS. TV.

I've always used bind to do that. Usually it just works.


--
“There are two ways to be fooled. One is to believe what isn’t true; the other is to refuse to believe what is true.”

—Soren Kierkegaard

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

The Natural Philosopher <tnp@invalid.invalid> wrote:

On 11/04/2024 21:49, Knute Johnson wrote:

On 4/11/24 11:21, The Natural Philosopher wrote:

On 11/04/2024 14:46, Knute Johnson wrote:

On 4/11/24 04:10, The Natural Philosopher wrote:

I installed BIND which normally works out of the box.

I'm curious why you did that and why you didn't mention it in your
first post?

I had no idea thåt there was a DNS issue. I haven't modified BINDS
configuration, but now its *working*.

???

So I'm still curious, why did you install bind?

I wanted a proper caching DNS server on my home network. One that I
could use to put local machines on. This PI is to be the house server. Storage. Media. DNS. TV.

I've always used bind to do that. Usually it just works.

Yes, I do similar, but with dnsmasq. It used to be on my
desktop/server (permanently on because it's my mail server too) but I
have now moved it to a recently acquired Asus DSL router that runs asuswrt-merlin software.

--
Chris Green
·

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)