Reboot from GUI don't find USB to boot from


Recommended Posts

Thanks for taking the time to replicate this!

 

As for the question, I use legacy/non UEFI to boot from USB as I believe everyone else with the problem is.

 

peter_sm tried the UEFI boot and it did not find anything to boot from, so I would assume I'd have the same situation if I tried to use it (would have to try though) which leaves me with no other options.

Link to comment
  • Replies 83
  • Created
  • Last Reply

Top Posters In This Topic

All,

 

I have a possible solution for this bug that I'd like some folks to test out when they can.  This isn't guaranteed to fix the issue at this point, but it's safe to perform and if it doesn't work, simply recopy your old syslinux folder back.  I have tested this on my equipment and it resolved the issue.

 

First and foremost, please make a complete backup of your USB flash device before performing this work.

 

Steps to Perform

 

1)  Shutdown your unRAID server completely.

2)  Unplug your USB flash device from your server and plug it into a Windows-based computer.

3)  Download this zip file and extract it to the syslinux folder on your USB flash device, overwriting the files that are there.

4)  Run make_bootable from the USB flash device root folder (make sure to Run as Administrator)

NOTE:  This will NOT work from a Mac at this time.

5)  Unplug the USB flash device from your computer and plug it back into your server and boot.

6)  After booted up, stop the array and reboot to ensure that the machine reboots correctly and that machine check errors are not displayed.

7)  Coffee break!

 

Here's the link to download the .zip file to extract to your syslinux folder on your USB flash device:

 

https://s3.amazonaws.com/dnld.lime-technology.com/temp/fix.zip

 

Please try this and let us know your results!!

 

EDIT:  Wanted to provide some insight on this as well.  The oddity of this bug is that it doesn't affect v5 which uses the same syslinux as we have in beta 10a.  We have determined that this looks to be the clear case of a buggy BIOS from ASRock.  Other mobos may be affected as well, but it seems to be an "odd man out" scenario and not something that many users are facing.

Link to comment

Very interesting.  I don't have one of the impacted systems, so can't help with testing.    But it's nice to know you (apparently) found a fix.    Since it doesn't manifest the issue in v5, it must have something to do with a BIOS call that doesn't work correctly in 64-bit mode ... but it must also be related to the way Syslinux does it, since a different version of Syslinux works okay.

 

Hopefully Peter, archedraft, and bungee91 can confirm that it resolves it for all of them.

 

... it would also be interesting to see if a BIOS update fixes it, in case everyone's not running the most current BIOS versions.  [Peter:  You indicated yours was current "as of 8 months ago" -- have you checked for any subsequent updates?]

 

 

Link to comment

Glad to hear this fix is working for those experiencing this issue.  This one had really perplexed us and in the end, we determined the cause to be a faulty BIOS.

 

It can't be the unraid distribution itself as the boot failure occurs before bzroot / bzimage is even loaded.

 

It can't be syslinux itself because then it would be affecting all motherboards and users the same.

 

The common thread here has been ASRock motherboards.  Couldn't replicate this on any other types yet.

 

So for now, this will remain as a hotfix for those users that are affected.

 

And just for giggles, here's proof that the motherboard BIOS is weird.  I have had fast boot enabled for months.  This is what it says in the bios about fast boot:

 

0a7d6c64476deaf84b52bdc4d387aff9.jpg

 

Hmm, wonder how unraid has been working for all these months?!?

 

Link to comment

Care to share insight into what was changed in this attempt to address the quirky issue? Was it some change in the configration or does this include a different version of syslinux than what beta 10a? I'm naturally curious about quirky issues.  :)

Almost didn't see this. In short, this hotfix upgrades syslinux to 6.03.

Link to comment

Definitely an interesting fix.  I noted from the beginning of this discussion that it could "NOT" be an OS-related issue, since it's happening before the OS even starts to boot ... and the OS booted fine from a cold start.

 

But it's also weird that changing to a different SysLinux fixed it ... which tends to indicate it's NOT a BIOS issue !!    To further muddy the issue, it worked fine with v5, but not with v6 - using the SAME version of SysLinux !!

 

Just as a matter of interest ... did the systems that were having this issue have Fast Boot enabled?  [According to the note JonP posted from the BIOS, these should NOT have been able to boot from the flash drive, so I assume that wasn't the case]

 

Bottom Line:  This is one of those issues that would have the Linux folks and Asus folks blaming each other -- but the important fact is that it's resolved  :)    It'd be interesting to have a hardware emulator on the system to do an actual trace and see what's different between the 32-bit and 64-bit processing of the boot code and reboot flags ... but it's clearly not worth the expense in either the hardware or the time to do that.

 

 

Link to comment

Definitely an interesting fix.  I noted from the beginning of this discussion that it could "NOT" be an OS-related issue, since it's happening before the OS even starts to boot ... and the OS booted fine from a cold start.

 

But it's also weird that changing to a different SysLinux fixed it ... which tends to indicate it's NOT a BIOS issue !!    To further muddy the issue, it worked fine with v5, but not with v6 - using the SAME version of SysLinux !!

 

Just as a matter of interest ... did the systems that were having this issue have Fast Boot enabled?  [According to the note JonP posted from the BIOS, these should NOT have been able to boot from the flash drive, so I assume that wasn't the case]

 

Bottom Line:  This is one of those issues that would have the Linux folks and Asus folks blaming each other -- but the important fact is that it's resolved  :)    It'd be interesting to have a hardware emulator on the system to do an actual trace and see what's different between the 32-bit and 64-bit processing of the boot code and reboot flags ... but it's clearly not worth the expense in either the hardware or the time to do that.

Agreed that there would be finger pointing either way. That said, the limited # of folks affected and the single board mfg being the only consistent thread here makes it still seem like the blame probably resides more on the hardware side, but truth be told we really wouldn't know what it was unless we expended far more time and resources than its worth it.

Link to comment

Just as a matter of interest ... did the systems that were having this issue have Fast Boot enabled?  [According to the note JonP posted from the BIOS, these should NOT have been able to boot from the flash drive, so I assume that wasn't the case]

 

I do not, in fact I even added a boot delay just in case, as I hate when booting at times having to fight with a computer to get into the BIOS!...

 

 

I haven't had a chance to try the fix, but it sure sounds promising!

I will certainly post my experience with it later this week.

Link to comment

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...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.