October 21, 201411 yr 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.
October 21, 201411 yr Guys. We are chasing down a hunch. If anyone is online today and wants to help test a possible fix, please hit me up on Google hangouts at [email protected]. thanks.
October 21, 201411 yr Author Jonp, I'm busy today with Yosemite installation. Hope you are on track to solve this, I might can help later this week.
October 22, 201411 yr I think we may have figured this out. No assistance needed tonight. Will post more later in the week once we've confirmed we have a solid solution.
October 22, 201411 yr I think we may have figured this out. No assistance needed tonight. Will post more later in the week once we've confirmed we have a solid solution. Great work -- I'm very interested in hearing just what was causing this.
October 22, 201411 yr I think we may have figured this out. No assistance needed tonight. Will post more later in the week once we've confirmed we have a solid solution. Awesome! I am also very interested to hear what the issue is.
October 25, 201411 yr 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.
October 25, 201411 yr 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?]
October 25, 201411 yr Thanks for working on this! Hopefully can test later this evening,if not tomorrow. I'm on the most recent bios, however there have been no updates since June.
October 25, 201411 yr ... it would also be interesting to see if a BIOS update fixes it, in case everyone's not running the most current BIOS versions. I did try updating to the newest bios on mine but it didn't change anything. Now to try this!
October 25, 201411 yr Well my server reboot! I have only attempted this one time but it has not successfully reboot since beta 10 so that is promising. Now off to watch a movie! Thanks jonp! How did you fix this???
October 25, 201411 yr 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.
October 26, 201411 yr Author Please try this and let us know your results!! Jonp, your fix solved the reboot issue!! great work My BIOS is the latest, was released in 7/23/2013. //Peter
October 26, 201411 yr 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: Hmm, wonder how unraid has been working for all these months?!?
October 26, 201411 yr 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.
October 26, 201411 yr Very intriguing! Now that this hotfix has been applied on my system, will I have to re-apply it after each update? I would assume not but thought I would check.
October 26, 201411 yr Very intriguing! Now that this hotfix has been applied on my system, will I have to re-apply it after each update? I would assume not but thought I would check. No need to reapply. Subsequent updates will work just fine.
October 26, 201411 yr No need to reapply. Subsequent updates will work just fine. Awesome. Thanks again for solving this one!
October 27, 201411 yr 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.
October 27, 201411 yr 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.
October 27, 201411 yr ... but truth be told we really wouldn't know what it was unless we expended far more time and resources than its worth it. Definitely agree ... as I noted before: ... it's clearly not worth the expense in either the hardware or the time to do that.
October 28, 201411 yr 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.
Archived
This topic is now archived and is closed to further replies.