Running Azure SQL Edge Contain on Apple M4 Pro

Hello internet, I’m having issues getting a container running for Azure SQL Edge on my MacBook, which has an M4 Pro chip.

I ran the following command in the terminal:
docker run -d -e "ACCEPT_EULA=1" -e "MSSQL_SA_PASSWORD=***" -e "MSSQL_PID=Developer" -e "MSSQL_USER=SA" -p 1433:1433 --name azuresqledge -d mcr.microsoft.com/azure-sql-edge

It looks like it wants to load for about three seconds and then quits.

Does anybody have any suggestions?

Here is a portion of the log:

2025-04-10 09:19:38.840 | This program has encountered a fatal error and cannot continue running at Thu Apr 10 14:19:38 2025
2025-04-10 09:19:38.840 | The following diagnostic information is available:
2025-04-10 09:19:38.840 | 
2025-04-10 09:19:38.840 |          Reason: 0x00000001
2025-04-10 09:19:38.840 |          Signal: SIGABRT - Aborted (6)
2025-04-10 09:19:38.840 |           Stack:
2025-04-10 09:19:38.840 |                  IP               Function
2025-04-10 09:19:38.840 |                  ---------------- --------------------------------------
2025-04-10 09:19:38.840 |                  0000aaaae89fba70 std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::~_Sp_counted_base()+0x25d0
2025-04-10 09:19:38.840 |                  0000aaaae89fb618 std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::~_Sp_counted_base()+0x2178
2025-04-10 09:19:38.840 |                  0000aaaae89fad1c std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::~_Sp_counted_base()+0x187c
2025-04-10 09:19:38.840 |                  0000ffff867e67a0 <unknown>
2025-04-10 09:19:38.840 |                  0000ffff860cf598 raise+0xb0
2025-04-10 09:19:38.840 |                  0000ffff860d0974 abort+0x154
2025-04-10 09:19:38.840 |                  0000aaaae89ff60c std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::~_Sp_counted_base()+0x616c
2025-04-10 09:19:38.840 |                  0000aaaae8ae9e54 std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::al
2025-04-10 09:19:38.840 |                  0000aaaae8ae9bf0 std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::al
2025-04-10 09:19:38.840 |                  0000aaaae8a0e358 std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::~_Sp_counted_base()+0x14eb8
2025-04-10 09:19:38.840 |                  0000aaaae8a0df80 std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::~_Sp_counted_base()+0x14ae0
2025-04-10 09:19:38.840 |                  0000aaaae8abce94 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > std::operator+<char, std::char_traits<char>, std::allocator<char> >(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_
2025-04-10 09:19:38.840 |                  0000ffff82489920 S_SbtUnimplementedInstruction+0x266ddc
2025-04-10 09:19:38.840 |                  0000ffff824bad8c S_SbtUnimplementedInstruction+0x298248
2025-04-10 09:19:38.840 |                  0000ffff824ba800 S_SbtUnimplementedInstruction+0x297cbc
2025-04-10 09:19:38.840 |                  0000ffff82479e88 S_SbtUnimplementedInstruction+0x257344
2025-04-10 09:19:38.840 |                  0000ffff822b3858 S_SbtUnimplementedInstruction+0x90d14
2025-04-10 09:19:38.840 |                  0000ffff822b49b4 S_SbtUnimplementedInstruction+0x91e70
2025-04-10 09:19:38.840 |                  0000ffff822b4a84 S_SbtUnimplementedInstruction+0x91f40
2025-04-10 09:19:38.840 |                  0000ffff822298d4 S_SbtUnimplementedInstruction+0x6d90
2025-04-10 09:19:38.840 |                  0000ffff824fc538 S_SbtUnimplementedInstruction+0x2d99f4
2025-04-10 09:19:38.840 |                  0000ffff7d2a64e0 S_SbtUnimplementedInstruction+0x5eb40
2025-04-10 09:19:38.840 |                  0000ffff7d2a5d78 S_SbtUnimplementedInstruction+0x5e3d8
2025-04-10 09:19:38.840 |         Process: 24 - sqlservr
2025-04-10 09:19:38.840 |          Thread: 143 (application thread 0x1d0)
2025-04-10 09:19:38.840 |     Instance Id: 1730b918-83c8-4cc2-8f51-619a515312d6
2025-04-10 09:19:38.840 |        Crash Id: 018ca5ae-306d-48ea-8b14-183ef6eb0ff2
2025-04-10 09:19:38.840 |     Build stamp: 7e3b976a7614e3cb6d16ce08aa8e3b28924df7f1870dfe9956e396a15452340b
2025-04-10 09:19:38.840 |    Distribution: Ubuntu 18.04.6 LTS aarch64
2025-04-10 09:19:38.840 |      Processors: 12
2025-04-10 09:19:38.840 |    Total Memory: 12529274880 bytes
2025-04-10 09:19:38.840 |       Timestamp: Thu Apr 10 14:19:38 2025
2025-04-10 09:19:38.840 |      Last errno: 2
2025-04-10 09:19:38.840 | Last errno text: No such file or directory

There are a ton of lines that look like this in the log too:

2025-04-10 09:19:39.456 | Capturing core d*mp and information to /var/opt/mssql/log...
2025-04-10 09:19:39.461 | /bin/cat: /proc/24/maps: Permission denied
2025-04-10 09:19:39.569 | /bin/cat: /proc/24/environ: Permission denied
2025-04-10 09:19:39.573 | /usr/bin/find: '/proc/24/task/24/fdinfo': Permission denied

Seems to be related

There is a GitHub issue link in the post but I share it here too

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.