rimelek
(Ákos Takács)
April 12, 2025, 9:38pm
2
Seems to be related
Just upgraded to Mac Desktop 4.33 and on our Apple Silicon machines containers we have based on the official Microsoft Azure SQL Edge image (https://hub.docker.com/r/microsoft/azure-sql-edge ) have stopped working. They worked fine in 4.32.
We can reproduce this by simply trying to run the base image and we receive this error:
2024-08-07 20:00:00 22:17:52.39 Server Successfully initialized the TLS configuration. Allowed TLS protocol versions are ['1.0 1.1 1.2']. Allowed TLS ciphers are ['E…
There is a GitHub issue link in the post but I share it here too
opened 11:12AM - 29 Jul 24 UTC
area/kernel
version/4.33.0
### Description
With the new Update V.4.33., the Vms started but after a few se… conds, they stopped.
### Reproduce
1 - Go to Dashboard
2- Start VM
### Expected behavior
_No response_
### docker version
```bash
Server: Docker Desktop 4.33.0 (160616)
Engine:
Version: 27.1.1
API version: 1.46 (minimum version 1.24)
Go version: go1.21.12
Git commit: cc13f95
Built: Tue Jul 23 19:57:14 2024
OS/Arch: linux/arm64
Experimental: false
containerd:
Version: 1.7.19
GitCommit: 2bf793ef6dc9a18e00cb12efb64355c2c9d5eb41
runc:
Version: 1.7.19
GitCommit: v1.1.13-0-g58aa920
docker-init:
Version: 0.19.0
GitCommit: de40ad0
```
### docker info
```bash
Capturing a dump of 10
2024-07-29 12:04:06 FAILED to capture a dump. Details in paldumper log.
2024-07-29 12:04:06 Executing: /opt/mssql/bin/handle-crash.sh with parameters
2024-07-29 12:04:06 handle-crash.sh
2024-07-29 12:04:06 /opt/mssql/bin/sqlservr
2024-07-29 12:04:06 10
2024-07-29 12:04:06 /opt/mssql/bin
2024-07-29 12:04:06 /var/opt/mssql/log/
2024-07-29 12:04:06
2024-07-29 12:04:06 17b1af70-a127-43ea-8108-952937bef880
2024-07-29 12:04:06 50073ca4-e466-455e-b8d7-e9aad4518627
2024-07-29 12:04:06
2024-07-29 12:04:06
2024-07-29 12:04:06
2024-07-29 12:04:06 Ubuntu 18.04.6 LTS
2024-07-29 12:04:07 Capturing core dump and information to /var/opt/mssql/log...
2024-07-29 12:04:12 Mon Jul 29 11:04:12 UTC 2024 Capturing program information
2024-07-29 12:04:13 Mon Jul 29 11:04:13 UTC 2024 Attempting to capture a dump with paldumper for pid 10
2024-07-29 12:04:14 WARNING: Capture attempt failure detected
2024-07-29 12:04:14 Attempting to capture a filtered dump with paldumper for pid 10
2024-07-29 12:04:14 WARNING: Attempt to capture dump failed. Reference /var/opt/mssql/log/core.sqlservr.10.temp/log/paldumper-debug.log for details
2024-07-29 12:04:14 Mon Jul 29 11:04:14 UTC 2024 Attempting to capture a dump with gdb
2024-07-29 12:04:14 Mon Jul 29 11:04:14 UTC 2024 Captured a dump with gdb
2024-07-29 12:04:14 Mon Jul 29 11:04:14 UTC 2024 Capturing program binaries
2024-07-29 12:04:16 Mon Jul 29 11:04:16 UTC 2024 Not compressing the dump files, moving instead to: /var/opt/mssql/log/core.sqlservr.07_29_2024_11_04_06.10.d
2024-07-29 12:04:06 This program has encountered a fatal error and cannot continue running at Mon Jul 29 11:04:06 2024
2024-07-29 12:04:06 The following diagnostic information is available:
2024-07-29 12:04:06
2024-07-29 12:04:06 Reason: 0x00000001
2024-07-29 12:04:06 Signal: SIGABRT - Aborted (6)
2024-07-29 12:04:06 Stack:
2024-07-29 12:04:06 IP Function
2024-07-29 12:04:06 ---------------- --------------------------------------
2024-07-29 12:04:06 000055555569e9ec <unknown>
2024-07-29 12:04:06 000055555569e432 <unknown>
2024-07-29 12:04:06 000055555569da41 <unknown>
2024-07-29 12:04:06 00007ffffcd2af10 killpg+0x40
2024-07-29 12:04:06 00007ffffcd2ae87 gsignal+0xc7
2024-07-29 12:04:06 00007ffffcd2c7f1 abort+0x141
2024-07-29 12:04:06 0000555555632672 <unknown>
2024-07-29 12:04:06 00005555556b5204 <unknown>
2024-07-29 12:04:06 00005555556e81f8 <unknown>
2024-07-29 12:04:06 00005555556e7fda <unknown>
2024-07-29 12:04:06 000055555563e4ea <unknown>
2024-07-29 12:04:06 000055555563e13f <unknown>
2024-07-29 12:04:06 Process: 10 - sqlservr
2024-07-29 12:04:06 Thread: 109 (application thread 0x1a8)
2024-07-29 12:04:06 Instance Id: 17b1af70-a127-43ea-8108-952937bef880
2024-07-29 12:04:06 Crash Id: 50073ca4-e466-455e-b8d7-e9aad4518627
2024-07-29 12:04:06 Build stamp: 388f6c66c6dbc4da12ba35a003fcb9b5e0f65b6bc460dbf45ba9cf2562768e67
2024-07-29 12:04:06 Distribution: Ubuntu 18.04.6 LTS
2024-07-29 12:04:06 Processors: 14
2024-07-29 12:04:06 Total Memory: 16749948928 bytes
2024-07-29 12:04:06 Timestamp: Mon Jul 29 11:04:06 2024
2024-07-29 12:04:06 Last errno: 2
2024-07-29 12:04:06 Last errno text: No such file or directory
2024-07-29 12:04:12 dmesg: read kernel buffer failed: Operation not permitted
2024-07-29 12:04:12 /usr/bin/timeout: failed to run command '/bin/journalctl': No such file or directory
2024-07-29 12:04:12 /usr/bin/timeout: failed to run command '/bin/journalctl': No such file or directory
```
### Diagnostics ID
2CC47E7A-01A1-406D-ABB8-461FE9D0521F/20240729111206
### Additional Info
_No response_
Let me quote the last comment :
As mentioned in #7368 (comment) this is not an issue with Docker Desktop but with MS SQL image. Latest MS SQL images already have support for newest Linux kernel with this issue fixed, all you need to do is to update your images and (in some cases) clear the image cache before doing so.
As for azure-sql-edge and other images which are no longer supported by Microsoft, your best bet is to either: a) Run standard Ubuntu SQL Server images under Rosetta virtualization , or b) contact Microsoft.
Thanks for the workaround, I can confirm it works
changes:
using image mcr.microsoft.com/mssql/server:2022-latest
platform linux/amd64
Tested on:
MacOS 15.3.1
M1 chip
Docker Desktop 4.37.2 (179585).
sqlpackage 162.5.57
So it seems tha the image you are using is old and not supported by Microsoft anymore so it is not updated and doesn’t support the new Linux kernels. In this case the one that is shipped with the Virtual Machine created by Docker Desktop.