Created attachment 214543 [details]
The UFS partition of the i386 memstick.img is missing the boot flag.
I observed a failure on a Lenovo X220 while attempting to use FreeBSD-13.0-CURRENT-i386-20200521-r361307-mini-memstick.img.xz due to this issue; the system reported
Press any key to reboot
Fixed by running from another machine:
# gpart set -a active -i 2 da0
This patch looks correct and I'll take care of it; we'll also need to figure out how far back this broke.
It looks like this was probably introduced by r342283 which added a 2nd partition to the i386 memstick. That change was actually a mistake for i386 though, as we do not have any EFI boot support for i386, so we should revert the i386 part of r342283.
By default mkimg makes the first partition active, if no -a flag:
# gpart show md0
=> 1 712744 md0 MBR (348M)
1 66584 1 efi [active] (33M)
66585 646160 2 freebsd (316M)
We need to at least revert the i386 part of r342283, which will restore the active flag on the bootcode-containing UFS partition. We may want to also explicitly specify `-a 1` in the hope that someone making a change similar to r342283 in the future will realize the need to update it, but it's not strictly necessary.
A commit references this bug:
Date: Sun May 24 18:25:50 UTC 2020
New revision: 361437
Make i386 memstick images bootable.
This reverts the i386 part of r342283, "Rework UEFI ESP generation", and
the followup commit in r342690.
r342283 added an ESP to the i386 memstick image, and as a side effect
made the ESP the active partition, not the bootcode-containing UFS
partition. As a result the i386 memstick images would not boot in
either UEFI or legacy mode - UEFI failed because we do not support i386
UEFI booting, and legacy mode failed because the partition with legacy
bootcode was not active.
The bootcode-containing UFS partition is again the only, and active,
Reported by: Jorge Maidana
Differential Revision: The FreeBSD Foundation