Approved.

In D37004#840306, @bapt wrote:

I don't think we should offer the choice, we should only default on the sane approach which is the symlink. people should be able to cp by themselves if they are in a corner case.

In D36705#839384, @gjb wrote:

Approved. Sorry, I missed this review.

Approved. Sorry, I missed this review.

In D36941#839031, @markmi_dsl-only.net wrote:

For:

ln -s efi ${DESTDIR}/boot/msdos

msdos points to efi in the same directory. No implicit / generation.

For:

ln -s /boot/efi ${DESTDIR}/boot/msdos

msdos points to /boot/efi .

Both ways reach the same file, as long as msdos is not moved to a different directory anyway.

Hmm. I'm actually wondering if it should be

ln -s /boot/efi ${DESTDIR}/boot/msdos

Thank you for the quick fix.

In D36879#837816, @jrtc27 wrote:

In D36879#837343, @gjb wrote:

Minor nit: please adjust the first line of the commit log message to fit within 80 characters. Otherwise, looks good to me.

I measure it at 68 characters already for the subject, and 65 for the body? Not sure what you're referring to.

Apologies for the delay, and thank you for pinging about it. Approved.

Minor nit: please adjust the first line of the commit log message to fit within 80 characters. Otherwise, looks good to me.

Approved.

Approved, once @bcr's comments are addressed.

Approved.

Approved.

In D36635#831806, @imp wrote:

In D36635#831793, @gjb wrote:

In D36635#831784, @manu wrote:

In D36635#831783, @gjb wrote:

I cannot think of any place off-hand (in the build process) where it is explictly encoded/hard-coded. However, I cannot speak to things like DTS files or the like.

DTS are loaded only from u-boot and overlays from the /boot/dtb/ directory (so on UFS in the image), so no worries here.

Excellent, thank you for confirming.

So should I also change the label to EFI always?

In D36635#831784, @manu wrote:

In D36635#831783, @gjb wrote:

I cannot think of any place off-hand (in the build process) where it is explictly encoded/hard-coded. However, I cannot speak to things like DTS files or the like.

DTS are loaded only from u-boot and overlays from the /boot/dtb/ directory (so on UFS in the image), so no worries here.

In D36635#831778, @imp wrote:

In D36635#831766, @jrtc27 wrote:

Isn't the point that it's not just EFI, because all the MBR images are ones that have RPI firmware files?

The label should be consistent with the mount point, regardless.

Yes. The pre-EFI days we had to have a number of files on a FAT partition (or in the first 2MB of the drive) that were used to get u-boot loaded... and that loaded ubldr in days of yore, but now loads the /efi/boot/bootxxx.efi file. This has transitioned from fixed areas in the first part of the disk to GPT partitions (which coincidentally cover the same space) since the early boot files now understand GPT these days. The ROMs in the old arm (esp armv4/armv5) SoCs were definitely limited in what they could do (and I did over-state that u-boot is the only one that cares about partitioning... some of them loaded off fixed areas, others loaded fixed files in the first FAT partition they found).

I'm less confident in changing the label itself. But I can't come up with a good reason to keep the old other than 'I worry that it may be encoded someplace else'...

In D36635#831695, @emaste wrote:

Huh, we previously created both /boot/efi and /boot/msdos, but only used one or the other depending on GPT/MBR? That's unfortunate.

Perhaps bump .Dd, too, when you are ready to commit.

In D34746#817400, @dch wrote:

do we need anything further to commit this yet?

Err... I lost track of who sent the latest review. You don't need approval. :)

I'm okay with this as long as @jhb is. Looks good to me, though.

Weird this wasn't discovered sooner. Good catch.

Approved.

Doc committers can commit to all three repositories for doc-related items, so no explicit permission is necessary unless you are under mentorship.

Yes, please go ahead.

In D35814#812885, @jrtc27 wrote:

In D35814#812882, @gjb wrote:

I do not object to the change, but I would prefer to test uname -s against "FreeBSD" and reverse the if/else logic. But I will not complain too loudly about this nit.

macOS wants the FreeBSD behaviour; currently Linux is the exception. I could flip it with != Linux, but if != .. else feels wrong to write.

I do not object to the change, but I would prefer to test uname -s against "FreeBSD" and reverse the if/else logic. But I will not complain too loudly about this nit.

Approved.

You have been added to the access and mentors files. Fire away at your convenience.

Approved. Give me a minute to add you to mentors/access files.

Apologies - I meant to look over this during the weekend, but then life happened...