Re: CURRENT: EFI boot failure

From: O. Hartmann <ohartman_at_zedat.fu-berlin.de>
Date: Fri, 19 Sep 2014 15:22:07 +0200
Am Wed, 17 Sep 2014 01:25:07 +0300
Andriy Gapon <avg_at_FreeBSD.org> schrieb:

> On 17/09/2014 00:32, Ed Maste wrote:
> > On 16 September 2014 17:03, O. Hartmann <ohartman_at_zedat.fu-berlin.de> wrote:
> >>
> >> In that case, is it still /boot/boot1.efifat or is it /boot/boot1.efi? What is the
> >> difference? Is the efi partition FAT?
> > 
> > An EFI system partition (ESP) is a FAT-formatted partition with a
> > specific GPT or MBR identifier and file system hierarchy; EFI firmware
> > will try to load /EFI/BOOT/BOOTX64.EFI from the ESP.
> 
> A very useful read about how EFI boot process works and how different OSes boot
> on top of it:
> http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html
> 
> > boot1.efi is an EFI application - that is, a PECOFF format binary.  It
> > searches for a UFS filesystem and loads loader.efi from that.  It is
> > intended to simplify the UEFI boot process, so that loader.efi, the
> > .4th files, loader.conf etc. do not all need to be installed in the
> > ESP.
> > 
> > boot1.efifat is a FAT filesystem image that contains a copy of
> > boot1.efi as /EFI/BOOT/BOOTX64.EFI.  It exists so that the installer
> > can treat it as opaque bootcode, like other boot schemes.  It's
> > certainly possible to create a partition, use newfs_msdos to format
> > it, and copy in boot1.efi instead.
> > 
> >> It is one disk, dedicated to FreeBSD (a laptop disk). Is there any documentation
> >> readable for non-developer for that matter? I'm curious about how EFI works on
> >> FreeBSD.
> > 
> > Better user-facing documentation is in progress; for now the best
> > source is probably the wik.
> > _______________________________________________
> > freebsd-current_at_freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> > 
> 
> 

The problem I reported about in the first place is triggered by a faulty loader.efi that
arises, when optimisation level is -O3. -O2 works fine.

I also realized that there is a kind of inconsistency in how COPTFLAGS and CFLAGS are
handled in reality compared to that what the manpage of make.conf states. Setting
COPTFLAGS=-O2 for compiling kernel stuff only ALWAYS incorporates CFLAGS, which is set to
CFLAGS=-O3 in make.conf in my case. loader.efi is, in my opinion, kernel stuff only as
well as kernel modules, which also gets compiled with CFLAGS.

Received on Fri Sep 19 2014 - 11:22:41 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:52 UTC