SQL Server Docker container fails on start up when run in a VM with Ubuntu 24.04

I’m able to run the Docker image mcr.microsoft.com/mssql/server:2019-CU25-ubuntu-20.04 perfectly fine on Debian 12 & Windows 10. However, when running the same image on a VM with Ubuntu 24.04, the following error occurs on container start-up:

sqlserver2019  | This program has encountered a fatal error and cannot continue running at Thu Jun 20 01:53:15 2024
sqlserver2019  | The following diagnostic information is available:
sqlserver2019  | 
sqlserver2019  |          Reason: 0x00000001
sqlserver2019  |          Signal: SIGABRT - Aborted (6)
sqlserver2019  |           Stack:
sqlserver2019  |                  IP               Function
sqlserver2019  |                  ---------------- --------------------------------------
sqlserver2019  |                  000064d890f8e2fc <unknown>
sqlserver2019  |                  000064d890f8dd42 <unknown>
sqlserver2019  |                  000064d890f8d351 <unknown>
sqlserver2019  |                  00007449027e3090 killpg+0x40
sqlserver2019  |                  00007449027e300b gsignal+0xcb
sqlserver2019  |                  00007449027c2859 abort+0x12b
sqlserver2019  |                  000064d890f143d2 <unknown>
sqlserver2019  |         Process: 9 - sqlservr
sqlserver2019  |          Thread: 128 (application thread 0x1f8)
sqlserver2019  |     Instance Id: 765a7d6c-ba67-4b16-bd6c-0bb87d617e75
sqlserver2019  |        Crash Id: b52af073-1db9-4ed7-a9c6-21ba1505f57b
sqlserver2019  |     Build stamp: e149a9e980d9936d4f4a616b06112de0e7b2f4e45c2cd3a0884ae319ad3d13b7
sqlserver2019  |    Distribution: Ubuntu 20.04.6 LTS
sqlserver2019  |      Processors: 4
sqlserver2019  |    Total Memory: 8327204864 bytes
sqlserver2019  |       Timestamp: Thu Jun 20 01:53:15 2024
sqlserver2019  |      Last errno: 2
sqlserver2019  | Last errno text: No such file or directory
Capturing a dump of 9
sqlserver2019  | Successfully captured dump: /var/opt/mssql/log/core.sqlservr.6_20_2024_1_53_15.9
sqlserver2019  | Executing: /opt/mssql/bin/handle-crash.sh with parameters
sqlserver2019  |      handle-crash.sh
sqlserver2019  |      /opt/mssql/bin/sqlservr
sqlserver2019  |      9
sqlserver2019  |      /opt/mssql/bin
sqlserver2019  |      /var/opt/mssql/log/
sqlserver2019  |      
sqlserver2019  |      765a7d6c-ba67-4b16-bd6c-0bb87d617e75
sqlserver2019  |      b52af073-1db9-4ed7-a9c6-21ba1505f57b
sqlserver2019  |      
sqlserver2019  |      /var/opt/mssql/log/core.sqlservr.6_20_2024_1_53_15.9
sqlserver2019  | 
sqlserver2019  | Ubuntu 20.04.6 LTS
sqlserver2019  | Capturing core dump and information to /var/opt/mssql/log...
sqlserver2019  | dmesg: read kernel buffer failed: Operation not permitted
sqlserver2019  | /usr/bin/timeout: failed to run command '/bin/journalctl': No such file or directory
sqlserver2019  | /usr/bin/timeout: failed to run command '/bin/journalctl': No such file or directory
sqlserver2019  | Thu Jun 20 01:53:31 UTC 2024 Capturing program information
sqlserver2019  | Dump already generated: /var/opt/mssql/log/core.sqlservr.6_20_2024_1_53_15.9, moving to /var/opt/mssql/log/core.sqlservr.9.temp/core.sqlservr.9.gdmp
sqlserver2019  | Moving logs to /var/opt/mssql/log/core.sqlservr.9.temp/log/paldumper-debug.log
sqlserver2019  | Thu Jun 20 01:53:31 UTC 2024 Capturing program binaries
sqlserver2019  | Thu Jun 20 01:53:32 UTC 2024 Not compressing the dump files, moving instead to: /var/opt/mssql/log/core.sqlservr.06_20_2024_01_53_29.9.d

The issue first arose from a colleague who was using a VM with Ubuntu 24.04 and I was able to replicate it with a fresh VM on virtual box (both VM’s are hosted on a native Windows OS). My colleague also stated that it works fine on a VM of his running Ubuntu 20.04, so the problem seems to be either with Ubuntu 24.04 specifically or a newer version than 20.04. Of course, it may be something VM related in combination with the OS version.

I cannot find a record of anyone else encountering the same problem. My colleague is testing to see how it performs on a native Ubuntu 24.04 installation (that work hasn’t been completed at this time).