Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Can't Upgrade From 6.12.14 to 7.0.0 OS. Stuck at "Booting SMP configuration"

Featured Replies

Solved by Binary100100

24 minutes ago, Binary100100 said:

All cores running? Everything smooth thus far?

Yeah, all cores running, same usage as before.  Although not really stressing it, because I have only been using unraid for about 2 weeks and had only just finished moving all my files to it from my old servers - so have only setup a few shares and one docker with Krusader in it.  Going to start setting up more containers with plex, sonarr etc and see how it goes. But really liking unraid so far and has a great community :)

 

 

 

25 minutes ago, Binary100100 said:

So .. since @Mundvlhas positive results with this we can positively determine it's a BIOS problem with this particular board? Or is it the entire line of z170 chipset? Also, why are we just now having this issue? What changed in 7 that would prevent our boards from running? Will there be a permanent fix for this in 7.1 or is future updating of our systems going to be involving the removal of the USB drive, modifying the cfg file, reinserting it and hoping it works?

@itimpi mentioned in the 7.0.0 release thread that standard updates don't touch that config file, so should hopefully be okay on that front.

  • Author
1 minute ago, Mundvl said:

 

@itimpi mentioned in the 7.0.0 release thread that standard updates don't touch that config file, so should hopefully be okay on that front.

Awesome.

Did you include the "idle=poll" or no? Mind sharing the cfg file? 😉

I'll give it a try tonight.

3 minutes ago, Binary100100 said:

Awesome.

Did you include the "idle=poll" or no? Mind sharing the cfg file? 😉

I'll give it a try tonight.

No didn't use 'idle=poll'.  I've attached the config file.

I did a bit of searching and found that it is not ideal to disable the intel microcode (as it can, but I assume not always affect performance and compatibility, it also includes patches for security vulnerabilities), so I'll probably try re-enabling it at some point in the future (probably when I add more storage) after an update or two - but I'm just happy I have a working unraid install again.

syslinux.cfg

  • Author
2 hours ago, Mundvl said:

No didn't use 'idle=poll'.  I've attached the config file.

I did a bit of searching and found that it is not ideal to disable the intel microcode (as it can, but I assume not always affect performance and compatibility, it also includes patches for security vulnerabilities), so I'll probably try re-enabling it at some point in the future (probably when I add more storage) after an update or two - but I'm just happy I have a working unraid install again.

syslinux.cfg 548 B · 1 download

Awesome.

We *should* be able to add the "dis_ucode_ldr" directly into UnRaid OS without editing that file. Right?

Maybe I'll give that a try.

Screenshot_20250121_154354_Brave.thumb.jpg.e46c701e94e17c435049cf9fff3940e5.jpg

To

Screenshot_20250121_154853_Brave.thumb.jpg.754f385e05987e0ec377f0ccc869b987.jpg

 

 

Edited by Binary100100

  • Author
  • Solution

Okay.

Made those changes to a CLEAN (separate) USB drive and it booted.

I'm going to try to update.🤞 

 

So... I was able to finally update.

So the fix is to add "dis_ucode_ldr" to the syslinux.cfg file to prevent the microcode which may potentially put our systems at risk.

Is this an actual "fix"... or a temporary patch?

syslinux.cfg

Edited by Binary100100

25 minutes ago, Binary100100 said:

Okay.

Made those changes to a CLEAN (separate) USB drive and it booted.

I'm going to try to update.🤞 

 

So... I was able to finally update.

So the fix is to add "dis_ucode_ldr" to the syslinux.cfg file to prevent the microcode which may potentially put our systems at risk.

Is this an actual "fix"... or a temporary patch?

Hopefully the latter.

  • Author
4 minutes ago, Mundvl said:

Hopefully the latter.

Indeed.

Still... I still feel a bit anxious about disabling the microcode.
It's odd that we don't start having issues until this update. Which leaves you wonder, what did they accidentally leave out? Will newer versions include an actual fix to this so we can remove that line? Or will we just have to (finally) upgrade our systems. I mean... if I really have to then... whatever. I'll probably get a 13500 or something. It's just a pain to do when I use this for... pretty much everything. Home Assistant, FTP server, VM, Plex Server, File storage and an Exit Node for Tailscale. Having this go down for long periods is out of the question. I have all of my data on the 12+1 drives encrypted too so if there are any issues with LUKS I'm screwed out of 109+TB. So any major issues make me anxious. 

  • Community Expert

If the no microcode works, it's probably the best option to use for now, it may prevent some mitigations to be loaded, but unless you are renting your server for other users to run VMs I would say it's pretty safe, I run my all servers with mitigations disabled for better performance, and that disables both microcode and Linux mitigations.

 

image.png

 

Still, when a new Intel microcode is available, with v7 or v7.1, it may no longer cause the issue you are seeing, but since it looks like only a specific Asrock model (or series) is affected, they may have a BIOS bug with those boards.

2 hours ago, JorgeB said:

If the no microcode works, it's probably the best option to use for now, it may prevent some mitigations to be loaded, but unless you are renting your server for other users to run VMs I would say it's pretty safe, I run my all servers with mitigations disabled for better performance, and that disables both microcode and Linux mitigations.

 

image.png

 

Still, when a new Intel microcode is available, with v7 or v7.1, it may no longer cause the issue you are seeing, but since it looks like only a specific Asrock model (or series) is affected, they may have a BIOS bug with those boards.

That's good to know, you put my mind at ease about running it like that.  Can hold off on any upgrades for a couple of years, except for more storage :)

  • Author
8 hours ago, JorgeB said:

If the no microcode works, it's probably the best option to use for now, it may prevent some mitigations to be loaded, but unless you are renting your server for other users to run VMs I would say it's pretty safe, I run my all servers with mitigations disabled for better performance, and that disables both microcode and Linux mitigations.

 

image.png

 

Still, when a new Intel microcode is available, with v7 or v7.1, it may no longer cause the issue you are seeing, but since it looks like only a specific Asrock model (or series) is affected, they may have a BIOS bug with those boards.

I have one VM and several dockers. I should be okay to do this, right?

  • Community Expert
24 minutes ago, Binary100100 said:

I have one VM and several dockers. I should be okay to do this, right?

Yes, only if you were renting the server for other users to run those VMs it could be a security issue, if they are yours, it's fine.

  • Author
5 minutes ago, JorgeB said:

Yes, only if you were renting the server for other users to run those VMs it could be a security issue, if they are yours, it's fine.

Okay. I'll give it a try.
Thanks.

Still... WHY do earlier versions of the OS work, while 7 doesn't? Obviously, something changed. 
George R (in an email) informed me that UnRaid 6.12.14 and v7 both use the same Intel Microcode which is the latest release.
intel-microcode: ver 20241112

 

So what happened? If they both use the same microcode then why is it an issue on v7?

  • Community Expert
1 minute ago, Binary100100 said:

Obviously, something changed. 

The kernel changed, the microcode is the same, like mentioned before, IMHO it all points to a BIOS bug with those Asrock boards.

  • Author
Just now, JorgeB said:

The kernel changed, the microcode is the same, like mentioned before, IMHO it all points to a BIOS bug with those Asrock boards.

Okay. That makes sense. So the newer kernel breaks AsRock z170 motherboards. Nice. 😒

  • Community Expert
41 minutes ago, Binary100100 said:

So the newer kernel breaks AsRock z170 motherboards. Nice.

Most likely, there's some BIOS issue that in conjunction with the newer kernel causes the problem, maybe it will no longer happen with a newer kernel, or a newer Intel microcode, since I doubt Asrock will fix the BIOS for an older board, especially if the issue is only with Linux.

  • Author
8 minutes ago, JorgeB said:

Most likely, there's some BIOS issue that in conjunction with the newer kernel causes the problem, maybe it will no longer happen with a newer kernel, or a newer Intel microcode, since I doubt Asrock will fix the BIOS for an older board, especially if the issue is only with Linux.

Yeah, it's good that we were able to identify the problem though. Although it effects a very small group of users, it might be worth including it in a disclaimer for OS7 and newer.

  • Community Expert

@Mundvland @Binary100100, you are both using the same Asrock Z170 OC Formula, right?

 

If it's just a couple of users with this specific model, not sure if it's worth a warning in the release notes, but if there are more affected users, especially using a similar but different board, please post here, and I can ask LT to add a note to the known issues.

  • Author
1 minute ago, JorgeB said:

@Mundvland @Binary100100, you are both using the same Asrock Z170 OC Formula, right?

 

If it's just a couple of users with this specific model, not sure if it's worth a warning in the release notes, but if there are more affected users, especially using a similar but different board, please post here, and I can ask LT to add a note to the known issues.

Motherboard
Temperature: 33.5 °C

ASRock Z170 OC Formula
American Megatrends Inc., Version P7.60
BIOS dated: Friday, 03/02/2018

Copy and paste from the UnRaid Dashboard.

  • Author
1 hour ago, JorgeB said:

@Mundvland @Binary100100, you are both using the same Asrock Z170 OC Formula, right?

 

If it's just a couple of users with this specific model, not sure if it's worth a warning in the release notes, but if there are more affected users, especially using a similar but different board, please post here, and I can ask LT to add a note to the known issues.

If this is due to the newer kernel... should someone report it to the the developers? 

Everything was fine with kernel version 6.1.126 in UnRaid 6.12.15 but something in kernel version 6.6.68 breaks the AsRock Z170 board. Maybe the devs should be made aware of the issue? I'm sure a lot has happened between kernel versions 6.1 and 6.6.
Looks like the latest version is 6.13. Hopefully the problem was discovered and repaired?

Edited by Binary100100

  • Community Expert
2 minutes ago, Binary100100 said:

If this is due to the newer kernel... should someone report it to the the developers? 

Don't think the kernel is the problem if it only happens with a specific board model, it's likely a BIOS bug, it would need to be fixed by Asrock, not Linux.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.