Hi,
I am trying to upgrade Umbraco 8.5.5 to 8.6.1. The update process runs fine but when I run my project, it builds fine but fails to run. It first asks me to "Download and Debug" a file and then throws "Umbraco.Core.Exceptions.BootFailedException: Boot failed".
I have tried updating Umbraco via Package Manager Console, NuGet package manager, re-cloned my repository, refreshed database but no use.
I have looked at a few other related posts but nothing helped me. If this is related to Umbraco update process, I am not really sure as I followed the standard update process.
Removing entry for "Umbraco.Core.MainDom.Lock" in web.config seems to fix the issue.
The default MainDom implementation of using a system-wide semaphore lock doesn't natively work on Azure because Azure doesn't respect system-wide semaphore or event wait handles.
during the upgrade . Wont allow the upgrade to take place .
Once you remove this it allows the upgrade to be done .
I see this is in the log : Execute "AddMainDomLock"
Once the Upgrade of the db is done ,
Then once the upgrade is completed this can be re-added
So not sure what is does ? or why is it required ? But if its not added i get error Lock.timeouts in log .
So can someone explain what this does ?
Andy
The SqlMainDomLock app setting key is need on Azure websites to change how the MainDomLock works. This is because previously a file lock was used (which on a VPS/Shared Hosting is no problem), however the Main Dom Lock behaviour on Azure doesn't work how Main Dom locks were meant to work and as such it would result in "File locked" errors being thrown where Nucache and Examine files couldn't be accessed after a slot swap/restart/auto move.
After a lot of investigation into this bizarre file lock error the cause was finally found and this key was introduced to change the lock from a File Lock to one in SQL.
In "theory" having the key in place before the Upgrade runs shouldn't be an issue, or having it on a non-azure environment, but it appears (based on various reports including this thread) that, because of various restarts, it does cause an issue.
The general advice is don't have the key in place during the upgrade but add it after the upgrade has been completed if you need it.
Hi! I'm having a very similar issue. I'm not upgrading, but just sometimes my application gets into this lock situation and either fails to boot, getting the following error, that I cannot find the cause of:
[BootFailedException: Boot failed: Umbraco cannot run. See Umbraco's log file for more details.
-> Umbraco.Core.Exceptions.BootFailedException: Boot failed.
-> System.TimeoutException: Cannot acquire MainDom
at Umbraco.Core.Runtime.MainDom.Acquire() in D:\a\1\s\src\Umbraco.Core\Runtime\MainDom.cs:line 172
Or sometimes it throws errors, when one of my replica servers are coming up:
I really need help fixing this, as I'm starting to think that Umbraco 8..18.4 is faulty.
There is one CMS server, and 2-4 front-end servers that are running in a kube instance in my case...
Umbraco upgrade from v8.5.5 to v8.6.1 throw "Boot Failed" error
Hi, I am trying to upgrade Umbraco 8.5.5 to 8.6.1. The update process runs fine but when I run my project, it builds fine but fails to run. It first asks me to "Download and Debug" a file and then throws "Umbraco.Core.Exceptions.BootFailedException: Boot failed".
I have tried updating Umbraco via Package Manager Console, NuGet package manager, re-cloned my repository, refreshed database but no use.
I have looked at a few other related posts but nothing helped me. If this is related to Umbraco update process, I am not really sure as I followed the standard update process.
Can anyone help me please?
You might have a package/code that is incompatible with version 8.6.1
Tried updating all packages. still no use
Did all packages update successfully?
Hi Ifrahim,
When you performed the upgrade, did you do any config changes at the same time?
Nik
Hi Nik
I didnt do any config changes. Just like a standard upgrade process, I ran Nuget command and chose to overwrite files (as asked).
I have seen this before, a restart of the website and app pool resolved this for me.
Still didnt work for me
Removing entry for "Umbraco.Core.MainDom.Lock" in web.config seems to fix the issue.
Thanks for your help guys.
check that you have these keys in web.config
Same issue Boot Failed
during the upgrade . Wont allow the upgrade to take place . Once you remove this it allows the upgrade to be done . I see this is in the log : Execute "AddMainDomLock" Once the Upgrade of the db is done , Then once the upgrade is completed this can be re-added
So not sure what is does ? or why is it required ? But if its not added i get error Lock.timeouts in log . So can someone explain what this does ? Andy
The SqlMainDomLock app setting key is need on Azure websites to change how the MainDomLock works. This is because previously a file lock was used (which on a VPS/Shared Hosting is no problem), however the Main Dom Lock behaviour on Azure doesn't work how Main Dom locks were meant to work and as such it would result in "File locked" errors being thrown where Nucache and Examine files couldn't be accessed after a slot swap/restart/auto move.
After a lot of investigation into this bizarre file lock error the cause was finally found and this key was introduced to change the lock from a File Lock to one in SQL.
In "theory" having the key in place before the Upgrade runs shouldn't be an issue, or having it on a non-azure environment, but it appears (based on various reports including this thread) that, because of various restarts, it does cause an issue.
The general advice is don't have the key in place during the upgrade but add it after the upgrade has been completed if you need it.
Hi! I'm having a very similar issue. I'm not upgrading, but just sometimes my application gets into this lock situation and either fails to boot, getting the following error, that I cannot find the cause of:
Or sometimes it throws errors, when one of my replica servers are coming up:
I really need help fixing this, as I'm starting to think that Umbraco 8..18.4 is faulty.
There is one CMS server, and 2-4 front-end servers that are running in a kube instance in my case...
is working on a reply...