Bug 239620 - 12-STABLE: boot failure due to bootloader issue on PCengine APU2C4 ( > r349288)
Summary: 12-STABLE: boot failure due to bootloader issue on PCengine APU2C4 ( > r349288)
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.0-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2019-08-03 17:38 UTC by O. Hartmann
Modified: 2019-08-14 15:14 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description O. Hartmann 2019-08-03 17:38:25 UTC
Using NanoBSD to create a 12-STABLE customized, efficient image for a small routing and firewall appliance, results lately in a boot loader failure at the very beginning of the boot process on a PCengine APU2C4.

The APU2C4 is equipted with 4 GB RAM, the latest firmware image available at https://pcengines.github.io/ , which is at the time of writing this PR v4.9.0.7, comprised of coreboot v4.9.0.7 and SeaBIOS 'rel-', see URL above.

The NanoBSD is booted from an internal SD card, the image is flashed via dd. 

SeaBIOS (version rel-

Press F10 key now for boot menu

Booting from Hard Disk...

 onsoles: internal video/keyboard   
 IOS drive C: is disk0 
 IOS drive D: is disk1 
 IOS 639kB/3404444kB available memory 
 reeBSD/x86 bootstrap loader, Revision 1.1  
 Mon Apr 15 21:28:11 CEST 2019 root@thor) 
 anic: free: guard2 fail @ 0x1000 + 2311663946 from Xçu0ç}4çl$♦├í@┤♠:2106163957 
 -> Press a key on the console to reboot <--   

The last known good revision of 12-STABLE is r349288 which boots fine on the APU2C4 with the above installed firmware version (v4.9.0.7). Starting with r350274 (not necessarily the first culprit revision) the above shown error occurs.
Comment 1 O. Hartmann 2019-08-14 15:14:45 UTC
I found the cause of this problem.

When compiling world with the option


the result is a broken loader unwilling to boot a legacy MBR system on this specific piece of hardware. I have enabled this option also on an older Core2duo based Fujitsu server, booting off from an mfi0 handled volume (MBR, this type of hardware is BIOS driven and can not handle secure boot or any fancy UEFI stuff) without problems.

Disabling the option mentioned above (with all the consequences as described in src.conf) results in a working loader as expected.