Fresh v13 install on Arm64 (Surface Pro 11)
# help-with-umbraco
b
Morning! I have a shiny new Surface Pro 11 with the Snapdragon Arm64 chip and I'm having difficulty installing v13 on it. The site builds and boots, but I get a 503 Service Unavailable console error in the
GetSetup
Umbraco API call. Nothing relevant in the Umbraco logs. This happens before the install form appears on the frontend. Interestingly a v14 install works fine, as does an unintended install via
dotnet new umbraco
e.g. the latest LTS with Clean Starter Kit example from Paul Seal's excellent package script writer: https://psw.codeshare.co.uk/?TemplateName=Umbraco.Templates&TemplateVersion=LTS&Packages=&UserEmail=admin%40example.com&ProjectName=MyProject&CreateSolutionFile=true&SolutionName=MySolution&UseUnattendedInstall=true&DatabaseType=SQLite&UserPassword=1234567890&UserFriendlyName=Administrator&IncludeStarterKit=true&StarterKitPackage=clean&OnelinerOutput=false&RemoveComments=false Could be a bug and I'll need to log an issue, but interested to hear if anyone else has tried this on Arm64? It should be the same as what has worked on Mac/Linux for a while right? Could it be to do with the NodeJs version installed on my machine? Thanks!
s
The link to Package Script Writer installs a v13 site.. so it works.. !
So which path did not work for you? What steps to set up v13 without using PWS?
b
Hey @Sebastiaan - I should have been a bit more specific, it's the web-based installer that fails when running a new project created with
dotnet new umbraco --version 13.4.1
I also tried the traditional Visual Studio 'create new Umbraco project' way with the same result.
i.e. attempting to install the database via the web installer rather than using the dotnet CLI
s
Ah I see! Well, you're the first ARM-only person I've heard of (good luck 😅). I'd stick with unattended installs anyway, but it sure sounds like something "special" is happening on your machine. Although, my Raspberry Pi is also ARM64, but I never tried a fresh install on them, also always unattended. Try to look in the windows event viewer (custom views > administrative events) to possibly get more info.
b
Haha well that is mildly terrifying 😆 - it should be a similar experience to using an Arm-based Mac though right? I know I wont be able to run SQL Server locally but I was hoping otherwise, most other .Net Core web dev would be OK. More digging required I think, if you have any thoughts on this or sources to read, do tell. I have another intel machine but was hoping to just use that for legacy projects (and to host SQL Server)
u
On my M3 Macbook I can only install V13 with unattended installs, which I'm fine with. SQL server runs well in Docker and with Azure Data Studio to manage it.
s
Yeah SQL docker is great. Apple M1/2/3 is not ARM64 though is it.
b
@Sebastiaan Apple M1/2/3 aka 'Apple Silicon' is indeed based on Arm64 architecture. Software support is a totally different matter of course! Windows on Arm64 being much newer and with more patchy support, so far. Hopefully as more laptops get these new chips it will improve.
s
Ah okay, fair enough, I just always heard: "apple designed their own whole processor". As far as I understand it though, ARM processors aren't very much alike AFAIK so it's a lot hard to compile for generic ARM than it is for x86 (since there is no real generic ARM).
b
In my mind doing Umbraco dev on Win/Arm64 should be reasonably equivalent to Mac OS/Apple Silicon (ASP.Net Core/Kestrel being cross-platform) so I'm interested to hear other's experiences and gotchas. Tooling support is where they may be some differences. Thanks @Sebastiaan and @_tommadden for chipping in 👍
b
@Barry Fogarty windows on arm will not be similar experience to MacOs/Linux on arm, and it is not because CPU, but architecture of Windows, a lot services in windows is still emulated on ARM so you will have a quite complicated way as even .net core on arm is not 100% same as on x86 🙂
c
Windows on Arm is also in its 3rd or 4th iteration? I think it WILL get better, and now that there are decent chips vs the slightly rubbish ones we had before - I used to own an Arm based surface years ago. I am interested in these new laptops though - I'd definitely consider it when it's time to upgrade. I suspect the experience on MacOs on Arm will be better in the short term though
b
@CarlCod_es it is 5th at least
c
nice - I've not managed to keep up with them all. I do remember trying to install windows for arm on a raspberry pi 3. It was horrible 😂😂
s
Pi 3 is near impossible, Pi 4 is doable, Pi 5 is excellent!
h
Hello @Barry Fogarty ! I Got a snapdragon too (xps 13”) though i Found a Way to run/install local sql on arm64 running Windows 11, not sure if it helps you out with the actual problem, just wanted to share this, it works flawless on my snapdragon atleast: https://github.com/jimm98y/MSSQLEXPRESS-M1-Install
b
@heine i wouldn't go with this one, I would just use docker based arm based sql image ;p
h
Hehe that could be a solution aswell 😄 i just had bad experiences with docker and memory issues in the past 😄 i guess its a question about configuation but the sql Express is so easy to setup and let you start up the Umbraco installation/site in no time together with iis Express
b
I wasn't fan of docker either, but it went a long way and now a lot things i moved to docker (sql server, azurite etc)
c
I've been using SQL Azure Edge on my M1 Mac for a while, for local dev it works fantastically well - would that not be a good option on Arm for windows? https://hub.docker.com/r/microsoft/azure-sql-edge
j
Worth pointing out that MS have discontinued SQL Azure Edge. In part, it seems, because developers using ARM were using it for SQL Server development workloads that are unsupported/unsupportable. Official recommendation for Apple Silicon is to use ADM64 images with Rosetta 2.
c
But it still works a treat 🙂
I hadn't head this before though - thanks for the flag
j
It might be the version flag, it doesn't work and isn't supported (I forget why it's actually there at all). A given version of the template package can only install the corresponding Umbraco version correctly (no it's not ideal but HQ don't want the overhead of maintaining a project template that can install multiple versions).
On a separate note... In a world where uSync exists and Umbraco fully supports a different cross platform database engine... is it really worth hacking around with trying to make MSSQL run where it doesn't want to?
s
This! 👆 SQLite is absolutely great for local development. I will caveat that I don't build very many real projects, so I don't know how other people get on with it, but it should be more than enough as far as I know. Plus, you don't have to spend loads of your memory keeping a SQL server instance running on your machine.
b
@Jason in early days of mac os on arm, it was problematic so not sure how it will behave on windows on arm 😉
j
Yeah, I hear that, but at least SQLite on arm64 is a supported scenario.
i
not sure if related (or if this is still a problem) - but I had the same issue and noticed that UseInstallerEndpoints(); was missing from the program.cs file (when I compared it to a working version of 13.4.1) - adding that back in fixed the install.
c
Coming back to this convo after a week camping in Cornwall, but for me one of the strengths of Umbraco from day 1 of me using it was it was NOT too opinionated. I have no problem using SQLite for local dev if that's your workflow, but migrating from SQLite to SQL server can be a pain, and would force you down the route of relying on 3rd party (uSync) or first party paid products to migrate schema and content/media If I was able to work on a real database, which I can export and import in native supported format, that's better all round - so yeah, I agree it's not the end of the world, but I do think we lose something in not being able to run SQL everywhere. Appreciate it's not an Umbraco problem, but a microsoft one too
c
I've found SQLite on ARM64 surprisingly good even for non-dev loads. While it may not be recommended, I do run my own quite large site in production off it. As it's on an Oracle Cloud VM on ARM64, it's an environment with the same problem around lack of Microsoft's native SQL Server support. The site handles between 125000-150000 page views per month, with a lot of additional background reading and writing going on all the time to some custom tables above and beyond what Umbraco itself does as I record a lot of additional internal metrics, and concurrent writing isn't supposed to be a strongpoint for it. And yet it still flies! I was amazed at just how fast UI Builder could manipulate from such big custom tables via SQLite too. I still think we'll get an ARM64 version of SQL Server eventually for all they're saying it's not currently planned, mainly as they have the ARM64 version of Windows Server 2025 itself kicking round in preview so it'd be strange for them not to do both (though it is Microsoft). But if they do, it may end up locked to Windows again and we'll be right back to the old days.
b
@CodeBunTes sqllite is not recommend as it has no data safety 😉 as long you do proper backups it is fine ;p
c
I suspect a lot of their work will be in their translation layer (Prism) for the first version of support for their early adopters, and that's fine for windows, but it's again limiting choices for non-windows OSs, which is a shame - just when things were getting to be more open. I hope you're right about eventually getting native ARM support. I just hoped it would be sooner than later
j
The thing is, SQL Server is an absolute beast. It's a big fat general purpose RDBMS, and we only ever use a tiny %age of it. Personally, I find it bonkers that as an industry we've settled on using something so unwieldy as a persistence layer for the web, but we are where we are. Azure SQL Edge might be the same engine, but it's not SQL Server, and I don't think it ever can/will be - the reality is that a big fat general purpose RDBMS needs a big fat general purpose CPU. The tiny %age of SQL that Umbraco uses might just correlate to the feature set that's available in Azure SQL Edge but there's no guarantees, and Umbraco's never going to officially support it. We should be looking at faster and lighter solutions for these faster and lighter RISC CPUs. My hope is that Umbraco makes more progress transitioning to Entity Framework, so we can properly abstract the database away and use more suitable database engines in the future.
c
This too. MySQL/MariaDb would be a much nicer option for running the CMS, 100%. Azure SQL Edge is definitely not the same as full SQL - there are a tonne of services which don't work, and without knowing anything about how the base RDBMS works with the other features we can't really say how easy or not it would be to continue to support just the base DBServer without the extra features. RISC though?!?? Let's get arm working first eh? 😂 As much as I would love to look at different architectures, Arm is the next most prolific architecture to target. Loving this chat by the way 🙂
h
+1 for mysql/mariadb support, it shouldn't be too difficult. In one of my other open source roles (Snitz Forums) we have supported both SQL and MySQL for some time
c
I think UmbracoHQ were probably happy when they were finally able to drop MySQL support from the older versions, though I'm not sure it had properly worked for a while anyway. When was the last time anyone here had tried it? More abstraction would be a nice ideal, though in my experience Entity Framework seems to be very much designed to work with MS SQL server first and foremost though, with anything else seemingly being a bit of a 'cross your fingers and hope'. When I moved the site from MS SQL to SQLite, I had all my custom tables being built using EFCore Migrations which worked fine on MSSQL. But there were then so many little additional nuances I found I had to work around to make that exact same code work the same with SQLite. Things like integer identity columns requiring special different attribute tagging adding for each platform to actually increment, or the fact that apparently an 'int' and an 'integer', while interchangeable in the MS SQL world, have important differences in behaviour in the SQLite world. So even if there were greater dependency on an abstraction layer, how swappable the underlying database would be without loads of custom overhead I'm still unsure.
h
The only difference for me between SQL and MySQL was in the initial EF migration scripts due to different definitions etc, not seen any problems other than that.
b
Sql lite has bigger differences than MsSQL and MySQL, https://db-engines.com/en/system/Microsoft+SQL+Server%3BMySQL%3BSQLite so technically EF should take care of mysql better than sql lite ;p
h
if you write raw SQL queries then you need to be mindful of case sensitivity for MySQL or make MySQL case incentive (it is case sensitive by default)
j
Well, the R in ARM stood for something last time I checked 😉
b
@Jason but Risk usually you think about risk-5 not arm 😄
j
Yeah, I'm talking about RISC as in... what it actually stands for 😅 People forget, especially us working mostly with high level programming languages, that targeting ARM64 is non-trivial. All the efficiency over x86/AMD64 comes from not implementing a lot of their features (i.e. instructions). We're lucky this is mostly abstracted away from us, but if you're working on lower level code, instruction sets matter. If you rely on something that there's no ARM equivalent for, then you need to (using web Dev parlance) polyfill that with code. And SQL server does some mad low level stuff that's way more hardware specific han you might think. The question then is, should devs even do that? Should software like MSSQL be rewritten for ARM64 or, would it actually be better to rely on virtualization or a comparability layer like Rosetta/Prism...
b
@Jason better would be use software which is native to ARM (mysql is compiled to arm64! postgres is arm64!) Microsoft is far from being arm friendly and before we will get proper support for arm64 it will be ages
but yeah in menatime for umbraco it is virtualization best option
c
You know I'd totally subconsciously mapped in my head that RISC is RISC-V, and that Arm was actually a RISC instruction set implementation 😂😂 All I meant that it's easier to support Arm as it's more widespread right now than RISC-V
While it would be awesome to support and open source CPU architecture like RISC-V, I don't think we're there yet, but one day 🙂
116 Views