You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Virtualization.framework does not provide an RTC device as /dev/rtc when a VM is booted using a Linux kernel image.
When booted from a disk image, rtc-efi is available as /dev/rtc0:
$ limactl create --name debug template://ubuntu-24.04 \ --set '.mounts |= [{"location":"{{.Dir}}/log","mountPoint":"/var/log","writable": true}] + .' \ --tty=false --log-level=warn3.50 GiB / 3.50 GiB [---------------------------------------] 100.00% 1.63 GiB/s
$ limactl start debug --log-level=warn
$ head -1 ~/.lima/debug/log/kern.log 2024-11-14T02:26:21.879392+00:00 lima-debug kernel: Booting Linux on physical CPU 0x0000000000 [0x610f0000]
$ grep rtc ~/.lima/debug/log/kern.log2024-11-14T02:26:21.879850+00:00 lima-debug kernel: rtc-efi rtc-efi.0: registered as rtc02024-11-14T02:26:21.879850+00:00 lima-debug kernel: rtc-efi rtc-efi.0: setting system clock to 2024-11-14T02:26:16 UTC (1731551176)
However, when booting with a kernel image, no RTC devices (such as rtc-efi) are present, so the Linux kernel begins counting from the time configured at build:
The system clock remains inaccurate until systemd-timesyncd.service synchronizes with an NTP server.
Known Issues Resulting from Lack of /dev/rtc0
Delayed NTP Synchronization: The time required for systemd-timesyncd.service to sync with an NTP server in the background can be lengthy—up to 30 seconds in some cases. If curl or apt-get install is executed in the foreground before synchronization completes, certificate validation fails, resulting in errors:
[ 6.489211] cloud-init[770]: + curl -fsSL https://get.docker.com[ 6.558633] cloud-init[770]: curl: (60) SSL certificate problem: certificate is not yet valid[ 6.558703] cloud-init[770]: More details here: https://curl.se/docs/sslcerts.html[ 6.558761] cloud-init[770]: curl failed to verify the legitimacy of the server and therefore could not[ 6.558834] cloud-init[770]: establish a secure connection to it. To learn more about this situation and[ 6.558926] cloud-init[770]: how to fix it, please visit the web page mentioned above.[ 6.559955] cloud-init[770]: LIMA 2024-08-08T23:51:16+09:00| WARNING: Failed to execute /mnt/lima-cidata/provision.system/00000002[ 6.561851] cloud-init[770]: LIMA 2024-08-08T23:51:16+09:00| Executing /mnt/lima-cidata/provision.user/00000003 (as user norio)[�[0;32m OK �[0m] Started �[0;1;39msession-c1.scope�[0m - Session c1 of User norio.[ 6.584176] cloud-init[770]: + command -v jq[ 6.584344] cloud-init[770]: + sudo apt-get install --assume-yes jq[ 6.723919] cloud-init[770]: Reading package lists...[ 6.725890] cloud-init[770]: Building dependency tree...[ 6.726179] cloud-init[770]: Reading state information...[ 6.726716] cloud-init[770]: E: Unable to locate package jq[ 6.728593] cloud-init[770]: LIMA 2024-08-08T23:51:16+09:00| WARNING: Failed to execute /mnt/lima-cidata/provision.user/00000003 (as user norio)
Guest Agent Time Synchronization Failure: fixSystemTimeSkew() in pkg/guestagent/guestagent_linux.go fails, preventing the guest OS from adjusting the time.
Using a kernel image for booting allows specifying kernel command-line arguments, which has proven beneficial, e.g., in QEMU-based workarounds (#2541). Therefore, ensuring the system works as expected under these configurations is essential.
The text was updated successfully, but these errors were encountered:
Using a kernel image for booting allows specifying kernel command-line arguments, which has proven beneficial, e.g., in QEMU-based workarounds (#2541). Therefore, ensuring the system works as expected under these configurations is essential.
So using kernel image is required only for qemu, but this issue is a about vz. Do we have a use case for using kernel image with vz?
2. Guest Agent Time Synchronization Failure: fixSystemTimeSkew() in pkg/guestagent/guestagent_linux.go fails, preventing the guest OS from adjusting the time.
Do you know why this fails? Can we fix this instead of waiting for NTP?
Description
The Virtualization.framework does not provide an RTC device as
/dev/rtc
when a VM is booted using a Linux kernel image.When booted from a disk image,
rtc-efi
is available as/dev/rtc0
:However, when booting with a kernel image, no RTC devices (such as
rtc-efi
) are present, so the Linux kernel begins counting from the time configured at build:Reference: https://developer.apple.com/forums/thread/760344
The system clock remains inaccurate until
systemd-timesyncd.service
synchronizes with an NTP server.Known Issues Resulting from Lack of
/dev/rtc0
Delayed NTP Synchronization: The time required for
systemd-timesyncd.service
to sync with an NTP server in the background can be lengthy—up to 30 seconds in some cases. Ifcurl
orapt-get install
is executed in the foreground before synchronization completes, certificate validation fails, resulting in errors:Guest Agent Time Synchronization Failure:
fixSystemTimeSkew()
inpkg/guestagent/guestagent_linux.go
fails, preventing the guest OS from adjusting the time.Using a kernel image for booting allows specifying kernel command-line arguments, which has proven beneficial, e.g., in QEMU-based workarounds (#2541). Therefore, ensuring the system works as expected under these configurations is essential.
The text was updated successfully, but these errors were encountered: