Unable to run SQL Server 2017 container with colima v0.7.5

### Description

A container created from `mcr.microsoft.com/mssql/server:2017-latest` crashes during startup. Using colima v0.6.8, the container runs without issues.

### Version

colima version 0.7.5
git commit: 1588c066b9ab9dae8205ef265929c7eb43dca473

runtime: docker
arch: aarch64
client: v27.2.1
server: v27.1.1
limactl version 0.23.2
qemu-img version 9.1.0
Copyright (c) 2003-2024 Fabrice Bellard and the QEMU Project developers

### Operating System

- [ ] macOS Intel <= 13 (Ventura)
- [ ] macOS Intel >= 14 (Sonoma)
- [ ] Apple Silicon <= 13 (Ventura)
- [X] Apple Silicon >= 14 (Sonoma)
- [ ] Linux

### Output of `colima status`

INFO[0000] colima is running using macOS Virtualization.Framework
INFO[0000] arch: aarch64
INFO[0000] runtime: docker
INFO[0000] mountType: virtiofs
INFO[0000] socket: unix:///Users/markuskeil/.colima/default/docker.sock

### Reproduction Steps

1. `colima delete`
2. `colima start --arch aarch64 --vm-type=vz --vz-rosetta --edit`
3. Edit the config yaml (because sqlserver is resource hungry)
- set `cpu: 4` (for good measure)
- set `memory: 4` (see notes below)
4. `docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=1Secure*Password1" -p 1433:1433 -d mcr.microsoft.com/mssql/server:2017-latest`

**Result**
The container crashes
> /usr/bin/timeout: failed to run command '/bin/journalctl': No such file or directory

Increasing the memory (step 3) appeared to fully fix the issue. But the error still appears on a regular basis (roughly estimated about 50% of the time) with no clear pattern.

### Expected behaviour

The container should start up without issues.

### Additional context

**Increasing memory settings**

Running the container with **colima v0.6.8** (inspired from #1043) and default memory settings did not work because of this error
> sqlservr: This program requires a machine with at least 2000 megabytes of memory.

After setting `memory: 4` in colima.yaml the container started without issues.
This setting appeared to fix this issue in v0.7.5 as well (I assumed that the error message was simply misleading) but after a few retries I am back to the same faulty behavior.

**Container log**
```
SQL Server 2017 will run as non-root by default.
This container is running as user root.
To learn more visit https://go.microsoft.com/fwlink/?linkid=2099216.
This program has encountered a fatal error and cannot continue running at Fri Sep 13 09:02:15 2024
The following diagnostic information is available:

Reason: 0x00000001
Signal: SIGABRT - Aborted (6)
Stack:
IP Function
---------------- --------------------------------------
00005555556a749c
00005555556a6ee2
00005555556a64f1
00007ffffcd2af10 killpg+0x40
00007ffffcd2ae87 gsignal+0xc7
00007ffffcd2c7f1 abort+0x141
000055555562de42
00005555556b4cb4
00005555556e81f8
00005555556e7fda
0000555555639cba
000055555563990f
Process: 9 - sqlservr
Thread: 79 (application thread 0x12c)
Instance Id: 720156bf-13f2-4a3f-86e1-2da26a1edffe
Crash Id: 511ff9f4-e842-438b-b939-10c81013bf5b
Build stamp: a061e85be3fdd5c8d55a05c62bda0b9e1d6d267f3cac4d70d78ec1a9a6f57be0
Distribution: Ubuntu 18.04.6 LTS
Processors: 2
Total Memory: 2054893568 bytes
Timestamp: Fri Sep 13 09:02:15 2024
Last errno: 2
Last errno text: No such file or directory
Capturing a dump of 9
FAILED to capture a dump. Details in paldumper log.
Executing: /opt/mssql/bin/handle-crash.sh with parameters
handle-crash.sh
/opt/mssql/bin/sqlservr
9
/opt/mssql/bin
/var/opt/mssql/log/

720156bf-13f2-4a3f-86e1-2da26a1edffe
511ff9f4-e842-438b-b939-10c81013bf5b

Ubuntu 18.04.6 LTS
Capturing core dump and information to /var/opt/mssql/log...
dmesg: read kernel buffer failed: Operation not permitted
/usr/bin/timeout: failed to run command '/bin/journalctl': No such file or directory
/usr/bin/timeout: failed to run command '/bin/journalctl': No such file or directory
Fri Sep 13 09:02:18 UTC 2024 Capturing program information
Fri Sep 13 09:02:19 UTC 2024 Attempting to capture a dump with paldumper for pid 9
WARNING: Capture attempt failure detected
Attempting to capture a filtered dump with paldumper for pid 9
WARNING: Attempt to capture dump failed. Reference /var/opt/mssql/log/core.sqlservr.9.temp/log/paldumper-debug.log for details
Fri Sep 13 09:02:19 UTC 2024 Attempting to capture a dump with gdb
WARNING: Unable to capture crash dump with GDB. You may need to
allow ptrace debugging, enable the CAP_SYS_PTRACE capability, or
run as root. See log in: /var/opt/mssql/log/core.sqlservr.9.temp/log/gdb.log
Fri Sep 13 09:02:19 UTC 2024 Capturing program binaries
Fri Sep 13 09:02:20 UTC 2024 Not compressing the dump files, moving instead to: /var/opt/mssql/log/core.sqlservr.09_13_2024_09_02_15.9.d
```

**Other SQL Server versions**

`2019-latest` and `2022-latest` run without any trouble.