UI for customizing QEMU -rtc option.

[trustin]

UTM currently adds -rtc base=localtime option automatically. It'd be nice if there's a configuration UI that allows a user specify other RTC options. More specifically, when running Linux guests, it makes sense to specify -rtc base=utc by default.

[brunocastello]

I also generally use -rtc base=localtime,clock=host when using vanilla QEMU. Being able to customize it would be good. Sometimes the clock is behind the host clock by a few minutes...

[wolfo]

It also would be handy for running Beta versions of OS's that expired on a certain date. I have added -rtc base=2000-05-05 in the extra QEMU arguments which, oddly enough, worked yesterday, but is now again superceded by the earlier automatic rtc base=localtime.

It would also be helpful if you could import a qemu string just like you can currently export it.

[ktprograms]

@osy There was a user on the Discord yesterday who was having problems installing Alpine Linux because of the date/time being incorrect, and Alpine not using NTP if running in QEMU.

The solution that was found was to run service hwclock start to enable using the RTC to set system time. However, the problem with that is the time will initially be the user's local time, but in UTC timezone, which is incorrect. For example, if my local time is 10:00 am, and I'm in UTC+8, when I start the hwclock service and check the time, it shows (rephrasing, forgot the date output format) 10:00 UTC. When I then set the timezone inside the VM to UTC+8, the time shown is 18:00 UTC+8, which is wrong.

This happens because the QEMU arguments contains -rtc base=localtime, which is incorrect. The QEMU man page states that base=localtime should only be needed on Windows hosts.

QEMU -rtc argument documentation

-rtc [base=utc|localtime|date][,clock=host|vm][,driftfix=none|slew]
Specify base as "utc" or "localtime" to let the RTC start at the current UTC or local time, respectively. "localtime" is required for correct date in MS-DOS or Windows. To start at a specific point in time, provide date in the format "2006-06-17T16:01:21" or "2006-06-17". The default base is UTC.
By default the RTC is driven by the host system time. This allows using of the RTC as accurate reference clock inside the guest, specifically if the host time is smoothly following an accurate external reference clock, e.g. via NTP. If you want to isolate the guest time from the host, you can set clock to "rt" instead. To even prevent it from progressing during suspension, you can set it to "vm".
Enable driftfix (i386 targets only) if you experience time drift problems, specifically with Windows' ACPI HAL. This option will try to figure out how many timer interrupts were not processed by the Windows guest and will re-inject them.

I asked about this on the #alpine-linux channel on OFTC IRC (log attached below), and the consensus is that base=utc should be used. Because base=utc is the default, I suggest omitting the -rtc argument completely, to allow users to customise it if they need to, without chance of a conflict.

IRC Log, See conversation between ktprograms, minimal and psykose

2022-02-18 02:24:56 <ktprograms> Hi, is "rc-service <service> start" asynchronous? (Does it return before the service has fully started?)
2022-02-18 02:25:15 <psykose> it returns as soon as the start() function returns
2022-02-18 02:25:37 <psykose> i would guess
2022-02-18 02:25:38 <raven523> the service might not actually be ready yet to perform its functions
2022-02-18 02:25:41 <ktprograms> Sometimes when running setup-alpine on certain systems (VMs), setup-apkrepos has a certificate error, I'm wondering if it's because the date/time isn't fully initialized yet
2022-02-18 02:25:42 <psykose> yep
2022-02-18 02:25:43 <psykose> no readyness
2022-02-18 02:25:50 <psykose> it can be
2022-02-18 02:25:51 <ktprograms> psykose: raven523: I see, thanks
2022-02-18 02:26:02 <psykose> but if you use chrony, it should block until time is set
2022-02-18 02:26:11 <psykose> and without rc_parallel, anything after it should be fine
2022-02-18 02:26:15 <psykose> since only one service starts
2022-02-18 02:26:21 <ktprograms> Should I test by adding a "sleep 10" to the end of setup-ntp?
2022-02-18 02:26:28 <psykose> well
2022-02-18 02:26:34 <psykose> you could just use chrony
2022-02-18 02:26:40 <psykose> or a vm time syncing solution
2022-02-18 02:26:47 <psykose> or figure out how to make default ntpd block
2022-02-18 02:26:48 <psykose> or something
2022-02-18 02:29:11 <ktprograms> Oh I just remembered what's the problem. setup-ntp isn't called if running in qemu, and the QEMU configuration being used doesn't set rtc time properly, so ntp is needed.
2022-02-18 02:29:31 <psykose> i would set up the configuration
2022-02-18 02:31:25 <ktprograms> psykose: agreed, but it's a VM app (https://github.com/utmapp/UTM), and so far customizing the rtc option hasn't been implemented.
2022-02-18 02:31:34 <ktprograms> psykose: What do you recommend it should be set to?
2022-02-18 02:31:48 <psykose> ah, then no idea
2022-02-18 02:31:56 <psykose> i would figure out how to run whatever ntp thing correctly
2022-02-18 02:32:53 <ktprograms> The problem is here[0], I remember asking about this a few months back when I first tried out Alpine, and iirc the response was because this isn't neccessary on properly set up qemu VMs. [0]: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-alpine.in#L189
2022-02-18 02:33:43 <ktprograms> psykose: The option used is "-rtc base=localtime". Does that seem correct?
2022-02-18 02:34:12 <psykose> this is setup-alpine, you can still invoke setup-ntp yourself
2022-02-18 02:34:14 <psykose> and uhh, no idea
2022-02-18 02:35:35 <ktprograms> psykose: The trouble is that you need networking set up before running setup-ntp, and then if you re-run setup-alpine, when it gets to the setup-networking step it suggests a static IP instead of dhcp
2022-02-18 02:37:35 <psykose> want a really pro solution
2022-02-18 02:37:49 <psykose> sed -i "someshitinsetupalpine" setupalpine; setup-alpine
2022-02-18 02:38:01 <psykose> and remove the qemu checks
2022-02-18 02:38:02 <psykose> :p
2022-02-18 02:38:22 <ktprograms> could be as simple as removing the '!' in the if
2022-02-18 02:38:30 <psykose> it's annoying there's no toggle for it, but you could also do setup-alpine; setup-ntp after
2022-02-18 02:38:31 <psykose> oh
2022-02-18 02:38:32 <psykose> right
2022-02-18 02:38:34 <psykose> apkrepos is in it
2022-02-18 02:38:34 <psykose> nvbm
2022-02-18 02:38:53 <ktprograms> But the problem is it's not very easy to type, and UTM is used on things like iPads so copy paste isn't an option
2022-02-18 02:39:01 <psykose> yep
2022-02-18 02:42:23 <ktprograms> psykose: Do you think adding ",clock=host" to the rtc configuration would help?
2022-02-18 02:42:59 <ktprograms> Or should the "is qemu" check be removed since people can just answer "none" if they don't want ntp?
2022-02-18 02:43:17 <minimal> ktprograms: do you have either of "hwclock" or "osclock" init.d services enabled?
2022-02-18 02:43:31 <psykose> clock=host should work by the sound of it
2022-02-18 02:44:26 <ktprograms> minimal: I'll check, it's just a boot with the default standard ISO
2022-02-18 02:47:15 <ktprograms> minimal: The started services (listed with rc-status) doesn't have hwclock or osclock. The list is sysfs, fsck, root, localmount, firstboot
2022-02-18 02:47:53 <ktprograms> Is it expected that it starts when booting from the ISO?
2022-02-18 02:48:10 <minimal> ktprograms: "-rtc base=localtime" as a QEMU option would make sense if you're running Qemu on a Windows machine (as typically they set the RTC to localtime not UTC)
2022-02-18 02:48:31 <ktprograms> minimal: It's a Mac host
2022-02-18 02:48:49 <minimal> ok, not sure which MacOS sets RTC to
2022-02-18 02:48:54 <ktprograms> But I'm not in UTC, should it still be base=UTC?
2022-02-18 02:48:59 <ktprograms> minimal: Any way to check?
2022-02-18 02:50:07 <psykose> it depends on the rtc, not whatever system time
2022-02-18 02:50:10 <psykose> just boot with both
2022-02-18 02:50:16 <psykose> if it's the wrong one the time will be fucked up
2022-02-18 02:50:22 <psykose> offset by some hours
2022-02-18 02:52:16 <minimal> I assume the Mac has something similar to "hwclock" to check the time
2022-02-18 02:53:48 <ktprograms> psykose: On a fresh boot from the ISO, it thinks it's in Nov 5 2021. If I run "service hwclock start", then it seemingly gets the correct time.
2022-02-18 02:54:05 <ktprograms> minimal: Not sure. Do you mean time from the rtc or what?
2022-02-18 02:54:46 <psykose> then the hwclock works
2022-02-18 02:54:57 <psykose> you could just start it then run setup-alpine
2022-02-18 02:54:58 <psykose> :)
2022-02-18 02:55:18 <ktprograms> psykose: Yep, thanks
2022-02-18 02:55:28 <ktprograms> Is it supposed to start by itself?
2022-02-18 02:55:32 <ktprograms> (the service)
2022-02-18 02:55:39 <psykose> by default neither that nor swclock is enabled
2022-02-18 02:56:00 <psykose> not everything has a hwclock, swclock has.. issues, or something
2022-02-18 02:56:07 <ktprograms> psykose: I see. ig it's hard to detect which (if any) should be used
2022-02-18 02:56:08 <psykose> someone that knows more can walk you through the finer points
2022-02-18 02:56:23 <psykose> but since it's qemu, i would assume for hwclock to always work
2022-02-18 02:57:01 <ktprograms> psykose: Yes, I would hope so
2022-02-18 02:57:14 <minimal> Mac seems to use UTC like Linux
2022-02-18 02:57:42 <ktprograms> minimal: Does that mean it should be "-rtc base=UTC" ?
2022-02-18 02:58:13 <minimal> ktprograms: re hwclock/swclock/osclock,well it depends on whether you expect to have NTP syncing or not
2022-02-18 02:58:46 <ktprograms> I see
2022-02-18 02:59:06 <minimal> ktprograms: according to Qemu manpage, "The default base is UTC"
2022-02-18 02:59:37 <minimal> swclock is only intended for machines with no RTC (like Raspberry Pis)
2022-02-18 02:59:52 <ktprograms> minimal: Does the part about "base=localtime" should be used for correct date on Windows refer to a Windows host or guest?
2022-02-18 03:00:34 <minimal> osclock (which doesn't actually do anything) is intended for machines expecting to have continuous access to NTP
2022-02-18 03:01:17 <minimal> ktprograms: that's referring to the host machine
2022-02-18 03:01:51 <ktprograms> minimal: So if this VM software is only meant to run on i*OS and macOS, it should just always be "-rtc base=UTC"?
2022-02-18 03:02:44 <ktprograms> Will it break any guests? I noticed that with "base=localtime", when I start hwclock it has the local time but with UTC timezone, which is wrong.
2022-02-18 03:03:12 <minimal> well the manpage says "-rtc base=utc" is the default (i.e. if you do not specify any "-rtc" value)
2022-02-18 03:03:41 <ktprograms> minimal: And default _should_ be correct most of the time?
2022-02-18 03:04:24 <minimal> ktprogram: the Alpine timezone is set by setup-timezone (strangely enough) ;-)
2022-02-18 03:04:32 <minimal> well should be called by setup-alpine
2022-02-18 03:05:42 <minimal> ktprogram: the default is correct for Linux and Mac hosts (unless you've purposely changed their RTC to something other than UTC) but not for Windows hosts
2022-02-18 03:05:47 <ktprograms> Yes, but if the hwclock is set to <host time> UTC, and you set the timezone, then the time will show up as <host time + offset from UTC>
2022-02-18 03:07:37 <psykose> that is how it normally works?
2022-02-18 03:07:40 <ktprograms> minimal: Look at https://0x0.st/o8yK.png
2022-02-18 03:07:49 <ktprograms> psykose: Yes, but then it has the wrong date/time
2022-02-18 03:07:59 <psykose> is your host UTC
2022-02-18 03:08:08 <ktprograms> +8
2022-02-18 03:08:10 <psykose> ah
2022-02-18 03:08:11 <psykose> then yes
2022-02-18 03:08:12 <psykose> in this case
2022-02-18 03:08:14 <psykose> whatever you have set
2022-02-18 03:08:15 <psykose> is wrong
2022-02-18 03:08:19 <psykose> and you want the other one
2022-02-18 03:08:31 <ktprograms> That's why the QEMU rtc base should be UTC
2022-02-18 03:08:32 <psykose> UTC should be 3 am in that picture, in the vm
2022-02-18 03:08:36 <psykose> yeah
2022-02-18 03:08:39 <psykose> and that should be the default
2022-02-18 03:08:46 <ktprograms> the adding 8 hours should be done by the VM and not QEMU
2022-02-18 03:08:48 <psykose> i assume that picture is base=localtime?
2022-02-18 03:08:55 <ktprograms> psykose: yes
2022-02-18 03:08:56 <psykose> yes
2022-02-18 03:08:58 <psykose> so, don't do that
2022-02-18 03:09:04 <psykose> keep it at the default (=UTC_
2022-02-18 03:09:08 <psykose> and that picture should become correct
2022-02-18 03:09:09 <ktprograms> ok time to make a PR to UTM
2022-02-18 03:09:09 <psykose> :)
2022-02-18 03:09:18 <psykose> ah, right
2022-02-18 03:09:18 <ktprograms> If I keep it at the default, is the -rtc argument needed?
2022-02-18 03:09:32 <psykose> nope, unless you want to make it explicitly 'documented'
2022-02-18 03:09:38 <psykose> sometimes i leave the defaults out, sometimes i leave them in
2022-02-18 03:09:39 <psykose> shrug
2022-02-18 03:09:48 <minimal> confused - you're Mac is UTC+8 and you want your Alpine VM to be UTC rather than UTC+8?
2022-02-18 03:10:11 <psykose> yeah
2022-02-18 03:10:20 <psykose> so it's only the 'same' as the host if you also set +8 in the vm
2022-02-18 03:10:25 <psykose> i believe that is correct generally
2022-02-18 03:10:27 <ktprograms> minimal: No, I want the VM to be also UTC+8, but when I start the hwclock before setting the timezone, then the date is <host time> but at UTC timezone
2022-02-18 03:10:29 <psykose> and not setting utc=host
2022-02-18 03:10:30 <minimal> sorry, clarification: your Mac is set to timezone that is UTC+8?
2022-02-18 03:10:33 <psykose> yes
2022-02-18 03:10:55 <ktprograms> minimal: So when you set the timezone the offset is added to the date, which makes it wrong (the second date in the picture)
2022-02-18 03:11:41 <minimal> why are you setting timezone AFTER hwclock?
2022-02-18 03:13:21 <minimal> "date" shows your time taking your timezone into consideration, "date -u" shows you time in UTC timezone regardless of timezone setting
2022-02-18 03:14:23 <ktprograms> minimal: Because the simplest for a user to do is to start hwclock then run "setup-alpine", which calls "setup-timezone"
2022-02-18 03:14:55 <ktprograms> minimal: Nevermind, I think the correct thing is to use base=utc
2022-02-18 03:17:51 <minimal> ktprograms: base=utc is the default so if you did not specify any "-rtc" option then you are already using it
2022-02-18 03:19:18 <ktprograms> minimal: Yes, but like I said earlier, UTM sets base=localtime. Given what has been found here, I think just removing the rtc option and letting it use the default should be correct. Thanks
2022-02-18 03:19:38 <minimal> can't comment on UTM as don't have a Mac
2022-02-18 03:19:54 <ktprograms> minimal: that's fine, it's basically just a UI wrapper to qemu
2022-02-18 03:21:01 <minimal> krprograms: Linux typically stores the time internally as UTC, the timezone setting is only used by the system (i.e. things like "date") to display it in the local time
2022-02-18 03:21:32 <ktprograms> minimal: Right, thanks
2022-02-18 03:22:16 <minimal> so you need to ensure that "date -u" show the correct UTC time for now, then sort out the timezone which will then ensure that "date" shows the correct local time
2022-02-18 03:22:31 <ktprograms> minimal: Yup, that's what I gathered. Thanks!
2022-02-18 03:23:24 <minimal> re: hwclock / osclock - as I said the decision relates as to whether NTP sync will be active all/most of the time or not
2022-02-18 03:23:44 <ktprograms> minimal: I doubt it will be because setup-alpine skips it
2022-02-18 03:25:13 <minimal> typically the linux-virt kernel (for a x86/x86_64 VM) will be configured so that the kernel during initialisation will set the system clock from the RTC and then once NTP sync is achieved for the system clock the kernel will approx every 11mins then sync the RTC with the system clock
2022-02-18 03:25:51 <ktprograms> minimal: I see. That explains why it works with the Virt ISO but not the Standard one
2022-02-18 03:26:34 <minimal> krprograms: the above still applies if neither hwclock nor osclock is enabled (osclock doesn't actually anything except satisfy other init.d service dependancy on "clock")
2022-02-18 03:27:09 <minimal> ktprograms: linux-lts kernel should act in the same way, I was focusing on linux-virt as you're running a VM
2022-02-18 03:29:40 <ktprograms> minimal: Hmm interesting. Not sure why the time isn't set then
2022-02-18 03:29:50 <ktprograms> It's aarch64 btw
2022-02-18 03:30:24 <minimal> linux-lts or linux-virt aarch kernel?
2022-02-18 03:30:33 <ktprograms> linux-lts (standard iso)
2022-02-18 03:32:12 <minimal> EFI/UEFI?
2022-02-18 03:32:23 <ktprograms> yes
2022-02-18 03:36:32 <minimal> well CONFIG_RTC_HCTOSYS=y and CONFIG_RTC_SYSTOHC=y appear to be enabled in kernel config, they enable to RTC->System clock at boot and the System clock->RTC at 11 min intervals (*once* NTP sync has occurred)
2022-02-18 03:37:32 <minimal> ah! CONFIG_RTC_DRV_EFI=m
2022-02-18 03:38:01 <minimal> that looks like the problem, that's the EFI/UEFI RTC driver as a module, its not built into the kernel
2022-02-18 03:38:19 <ktprograms> I see
2022-02-18 03:38:57 <minimal> so the kernel sets System clock from RTC when it initialises - but if the RTC driver is a loadable module then it is not loaded until after kernel initialises
2022-02-18 03:39:10 <minimal> and so kernel does not set System clock from RTC
2022-02-18 03:39:21 <ktprograms> And that's why manually using hwclock is needed?
2022-02-18 03:39:44 <minimal> well that's one thing that hwclock init.d will do
2022-02-18 03:41:02 <minimal> try doing a "dmesg | grep rtc" so see what happened during boot
2022-02-18 03:42:15 <ktprograms> rtc-efi seems to have set system clock to the correct time (<host time> UTC, that's just a problem with the "base=localtime"
2022-02-18 03:42:27 <ktprograms> minimal: I'm just summarizing, do you want a screenshot?
2022-02-18 03:42:57 <ktprograms> But date shows some time in Nov 5 2021
2022-02-18 03:44:08 <minimal> ktprograms: the first part of dmesg output is a time offset from when the kernel started, so how many seconds does it show for the "setting system time" entry
2022-02-18 03:45:46 <ktprograms> minimal: 5.3
2022-02-18 03:47:01 <minimal> yeah, so 5.3 seconds from kernel init whereas on a machine I'm looking at here its set 0.5 seconds from kernel init
2022-02-18 03:47:37 <ktprograms> minimal: Is it also from "rtc-efi rtc-efi.0" ?
2022-02-18 03:51:57 <minimal> its 5.3 seconds as that's how long it took kernel to initialise, to load and run initramfs, mount rootfs, start openrc, the modules init.d service to load rtc-efi etc (assuming rtc-efi is not included in the initramfs)
2022-02-18 04:06:43 <ktprograms> minimal: I see, thanks
2022-02-18 04:08:48 <minimal> it probably isn't a concern to you but if you want the time to be set as early as possible so that logs etc are accurate then the driver needs to be built into the kernel
2022-02-18 04:09:28 <ktprograms> minimal: I don't think that's a big concern. What I'm more wondering is why the date output is so wrong before starting hwclock, even though dmesg shows the correct time
2022-02-18 04:12:17 <minimal> your earlier screenshot made no sense as the difference is 3+ months, its not a timezone difference as the minute values don't align
2022-02-18 04:13:17 <Aftershock> wow it really just has my ip in there lol
2022-02-18 04:13:25 <psykose> it wasn't, it was feb18 on both (after hwclock started)
2022-02-18 04:13:36 <psykose> before hwclock it was fucked up for sure
2022-02-18 04:13:58 <psykose> as for dmesg, that hasn't been posted, so no idea
2022-02-18 04:14:00 <psykose> could i see it
2022-02-18 04:14:19 <ktprograms> minimal: New screenshot, including dmesg: https://0x0.st/o8yj.png
2022-02-18 04:14:43 <ktprograms> The time shown in dmesg is correct (or as correct as it can be with base=localtime, ignore the timezone)
2022-02-18 04:15:54 <minimal> that's showing almost exactly the same date/time as the earlier screenshot
2022-02-18 04:16:12 <ktprograms> minimal: The output of the date command is crazy
2022-02-18 04:16:25 <minimal> like its some default value set during boot/VM initialisation
2022-02-18 04:16:27 <psykose> i think rtc-efi failed to set the time
2022-02-18 04:16:38 <psykose> or there is some other thing after that that sets it again
2022-02-18 04:17:32 <ktprograms> psykose: I don't see anything implying it failed to set the time
2022-02-18 04:17:48 <psykose> you could post the whole dmesg, but i doubt there's anything in there
2022-02-18 04:19:06 <ktprograms> psykose: Do you want me to post it? I looked through it and I don't see anything important
2022-02-18 04:19:30 <psykose> sure
2022-02-18 04:19:39 <psykose> as a general rule nobody complains about more logs :)
2022-02-18 04:19:53 <psykose> even if they are mostly empty and don't show the issue
2022-02-18 04:20:13 <minimal> ktprograms: is this run-from-ram Alpine install or Sys-mode?
2022-02-18 04:20:57 <psykose> var/log/messages too i guess, just in case
2022-02-18 04:23:03 <ktprograms> minimal: booting the ISO
2022-02-18 04:23:16 <minimal> right, so run-from-ram then
2022-02-18 04:24:02 <minimal> ok, right after a boot can you run "ls -l /lib/rc/cache/" ?
2022-02-18 04:25:07 <ktprograms> dmesg: https://tpaste.us/YEK6
2022-02-18 04:25:35 <ktprograms> /var/log/messages: https://tpaste.us/5nBx
2022-02-18 04:26:16 <ktprograms> minimal: no such file or directory
2022-02-18 04:27:16 <minimal> ok, then "ls -l /run/openrc"
2022-02-18 04:33:47 <minimal> krprograms: I think the output of the above will confirm what I suspect is the problem
2022-02-18 04:34:58 <psykose> don't you want the tree of run/openrc, or something other than top-level
2022-02-18 04:35:09 <minimal> "ls -l /run/openrc"
2022-02-18 04:35:22 <minimal> just that
2022-02-18 04:37:08 <minimal> the /var/log/messages is confirming what I already suspected
2022-02-18 04:46:09 <minimal> ktprograms: still around?
2022-02-18 04:47:28 <minimal> psykose: think he's gone
2022-02-18 04:48:34 <minimal> so what I am suspecting is that after he boots the file /run/openrc/deptree will be timestamped as Nov 5 11:17
2022-02-18 04:50:32 <Aftershock> has anyone used diskless mode? I am running alpine on a pi and I don't think I set it up quite right. Can I just use /etc/fstab to mount a persistent /var and /etc? Or is there a specific way that data disk needs to be setup.
2022-02-18 04:51:08 <minimal> as he's running from RAM then I suspect the APKOVERLAY file (or whatever its called that's managed by lbu) contains a deptree file with this timestamp and its copied to /run/openrc. On a disk-install (Sys-mode) this file is copied from /lib/rc/cache/deptree
2022-02-18 05:30:00 <ktprograms> Sorry, had to make lunch
2022-02-18 05:30:59 <ktprograms> /run/openrc/deptree is timestamped Nov 21 2021, whereas date says Nov 5 2021
2022-02-18 05:31:58 <ktprograms> It seems the 3.15 ISOs were created on Nov 24 2021, is that related?
<snip>
2022-02-18 14:04:59 <minimal> ktprograms: the "clock skew" messages in your logs are an indication that openrc is changing the system clock date/time during boot to Nov 2021, and then later in boot the efi rtc drive loads and date/time is changed again using RTC and so is then accurate - you can see in the time changing of the timestamps of the log entries you provided

2022-02-18 14:09:21 <ktprograms> minimal: I see, but why does date show the wrong time?

2022-02-18 14:14:33 <minimal> because OpenRC i setting the system clock using the date of a file when it first starts. I have seen this before on a RPI which has no RTC - the machine's system clock defaults to a date/time in 1970, then when OpenRC starts it sets system clock to the date/time of the /lib/rc/cache/deptree file and displays a "clock skew" warning. The /run/openrc/deptree file is created as a duplicate of the other deptree file

2022-02-18 14:15:47 <minimal> then when you shutdown the machine the date/time of the /lib/rc/cache/deptree file is updated to the current date/time of the system clock (on the assumption that NTP has since run to make the system clock accurate) so that the revised date/time of this file will be used on next boot

2022-02-18 14:16:40 <minimal> as you are booting off an ISO (using run-from-ram) then the date/time of that file (or its alternative) cannot be updated and so every time you boot sets the date/time to the same Nov value

2022-02-18 14:16:57 <minimal> its meant to be a OpenRC "feature" for systems without a RTC

2022-02-18 14:18:02 <minimal> whilst your system does have an RTC its handled by a loadable kernel module which is loaded AFTER OpenRC starts. If it was built into the kernel then the system clock would be set from RTC BEFORE OpenRC starts and you would not be seeing this date/time strangeness

2022-02-18 15:39:35 <ktprograms> minimal: Thanks, makes a lot of sense.

2022-02-18 15:40:08 <ktprograms> So in this case starting the hwclock service before running setup-alpine is correct?

2022-02-18 15:40:38 <minimal> ktprograms: so I assume the Nov 5 2021 date related to a file on the ISO timestamped shortly before the Alpine 3.15.0 release

2022-02-18 15:42:02 <minimal> ktprograms: you'll still have the system clock changing at different stages during boot and seeing the "clock skew" messages which are openrc complaining about the time changing

2022-02-18 15:45:04 <minimal> ktprograms: are you always booting the VM using the ISO or are you booting the VM from the ISO once to then use setup-alpine to install alpine onto a (VM) disk?

Can you please help to add this change (less work for both of us than making a PR)? Thanks!

[adespoton]

Related to #3124