Installation on an external hard drive hangs during POST.

Hi everyone. I could use some help in getting a FreeBSD installation up and running. I'm almost there.

What I wish to do:

Run FreeBSD 9.0-RELEASE (AMD64) from an external hard drive. Specifically from a WD Elements 500Gb USB 2.0 drive (Model number WD5000C035-000).

What has happened so far:

I succesfully ran the installer, accepting the default settings, from the installation DVD FreeBSD-9.0-RELEASE-amd64-dvd1.iso. Booting from the DVD would also hang at first. I got around this obstacle by changing the mode for the SATA controller from AHCI mode to Native IDE in the BIOS configuration utility.

After rebooting the computer seems to hang at POST. There are no messages as to the amount of RAM detected or devices found. Detaching the drive and rebooting allows for the POST to continue as normal. It's again possible to boot from a disk in the DVD drive for example. Only repartitioning the hard drive allows for the computer to boot with the drive attached.

Guesses as to the nature of the problem (and a few possible solutions):

1st guess: BIOS doesn't recognize the boot manager and thus fails to hand over the control to it. Possible solutions:

The FAQ explains how to rewrite the MBR through sysinstall http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#BOOTMANAGER-RESTORE.
Or, from the command line: fdisk -B -b /boot/boot0 da0 http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-blocks.html.
Or, find a way to replace the FreeBSD boot manager with GRUB. Perhaps that would work as it worked before with Linux.

In case the above ideas make sense, I'd need help with finding instructions for booting into somekind of a "rescue system" and getting into the installed system on the external hard drive.

2nd guess: BIOS doesn't understand the GPT partioning scheme. Solution:

Try formatting the drive during installation to use MBR partitioning instead.
I should probably be able to pull this one off but is this really a good idea? There's probably a good reason for preferring to use GPT partitioning instead.

Additional notes:

I've successfully run Linux on the system. Thus booting from the external drive is possible. Updating the BIOS without Windows, which I do not have, is impossible due to the firmware being distributed as .exe- files.

Motherboard: Gigabyte GA-880GMA-UD2H rev. 2.1. BIOS is at the first version, namely F3.
System architecture: AMD64.
 
Thanks for answering. Too bad that I missed your initial post. I must've gone past the thread, but failed to recognize the connection by skimming through the topic lines.

Looking at your post, it seems that MBR partioning from the installer might work. I'm going to try and see if that breaks the back of this obsessively addictive little problem. As I understood it, you also managed to use GPT partioning but your description of the steps sounds like geek :) I worry about the issue only because MBR seems to be on its way out. Though it's probably just a bug in FreeBSD since Fedora Linux initializes the disk with GUID partioning without any problems.

As to the rescue disc issue, documentation seems oddly silent about the differences between the "Shell" and "Live CD" options offered. I guess it'd be safe to run the fdisk command either way though.

I doubt updating the BIOS would help, since the system boots a GUID partioned disk created by Fedora without problems. Also, writing the chip isn't a problem. Actual firmware files can be used for updating through the built in Q-Flash utility. I simply don't know how to "look into" the .exe-file and see if Gigabyte has merely repackaged the actual firmware file for use by the Windows utility.
 
How is the external drive connected? eSata or USB?
Does the system hang DURING the POST or AFTER it (before loading OS)?
I think if POST is not finished (no messages about RAM and devices) it may be incompatibility or even failure in the hardware.
 
This thread can be closed. I finally just gave in and bought a separate hard drive for FreeBSD. Installation went without any problems at all, and I'm now able to stare at a foreign looking system through a very fine looking text interface.

The issue with the original drive remains a mystery. Sudden, occasional reboots by the system caused the Linux installation I had been running to become unbootable. I'm not sure whether the reboots happened due to the drive's automatic behaviour of powering down, or if the drive had just gotten bad. Such hardware is of course just too unreliable. Or it's a wonderful excuse at least.
 
Back
Top