Installing on UEFI amd64 with bios only supporting UEFI boot

unAmygdala

unAmygdala

Solution: Use MBR Partitioning Scheme (easy, from installer)

Solution: Boot from memstick (easy)

The FreeBSD Foundation has been working towards the future of booting in x86 and catching up to our friends in Linux-land by sponsoring work on a UEFI enabled boot loader. This work was taken on by Benno Rice (benno@freebsd.org) and Ed Maste (emaste@freebsd.org).

Many thanks to the folks at the FreeBSD Foundation for these initial steps into UEFI. The project branch in subversion is publicly available and I highly encourage folks to engage the community to get this closer to production grade.

-- http://blog.ignoranthack.me/?p=147 December 2, 2013
Click to expand...

I am not having luck installing Freebsd rel. 10 from memory stick onto a 2012/13 Intel Atom D2550 (1.86GHz) 2GB DDR3 320GB HDD Capacity system (Asus Eee EB1033-B048E). I tried an install using guided mode, selecting the entire disc, and going with the defaults. But, I think something is going on with the UEFI bios that's causing the system to be unable to detect the first logical slice containing the first cylinder block when booting from a memorystick. I received an error when partitioning the system that it was not working on the first slice. Is guided mode disk set up compatible with UEFI systems containing a pre-installed os (whether or not secure boot is used)?

I am attempting to determine if this has anything to do with UEFI and/or my bios. When the project was announced over a year ago, UEFI was due 'soon'. The most recent news predates Rel. 10 and indicates that full UEFI support in the FreeBSD source code is 'pending.' So what's the current status of the UEFI project and will this make it possible to run FreeBSD off of EUFI conveniently?

Is there a way to determine if secure boot or UEFI is enabled in bios firmware where you don't have gui bios access to such options? Asus' website and manuals for the EB1033 refer to bios settings and options that are different than what's on my EB1033. For example, I have a completely different bios than that on the Asus EB1033 troubleshooting tip discussing disabling smart boot (http://support.asus.com/Troubleshooting ... &p=20&m=... ). I have Asus Bios 0501 American Megatrends version 2.10.12.08. However, I've seen other screenshots with a similar but different bios that has the same version number (E.G. http://www.manualslib.com/manual/324987 ... ml?page=91 looks exactly like my boot menu in all respects, including version number, but, does not have "Option ROM Messages," "Setup Mode," UEFI/Legacy Boot," and "PCI ROM Priority".) The bios version that shipped with my EB1033 (Bios 0501 build date 5/23/2012 version 2.10.12.08) seems to be the 'advanced mode' interface. I don't have an option to go into a simple mode (the simple mode has more boot options than the 'advanced mode' interterface). There is no option to disable or enable secure boot. There is no option to select UEFI or legacy mode.

According to Microsoft http://technet.microsoft.com/en-us/libr ... 24987.aspx Windows 8 is the only OS currently using keys for secure boot. I have read elsewhere (e.g. http://vip.asus.com/forum/view.aspx?boa ... uage=en-us ) that secure boot can be an issue with preinstalled Windows 7 (perhaps used for checking the validity of windows 7 license keys). I don't think secure boot is an issue, but, if there's some way to probe for the presence or absence of secure boot using FreeBSD or other software tools (i.e. its been hardcoded and not available as a bios option) I could eliminate worries that secure boot is causing problems.

The system recognizes the drive as ada0 when booting the live fs memstick image. I am confused by the message, "Previously was known as ad4"? Is the drive recognized differently or use a different device in /dev when running off bootable usb livefs image as opposed to running off the filesystem installed by the membstick image onto a physical drive?



dmesg [snipped]
Code: 
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <ST320LT020-9YG142 0001SDM1> ATA-8 SATA 2.x device
ada0: Serial Number W0489HT6
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C)
ada0: quirks=0x1<4K>
ada0: Previously was known as ad4
Is it normal that gpart shows a disc by it's device name and by a disc id on a single disc system dedicated to FreeBSD, or, does this indicate different naming schemes are being used? Otherwise, from what I can see from gpart, things look as they should, except, what's that free space doing at the beginning of the drive and what would happen if I try resizing the 64k freebsd-boot slice ada01 to cover the 3k free space and put down a new freesd-boot on the single slice at the beginning of the disc?

gpart show
Code: 
=>       34  625142381 [b] ada0[/b]  GPT  (298G)
         34          6        - free -  (3.0K)
         40        128     1  freebsd-boot  [bootme]  (64K)
        168  616562552     2  freebsd-ufs  (294G)
  616562720    8388608     3  freebsd-swap  (4.0G)
  624951328     191087        - free -  (93M)

=>       34  625142381  [b]diskid/DISK-W0489HT6[/b]  GPT  (298G)
         34          6                        - free -  (3.0K)
         40        128                     1  freebsd-boot  [bootme]  (64K)
        168  616562552                     2  freebsd-ufs  (294G)
  616562720    8388608                     3  freebsd-swap  (4.0G)
  624951328     191087                        - free -  (93M)

=>       0  31266816  da0  BSD  (15G)
         0   1362080    1  freebsd-ufs  (665M)
   1362080  29904736       - free -  (14G)


gpart list
Code: 
Geom name: ada0
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 625142414
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: ada0p1
   Mediasize: 65536 (64K)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r0w0e0
   rawuuid: [snip]
   rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
   attrib: bootme
   label: (null)
   length: 65536
   offset: 20480
   type: freebsd-boot
   index: 1
   end: 167
   start: 40
2. Name: ada0p2
   Mediasize: 315680026624 (294G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r0w0e0
   rawuuid: [snip]
   rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
   label: (null)
   length: 315680026624
   offset: 86016
   type: freebsd-ufs
   index: 2
   end: 616562719
   start: 168
3. Name: ada0p3
   Mediasize: 4294967296 (4.0G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r0w0e0
   rawuuid: [snip]
   rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
   label: (null)
   length: 4294967296
   offset: 315680112640
   type: freebsd-swap
   index: 3
   end: 624951327
   start: 616562720
Consumers:
1. Name: ada0
   Mediasize: 320072933376 (298G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r0w0e0

What is the preferred method for creating a usb boot disk for running FreeBSD on an internal drive? That is, what do you change on the FreeBSD 10 memstick livefs to get it to use a filesystem installed on disk instead of the filesystem on the disk. Like a monkey, without knowing or remembering precisely what I did, I have -- two or three times -- been able to boot to where the root filesystem is running off the hdd. Whether it's the hardware or new features in FreeBSD, this system appears to run like a dream, notwithstanding the install issues, including support for wireless keyboards and mice (though not perhaps at the boot levels where I need to be testing what settings will work before committing them to file).

Am I correct that since I am using the "GPT" scheme, I should not need to use fdisk or bsdlabel (except to bootstap around UEFI, if that's an issue)?

I thought putting a bootme flag on the FreeBSD boot partition might help (particularly if it's an UEFI system which is supposed to look for bootme flags).

Code: 
gpart set -a bootme -i 1 ada0

This seemed to have no effect.

I tried installing bootcode, also to no effect.

Code: 
gpart bootcode -b /boot/pmbr -p /boot/gptboot -i ad4
(I belive I did -i ada0 as well)

I did the following, which didn't seem to cause damage or cure things, but, which might have been a mistake:

Code: 
gpart add -t freebsd-boot -l gpboot /dev -b 40 -s 512k da0

Question: Does it make any difference when partitioning and formatting whether a dedicated internal hdd for freebsd using these commands, assuming they are the correct commands, that the commands are issued in single user or multi-user mode from livefs memstick or from the memstick shell?

From the memstick shell, I tried to set the current boot device to the installed drive, without luck.

Code: 
set currdev=ada01

I am at the point where I need to learn more fundamentals before I can get a long-needed upgrade. To be clear, I don't want anything to do with the windows 7 that was pre-installed on the disc -- I don't want or need a dual booting system --, and, I don't want to lose any UEFI related data that might prevent the system from being able to boot at all. Thanks all in advance.
 
Re: Partitioning EUFI Systems with FreeBSD-Install Guided Se

A. You mean UEFI, the new type of BIOS, right? Never heard of EUFI.
B. UEFI secure boot will not be supported by FreeBSD until mid-2014, in version 10.1, judging by this article that quotes Kirk himself. But I don't know whether this also apples to non-secure-boot UEFI.
C. Your real problem seems to be that your motherboard is running a weird UEFI version, which doesn't allow turning BIOS compatible mode on, or turning secure boot off. On my systems with UEFI (which are all amd64 architecture), you have to turn BIOS-compatible mode on to do anything useful.
D. Your question about ada0 versus ad4: That's normal; the naming convention for ATA disks changed recently, and the old name is still printed. The rest of the dmesg output looks normal.
E. The gpart show output looks normal. Some of my disks have 3KiB free at the beginning, others don't.
F. I have only used gpt on FreeBSD 9.0, never needed fdisk or bsdlabel.
G. In your various "gpart" command, you are using da0 and ad4. Your disk is called ada0. I think in a normal system, /dev/adx still exists, and is a softlink to adax, but AFAIK, there is no longer a da0. You should probably issue all commands against ada0.
H. Whether you use single- or multi-user mode should not matter.

Hope any of these scattered hints help.
 
Re: Partitioning EUFI Systems with FreeBSD-Install Guided Se

It helps. Provides a little confidence when I contact Asus Tech support and find out why there's a security code preventing me from being able to install a bios firmware update and figure out more precisely what's with this particular bios. I did mean to say UEFI. Thanks. Avoids confusion. [add extraneous thanks, ratings, and smileys here]
 
fdisk ada0: confirms it's EFI GPT ??

doesn't the output of fdisk ada0 ("sysid 238 (0xee),(EFI GPT)"confirm that ada0 is UEFI GPT?

Code: 
******* Working on device /dev/ada0 *******
parameters extracted from in-core disklabel are:
cylinders=620181 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=620181 heads=16 sectors/track=63 (1008 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 238 (0xee),(EFI GPT)
    start 1, size 625142447 (305245 Meg), flag 0
	beg: cyl 0/ head 0/ sector 2;
	end: cyl 1023/ head 255/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

I've started a case with ASUS to troubleshoot, but, the tech support I spoke to said that UEFI would not be relevant to my system because it ships with Windows 7 and wasn't able to tell me whether there were any bios settings to enable or disable UEFI in my present bios version or in a newer bios version that is available.
 
Re: Partitioning UEFI Systems with FreeBSD-Install Guided Se

UEFI and GPT are two separate things. UEFI is a replacement for the BIOS, with new standards and a new way of operating. GPT is a disk partitioning format.

Yes, partition type 0xEE should indicate GPT. gpart show is the easy way to tell. fdisk(8) is old and really only understands the MBR. What it sees is the PMBR, which is technically not required with GPT.
 
Using a memstick to boot up the installed filesystem

I should note that this system is a consumer level nettop device that comes pre-installed with Windows 7. The descriptive name of the bios includes the words "Asus UEFI Bios Utlity". Most newer full blown asus motherboards with uefi bios ship with a bios utility that allows you to disable secure boot and to enable legacy bios mode. EB1033's, at least early shipped models, have a simplified, perhaps intermediate bios which does not have options to disable uefi mode. In the UEFI part of the bios settings, which might perhaps be in the firmware and not adjustable on the HDD anywhere, it wants to boot to windows or a customized boot loading system (perhaps something to hide the partition containing a recover cd). So for a system like this (assuming I will not be able to update to the latest bios and/or the latest bios would not allow disabling of uefi) there are two main ways I can use it, absent UEFI support in the development trunk, (1) boot from a memorystick, or, (2) set up a partitioning and filesystem scheme according to what's embedded in the firmware and/or use use a hybrid or bootstrap method to boot from a freebsd partition that is not on the first logical slice (as it is recognized by the bios) and/or install and configure a UEFI filesystem.

I needed to replace my server a couple months ago and need an operational system A.S.A.P., Option two seems overwhelmingly complex to me right now given my problems with option one. There's a possibility UEFI support will be available following an update around mid-summer and the system would boot normally once upgraded with UEFI support without the need to change or alter my filesystem/partitioning scheme further. For these and other logical reasons, I'd like to boot from a memory stick.

I can manually boot the kernel of the memstick and load and run FreeBSD off of ada0 following these steps:

  • boot up to boot menu and select "Escape to Loader Prompt" from the menu
  • Code: 
    set currdev=disk1
  • Code: 
    set rootdev=disk1
  • Code: 
    boot
  • It asks for the Mountpoint, manually enter
    Code: 
    ufs:ada0p2

Ideally, I need this system to boot non-interactively. That is, do what it does when I perform the above actions without having to perform the above actions.

I created /boot/loader.conf:
Code: 
set currdev=disk1
set rootdev=disk1

Setting these variables alone doesn't work. Booting from the livefs memstick image with these settings in /boot/loader.conf causes the system to hang with the message, "cannot find kernel." There should be someplace to set the root filesystem where kernel can be found. Where do you configure the mountpoint if you do not want to have to manually enter the mountpoint, e.g. ufs:ada0p2 in this case? I believe if I can just provide the loader with the correct mountpoint the system would be able to boot without human intervention.

It seems that /etc/fstab might be the place to set the mountpoint, but, I'd like to make sure. The fstab on the memstick has the following entry:
Code: 
/dev/ufs/FreeBSD_Install      /    ufs    ro,noatime   1   1

Would I simply change the mount point by changing this file and adding in the contents of fstab off of the non-booting system installed on the HDD as follows:
Code: 
/dev/ada0p2    /        ufs     rw    1    1
/dev/ada0p3    none   swap  rw    0    0

Or, is the mountpoint for the third stage boot up process specified somewhere other than fstab? (fstab entries being dynamically created)

The answer to my first question, "Is guided mode disk set up compatible with [firmware] UEFI [bios] systems containing a pre-installed os (whether or not secure boot is used)?" seems to be, to the extent the question is intelligible, "No." This is not a qualified 'no', however.

If I did not zero out the drive w/ windows 7 pre-installed prior to installing from the livefs memstick install image for FreeBSD 10 using the Guided Mode and selecting entire disk, could I be having problems that are completely unrelated to UEFI? Is this likely? Would it be a good idea to wipe the disk with the following command and reinstall using guided mode entire disk settings?

Code: 
dd if=/dev/zero of=/dev/ada0

My thought was that gpart did a good job of overwriting filesystem and bootcode data and it's not necessary to completely erase a hdd when your are repartitioning it and installing new partitions over the entire disk.

The bios was able to recognize the harddrive when I tried manually creating partitions and setting the first partition as an uefi partition and then adding gpt partitions for / and swap. It still would not boot from HDD, only from a memstick. I'm wondering if I want to ensure that after I've spent time setting this server up I might be able to boot off of the hdd without using the memstick whether I should not use guided mode, and set some space aside at the beginning of the disk so that I could add the appropriate bootcode/bootstraps once I figure out how to do that?
----------------------
Wikipedia: GUID Partition Table
Wikipedia: EFI System partition
 
Re: Partitioning UEFI Systems with FreeBSD-Install Guided Se

If the installer boots, Secure Boot and UEFI are non-issues.

If FreeBSD has been installed on that disk, adding this to /boot/loader.conf should be enough:
Code: 
vfs.root.mountfrom="ufs:ada0p2"
That is usually not necessary.

/etc/fstab still must be correct.
 
Using a Memory Stick as a Bootloader

wblock@ said:
If the installer boots, Secure Boot and UEFI are non-issues.
Click to expand...

How so? It's my understanding this UEFI bios will boot from any properly formatted USB device in legacy mode and it's just a problem when booting from a device where the bios is expecting a UEFI filesystem on the device, e.g. the internal hdd.

wblock@ said:
If FreeBSD has been installed on that disk, adding this to /boot/loader.conf should be enough:
Code: 
vfs.root.mountfrom="ufs:ada0p2"
Click to expand...

Thanks. This works. The only change to the freebsd 10 memstick livefs that must be made in order to use the memstick as a boot device is to add or create a /boot/loader.conf with vfs.root.mountfrom="ufs:ada0p2" (or appropriate device).

Now I would like to configure a bootonly usb stick with these settings so that I can use a cheap 250 mb usb device. Over five years of operation as a server, I doubt it's going to be rebooted more than a thousand times and it's not going to be writing to the usb so I'm better off with a couple < $5 usb keys than wasting a more useful 16gb memstick burned the livefs installer image to. I thought I'd start with the bootonly image as a template; something like that is all that's necessary for this hack around firmware UEFI issues.

Setting currdev and rootdev in loader.conf is not necessary.

wblock@ said:
/etc/fstab still must be correct.
Click to expand...

Yeah, it shouldn't be necessary to change what's been detected/created by sysinstall. I don't think mountpoints specified in fstab are used during boot stages ... seems it's done at /boot/loader.conf w/ vfs.root.mountfrom="ufs:ada0p2".

It seems this work-around might cause problems down the road when I want to upgrade to current release ... I'll probably have to keep the memstick kernel synchronized with the system kernel. It's not an elegant solution. I would prefer not to have to use a memorystick to boot the system.
 
Re: Using a Memory Stick as a Bootloader

unAmygdala said:
wblock@ said:
If the installer boots, Secure Boot and UEFI are non-issues.
Click to expand...

How so? It's my understanding this UEFI bios will boot from any properly formatted USB device in legacy mode and it's just a problem when booting from a device where the bios is expecting a UEFI filesystem on the device, e.g. the internal hdd.
Click to expand...

Just that: if it boots, then Secure Boot is disabled and UEFI is capable of booting from a "legacy" device.

It seems this work-around might cause problems down the road when I want to upgrade to current release ... I'll probably have to keep the memstick kernel synchronized with the system kernel. It's not an elegant solution. I would prefer not to have to use a memorystick to boot the system.
Click to expand...

Normally, /etc/fstab is found on the boot device and passed to the kernel. It may be possible to find a way to get that to work normally. Another option would be to find an alternate boot loader, like SYSLINUX or Grub.
 
Confirmation that it is a UEFI Issue

There should be more forum members who've tried installing FreeBSD onto a recent amd64 computer from Asus. Has anyone been able to install FreeBSD to an Asus amd64 UEFI enabled computer without having to enable legacy boot bios (and disabling secure boot) and/or manually partition the system with a UEFI filesystem to boot?

It's my understanding that FreeBSD will not boot in UEFI and that you have to (1) enable legacy boot, or, (2) manually create a UEFI partition and use that to bootstrap another partitioning scheme (mbrs & BSD labelling, or, gpt, or a hybrid with both mbrs/bsdlabelling and gpt.), or (3) use the UEFI development branch of FreeBSD instead of release/current (See"Moving forward by going slightly backwards and to the right, UEFI booting on #FreeBSD").

Asus Tech support and others have told me that I should not be having problems with UEFI because the Asus EB1033 is a Windows 7 system. Nevertheless, the bios descriptive name says "UEFI Bios". There are no indications that a problem is being caused by something else. As shipped, the bios recognizes that Windows 7 is installed on the disc and allows Windows 7 to boot. When I use guided mode, use entire disc, to install FreeBSD, it creates a freebsd boot partition in the first slice. The bios utility does not recognize that there is a harddrive installed; no harddrive appears in the bios boot manager.

I am confused because gpart and FreeBSD do support UEFI filesystems and there are methods to boot FreeBSD UEFI that involve custom partitioning schemes. It seems that in my testing, when I followed the manual partitioning install procedure and created a 1gb UEFI filesystem partition in the first slice and FreeBSD boot, /, and swap in the 2nd, 3rd, and 4th partitions, the bios utility recognized that there was a harddrive on the system. In otherwords, simply adding a UEFI filesystem in the first partition allowed the bios to recognized that there's a HDD installed, which is a big step in moving forward.

FreeBSD would not boot from the second partition because other than creating a UEFI filesystem in the first partition, I did not add any boot information to the UEFI system I created. I understand you have to write UEFI boot information to the UEFI filesystem, but, I have no understanding of what actually needs to be written to the UEFI filesystem/partition. The UEFI filesystem probably needs to be a specific size, and/or, has to be small -- 1gb was too big for me to add bootloaders to the UEFI filesystem.

I zero'd out the drive last night and did a re-install using guided mode, select entire disk just to rule out any possibility that data on the disk is causing a problem rather than being a UEFI issue.
 
Resolved Using Semi-Guided Manual MBR Patitioning

I'll update this comment in the next couple of days with easy to use screen pictures, but, for now, I just wanted to outline a solution for a self-booting installation of FreeBSD on a asus eb1033 and other's with the Ausus UEFI Bios Utility 5010 that do not have access to legacy boot ability.

[Links to related threads, issues ... There's a few related threads to this one.] I found a reference where someone had resolved the issue using an MBR partitioning scheme.

From the liveFS memstick installer, I selected manual partitioning (advanced -- this is called 'advanced' because it's not guided, but, it's still guided with a GUI interface and is not truly advanced manual like the partitioning shell is for direct use of partitioning commands. Still using only the install interface, I used 'create' and (1) created a MBR filesystem over the entire drive, (1) created a freebsd-ufs slice mounted at / over all but 4 GB (294GB), and, (3) created a freebsd-swap slice over the remaining 4 GB. Then I selected Finish and proceeded with the installation.

My understanding is that UEFI is backwards compatible with MBR (a dos based filesystem), that GPT is a different partitioning scheme, and that in order to use GPT with UEFI on a system where you cannot change to legacy boot mode in the CSM, you'll need to wait until UEFI is [incorporated into the trunk.]

So, at the cost of not being able to use the GPT partitioning scheme, there is at least one workaround for UEFI only amd64 systems that avoids the necessity to boot from a USB stick.

What are the security and performance implications for using a DOS based MBR partitioning scheme over GPT on a single dedicated disk system?
 
Re: Resolved Using Semi-Guided Manual MBR Patitioning

unAmygdala said:
What are the security and performance implications for using a DOS based MBR partitioning scheme over GPT on a single dedicated disk system?
Click to expand...

Almost none, really. At present, FreeBSD does not support UEFI's Secure Boot, so that is a moot point.

Performance can have one difference. Currently, FreeBSD forces strict CHS slice alignment when creating an MBR. On drives with 4K blocks, this usually creates misaligned partitions. Write performance can be less than half of what the drive can really do. That is only an issue if the drive has 4K blocks. True block size can be checked with diskinfo -v | grep stripesize. If that reports 0, no problem. If it says 4096, prepare to repartition.

The typical layout of FreeBSD on MBR is to use a single slice, subdividing it with FreeBSD partitions. There is no performance difference with that, either, it just lets FreeBSD divide the disk into more than the four slices provided by MBR. However, those FreeBSD partitions can be aligned to 4K blocks, giving a workaround to the problem of misaligned slices.
 
Re: Resolved Using Semi-Guided Manual MBR Patitioning

unAmygdala said:
My understanding is that UEFI is backwards compatible with MBR (a dos based filesystem), that GPT is a different partitioning scheme, and that in order to use GPT with UEFI on a system where you cannot change to legacy boot mode in the CSM, you'll need to wait until UEFI is [incorporated into the trunk.]
Click to expand...
I don't think this is correct. I have a UEFI system booting a GPT disk with FreeBSD. I do have to use legacy boot mode but it works without any issues. I did have some issues getting Windows 7 to boot again. Apparently some UEFI implementations will automatically switch to legacy boot when they detect an active MBR partition. GPT creates a 'fake' MBR partition for backwards compatibility. Removing the 'active' bit from the 'fake' MBR partition solved my Windows 7 boot issues.
 
Re: Installing on UEFI amd64 with bios only supporting UEFI

I do have to use legacy boot mode.
Click to expand...

I'm sorry I don't have a clear enough understanding of technical terms to use them precisely. My issue relates certain trimmed down UEFI bios' that lack a user option to switch from UEFI boot mode to legacy boot mode. Everything I've encountered so far leads me to believe that you cannot boot GPT partitioned amd64 system in UEFI mode with FreeBSD production/release.
 
Re: Installing on UEFI amd64 with bios only supporting UEFI

You can't UEFI boot FreeBSD, that has nothing to do with GPT or MBR. You can also UEFI boot MBR. All UEFI requires is a FAT16/32 partition with some special files on it.

It's only Windows that has to be UEFI booted before it's able to use GPT.
 
Re: Confirmation that it is a UEFI Issue

unAmygdala said:
There should be more forum members who've tried installing FreeBSD onto a recent amd64 computer from Asus. Has anyone been able to install FreeBSD to an Asus amd64 UEFI enabled computer without having to enable legacy boot bios (and disabling secure boot) and/or manually partition the system with a UEFI filesystem to boot?

It's my understanding that FreeBSD will not boot in UEFI and that you have to (1) enable legacy boot, or, (2) manually create a UEFI partition and use that to bootstrap another partitioning scheme (mbrs & BSD labelling, or, gpt, or a hybrid with both mbrs/bsdlabelling and gpt.), or (3) use the UEFI development branch of FreeBSD instead of release/current (See"Moving forward by going slightly backwards and to the right, UEFI booting on #FreeBSD").

Asus Tech support and others have told me that I should not be having problems with UEFI because the Asus EB1033 is a Windows 7 system. Nevertheless, the bios descriptive name says "UEFI Bios". There are no indications that a problem is being caused by something else. As shipped, the bios recognizes that Windows 7 is installed on the disc and allows Windows 7 to boot. When I use guided mode, use entire disc, to install FreeBSD, it creates a freebsd boot partition in the first slice. The bios utility does not recognize that there is a harddrive installed; no harddrive appears in the bios boot manager.

I am confused because gpart and FreeBSD do support UEFI filesystems and there are methods to boot FreeBSD UEFI that involve custom partitioning schemes. It seems that in my testing, when I followed the manual partitioning install procedure and created a 1gb UEFI filesystem partition in the first slice and FreeBSD boot, /, and swap in the 2nd, 3rd, and 4th partitions, the bios utility recognized that there was a harddrive on the system. In otherwords, simply adding a UEFI filesystem in the first partition allowed the bios to recognized that there's a HDD installed, which is a big step in moving forward.

FreeBSD would not boot from the second partition because other than creating a UEFI filesystem in the first partition, I did not add any boot information to the UEFI system I created. I understand you have to write UEFI boot information to the UEFI filesystem, but, I have no understanding of what actually needs to be written to the UEFI filesystem/partition. The UEFI filesystem probably needs to be a specific size, and/or, has to be small -- 1gb was too big for me to add bootloaders to the UEFI filesystem.

I zero'd out the drive last night and did a re-install using guided mode, select entire disk just to rule out any possibility that data on the disk is causing a problem rather than being a UEFI issue.
Click to expand...
I've been able to install FreeBSD on UEFI with Secure Boot disabled, if I also enable the BIOS. I'm not at home, and my laptop only has BIOS. But UEFI Secure Boot is evil. Whoever thought of "Secure Boot" should have been required to leave the US instead of Snowden.
 
Re: Resolved Using Semi-Guided Manual MBR Patitioning

wblock@ said:
True block size can be checked with diskinfo -v | grep stripesize. If that reports 0, no problem. If it says 4096, prepare to repartition.
Click to expand...

Code: 
$ diskinfo -v ada0 | grep stripesize
        4096            # stripesize
$

Now I am concerned. Until now, the only thing I've notice from a user perspective is that a dos based filesystem with mbr partition takes longer to sync discs when the system is shutting down abnormally ... it writes out individual blocks to the screen and is otherwise using a different syncing method than with a gpt partitioned system ... the output is similar to FreeBSD 3 or 4 back in 1998.

Although I am using a 4096 stripesize, I do not notice abnormally slow disc read and writes. I mean, if you had not informed me that I might be, or am, experiencing abnormally slow disc read and writes because I am using a 4096 stripe size, I would never have suspected that there's something seriously wrong with my filesystem. How can I check that my system is having performance problems due to a poorly formatted disc? I can probably perform any of the following disc tests from benchmarks/phoronix-test-suite, but I would want to perform a test that someone else could interpret:

  • hdparm
  • Timed Disk Reads
  • Unpacking The Linux Kernel
  • Threaded I/O Tester
  • SQLite
  • PostMark
  • IOzone
  • Flexible IO Tester
  • FS-Mark
  • Dbench
  • Compile Bench
  • BlogBench
  • AIO-Stress

I might have to open the EB1033 up to get the model number and references to for the specs on the Sata II drive. If you have suggestions as to what I can do to figure out if I am getting sub-par disk performance, I'd like to know. I recognize that in using dos based file system with mbr I'm going to have different performance and am willing to accept a performance drop of 90%, but, if I could be having better performance that I seem to already be having, I would appreciate help on how I can be more efficient with my energy use.
 
Re: Installing on UEFI amd64 with bios only supporting UEFI

If ada0 is partitioned as shown in the first post in this thread, it's fine. The starting block and size of both the UFS and swap partitions are aligned to 4K blocks. Performance is only a problem when the partitions are not evenly aligned with the disk blocks. Mostly that happens with MBR.

Otherwise, please show the current output of gpart show.
 
Re: Installing on UEFI amd64 with bios only supporting UEFI

The first topic in this thread shows a GPT filesystem. The MBR filesystem looks like this.

Code: 
$ gpart show
=>       63  625142385  ada0  MBR  (298G)
         63         63        - free -  (32K)
        126  624951180     1  freebsd  [active]  (298G)
  624951306     191142        - free -  (93M)

=>        0  624951180  ada0s1  BSD  (298G)
          0  616562688       1  freebsd-ufs  (294G)
  616562688    8388491       2  freebsd-swap  (4.0G)
  624951179          1          - free -  (512B)

If I understand sufficiently, I should be okay because the stripe offsets for ada0 are 0 for the MBR filesystem (as well as when the disk was formatted as a GPT system). I don't see anything out of whack here, but, I can't tell.

Code: 
$ gpart list
Geom name: ada0
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 625142447
first: 63
entries: 4
scheme: MBR
Providers:
1. Name: ada0s1
   Mediasize: 319975004160 (298G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 3072
   Mode: r2w2e3
   attrib: active
   rawtype: 165
   length: 319975004160
   offset: 64512
   type: freebsd
   index: 1
   end: 624951305
   start: 126
Consumers:
1. Name: ada0
   Mediasize: 320072933376 (298G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r2w2e5

Geom name: ada0s1
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 624951179
first: 0
entries: 8
scheme: BSD
Providers:
1. Name: ada0s1a
   Mediasize: 315680096256 (294G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 3072
   Mode: r1w1e1
   rawtype: 7
   length: 315680096256
   offset: 0
   type: freebsd-ufs
   index: 1
   end: 616562687
   start: 0
2. Name: ada0s1b
   Mediasize: 4294907392 (4.0G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 3072
   Mode: r1w1e0
   rawtype: 1
   length: 4294907392
   offset: 315680096256
   type: freebsd-swap
   index: 2
   end: 624951178
   start: 616562688
Consumers:
1. Name: ada0s1
   Mediasize: 319975004160 (298G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 3072
   Mode: r2w2e3

Probing for specific characteristics seems like a better way to diagnose filesystem performance than using a benchmark. I believe only a few of the benchmarks listed above would work without installing additional binaries and they would probably only show poor performance, not the reason for it. Thank you.
 
Re: Installing on UEFI amd64 with bios only supporting UEFI

I may be mistaken (it's a tricky subject after all) but it looks like your freebsd slice is starting at block 126. That would be a 63 KB offset. That doesn't divide well with either 4 or 8 KB sectors. I think the offset should have been 128, or 64 K. That's nicely dividable by both 4 and 8 K.
 
Re: Installing on UEFI amd64 with bios only supporting UEFI

gpart(8) forces MBR slices to CHS alignment, as specified by the MBR standard. On modern drives, CHS values have no meaning, and usually default to 63 sectors per track, which is almost never aligned with 4K blocks.

On ada0, the slice starts at 126. As @SirDice says, that is not evenly aligned with 4K blocks. But there is another level of partitioning, the BSDlabel inside that slice. The starting block of the freebsd-ufs partition is zero. So that partition starts at block 126+0, still not aligned.

However, this is a Seagate drive with their "SmartAlign" feature, which claims to make 4K block alignment unnecessary. I've researched that before, and it seems to work. In this case, I'd leave it alone. For the future, see Disk Setup On FreeBSD, which shows how to create aligned partitions for either GPT or MBR.
 
Last edited by a moderator:
Re: Installing on UEFI amd64 with bios only supporting UEFI

wblock@ said:
gpart(8) forces MBR slices to CHS alignment, as specified by the MBR standard. On modern drives, CHS values have no meaning, and usually default to 63 sectors per track, which is almost never aligned with 4K blocks.

On ada0, the slice starts at 126. As @SirDice says, that is not evenly aligned with 4K blocks. But there is another level of partitioning, the BSDlabel inside that slice. The starting block of the freebsd-ufs partition is zero. So that partition starts at block 126+0, still not aligned.
Click to expand...

There are even more complications to that §e The first partition shows to be starting from offset 0 inside the slice ada0s1. However, the first 16 blocks of the slice are reserved for the bootcode /boot/boot and there's some "magic" done to make sure those 16 blocks are never overwritten even if the first partition overlaps with the area. Luckily the 16 blocks don't change the alignment because 16 512B sectors makes up a multiple of 4096 bytes.

More and more reasons to migrate to GPT...
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top