Bug 198642

Summary:	EFI boot yields various error messages
Product:	Base System	Reporter:	cipher_nl
Component:	misc	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Some People	CC:	benno, emaste, jhb
Priority:	---
Version:	10.1-RELEASE
Hardware:	amd64
OS:	Any

Description cipher_nl 2015-03-16 19:00:35 UTC

I'm trying to get EFI boot working by following the document: https://wiki.freebsd.org/UEFI

It roughly says:
gpart create -s gpt da0
gpart add -t efi -s 800K da0
gpart add -t freebsd-ufs da0
dd if=/boot/boot1.efifat of=/dev/da0p1
newfs /dev/da0p2

I created a USB Stick roughly using the guideline above, but use a MFSroot on the UFS partition instead, and have partitions aligned to 1024K-boundaries. Then, i used RaWrite to create the USB stick.

When trying to boot my USB stick on two real hardware systems (J1900) however, it first yields an error message that it cannot load /boot/loader.conf, and when it tries to load /boot/kernel/kernel, i get random error messages from the the following list:

---
inflate: invalid code lengths set
invalid distance too far back
invalid distance code
inflate: invalid stored block lengths
readin failed. elf64_loadimage: read failed
inflate: invalid block type
---

The strange thing is that trying to boot (OK loader prompt) will yield a different error. I would expect getting the same error from the same input. It appears the error is randomly chosen from the above list. Maybe this is a clue?

I am using a preloaded mfsroot. I saw some recent commits to HEAD (r279929) about addressing some issues with EFI staging area. But i'm not sure this is the problem, since the loader cannot load /boot/loader.conf or even the kernel itself. So loading the mfsroot of about 10MB would probably not be the issue?

Having a working EFI boot is important, since some motherboards will not boot from MBR bootsector when GPT partitions are detected, or do not support MBR-style boot at all and insist on EFI boot.

Comment 1 John Baldwin freebsd_committer

2015-03-16 19:13:35 UTC

gzipfs is not going to work without the changes in 279949 (the inflate messages are errors from gzipfs).  You can try unzipping the kernel to see if that
allows the kernel to work, but in general I'd recommend grabbing both 279949 and 279929 (the latter will at least report errors if your mfsroot is too large).

Comment 2 cipher_nl 2015-03-16 19:16:32 UTC

I indeed used a gzipped kernel (kernel.gz) but i also tried with an unzipped kernel. I guess the mfsroot itself may also not be gzipped?

Is it possible to update the wiki UEFI page (wiki.freebsd.org/UEFI) to reflect that GZIP-compressed kernel/mfsroot is not supported at this time?

Comment 3 John Baldwin freebsd_committer

2015-03-16 20:08:46 UTC

It's supported now. :)

Either try unzipping both the kernel and mfsroot, or build an updated loader.efi from HEAD.

Comment 4 cipher_nl 2015-03-16 21:29:11 UTC

Just tried with recent HEAD and it works perfectly without any problems, using a gzipped kernel and gzipped mfsroot.

Now two issues i still want to investigate:

1) i compiled the HEAD with EFI_STAGING_SIZE=64 to increase the staging area to 64MiB instead of the 32MiB default. Maybe this increase is not necessary.

2) using the /boot/efiboot.fat file from HEAD on other branches like STABLE/10. This would allow booting 9.x and 10.x as well, if it works.

Thanks for the help John Baldwin!