Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot

[RVP <rvp%SDF.ORG@localhost>]

On Thu, 7 Jul 2022, br0nko wrote:

> I wanted to resurrect an old i386 alix box, and I did follow the
> guide to create a custom image trough mkimage
> (https://www.netbsd.org/docs/guide/en/chap-inst-media.html#chap-inst-media-creating-live-images).
> I did first try on amd64 so that I can first test on my laptop.
> Build was successful but when I boot the USB key, I'm stuck on
> primary bootstrap ("NetBSD/x86 ffsv1 Primary Bootstrap"), no error.
> However I can boot it from grub (installed on the laptop hard-drive),
> image is fully functional that way.

Right. After ~10 hours of doing `build.sh release' I have a patch. However,
I'm not at all certain that this script is meant to be used on the x86 arch.
because:

a) It only seems to be used by the evbarm and evbmips builds.

b) `build live-image' already works (better!) than this script.

c) it does very odd things:
1. writes a partition table and an MBR.
2. promptly over-writes it with the primary bootstrap (PBR) and the
   disklabel, so the system actually boots directly from the PBR.

Still, here's the patch:

---
diff -urN a/distrib/utils/embedded/mkimage b/distrib/utils/embedded/mkimage
--- a/distrib/utils/embedded/mkimage	2021-09-25 08:54:30.000000000 +0000
+++ b/distrib/utils/embedded/mkimage	2022-07-10 08:18:03.575853000 +0000
@@ -255,7 +255,7 @@
 	echo ${bar} Populating ffs filesystem ${bar}
 	${MAKEFS} -rx ${endian} -N ${release}/etc -t ffs \
 	    -O ${ffsoffset} \
-	    -o d=4096,f=8192,b=65536 -b $((${extra}))m \
+	    -o d=8192,f=2048,b=16384 -b $((${extra}))m \
 	    -F "$tmp/selected_sets" ${image} "${release}" "${mnt}"
 fi

---

1. Make sure you pass the `-r sd' or `-r wd' flags, otherwise, the script
defaults to `ld' and builds an /etc/fstab with that baked in.

2. This doesn't produce a very good live image as a) there's hardly any
free space left over, and b) it doesn't grow the root partition like
`build.sh live-image' does.

I'm don't know what this little oddball script is doing in the Guide...



On Sat, 9 Jul 2022, Lloyd Parkes wrote:

> 63 is a popular offset because the BIOS field for track length can only
> hold values 0-63.

Of course--I should've remembered that :)

-RVP