Do we still want to uuencode stuff? I thought we decided binaries made more sense.

I was thinking I'd make that change along with the size bump from 128k to 512k, to avoid extra churn.

what would cause the offset to be different?

Also, when can we nuke this from orbit and use makefs instead?

I wouldn't expect them to be different, but nothing guaranteed that before, and if it did happen the boot file would just be inserted at the wrong offset on some architecture(s).

@smahadevan_freebsdfoundation.org is now at the "it compiles and starts, but segfaults" stage of adding msdos support to makefs.

There's nothing in the UEFI standard that would make the offset different. There's no need, imho, to make things overly complicated like this, especially since the 'future proof' argument is counterweighted by ongoing work to move to makefs.

The offset has nothing to do with the UEFI standard; it's just the offset in the filesystem image where msdosfs(5) happened to put the first block of a dummy file.

I don't see this as making things overly complicated, just addressing a longstanding bug which would have been rather hard to diagnose if we tripped over it.

But the template will be the same on all systems.... It's just an MSDOSFS we're kludgily plopping data into.... We totally control that... Just think it will be more complicated code that eventually will be ripped out....

Well, excluding that UEFI incorporates FAT by reference I mean.

OK, but relative to the refactoring here to loop over all archs this offset issue is a 2 line change (one in generate-fat.sh and one in Makefile).

To avoid this would be even more complicated, with something like:

BOOT1_KNOWN_OFFSET=2d
echo "BOOT1_OFFSET=0x$BOOT1_KNOWN_OFFSET" >> Makefile.fat

before the loop and then

if [ $BOOT1_OFFSET != 0x$BOOT1_KNOWN_OFFSET ]; then
        echo "Bad offset" >&2
        exit 1
fi

inside the loop.

That is, this change is a pretty substantial change to the template generation script, but only a trivial change to the Makefile and Makefile.fat, and there's no need to regenerate the .uu files.

Removing the .uu files and replacing them with .bz2 is a much larger change to the templates (and only a minor change to the generate-fat script and Makefile), and can be combined with a size bump so there's only one instance of churn.

Quick update: @smahadevan_freebsdfoundation.org is now at the "it creates a FAT filesystem image and the contents of the desired files are found within that image, but there are no directory entries" :)

In other words it's getting close. We'll still have the bootstrapping issues to deal with, however.

-ne 0 is a better idiom.

I generally use ${0##*/} instead of $0 to strip the dirname.

The cleanup for mounting/unmounting/removing the directory should really be done unconditionally in a trap'ed function, e.g.,

cleanup_stub()
{
    umount stub
    mdconfig -d -u $DEVICE
    rmdir stub
}
trap cleanup_stub EXIT INT TERM

Hardcoding 512 for the byte sector size isn't a good practice.

I'm not sure I agree - if id -u did happen to produce some non-numeric output we'd get

[: foo: bad number

and the script continues on.

Not introduced in this change; could be addressed in a subsequent change.

It's not the same on all systems: the filename is different.

Needs to be increased to 512k

Yes - I plan to commit this change first, followed by a subsequent one to increase the size to 512k, switch from bzip2 to xz, and stop uuencoding the files (so that the template files only change once to avoid unnecessary repo churn).