SOLVED Won't POST with 9.3 on USB

[solarisguy]

[...] the problem is apparently a GRUB issue [...]

and BIOS issue. Since BIOS gets stuck already in POST

 

[sef]

the problem is apparently a GRUB issue.

It is? How do you know this?

Remember: the only time the boot blocks are modified are during the first installation (ISO install, or GUI_Upgrade 9.2 ot 9.3); the rest of the time, all that's going on is that the filesystems (there are two) are being modified, in ways far more invasive than with the old scheme. (Which means that it's more likely to be due to ZFS than grub.)

That isn't to rule grub out. But there are a significant number of players in this -- BIOS, USB controller chip, USB bus, thumb drive controller, thumb drive storage, power, and then yes grub and ZFS.

 

[joeschmuck]

It is? How do you know this?.

All I can say is I strongly suspect it is a GRUB issue because this also happens in VMWare but only during a reboot, not a shutdown and then boot. FreeBSD 9.3 works perfectly, no issues at all. There is something hinky going on. If I were a programmer again (knowledgeable in this code) I'd be more than happy to troubleshoot the issue but I'm not able to help. I do wish I could.

As for the UEFI, I don't know if there is a workaround for GRUB after an update but I feel the only easy solution is to use a SATA drive as the boot device. Many folks are using DOMs, I am using a SSD on my test rig.

 

[sef]

I have had no issue with a VM, but I use Fusion on a Mac.

 

[joeschmuck]

I have had no issue with a VM, but I use Fusion on a Mac.

There is a thread here in the 9.3 section and I had created a bug report for the VMWare issue.

 

[cyberjock]

All I'm saying is I hear a lot of AMD bashing when the problem is apparently a GRUB issue. The rest of FreeNAS 9.3 appears to be working fine once you get it booted up. As for AMD causing problems for FreeBSD, well a little perspective needs to be added here... I have never seen a software provider dictate hardware requirements, it has always been up to the software provider to adjust their software to be compatible with the hardware. Currently FreeBSD is still supporting AMD so just because they need to do some development, I would at least expect any release version to run fine on both Intel and AMD hardware. FreeNAS is based on FreeBSD Released versions.

So not true.
- Look at building a game. You build the game and nvidia comes to the game developer's assistance to help optimize the game for nvidia hardware. (AMD is crying fowl because game developer's are happily taking nvidia code and using it while AMD isn't even offering the same service for free).
- Remember back in the 90s when people called some desktops Wintels because Intel and Windows were sleeping with each other to make both optimized for each other. Back then Microsoft actually provided input to Intel for the MMX optimizations. Of course this pissed off linux and everyone else. Of course, now Intel has a dedicated development team for Windows, Linux, and FreeBSD. AMD has a dedicated development team for Windows, 3 or 4 people for Linux, and none for FreeBSD.

Cyberjock, you and I will likely never agree on this and that is okay. I certainly will never hate you for a disagreement.

I feel the same way. We disagree on this and it's okay. Diversity is good.

I don't think you are understanding the reason why I posted what I did. AMD hardware obviously can work. But when it doesn't work it makes a mess for everyone. There's 2 possible problems; FreeNAS has a bug or there's an incompatibility with AMD. Notice how these obscure problems seems to be on AMD hardware regularly. The answer of 'that's AMD for ya' may not be correct 100% of the time, but the devs aren't about to work on stuff that only appears on AMD. We've learned from experience that too often devs spend stupendous amounts of time troubleshooting problems that turn out to be unfixable because of something not right with the system. It might be the AMD CPU, it might be the crappy BIOS implementation, but in any case isn't fixable. So we're left with two options:

1. Spend all this time to rule out everything, including stuff we are fairly sure we couldn't fix anyway (like AMD problems).
2. Realize that some bugs appear only on AMD systems and not spend time on them and focus on stuff we are sure we can fix.

If you want to do #1, that's what we were doing in 8.x. 9.x has seen massive improvements in adding code because AMD is basically ignored. I don't know about you, but I'm 100% cool with ignoring AMD because of the history with the percentage of AMD-based bugs that are fixable being in the low single-digits. I'd rather the devs work on what they are sure they can fix. AMD support should really be handled at the largest common denominator (and that would be FreeBSD and its forums).

 

[sef]

There is a thread here in the 9.3 section and I had created a bug report for the VMWare issue.

Which bug number? Where in the many threads?

I am specifically trying to determine what boot device you used -- whether it was a VMWare virtual disk, or direct access to a USB device. Also which sort of VMWare you used (ESXi, Fusion, VMWare for Workstation, etc.).

 

[gpsguy]

Here's the thread: https://forums.freenas.org/index.ph...nt-work-nightly-2014-10-24.24322/#post-153113

Which bug number? Where in the many threads?

It wasn't a show stopper for me - it's just my test environment. And, after someone posted that it worked in ESX 5.5 update 1 ... well okay. I'll upgrade to ESXi 5.5 u2 after the first of the year. I saw no reason to use the (free) crippled versions of 5.5 prior to update 2, so I stayed with ESXi 5.1.

 

[sef]

Was that with a virtual disk to boot from, or a real thumb drive? If a virtual disk, was it SATA, IDE, other?

Thanks!

 

[joeschmuck]

Was that with a virtual disk to boot from, or a real thumb drive? If a virtual disk, was it SATA, IDE, other?

Thanks!

I tried SATA, SCSI, and IDE, no change in results. It still happened last night as well.

And, after someone posted that it worked in ESX 5.5 update 1 ... well okay. I'll upgrade to ESXi 5.5 u2 after the first of the year. I saw no reason to use the (free) crippled versions of 5.5 prior to update 2, so I stayed with ESXi 5.1.

I'll have to check into this to see if there is a fix for VMWare Workstation, I just hope I don't have to purchase version 11 because that would be a deal breaker. I might have to use a different VM platform or just stick to my test rig hardware system.

 

[gpsguy]

Virtual. My only option with the FreeBSD 64bit template was SCSI.

Was that with a virtual disk to boot from, or a real thumb drive? If a virtual disk, was it SATA, IDE, other?

 

[ThreeDee]

I've discovered a "quirk" in my setup that just started with the 9.3 Beta .. maybe my motherboard is going bad all of a sudden? .. but I started another thread stating that upon reboot after applying upgrades, sometimes I get "This is a NAS data disk and can not boot system. System halted." .. the system fails to see the USB drive anymore.

So I plug in the flash drive to another USB port and then the system can see the drive again. Another couple upgrades later and my setup cannot see the flash drive again .. I change back to the original internal USB port and it's up and running again.

 

[sef]

Virtual. My only option with the FreeBSD 64bit template was SCSI.

Interesting.

All I've got to play with here is Fusion 7, and ESXi 5.5. I've never had any problems via Fusion (and I've done hundreds of installs and upgrades that way by now). I'll try with ESXi this weekend, hopefully.

 

[joeschmuck]

I've discovered a "quirk" in my setup that just started with the 9.3 Beta .. maybe my motherboard is going bad all of a sudden? .. but I started another thread stating that upon reboot after applying upgrades, sometimes I get "This is a NAS data disk and can not boot system. System halted." .. the system fails to see the USB drive anymore.

So I plug in the flash drive to another USB port and then the system can see the drive again. Another couple upgrades later and my setup cannot see the flash drive again .. I change back to the original internal USB port and it's up and running again.

Your MB is not going bad, it's the way FreeNAS is doing it's upgrades.

 

[sef]

Please stop saying that until you have proof. You could start by explaining how GRUB causes the BIOS to not recognize a thumb drive, but then magically recognize it when the system is power cycled. Without the OS running between the two.

It may be GRUB, but it is equally likely to be other things.

 

[sef]

I've discovered a "quirk" in my setup that just started with the 9.3 Beta .. maybe my motherboard is going bad all of a sudden? .. but I started another thread stating that upon reboot after applying upgrades, sometimes I get "This is a NAS data disk and can not boot system. System halted." .. the system fails to see the USB drive anymore.

So I plug in the flash drive to another USB port and then the system can see the drive again. Another couple upgrades later and my setup cannot see the flash drive again .. I change back to the original internal USB port and it's up and running again.

My suggestion would be to try a better (or possibly just newer?) thumb drive, or, better yet, use something other than a thumb drive.

That said, as I've stated multiple times, we don't know what's going on -- this is not something I've ever had happen. I even tried a few rounds with a cheap, crappy, Hello Kitty thumb drive, and couldn't get it to happen.

 

[joeschmuck]

Please stop saying that until you have proof. You could start by explaining how GRUB causes the BIOS to not recognize a thumb drive, but then magically recognize it when the system is power cycled. Without the OS running between the two.

It may be GRUB, but it is equally likely to be other things.

I completely stick by my statement as I do not feel ThreeDee has a failing motherboard at all and I'm certain (because many others have had the exact same experience with 9.3) that it is the factor of the upgrade process.

So when someone sets up a USB boot device in the BIOS to be the first item, many BIOSs will remember the USB device as it is. If you change the software on the device it may not recognize it as being the same device and now it's no longer the first boot device. I have experienced this over the years, not with FreeNAS but other OS's. I am very scientific about troubleshooting things and if this were the first or only complaint of this type, well I suggest a BIOS upgrade first and then start looking at FreeNAS 9.3 because his machine works fine with 9.2.

I hope I am able to find the smoking gun and I am about to run FreeNAS 9.3 on yet another piece of hardware in an effort to recreate the problem on my own hardware. If this problem doesn't get fixed then I'm certain the only resolution is to either replace the MB with something that will not be affected by this issue or just install a SSD boot drive (because they are cheap now) at the SATA0 port.

 

[sef]

You can try getting rid of the scrub of the boot pool (look in /usr/local/lib/freenasOS/Update.py, just delete the lines that have the scrub in them). (Similarly, for the ISO install, go to shell and wait for the scrub to finish.)

 

[Apollo]

Could it be a case of Write once as ZFS is know for, meaning that the first install it is located in a memory location accessible to boot or BIOS, but after a few updates, the start location is being pushed further up the memory map (while the former installs are still present and consuming disk space) and goes beyond a limit the BIOS cannot handle?

 

[cyberjock]

That said, as I've stated multiple times, we don't know what's going on -- this is not something I've ever had happen. I even tried a few rounds with a cheap, crappy, Hello Kitty thumb drive, and couldn't get it to happen.

I know where you got the "Hello Kitty" thumbdrive. ;)