Solved Fresh UEFI Install Fails to Boot

atomicbeef

atomicbeef

Hello everyone,

I'm trying to install FreeBSD with full disk encryption on my first generation Thinkpad X1 Carbon which seems to be fully supported on 11-CURRENT according to the wiki. However, I am unable to get FreeBSD to boot at all, no matter how I partition the disk or which filesystems I use. The hard drive I did the install to is simply skipped in the boot order as if it didn't have an OS installed to it. I've tried following the BSD Now tutorial on full disk encryption multiple times with some attempts using ZFS and others using UFS, but it fails to boot.

To make sure that I wasn't just messing up something related to the full disk encryption, I decided to use the auto UFS option in the installer and have it create the partitioning scheme for me. The end result was:
Code: 
ada0p1 - EFI -    800K
ada0p2 - UFS -   145G    /
ada0p3 - Swap - 4G        none
Unfortunately, even this install failed to boot.

I also entered the shell of the installer and mounted the various partitions created by the installer to verify that there was something on them and everything looked all good.

I was able to install 10.1-RELEASE with UEFI working out of the box sometime a year ago, so there could be a bug in 11-CURRENT.
 
Whoops, I forgot that CURRENT isn't officially supported. I'm going to install 10.2-RELEASE and if I can get that working I'll try compiling and installing an up to date version of CURRENT.
 
Somehow my install managed to start working as soon as I inserted the 10.2-RELEASE USB so I toyed around with it for a bit and made sure everything worked on my laptop. After I found that everything worked, I set out to reinstall the system with full disk encryption. I went to dd the 11-CURRENT image to the USB and was met with a USB that didn't boot. I then tried to dd the 10.2-RELEASE image to the USB, but the USB still failed to boot. So right now I'm left with a functioning non encrypted 11-CURRENT install and a non functioning FreeBSD installation USB. I also tried to dd the images to another USB, but that one refuses to boot as well.
 
It may be a buggy UEFI that needs a workaround similar to what has been done for a few other Thinkpad notebooks. You should bring this question up on the freebsd-current mailing list if you're able to follow through with help debugging.
 
I'm not sure that's the issue as the USB was booting the CURRENT image perfectly a few days ago, but I'll ask the freebsd-current mailing list either way. Thanks for your help!
 
Make sure you dd(8) to the disk, not a partition within the disk. For example:
Good:
Code: 
dd if=myimage.img of=/dev/da0
Not good:
Code: 
dd if=myimage.img of=/dev/da0p1
 
I've been using dd(1) like this:
Code: 
dd if=FreeBSD-11.0-CURRENT-amd64-20151217-r292413-memstick.img of=/dev/da0 bs=1M conv=sync
Since this is the exact syntax that the handbook uses, I don't think the issue lies with the usage of dd(1).
 
Have you tried it on a Linux distro? Format the USB as FAT32 and use the same command replacing /dev/da0 by /dev/sdX (X=letter pertaining to the USB device).
 
I just tried using the Arch Linux live CD to dd(8) the newest 11-CURRENT image (from the 29th) onto a USB, but it still failed to boot. Since I didn't have enough space on the Arch Linux USB to download the entire 11-CURRENT image, I had to instead download the 11-CURRENT image onto my server and use a combination of ssh(1) and dd(1) in the form of ssh user@hostname "dd if=FreeBSD-11.0-CURRENT-amd64-20151229-r292858-mini-memstick.img" | dd of=/dev/sdc I highly doubt that this small detail actually had any affect though.

I'm very confused as to how a USB stick that was booting FreeBSD through UEFI a few days ago suddenly stopped working. I have now tried to put the 11-CURRENT image on two different USBs through Win32DiskImage on Windows 10 and dd(1) on Linux and FreeBSD. I'm also too lazy to buy a USB CD reader so I'm going to continue to try to get UEFI working on this laptop.

EDIT: I decided to try booting the USB on my desktop and it didn't work either. This means that the issue is not a buggy UEFI, but something going on with how I create the USB.
 
atomicbeef said:
ssh user@hostname "dd if=FreeBSD-11.0-CURRENT-amd64-20151229-r292858-mini-memstick.img" | dd of=/dev/sdc
Click to expand...

That command is confusing me! Sorry, never seen it before.
Anyway, is it possible for you (from Arch Linux Live) to format the hard drive you want to use to install FreeBSD and copy ( scp username@remotehost:PATH_TO_IMAGE /LOCAL_DIRECTORY) the image from your server to that drive, then try dd.
 
Okay so I mounted my hard drive from the Arch live USB and used dd(1) to copy the image to another USB. The FreeBSD USB once again failed to boot.

The command I listed above is a little complicated to understand at first, but if you take it piece by piece it becomes easy to understand. According to ssh(1), you can run a command on the remote machine by specifying it after the user and hostname. In this case, the command is dd if=FreeBSD-memstick.img. If you execute dd(1) without the of argument, it will copy the file to stdout. You can then pipe this output to dd(1) on the local machine and specify the of argument to copy the input (which is the file) to the device. In the end, this command has the effect of streaming the contents of the file over the network instead of reading the contents of the file from a local storage medium.
 
atomicbeef said:
Okay so I mounted my hard drive from the Arch live USB and used dd(1) to copy the image to another USB. The FreeBSD USB once again failed to boot.

The command I listed above is a little complicated to understand at first, but if you take it piece by piece it becomes easy to understand. According to ssh(1), you can run a command on the remote machine by specifying it after the user and hostname. In this case, the command is dd if=FreeBSD-memstick.img. If you execute dd(1) without the of argument, it will copy the file to stdout. You can then pipe this output to dd(1) on the local machine and specify the of argument to copy the input (which is the file) to the device. In the end, this command has the effect of streaming the contents of the file over the network instead of reading the contents of the file from a local storage medium.
Click to expand...
I use that concept not only with ssh(1) but when downloading scripts from my online storage as well. However, that dd(1) command looked a bit confusing but I get it now, it acts as the command mv(1) or cp(1), after all, it is "dd --convert and copy a file".

Anyway, the only other things I can think of why your USB not booting are; verify the integrity of the image's CHECKSUM (if you haven't already) and/or you need to boot it as UEFI device because that's how I did it on mine and if I choose the none UEFI option from the boot menu, it fails.
 
I've verified the checksums of all of the images I used and they all match and I'm booting the device as UEFI so I have no idea why I can't get the USB to boot FreeBSD when using UEFI, especially since it was working just fine a few days ago on both my desktop and my laptop. Thanks for everyone for taking the time to give me all of these suggestions though, I appreciate it.
 
Can you boot a none UEFi version of the FreeBSD image? because I'm suspecting it's the secure boot option that's causing all these problems (happened on my Asus motherboard). Go to the UEFI and turn off the secure boot or change the options (not sure what motherboard you have).
 
On my UEFI-compliant Asus laptop there is the CMS (legacy BIOS) option. Do you have something similar, atomicbeef? This, and secure boot disabled as youngunix suggested are probably your best bets :).

I daresay you are in the end quite lucky that your computer is not a Mac, because their (Apple's) UEFI cannot be accessed and altered so easily :(.
 
youngunix said:
Can you boot a none UEFi version of the FreeBSD image?
Click to expand...
Whenever I use dd(1) to put an image on a USB, I can only get that image to boot through UEFI. For example, if the image is non UEFI only, it would not show up at all on my desktop as a bootable device and would show up as a device on my laptop, (I think any storage device, bootable or not showed up) but would be skipped over as a non bootable device. This applies to all images I have ever used dd(1) for, including Linux distros.
youngunix said:
I'm suspecting it's the secure boot option that's causing all these problems (happened on my Asus motherboard). Go to the UEFI and turn off the secure boot or change the options (not sure what motherboard you have).
Click to expand...
As far as I can tell, my desktop does not support secure boot since I have to manually remove Arch's secure boot override to get it to boot in UEFI and I don't have any settings on my motherboard for secure boot. On the other hand, my laptop boots the Arch live CD fine without me having to remove its secure boot override, but doesn't have an option for secure boot either.

Atsuri said:
I daresay you are in the end quite lucky that your computer is not a Mac, because their (Apple's) UEFI cannot be accessed and altered so easily :(.
Click to expand...
I know firsthand how bad Macs are if you aren't trying to boot OS X. I actually used to use a Macbook Air before getting my Thinkpad and switched because trying to run anything other than OS X was pure masochism.
 
atomicbeef said:
Whenever I use dd(1) to put an image on a USB, I can only get that image to boot through UEFI. For example, if the image is non UEFI only, it would not show up at all on my desktop as a bootable device and would show up as a device on my laptop, (I think any storage device, bootable or not showed up) but would be skipped over as a non bootable device. This applies to all images I have ever used dd(1) for, including Linux distros.
Click to expand...

Can you post the specs for the desktop and laptop? Because that's definitely a hardware issue.
 
Sure, the specs are as follows:
Code: 
Desktop:
Motherboard - Sabertooth 990 FX Revision 1
RAM - 8 GB
Video - Radeon HD 7970
CPU - FX-8350

Laptop:
Thinkpad X1 Carbon
RAM - 4 GB
Video - Intel HD Graphics 4000
CPU - Intel i5-2520M
 
I looked up Sabertooth 990 FX and it seems that it doesn't have the options to control the UEFI. However, you said it worked a few days ago, so do a BIOS reset (Clear RTC RAM) and see if that helps.
Code: 
To erase the RTC RAM:
1. Turn OFF the computer and unplug the power cord.
2. Move the jumper cap from pins 1-2 (default) to pins 2-3. Keep the cap on pins 2-3
for about 5–10 seconds, then move the cap back to pins 1-2.
3. Plug the power cord and turn ON the computer.
4. Hold down the <Del> key during the boot process and enter BIOS setup to
re-enter data.
 
Before resetting the RTC RAM, I decided to try my luck one last time and write the latest 11-CURRENT image using Win32DiskImager to my USB. This time the USB actually booted on my desktop! Thrilled with my sudden discovery, I went to boot the USB on my laptop and...nothing. The USB still failed to boot. At this point, I gave up on EFI and decided to just install RELEASE and compile an up to date version of CURRENT.

I used Win32DiskImager to write the 10.2-RELEASE non UEFI memstick image and it actually boots on my laptop. I can also install a working system using UFS without encryption, but if I try to install using ZFS with encryption, I get an operating system not found message after the installer finishes. If I install ZFS without encryption, the system hangs before even starting the loader. As for installing with UFS and MBR with full disk encryption, I'll have to read the handbook and other documentation as I can't find any tutorials that meet my requirements and actually works.
 
ZFS never worked for either, I gave up after 5 attempts and 2 HDDs.
Remember that -CURRENT is never guaranteed to work.
Did you at least try a UEFI -RELEASE or -STABLE (-STABLE UEFI worked for me)? And do they work on the desktop?
 
Perhaps I wasn't clear in my previous post. I have tried many UEFI -RELEASES and only once did it work on my desktop, but not on my laptop. Right now I am trying to install 10.2-RELEASE on my laptop, but I cannot figure out how to get full disk encryption working with UFS and MBR. I can't try to install anything on my desktop since I have a Windows install (with lots of data) alongside an existing FreeBSD install and I don't have the time right now to back it all up, nuke the disk and try installing it through UEFI. I also see no point in doing so since MBR is working just fine for me. The whole reason I wanted to do UEFI in the beginning was because I thought that it was the only way to get a working image on my USB, but I proved myself wrong today when I got my USB to boot MBR just fine on my desktop and my laptop.
 
As I said in my first post, I already tried that tutorial. It's not much help to me in my current situation because that tutorial focuses on GPT instead of MBR. I'm going to read up on this tomorrow and post my results.
 
You must log in or register to reply here.
Back
Top