windows
windows copied to clipboard
dockur
[Bug]: Error when pausing container: OCI runtime pause failed: timeout of 10s reached on Fedora 40 with Docker Compose
Operating system
Fedora Linux 40 (XFCE)
Description
Following a fresh installation of Windows (and a single reboot), I encounter a problem when attempting to pause the container.
Steps to Reproduce:
- Freshly install the Windows container using the provided
compose.yamlanddocker compose up. - Shut down the Windows container.
- Launch the Windows container using
docker compose start. - Run the command:
docker compose pause.
Expected Behaviour: Windows should pause without any issues.
Actual Behaviour: The following error is displayed:
Error response from daemon: cannot pause container 5bdf7c5c60e4249a69c4fd599f9d5921fa732fa3bcc5f7d8bc09789c4b9674a9: OCI runtime pause failed: timeout of 10s reached waiting for the cgroup to freeze: unknown
Additionally, Windows becomes entirely unresponsive. Attempting to run docker compose unpause produces the error:
Error response from daemon: Container 5bdf7c5c60e4249a69c4fd599f9d5921fa732fa3bcc5f7d8bc09789c4b9674a9 is not paused
Additional Information:
- When using
podman-compose, pausing and resuming Windows works without issues. - My environment details are as follows:
- OS: Fedora 40 (XFCE) amd64
- Kernel version: 6.9.11
- Docker version: 27.1.1 (Build 6312585)
- Docker Compose version: 2.29.1
Thank you for your help!
Docker compose
# For documentation, FAQ, additional configuration options and technical help, visit: https://github.com/dockur/windows
name: "winapps" # Docker Compose Project Name.
volumes:
# Create Volume 'data'.
# Located @ '/var/lib/docker/volumes/winapps_data/_data' (Docker).
# Located @ '/var/lib/containers/storage/volumes/winapps_data/_data' or '~/.local/share/containers/storage/volumes/winapps_data/_data' (Podman).
data:
services:
windows:
image: dockurr/windows # https://hub.docker.com/r/dockurr/windows
container_name: WinApps # Created Docker VM Name.
environment:
# Version of Windows to configure. For valid options, visit:
# https://github.com/dockur/windows?tab=readme-ov-file#how-do-i-select-the-windows-version
# https://github.com/dockur/windows?tab=readme-ov-file#how-do-i-install-a-custom-image
VERSION: "tiny11"
RAM_SIZE: "4G" # RAM allocated to the Windows VM.
CPU_CORES: "4" # CPU cores allocated to the Windows VM.
DISK_SIZE: "64G" # Size of the primary hard disk.
#DISK2_SIZE: "32G" # Uncomment to add an additional hard disk to the Windows VM. Ensure it is mounted as a volume below.
#USERNAME: "Docker" # Uncomment to set a custom Windows username. The default is 'Docker'.
#PASSWORD: "" # Uncomment to set a password for the Windows user. There is no default password.
HOME: "${HOME}" # Set path to Linux user home folder.
privileged: true # Grant the Windows VM extended privileges.
ports:
- 8006:8006 # Map '8006' on Linux host to '8006' on Windows VM --> For VNC Web Interface @ http://127.0.0.1:8006.
- 3389:3389/tcp # Map '3389' on Linux host to '3389' on Windows VM --> For Remote Desktop Protocol (RDP).
- 3389:3389/udp # Map '3389' on Linux host to '3389' on Windows VM --> For Remote Desktop Protocol (RDP).
stop_grace_period: 120s # Wait 120 seconds before sending SIGTERM when attempting to shut down the Windows VM.
restart: on-failure # Restart the Windows VM if the exit code indicates an error.
volumes:
- data:/storage # Mount volume 'data' to use as Windows 'C:' drive.
- ${HOME}:/shared # Mount Linux user home directory @ '\\host.lan\Data'.
#- /path/to/second/hard/disk:/storage2 # Uncomment to mount the second hard disk within the Windows VM. Ensure 'DISK2_SIZE' is specified above.
- ./oem:/oem # Enables automatic post-install execution of 'oem/install.bat', applying Windows registry modifications contained within 'oem/RDPApps.reg'.
- ${HOME}/Win11.iso:/custom.iso # Uncomment to use a custom Windows ISO. If specified, 'VERSION' (e.g. 'tiny11') will be ignored.
devices:
- /dev/kvm # Enable KVM.
#- /dev/sdX:/disk1 # Uncomment to mount a disk directly within the Windows VM (Note: 'disk1' will be mounted as the main drive).
#- /dev/sdY:/disk2 # Uncomment to mount a disk directly within the Windows VM (Note: 'disk2' and higher will be mounted as secondary drives).
Docker log
❯ Starting Windows for Docker v3.12...
❯ For support visit https://github.com/dockur/windows
❯ CPU: 11th Gen Intel Core TM i7 1185G7 | RAM: 26/32 GB | DISK: 195 GB (btrfs) | HOST: 6.9.11-200.fc40.x86_64...
❯ Extracting local ISO image...
❯ Adding drivers to image...
❯ Adding OEM folder to image...
❯ Adding win11x64.xml for automatic installation...
❯ Building Windows 11 image...
❯ Creating a 64G growable disk image in raw format...
❯ Booting Windows using QEMU v8.2.4...
BdsDxe: failed to load Boot0002 "UEFI QEMU QEMU HARDDISK " from PciRoot(0x0)/Pci(0xA,0x0)/Scsi(0x0,0x0): Not Found
BdsDxe: loading Boot0001 "UEFI QEMU QEMU CD-ROM " from PciRoot(0x0)/Pci(0x5,0x0)/Scsi(0x0,0x0)
BdsDxe: starting Boot0001 "UEFI QEMU QEMU CD-ROM " from PciRoot(0x0)/Pci(0x5,0x0)/Scsi(0x0,0x0)
❯ Windows started succesfully, visit http://localhost:8006/ to view the screen...
BdsDxe: loading Boot0004 "Windows Boot Manager" from HD(1,GPT,02021BFB-DEC3-4683-98B0-307D20AF9626,0x800,0x40000)/\EFI\Microsoft\Boot\bootmgfw.efi
BdsDxe: starting Boot0004 "Windows Boot Manager" from HD(1,GPT,02021BFB-DEC3-4683-98B0-307D20AF9626,0x800,0x40000)/\EFI\Microsoft\Boot\bootmgfw.efi
❯ Shutdown completed!
❯ Starting Windows for Docker v3.12...
❯ For support visit https://github.com/dockur/windows
❯ CPU: 11th Gen Intel Core TM i7 1185G7 | RAM: 26/32 GB | DISK: 184 GB (btrfs) | HOST: 6.9.11-200.fc40.x86_64...
❯ Booting Windows using QEMU v8.2.4...
BdsDxe: loading Boot0004 "Windows Boot Manager" from HD(1,GPT,02021BFB-DEC3-4683-98B0-307D20AF9626,0x800,0x40000)/\EFI\Microsoft\Boot\bootmgfw.efi
BdsDxe: starting Boot0004 "Windows Boot Manager" from HD(1,GPT,02021BFB-DEC3-4683-98B0-307D20AF9626,0x800,0x40000)/\EFI\Microsoft\Boot\bootmgfw.efi
❯ Windows started succesfully, visit http://localhost:8006/ to view the screen...
Screenshots (optional)
No response
I suspect this is some bug in Docker, not in this container.
The fact that it works correctly using podman is a big sign of that. So this should be reported to the Docker team.
