Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/distrib/amd64/liveimage/emuimage



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


Home | Main Index | Thread Index | Old Index