Seg Fault during boot process, 10.0-RELEASE

G

gdh

tl;dr

Booting with FreeBSD-10.0-RELEASE-amd64-memstick.img burned to usb with the following command (run on Ubuntu 13.10):

sudo dd if=FreeBSD-10.0-RELEASE-amd64-memstick.img of=/dev/sdb bs=64k

The SHA256 sum of the .img file was verified.

System specs: Core i7 2.4 GHz, Nvidia GTX 670, 15.6 GB RAM. Computer is a System76 Bonobo Extreme (https://system76.com/laptops/model/bonx8). Output shown below.



------------------------------------------------------------------------------------------------------------

Hello all,

I'm going to start the Operating Systems class here at my university. I thought it would be a good idea to install FreeBSD since it seems to be much easier to hack for than Linux, thanks to the Documentation Project. However, I can't even get the installer to boot into the install menu. I have no idea what is causing the seg fault, and I highly doubt such a bug would be in a release. It has to be something I'm doing wrong.

I searched Google for an answer, and there didn't seem to be one.

I guess I must say that I didn't create an empty partition for FreeBSD; I was planning to replace Linux completely. (I have a full backup of my files, and I've installed Linux so many times that I prefer to take the plunge.) If I must create a partition, than that might be the problem, but the Handbook said that if FreeBSD was going to be installed as the only OS, such an action wasn't necessary.

There's got to be something I'm doing wrong; the problem is that I'm so new to FreeBSD (not even installed), that I have no idea what to do, and the Handbook doesn't provide any hints for this particular case. At least, not that I know of. Anyway, some help would be greatly appreciated.
 

Attachments

  • IMG_20140608_211830.jpg
    IMG_20140608_211830.jpg
    330.6 KB · Views: 496
It's failing to run fsck(8) on the install medium (the USB memory stick) and the problem has nothing to do with hard disk partitioning. Try with a different USB memory stick.
 
Most likely you did not write to the USB stick correctly. Be aware that Linux uses USB drives asynchronously and when dd() has finished it does not actually mean that the cache has been flushed. The same happens on Linux when you unmount a filesystem (which is more dangerous). Usually you would expect that after unmount returns to command line, the device can be ejected. This is wrong for Linux. With my slow USB (v1) stick it can take half an hour(!) after unmount succeeded and you can actually eject the USB stick.

If you have LEDs on your USB stick, make sure they don't show write activity anymore. You can also take a look at I/O activity in the system. Or make sure the writes are synchronized (don't know how to do it).

Many people report problems with USB drives here. Make sure that you verify the checksum, of the image and also on the USB memstick (read back with dd() and give exact size: count parameter must be imagesize dived by bs parameter).
 
Thank you for your replies; that was exactly the problem. A little Google searching helped me find the sync(8) command, which flushes out all writes to disk. If any Linux user has the same problem, you can point them to that.

Thanks again!
 
You must log in or register to reply here.
Back
Top