|
Bugzilla – Full Text Bug Listing |
| Summary: | Allow the correct time for systemd even in initrd | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Ulrich Windl <Ulrich.Windl> |
| Component: | Basesystem | Assignee: | 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
(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 ``` (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. (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 (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. ... (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. |