FreeBSD and UEFI?

On 03/10/2013, at 7:46 AM, Michael Copeland <michael at kryptos-security.com> wrote:

> Hmm
> Should I build with GCC?
>
Yes, the in-tree version of clang doesn't understand __attribute__((ms_abi)) and so it won't generate the Microsoft function call code that UEFI expects. You'll need gcc >= 4.7 so you'll need it from ports. This has been one of the blockers on getting it done (beyond my lack of time).

Cheers,
Benno.
Click to expand...
With the Microsoft reference we are back on the reason, this thread was started. I'm happy without UEFI. In fact I took the opportunity to install Windows 7 back on MBR. Works fine here and no BIOS manual switching is required.
Recent Windows versions are known, that they do not wait until the user mounts a hot plugged removable disk device. It not only tries to get information from that device, but even tries to write on it. Therefore I feel much more secure if Windows does not touch/search/index my removable FreeBSD disks at all.
 
A FreeBSD 9.2-RELEASE installation with GPT, did not boot when UEFI was enabeled. It was required to disable UEFI in order to have any use oft it.
 
Ah, but that's not necessarily due to FreeBSD 9.2. Clearing the active flag on the PMBR may make it work: gpart clear -a active ada0
 
wblock@ said:
Ah, but that's not necessarily due to FreeBSD 9.2. Clearing the active flag on the PMBR may make it work: gpart clear -a active ada0
Click to expand...

Your command is some sort of pseudo code that could be understood by humans but not by the gpart() tool, which has implemented

gpart set -a attrib -i index [-f flags] geom
gpart unset -a attrib -i index [-f flags] geom

gpart clear is not known by gpart.

Activating is a term used in the MBR environment. As far as I understand GPT schemes there is no such thing. At least with GPT scheme it is different.

In gptboot() can be read:
PARTITION ATTRIBUTES
gptboot checks and manages several attributes of GPT UFS partitions.

bootme Attempt to boot from this partition. If more than one partition has the bootme attribute set, gptboot will attempt to boot each one until successful.

bootonce Attempt to boot from this partition only one time. Setting this attribute with gpart(8) automatically also sets the bootme attribute. Multiple partitions may have the bootonce and bootme attributes set.

bootfailed The bootfailed attribute marks partitions that had the bbootonce attribute set, but failed to boot. This attribute is managed by the system. See BOOTING and POST-BOOT ACTIONS below for details.

USAGE
For normal usage, the user does not have to set or manage any of the partition attributes. gptboot will boot from the first UFS partition found.
Click to expand...

So ada0p1 should not have any attributes by default and it has none, as can been seen:

Code: 
#> gpart list ada0
Geom name: ada0
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 488397134
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: ada0p1
   Mediasize: 524288 (512k)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 20480
   Mode: r0w0e0
   rawuuid: d100e823-2e89-11e3-9ba8-e069956961c1
   rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
   label: gptboot
   length: 524288
   offset: 20480
   type: freebsd-boot
   index: 1
   end: 1063

Your turn :)
 
The problems is that the GEOM provider that represents the GPT partitioned disk hides the protective MBR and all the partition table entries in it so it's not possible to edit the protective MBR or it's properties directly while the GEOM class instance that handles the GPT partitioned disk has a lock on the disk. You can possibly use the old fdisk(8) to edit the PMBR but it would have to be done in single user mode or from a rescue media.
 
You mean change the flag 80 to zero?

fdisk() allows only to set the flag to a partition

Code: 
#> fdisk -a /dev/ada0p1
******* Working on device /dev/ada0p1 *******
parameters extracted from in-core disklabel are:
cylinders=1 heads=16 sectors/track=63 (1008 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=1 heads=16 sectors/track=63 (1008 blks/cyl)

fdisk: invalid fdisk partition table found
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 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 945 (0 Meg), flag 80 (active)
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 0/ head 15/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
Partition 1 is marked active
Do you want to change the active partition? [n] y
Supply a decimal value for "active partition" [1] 0
Active partition number must be in range 1-4.  Try again.
 
No, don't use it on the ada0p1 partition but on the whole disk ada0. The partition type should be

Code: 
sysid 238 (0xee),(EFI GPT)
.

I'm wondering however if the FreeBSD fdisk(8) actually allows the clearing of the active flag alltogether. Linux fdisk does I'm pretty sure so you could try some Linux live CD.
 
Erratus said:
You mean change the flag 80 to zero?

fdisk() allows only to set the flag to a partition
Click to expand...
Correct. I ran into this myself some time ago. I had to manually 'unset' that flag to get my system booting again.

Thread 35897
 
I found this tool which might do the job: sysutils/gdisk
And an informative site on this theme: http://www.rodsbooks.com/gdisk/hybrid.html

Here is a first dry run:

Code: 
#> gdisk /dev/ada0
GPT fdisk (gdisk) version 0.8.6

NOTE: Write test failed with error number 1. It will be impossible to save
changes to this disk's partition table!
You may be able to enable writes by exiting this program, typing
'sysctl kern.geom.debugflags=16' at a shell prompt, and re-running this
program.

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Recovery/transformation command (? for help): o

Disk size is 488397168 sectors (232.9 GiB)
MBR disk identifier: 0x00000000
MBR partitions:

Number  Boot  Start Sector   End Sector   Status      Code
   1                     1           39   primary     0xEE
   2                    40         1063   primary     0xA5
   3                  2048    488397127   primary     0xA5

Command (? for help): r

Recovery/transformation command (? for help): h

WARNING! Hybrid MBRs are flaky and dangerous! If you decide not to use one,
just hit the Enter key at the below prompt and your MBR partition table will
be untouched.

Type from one to three GPT partition numbers, separated by spaces, to be
added to the hybrid MBR, in sequence: 1 2
Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): [red]y [/red]

Creating entry for GPT partition #1 (MBR partition #2)
Enter an MBR hex code (default A5):
Set the bootable flag? (Y/N): [red]n[/red]

Creating entry for GPT partition #2 (MBR partition #3)
Enter an MBR hex code (default A5):
Set the bootable flag? (Y/N): [red]n[/red]

Unused partition space(s) found. Use one to protect more partitions? (Y/N): [red]n[/red]

Recovery/transformation command (? for help): q

As I’m still uncertain if I choose the right options and still thinking about possible side effects like this:
Note that even with the extra protective partition, significant parts of a disk could go unprotected. In the case of this example, it's just a few sectors at the end of the disk; however, if you hybridize two non-contiguous partitions, the last of which is not at the end of the disk, either the partitions at the end of the disk or the space between the partitions will be unallocated in an MBR sense.
Click to expand...
comments are welcome.
 
Sorry, I cut a sample from email that was wrong. But it was close, should have been gpart unset -a active ada0. You will need a recent 9-STABLE to be able to use that.

Don't use hybrid MBRs, that combines the worst features and problems of both.

Edit: finally fixed, not "clear" but "unset".
 
wblock@ said:
Sorry, I cut a sample from email that was wrong. But it was close, should have been gpart clear -a active ada0. You will need a recent 9-STABLE to be able to use that.

Don't use hybrid MBRs, that combines the worst features and problems of both.
Click to expand...

I do not see any difference to post 30. Did you edit it?
So gpart clear is not implemented in 9.2-RELEASE.

Manually editing the raw device should also be possible, but how?
 
I decided to do an experiment by putting FreeBSD 9.1 on a USB hard drive, with a full GPT partitioning scheme and it booted. Yet it's never worked whenever it's installed to the main drive?
 
zspider said:
I decided to do an experiment by putting FreeBSD 9.1 on a USB hard drive, with a full GPT partitioning scheme and it booted. Yet it's never worked whenever it's installed to the main drive?
Click to expand...

USB uses just it's own interface. If I remember it right, what I've learned in the past days, booting from USB is like booting from BIOS legacy. So you should check your BIOS setup regarding UEFI, when using the "main" interface (i.e. ad*).
 
Erratus said:
USB uses just it's own interface. If I remember it right, what I've learned in the past days, booting from USB is like booting from BIOS legacy. So you should check your BIOS setup regarding UEFI, when using the "main" interface (i.e. ad*).
Click to expand...

UEFI can't be disabled on this version of the AMI BIOS, it used to be you could, but they took that option away judging by screenshots of menus past. Thanks for the tip about the USB, I'm glad I didn't tear down a working system just to see if it would work.
 
So you updated your BIOS and lost disabling UEFI? Then I would look at the release notes of the BIOS versions of your mainboard and look if you can load an legacy BIOS version, that does not affect problems you might have had.
Some people update without any need their BIOSes, just for having a newer one. This is generally not advisable to do, unless you have a problem on the system you have to solve.
 
Erratus said:
I do not see any difference to post 30. Did you edit it?
So gpart clear is not implemented in 9.2-RELEASE.
Click to expand...

No, it should be "unset". Edited now

Manually editing the raw device should also be possible, but how?
Click to expand...

Read the PMBR into a file, modify, then write it back out. But that requires knowledge of the construction of the PMBR.
 
zspider said:
I decided to do an experiment by putting FreeBSD 9.1 on a USB hard drive, with a full GPT partitioning scheme and it booted. Yet it's never worked whenever it's installed to the main drive?
Click to expand...

Interesting ... Was it your BIOS handing over to the USB drive or was it the boot0 loader on the HDD?
 
vanessa said:
Interesting ... Was it your BIOS handing over to the USB drive or was it the boot0 loader on the HDD?
Click to expand...

I have different hostnames for each install, so when it booted I was able to tell immediately that it indeed booted from the external drive.;)

Erratus said:
So you updated your BIOS and lost disabling UEFI? Then I would look at the release notes of the BIOS versions of your mainboard and look if you can load an legacy BIOS version, that does not affect problems you might have had.
Some people update without any need their BIOSes, just for having a newer one. This is generally not advisable to do, unless you have a problem on the system you have to solve.
Click to expand...

Actually ironically I think the reason I updated it (quite a while ago) was to see if I could get that option, going back isn't really a good idea, especially when many of the updates involve "thermal protection" or "thermal policies". I'm fine with the MBR way as long as the sectors can be 4k aligned and as far as I can tell, they are.
 
You must log in or register to reply here.
Back
Top