[gentoo-user] Who sets the symlink /dev/rtc => /dev/rtc0 ?

[meino....@gmx.de]

Hi,

In the kernel config I set

CONFIG_RTC_HCTOSYS_DEVICE="rtc1"

and I grepped through /etc and looked
for something suspicious...nothing found.

So...which ghost in my system dares to set
the symlink /dev/rtc to point to /dev/rtc0
instead of /dev/rtc1 ???

Any ides?

Best regards,
mcc

[Pavel Volkov]

I bet it's /usr/lib64/udev/rules.d/50-udev-default.rules

[Alan McKinnon]

On 25/08/2013 20:26, meino....@gmx.de wrote:
> Hi,
>
> In the kernel config I set
>
> CONFIG_RTC_HCTOSYS_DEVICE="rtc1"
>
> and I grepped through /etc and looked
> for something suspicious...nothing found.
>
> So...which ghost in my system dares to set
> the symlink /dev/rtc to point to /dev/rtc0
> instead of /dev/rtc1 ???

You say there's a ghost in the machine, and the instant answer "udev"
did not immediately jump into your mind?

tut, tut (such an obvious target) :-)


grep through every file installed by udev for "rtc", let's see what
comes out


--
Alan McKinnon
alan.m...@gmail.com

[Philip Webb]

130825 Pavel Volkov suggested:
> On Sunday 25 August 2013 20:26:32 meino....@gmx.de asked:

>> So...which ghost in my system dares to set the symlink /dev/rtc
>> to point to /dev/rtc0 instead of /dev/rtc1 ???

> I bet it's /usr/lib64/udev/rules.d/50-udev-default.rules

I have /usr/udev/rules.d/50-udev-default.rules (on a 64-bit system),
which contains the lines :

# select "system RTC" or just use the first one
SUBSYSTEM=="rtc", ATTR{hctosys}=="1", SYMLINK+="rtc"
SUBSYSTEM=="rtc", KERNEL=="rtc0", SYMLINK+="rtc", OPTIONS+="link_priority=-100"

However, in /dev I have :

crw------- 1 root root 10, 135 Aug 25 07:39 /dev/rtc

ie it's not a symlink. I'm using udev-204 .

HTH

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

[meino....@gmx.de]

Alan McKinnon <alan.m...@gmail.com> [13-08-26 04:34]:

Hi Alan,

carefully read my posting again.... ;)

Best regards,
mcc

[meino....@gmx.de]

Philip Webb <pur...@ca.inter.net> [13-08-26 04:35]:

Hi,

I finally found the culprit:

There udev-related files under /lib, where I did not search for it.
I had expected them under /etc...
I fixed one of the rules and now there is the correct link.

Nonetheless, ls -l /proc shows:
beagleboneblack:/root>ls -l /proc
total 0
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 1
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 10
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 11
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 12
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 13
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 14
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 15
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 16
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 17
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 18
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 188
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 19
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 196
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 2
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 20
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 21
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 24
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 27
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 3
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 36
dr-xr-xr-x 8 root root 0 2013-08-26 05:12 362
dr-xr-xr-x 8 root root 0 2013-08-26 05:12 363
dr-xr-xr-x 8 root root 0 2013-08-26 05:12 364
dr-xr-xr-x 8 root root 0 2013-08-26 05:12 365
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 38
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 39
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 40
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 41
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 42
dr-xr-xr-x 8 messagebus messagebus 0 2013-08-26 05:12 436
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 45
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 46
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 5
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 53
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 55
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 56
dr-xr-xr-x 8 root root 0 2013-08-26 05:12 612
dr-xr-xr-x 8 root root 0 2013-08-26 05:12 632
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 69
dr-xr-xr-x 8 root root 0 2013-08-26 05:12 698
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 7
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 70
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 71
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 74
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 75
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 76
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 79
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 8
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 80
dr-xr-xr-x 8 root root 0 2013-08-26 05:12 800
dr-xr-xr-x 8 root root 0 2013-08-26 05:12 855
dr-xr-xr-x 8 root root 0 2013-08-26 05:13 882
dr-xr-xr-x 8 root root 0 2013-08-26 05:13 883
dr-xr-xr-x 8 root root 0 2013-08-26 05:13 884
dr-xr-xr-x 8 root root 0 2013-08-26 05:13 885
dr-xr-xr-x 8 root root 0 2013-08-26 05:13 886
dr-xr-xr-x 8 root root 0 2013-08-26 05:13 887
dr-xr-xr-x 8 root root 0 2013-08-26 05:13 896
dr-xr-xr-x 8 root root 0 1970-01-01 01:00 9
dr-xr-xr-x 8 root root 0 2013-08-26 05:13 900
dr-xr-xr-x 8 root root 0 2013-08-26 05:28 917
dr-xr-xr-x 8 root root 0 2013-08-26 05:28 955
dr-xr-xr-x 8 root root 0 2013-08-26 05:28 966
dr-xr-xr-x 4 root root 0 2013-08-26 05:28 asound
-r--r--r-- 1 root root 0 2013-08-26 05:28 buddyinfo
dr-xr-xr-x 3 root root 0 2013-08-26 05:28 bus
-r--r--r-- 1 root root 0 2013-08-26 05:28 cgroups
-r--r--r-- 1 root root 0 2013-08-26 05:28 cmdline
-r--r--r-- 1 root root 26642 2013-08-26 05:28 config.gz
-r--r--r-- 1 root root 0 2013-08-26 05:28 consoles
dr-xr-xr-x 2 root root 0 2013-08-26 05:28 cpu
-r--r--r-- 1 root root 0 2013-08-26 05:28 cpuinfo
-r--r--r-- 1 root root 0 2013-08-26 05:28 crypto
dr-xr-xr-x 12 root root 0 2013-08-26 05:28 device-tree

There are still files stamped with the UNIX's big bang moment.
But the kernel is configured to use rtc1 instead of rtc0.

The journey isn't at its end, still.

ANy further ideas ?

Best regards,
mcc

[William Kenworthy]

Does it make a difference ...? While I can see an advantage for files
that need the correct date to have them, in my experience that for most
files its irrelevant including those in /dev. The Rpi doest care (and
its interesting to see what files the Rpi is actually using as they
update :) - I just use ntp to set the system time and dont seem to have
any problems - so what problem do the older files actually cause?

You could use a "find" command identify then "touch" the files and
update their timestamp once the system is up/before whatever is critical
starts.

BillK

[Alan McKinnon]

It was in /lib/ ?


--
Alan McKinnon
alan.m...@gmail.com

[Alan McKinnon]

Does it really matter ?

Those files with Epoch timestamps are PIDs started very early. They are
probably kernel threads exposed as PIDs anyway, and there's serious
magic going on to make that all work. It all happens after init starts
but before your rtc gets set and ntp starts.

You seem to have accomplished the bits that matter and are now chasing
after other bits that don't. I say it's time to stop and say it's good
enough

Consider this: that cpu has an rtc on-board, it has no battery. Every OS
in existence is going to have the same issue in some form or other, and
yet it doesn't seem to matter as stuff works.


--
Alan McKinnon
alan.m...@gmail.com

[Neil Bothwick]

On Mon, 26 Aug 2013 05:30:12 +0200, meino....@gmx.de wrote:

> There udev-related files under /lib, where I did not search for it.

That's where udev's own rules live.

> I had expected them under /etc...

That's where user rules live.

> I fixed one of the rules and now there is the correct link.

For now. Copy the rule to /etc/ if you don't want it overwritten by the
next udev update.


--
Neil Bothwick

Who messed with my anti-paranoia shot?