Bug 1216468

Summary: Allow the correct time for systemd even in initrd
Product: [openSUSE] openSUSE Distribution Reporter: Ulrich Windl <Ulrich.Windl>
Component: BasesystemAssignee: systemd maintainers <systemd-maintainers>
Status: RESOLVED WORKSFORME QA Contact: E-mail List <qa-bugs>
Severity: Enhancement    
Priority: P5 - None CC: antonio.feijoo
Version: Leap 15.5   
Target Milestone: ---   
Hardware: x86-64   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Ulrich Windl 2023-10-22 17:53:31 UTC
Running the RTC in local time (CEST), the time journald logs is 2 hours ahead until the actual root filesystem was mounted:

...
Okt 22 21:21:16 i7g4x4a systemd[1]: Starting Switch Root...
Okt 22 21:21:16 i7g4x4a haveged[203]: haveged: Couldn't create nammed semaphore haveged_sem error: Function not implemented
Okt 22 21:21:16 i7g4x4a systemd[1]: Switching root.
Okt 22 21:21:16 i7g4x4a systemd-journald[206]: Journal stopped
Okt 22 19:21:21 i7g4x4a systemd-journald[206]: Received SIGTERM from PID 1 (systemd).
Okt 22 19:21:21 i7g4x4a systemd[1]: RTC configured in localtime, applying delta of 120 minutes to system time.
...

Couldn't initrd contain the correct zone information, too (so that the time logged would be correct)?
I noticed this bug when using "journalctl -S 19:4", and the _whole_ journal since boot had been displayed.
Comment 1 Antonio Feijoo 2023-10-23 10:07:59 UTC
(In reply to Ulrich Windl from comment #0)
> Running the RTC in local time (CEST), the time journald logs is 2 hours
> ahead until the actual root filesystem was mounted:

Isn't CEST = UTC+2? Then the right time is logged in the initrd. My question is, what time do you want to configure in the system, UTC or CET/CEST?

> Okt 22 21:21:16 i7g4x4a systemd[1]: Starting Switch Root...
> Okt 22 21:21:16 i7g4x4a haveged[203]: haveged: Couldn't create nammed
> semaphore haveged_sem error: Function not implemented
> Okt 22 21:21:16 i7g4x4a systemd[1]: Switching root.
> Okt 22 21:21:16 i7g4x4a systemd-journald[206]: Journal stopped
> Okt 22 19:21:21 i7g4x4a systemd-journald[206]: Received SIGTERM from PID 1
> (systemd).
> Okt 22 19:21:21 i7g4x4a systemd[1]: RTC configured in localtime, applying
> delta of 120 minutes to system time.

Is value "LOCAL" in /etc/adjtime? If so, running `timedatectl` should display the following warning, which explains the problem quite well.

```
RTC in local TZ: yes

Warning: The system is configured to read the RTC time in the local time zone.
         This mode cannot be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.
```

If you want your system and initrd in UTC:
```
$ timedatectl set-local-rtc 0
$ timedatectl set-timezone UTC
```
Comment 2 Ulrich Windl 2023-10-24 20:52:10 UTC
(In reply to Antonio Feijoo from comment #1)
This is what I have:

# cat /etc/adjtime 
0.0 0 0.0
0
LOCAL
# timedatectl 
               Local time: Di 2023-10-24 22:45:41 CEST
           Universal time: Di 2023-10-24 20:45:41 UTC
                 RTC time: Di 2023-10-24 22:45:41
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
              NTP service: inactive
          RTC in local TZ: yes

As the system uses dual-boot (Windows/Linux), and Windows could only handle localtime in the past, the time is set to local time in BIOS/RTC.

According to https://superuser.com/q/975717 it's still a mess.
Comment 3 Antonio Feijoo 2023-10-25 08:38:35 UTC
(In reply to Ulrich Windl from comment #2)
> As the system uses dual-boot (Windows/Linux), and Windows could only handle
> localtime in the past, the time is set to local time in BIOS/RTC.

Hmm... I see on the systemd code that this is done on purpose only after switching root. After digging into the code history I can find an old commit (https://github.com/systemd/systemd/commit/19e65613) with some explanation: 

/*
 * Do dummy first-time call to seal the kernel's time warp magic
 *
 * Do not call this this from inside the initrd. The initrd might not
 * carry /etc/adjtime with LOCAL, but the real system could be set up
 * that way. In such case, we need to delay the time-warp or the sealing
 * until we reach the real system.
 */

Which led me to the dracut's `warpclock` module. Could you try adding it to the initrd and reboot after that?

$ dracut -f -a warpclock
Comment 4 Ulrich Windl 2023-11-04 00:42:52 UTC
(In reply to Antonio Feijoo from comment #3)
> Which led me to the dracut's `warpclock` module. Could you try adding it to
> the initrd and reboot after that?
> 
> $ dracut -f -a warpclock

I tried it, and it worked:
...
Nov 04 01:24:28 i7g4x4a kernel: PM: RTC time: 01:24:28, date: 2023-11-04
...
Nov 04 01:24:28 i7g4x4a systemd[1]: RTC configured in localtime, applying delta of 60 minutes to system time.
...
Nov 04 01:24:39 i7g4x4a systemd[1]: System is tainted: local-hwclock
...
Nov 04 01:24:40 i7g4x4a systemd[1]: Switching root.
Nov 04 01:24:40 i7g4x4a haveged[204]: haveged: Couldn't create nammed semaphore haveged_sem error: Function not implemented
Nov 04 01:24:40 i7g4x4a systemd-journald[208]: Journal stopped
Nov 04 01:24:45 i7g4x4a systemd-journald[208]: Received SIGTERM from PID 1 (systemd).
Nov 04 01:24:45 i7g4x4a systemd[1]: RTC configured in localtime, applying delta of 60 minutes to system time.
Nov 04 01:24:45 i7g4x4a systemd[1]: systemd 249.16+suse.195.gb473c02cc0 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR -IMA -SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +>
Nov 04 01:24:45 i7g4x4a systemd[1]: Detected architecture x86-64.
...
Comment 5 Antonio Feijoo 2023-11-06 07:16:29 UTC
(In reply to Ulrich Windl from comment #4)
> (In reply to Antonio Feijoo from comment #3)
> > Which led me to the dracut's `warpclock` module. Could you try adding it to
> > the initrd and reboot after that?
> > 
> > $ dracut -f -a warpclock
> 
> I tried it, and it worked:

Glad to hear that, so let's close this bug. I'm not sure about the closing status, but I'd say that "worksforme" is good enough.