maya@ wrote:
> Module Name: src
> Committed By: maya
> Date: Tue Apr 16 16:13:45 UTC 2024
>
> Modified Files:
> src/distrib/amd64/liveimage/emuimage: Makefile rc.conf.emuimage
> spec.emuimage
>
> Log Message:
> restore amd64 live image support for resize root after combined mbr/gpt commit
>
> we need to resize_gpt now, as it takes precedence over mbr/disklabel
> this change brings us to behave like the evbarm images.
>
> XXX: we don't seem to touch disklabel and MBR, but they exist. Not sure
> whether
> that has any negative repercussions, maybe another system might regard MBR as
> the
> sole source of truth when GPT also exists.
Actually disklabel or MBR does NOT exist in USE_GPT=YES case.
In src/distrib/common/bootimage/Makefile.bootimage,
both ${TOOL_FDISK} and ${TOOL_DISKLABEL} are only invoked
inside .if ${USE_GPT} == "no".
"${TOOL_GPT} biosboot -c /usr/mdec/gptmbr.bin" by USE_GPTMBR=yes
does all the tricks, i.e. gptmbr.bin in the MBR sector just reads
the first sector of the specified GPT partition:
https://github.com/NetBSD/src/blob/124fe5e/sys/arch/i386/stand/mbr/gptmbr.S
and the loaded pbr.S in the primary bootxx checks a GPT partition table
and loads the whole (~8KB) the primary bootxx:
https://github.com/NetBSD/src/blob/124fe5e/sys/arch/i386/stand/bootxx/pbr.S#L134-L135
https://github.com/NetBSD/src/blob/124fe5e/sys/arch/i386/stand/bootxx/pbr.S#L372-L380
Maybe this is the reason why some odd machines cannot boot UEFI images
(such ugly implemantations might assume MBR partition really exists).
---
Izumi Tsutsui
