Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Rick Thomas]

On Mon, Feb 22, 2021, at 2:45 AM, Leigh Brown wrote:
> Hi Rick,
... 
> Take a look at the following. No soldering required, and they fit in the
> case nicely (for Pi4 at least).
> 
> Adafruit PiRTC - PCF8523 Real Time Clock for Raspberry Pi
> (https://www.adafruit.com/product/3386)
> 
> Adafruit PiRTC - Precise DS3231 Real Time Clock for Raspberry Pi
> (https://www.adafruit.com/product/4282)

I've ordered one of the high precision modules from adafruit.  It looks like it 
will fit inside the case and hence be protected from accidental damage or 
exposure to the elements.

I'll report back when I've got it installed.

Thanks for the pointers!
Rick

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Leigh Brown]

Hi Rick,

On 2021-02-21 21:58, Rick Thomas wrote:

On Sun, Feb 21, 2021, at 11:49 AM, Reco wrote:

On Sun, Feb 21, 2021 at 02:36:52PM -0500, Alan Corey wrote:
> That's why when you get a real time you adjust the times on your logged
> events.  There's the time you got the time fix, everything else is N
> microseconds before that back to when you started recording. So you record
> back to  minus .

Yup. But by the time you get this "real time" you have other processes
(rpc.gssd, for instance) which already have managed to communicate 
with

someone (KDC), and are in the wrong state (krb5 time difference).

RTC solves this, "fake RTC" (i.e. storing a timestamp on reboot) 
solves

it to some extent, but nothing else does.

Reco


My goal is to replace my aging sheevaplug with something more modern.
The sheevaplug exists for the purpose of providing network services
(in particular, for the purposes of this discussion, NTP) to the 20 or
so computers on my home LAN.  To do that, it needs to have a reliable
source of accurate time (to a few tens of milliseconds) as soon after
boot as possible.

The machine I'd like to use is a Raspberry Pi4B or a Pi0W.  But
without an RTC it won't do the job.

Hence, I'm looking for an RTC module that can be easily added to a
Pi4B or Pi0W with minimal (ideally none) soldering, and with Debian
kernel support.  If the module also does GPS, so much the better!  But
that's not strictly necessary.  It would be very nice if it fits
inside the existing case for the Pi4B.

Do any of the devices that folks have mentioned here fit that bill?


Take a look at the following. No soldering required, and they fit in the
case nicely (for Pi4 at least).

Adafruit PiRTC - PCF8523 Real Time Clock for Raspberry Pi
(https://www.adafruit.com/product/3386)

Adafruit PiRTC - Precise DS3231 Real Time Clock for Raspberry Pi
(https://www.adafruit.com/product/4282)

Regards,

Leigh.

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Reco]

Hi.

On Sun, Feb 21, 2021 at 01:58:08PM -0800, Rick Thomas wrote:
> Hence, I'm looking for an RTC module that can be easily added to a
> Pi4B or Pi0W with minimal (ideally none) soldering, and with Debian
> kernel support.  If the module also does GPS, so much the better!  But
> that's not strictly necessary.  It would be very nice if it fits
> inside the existing case for the Pi4B.
> 
> Do any of the devices that folks have mentioned here fit that bill?

DS1307 has in-tree kernel module that works. A minor problem is that
Debian does not build it - #958904.

And if soldering is not your cup of tea - look for so-called Breakout
Board Kit, like that one - [1].

[1] https://www.amazon.com/DS1307-Real-Clock-Breakout-Board/dp/B00NAY199E

Reco

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[oregano]

February 21, 2021 7:12 AM, "Rick Thomas"  wrote:

> Since one of my goals is to run this as an NTP server, I was somewhat 
> surprised to note that
> "hwclock" didn't work (Missing driver, maybe?) :
> root@pi:~# hwclock --verbose --show
> hwclock from util-linux 2.33.1
> System Time: 1613889592.600667
> Trying to open: /dev/rtc0
> Trying to open: /dev/rtc
> Trying to open: /dev/misc/rtc
> No usable clock interface found.
> hwclock: Cannot access the Hardware Clock via any known method.


FYI, for next purchase, maybe. Pine A64+ board had a couple options for RTC 
battery attachments and for battery backup. On Bullseye/sid, that command is 
working. Thanks for helping me feel I didn't waste a few dollars on that 
option. :)

# hwclock --verbose --show
hwclock from util-linux 2.36.1
System Time: 1613958480.577164
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1612997502 seconds after 1969
Last calibration done at 1612997502 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2021/02/22 01:48:03
Hw clock time : 2021/02/22 01:48:03 = 1613958483 seconds since 1969
Time since last adjustment is 960981 seconds
Calculated Hardware Clock drift is 0.00 seconds
2021-02-21 20:48:01.547366-05:00

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Rick Thomas]

On Sun, Feb 21, 2021, at 11:49 AM, Reco wrote:
> On Sun, Feb 21, 2021 at 02:36:52PM -0500, Alan Corey wrote:
> > That's why when you get a real time you adjust the times on your logged
> > events.  There's the time you got the time fix, everything else is N
> > microseconds before that back to when you started recording. So you record
> > back to  minus .
> 
> Yup. But by the time you get this "real time" you have other processes
> (rpc.gssd, for instance) which already have managed to communicate with
> someone (KDC), and are in the wrong state (krb5 time difference).
> 
> RTC solves this, "fake RTC" (i.e. storing a timestamp on reboot) solves
> it to some extent, but nothing else does.
> 
> Reco

My goal is to replace my aging sheevaplug with something more modern.  The 
sheevaplug exists for the purpose of providing network services (in particular, 
for the purposes of this discussion, NTP) to the 20 or so computers on my home 
LAN.  To do that, it needs to have a reliable source of accurate time (to a few 
tens of milliseconds) as soon after boot as possible.

The machine I'd like to use is a Raspberry Pi4B or a Pi0W.  But without an RTC 
it won't do the job.

Hence, I'm looking for an RTC module that can be easily added to a Pi4B or Pi0W 
with minimal (ideally none) soldering, and with Debian kernel support.  If the 
module also does GPS, so much the better!  But that's not strictly necessary.  
It would be very nice if it fits inside the existing case for the Pi4B.

Do any of the devices that folks have mentioned here fit that bill?

Thanks!
Rick

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Gene Heskett]

On Sunday 21 February 2021 09:20:07 Jeffrey Walton wrote:

> On Sun, Feb 21, 2021 at 8:58 AM Reco  wrote:
> > Hi.
> >
> > On Sun, Feb 21, 2021 at 08:42:45AM -0500, Alan Corey wrote:
> > > I guess a question is why you want an RTC. If you have a decent
> > > internet connection just run NTP on something and it will set the
> > > computer's clock.
> >
> > IPSec, Tor, sec=krb5* NFS mounts.
>
> And anything related to X.509.
>
> In the old days of cell phones, back when you needed a SIM card to get
> time from the network, you had to jump through hoops to use a
> non-provisioned device for development.
>
> I think things have gotten better since then. I don't recall seeing
> clock problems on unprovisioned devices in a while.
>
> > At least these four things are badly screwed if Debian OS lacks
> > access to RTC. Systemd manages to launch those before NTP-based time
> > synchronization kicks in, which leads to funny things to say the
> > least.
>
> This may be a Systemd bug.
>
> > And last, but not least, having working RTC leads to meaningful
> > timestamps in log files that describe "early boot" (i.e. before NTP
> > time sync kicks in), and that's valuable to me by itself.
>
> Jeff

And I try to make it easy on the level2 servers (most distro 
naintained "pool.ntp.org" site that supply the net since I have 5 or 6 
machines running mostly 24/7, I've configured my router to rebroadcast 
on my local, not accessable home network. So that makes this router a 
level 17 server and all the rest of my boxes get time well wihin 5 
milliseconds of ntp. But to the level2 servers in the typical pool, I am 
just one client.

Since its a free service but they still have to pay for the bandwidth, 
and electricity to run them, it makes sense to cut the bytes used if you 
can.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Reco]

On Sun, Feb 21, 2021 at 02:36:52PM -0500, Alan Corey wrote:
> That's why when you get a real time you adjust the times on your logged
> events.  There's the time you got the time fix, everything else is N
> microseconds before that back to when you started recording. So you record
> back to  minus .

Yup. But by the time you get this "real time" you have other processes
(rpc.gssd, for instance) which already have managed to communicate with
someone (KDC), and are in the wrong state (krb5 time difference).

RTC solves this, "fake RTC" (i.e. storing a timestamp on reboot) solves
it to some extent, but nothing else does.

Reco

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Alan Corey]

That's why when you get a real time you adjust the times on your logged
events.  There's the time you got the time fix, everything else is N
microseconds before that back to when you started recording. So you record
back to  minus .

On Sun, Feb 21, 2021, 12:47 PM Reco  wrote:

> On Sun, Feb 21, 2021 at 12:19:31PM -0500, Alan Corey wrote:
> > I think it's unreasonable to expect that kind of time accuracy from the
> > first microsecond of bootup.  Relative accuracy maybe, by counting cycles
> > of a crystal oscillator and storing events in some buffer.  Then once you
> > have a good time reference write them all out to permanent storage by
> doing
> > the arithmetic to assign real times to those events.
>
> The kernel itself does exactly this.
> But what does it tell the kernel about the "right" time in the rest of
> the world (i.e. - any other host)? Exactly nothing.
>
> End result - you can measure whatever happens during the boot just fine,
> but you start 1st Jan 1970 0:00 each boot.
>
> You see, the problem is not the timekeeping, it's the setting
> more-or-less the same time on different systems.
>
> Reco
>
>

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Reco]

On Sun, Feb 21, 2021 at 12:19:31PM -0500, Alan Corey wrote:
> I think it's unreasonable to expect that kind of time accuracy from the
> first microsecond of bootup.  Relative accuracy maybe, by counting cycles
> of a crystal oscillator and storing events in some buffer.  Then once you
> have a good time reference write them all out to permanent storage by doing
> the arithmetic to assign real times to those events.

The kernel itself does exactly this.
But what does it tell the kernel about the "right" time in the rest of
the world (i.e. - any other host)? Exactly nothing.

End result - you can measure whatever happens during the boot just fine,
but you start 1st Jan 1970 0:00 each boot.

You see, the problem is not the timekeeping, it's the setting
more-or-less the same time on different systems.

Reco

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Alan Corey]

I think it's unreasonable to expect that kind of time accuracy from the
first microsecond of bootup.  Relative accuracy maybe, by counting cycles
of a crystal oscillator and storing events in some buffer.  Then once you
have a good time reference write them all out to permanent storage by doing
the arithmetic to assign real times to those events.

On Sun, Feb 21, 2021, 11:24 AM Reco  wrote:

> Hi.
>
> On Sun, Feb 21, 2021 at 06:10:08PM +0200, Andrei POPESCU wrote:
> > On Du, 21 feb 21, 09:20:07, Jeffrey Walton wrote:
> > > On Sun, Feb 21, 2021 at 8:58 AM Reco  wrote:
> > > > On Sun, Feb 21, 2021 at 08:42:45AM -0500, Alan Corey wrote:
> > > > > I guess a question is why you want an RTC. If you have a decent
> > > > > internet connection just run NTP on something and it will set the
> > > > > computer's clock.
> > > >
> > > > IPSec, Tor, sec=krb5* NFS mounts.
> > >
> > > And anything related to X.509.
> > >
> > > In the old days of cell phones, back when you needed a SIM card to get
> > > time from the network, you had to jump through hoops to use a
> > > non-provisioned device for development.
> > >
> > > I think things have gotten better since then. I don't recall seeing
> > > clock problems on unprovisioned devices in a while.
> > >
> > > > At least these four things are badly screwed if Debian OS lacks
> access
> > > > to RTC. Systemd manages to launch those before NTP-based time
> > > > synchronization kicks in, which leads to funny things to say the
> least.
> > >
> > > This may be a Systemd bug.
> >
> > I'd say it's up to each daemon to declare its dependencies in the
> > service file.
>
> The problem here is "started NTPd != time sync". Lack of internet
> connectivity, slow to start 1st stratum time source (GNSS cold start can
> take several minutes), misconfiugured resolver - it all will lead to the
> problem described above.
>
> And it's perfectly understandable why systemd does not have
> "time-synced.target" state. To have it it needs to magically deduce
> correct time somehow :)
>
> So no, it's not a bug per se, but an unimplementable restriction, and it
> cannot be solved by introducing everyone's dependency on ntpd. Besides,
> if your platform provides RTC (and most do) - it's a problem that should
> not arise at the first place.
>
>
> > The problems are likely also much less visible for systems that are
> > always on as systemd-timesyncd will quite quickly advance the clock on
> > reboots based on a time stamp saved during shutdown.
>
> And again - started systemd-timesyncd != synced time. The only
> difference with proper ntpd is that systemd-timestynced uses only one
> source of correct time - another NTP server.
>
> Reco
>
>

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Reco]

Hi.

On Sun, Feb 21, 2021 at 06:10:08PM +0200, Andrei POPESCU wrote:
> On Du, 21 feb 21, 09:20:07, Jeffrey Walton wrote:
> > On Sun, Feb 21, 2021 at 8:58 AM Reco  wrote:
> > > On Sun, Feb 21, 2021 at 08:42:45AM -0500, Alan Corey wrote:
> > > > I guess a question is why you want an RTC. If you have a decent
> > > > internet connection just run NTP on something and it will set the
> > > > computer's clock.
> > >
> > > IPSec, Tor, sec=krb5* NFS mounts.
> > 
> > And anything related to X.509.
> > 
> > In the old days of cell phones, back when you needed a SIM card to get
> > time from the network, you had to jump through hoops to use a
> > non-provisioned device for development.
> > 
> > I think things have gotten better since then. I don't recall seeing
> > clock problems on unprovisioned devices in a while.
> > 
> > > At least these four things are badly screwed if Debian OS lacks access
> > > to RTC. Systemd manages to launch those before NTP-based time
> > > synchronization kicks in, which leads to funny things to say the least.
> > 
> > This may be a Systemd bug.
> 
> I'd say it's up to each daemon to declare its dependencies in the 
> service file.

The problem here is "started NTPd != time sync". Lack of internet
connectivity, slow to start 1st stratum time source (GNSS cold start can
take several minutes), misconfiugured resolver - it all will lead to the
problem described above.

And it's perfectly understandable why systemd does not have
"time-synced.target" state. To have it it needs to magically deduce
correct time somehow :)

So no, it's not a bug per se, but an unimplementable restriction, and it
cannot be solved by introducing everyone's dependency on ntpd. Besides,
if your platform provides RTC (and most do) - it's a problem that should
not arise at the first place.


> The problems are likely also much less visible for systems that are 
> always on as systemd-timesyncd will quite quickly advance the clock on 
> reboots based on a time stamp saved during shutdown.

And again - started systemd-timesyncd != synced time. The only
difference with proper ntpd is that systemd-timestynced uses only one
source of correct time - another NTP server.

Reco

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Andrei POPESCU]

On Du, 21 feb 21, 09:20:07, Jeffrey Walton wrote:
> On Sun, Feb 21, 2021 at 8:58 AM Reco  wrote:
> > On Sun, Feb 21, 2021 at 08:42:45AM -0500, Alan Corey wrote:
> > > I guess a question is why you want an RTC. If you have a decent
> > > internet connection just run NTP on something and it will set the
> > > computer's clock.
> >
> > IPSec, Tor, sec=krb5* NFS mounts.
> 
> And anything related to X.509.
> 
> In the old days of cell phones, back when you needed a SIM card to get
> time from the network, you had to jump through hoops to use a
> non-provisioned device for development.
> 
> I think things have gotten better since then. I don't recall seeing
> clock problems on unprovisioned devices in a while.
> 
> > At least these four things are badly screwed if Debian OS lacks access
> > to RTC. Systemd manages to launch those before NTP-based time
> > synchronization kicks in, which leads to funny things to say the least.
> 
> This may be a Systemd bug.

I'd say it's up to each daemon to declare its dependencies in the 
service file.

The problems are likely also much less visible for systems that are 
always on as systemd-timesyncd will quite quickly advance the clock on 
reboots based on a time stamp saved during shutdown.

Kind regard,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Jeffrey Walton]

On Sun, Feb 21, 2021 at 8:58 AM Reco  wrote:
>
> Hi.
>
> On Sun, Feb 21, 2021 at 08:42:45AM -0500, Alan Corey wrote:
> > I guess a question is why you want an RTC. If you have a decent
> > internet connection just run NTP on something and it will set the
> > computer's clock.
>
> IPSec, Tor, sec=krb5* NFS mounts.

And anything related to X.509.

In the old days of cell phones, back when you needed a SIM card to get
time from the network, you had to jump through hoops to use a
non-provisioned device for development.

I think things have gotten better since then. I don't recall seeing
clock problems on unprovisioned devices in a while.

> At least these four things are badly screwed if Debian OS lacks access
> to RTC. Systemd manages to launch those before NTP-based time
> synchronization kicks in, which leads to funny things to say the least.

This may be a Systemd bug.

> And last, but not least, having working RTC leads to meaningful
> timestamps in log files that describe "early boot" (i.e. before NTP time
> sync kicks in), and that's valuable to me by itself.

Jeff

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Reco]

Hi.

On Sun, Feb 21, 2021 at 08:42:45AM -0500, Alan Corey wrote:
> I guess a question is why you want an RTC. If you have a decent
> internet connection just run NTP on something and it will set the
> computer's clock.

IPSec, Tor, sec=krb5* NFS mounts.

At least these four things are badly screwed if Debian OS lacks access
to RTC. Systemd manages to launch those before NTP-based time
synchronization kicks in, which leads to funny things to say the least.


And last, but not least, having working RTC leads to meaningful
timestamps in log files that describe "early boot" (i.e. before NTP time
sync kicks in), and that's valuable to me by itself. 

Reco

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Alan Corey]

I guess a question is why you want an RTC.  If you have a decent
internet connection just run NTP on something and it will set the
computer's clock.  If you have a cell phone install the Termux app and
then NTP under that, that can be your local NTP clock.

I looked into it a little years ago when I had only a part time dial
up connection.  There is a time signal on GPS satellites with about 1
microsecond accuracy, it's how a GPS works, by triangulation.  But
then I got my first cell phone which got me both internet and an
accurate time.  And now I tether one to a Pi with a USB cable and it's
a wifi AP for the whole house.


On 2/21/21, Reco  wrote:
>   Hi.
>
> On Sun, Feb 21, 2021 at 02:26:26AM -0800, Rick Thomas wrote:
>> On Sat, Feb 20, 2021, at 11:14 PM, Reco wrote:
>> >Hi.
>> >
>> > On Sat, Feb 20, 2021 at 10:53:18PM -0800, Rick Thomas wrote:
>> > > root@pi:~# ls -l /dev/rtc*
>> > > ls: cannot access '/dev/rtc*': No such file or directory
>> > >
>> > > What package should I file a bug report against for this problem?
>> >
>> > There's nothing to report. No model of Raspberry PI has RTC, so this is
>> > expected.
>>
>> Hmmm... A little googling turns up a GPS hat from Adafruit which fits
>> the Pi4B.  It can double as both a battery backed hardware clock and
>> an NMEA-PPS source for ntp, which would be very cool.  Cost is about
>> $40 which is well within the budget for this project.
>
> Way too expensive. A battery-backed DS1307 chip will cost you $4-5 on
> Amazon *and* will do the same as far as RTC is concerned.
>
> Of course, if you absolutely need GNSS that's different. Separate GNSS
> UART connected chip cost me $20 - a certain Neoway G7.
>
> And yes, you can attach both to your RPi.
>
> Reco
>
>


-- 
-
Education is contagious.

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Reco]

Hi.

On Sun, Feb 21, 2021 at 02:26:26AM -0800, Rick Thomas wrote:
> On Sat, Feb 20, 2021, at 11:14 PM, Reco wrote:
> > Hi.
> > 
> > On Sat, Feb 20, 2021 at 10:53:18PM -0800, Rick Thomas wrote:
> > > root@pi:~# ls -l /dev/rtc*
> > > ls: cannot access '/dev/rtc*': No such file or directory
> > > 
> > > What package should I file a bug report against for this problem?
> > 
> > There's nothing to report. No model of Raspberry PI has RTC, so this is
> > expected.
> 
> Hmmm... A little googling turns up a GPS hat from Adafruit which fits
> the Pi4B.  It can double as both a battery backed hardware clock and
> an NMEA-PPS source for ntp, which would be very cool.  Cost is about
> $40 which is well within the budget for this project.

Way too expensive. A battery-backed DS1307 chip will cost you $4-5 on
Amazon *and* will do the same as far as RTC is concerned.

Of course, if you absolutely need GNSS that's different. Separate GNSS
UART connected chip cost me $20 - a certain Neoway G7.

And yes, you can attach both to your RPi.

Reco

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Alan Corey]

Price sounds high, look around a little.  This is a GPS clock module?  The
bare module is in the $5 range I think, I have a few.  Mine came from dx.com

On Sun, Feb 21, 2021, 5:42 AM Rick Thomas  wrote:

> On Sat, Feb 20, 2021, at 11:14 PM, Reco wrote:
> >   Hi.
> >
> > On Sat, Feb 20, 2021 at 10:53:18PM -0800, Rick Thomas wrote:
> > > root@pi:~# ls -l /dev/rtc*
> > > ls: cannot access '/dev/rtc*': No such file or directory
> > >
> > > What package should I file a bug report against for this problem?
> >
> > There's nothing to report. No model of Raspberry PI has RTC, so this is
> > expected.
>
> Hmmm... A little googling turns up a GPS hat from Adafruit which fits the
> Pi4B.  It can double as both a battery backed hardware clock and an
> NMEA-PPS source for ntp, which would be very cool.  Cost is about $40 which
> is well within the budget for this project.
>
> Thanks for the encouragement!
> Rick
>
>

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Rick Thomas]

On Sat, Feb 20, 2021, at 11:14 PM, Reco wrote:
>   Hi.
> 
> On Sat, Feb 20, 2021 at 10:53:18PM -0800, Rick Thomas wrote:
> > root@pi:~# ls -l /dev/rtc*
> > ls: cannot access '/dev/rtc*': No such file or directory
> > 
> > What package should I file a bug report against for this problem?
> 
> There's nothing to report. No model of Raspberry PI has RTC, so this is
> expected.

Hmmm... A little googling turns up a GPS hat from Adafruit which fits the Pi4B. 
 It can double as both a battery backed hardware clock and an NMEA-PPS source 
for ntp, which would be very cool.  Cost is about $40 which is well within the 
budget for this project.

Thanks for the encouragement!
Rick

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Reco]

Hi.

On Sat, Feb 20, 2021 at 10:53:18PM -0800, Rick Thomas wrote:
> root@pi:~# ls -l /dev/rtc*
> ls: cannot access '/dev/rtc*': No such file or directory
> 
> What package should I file a bug report against for this problem?

There's nothing to report. No model of Raspberry PI has RTC, so this is
expected.

Reco