Increase EFI MSDOSFS image size to 512Kib
ClosedPublic

Authored by allanjude on Feb 20 2017, 12:12 AM.

Details

Summary

This patch increases the size of the msdosfs image generated for EFI boot1 to 512Kib. This is a part of https://reviews.freebsd.org/D7589, and is necessary to fit the GELI EFI support, which increases the size of the boot1 program.

This patch is a component of https://reviews.freebsd.org/D7589.

Test Plan

This does not affect behavior at all. It merely causes a larger image to be generated.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 11536
Build 11890: arc lint + arc unit
eric_metricspace.net retitled this revision from to Increase EFI MSDOSFS image size to 512Kib.Feb 20 2017, 12:12 AM
eric_metricspace.net updated this object.
eric_metricspace.net edited the test plan for this revision. (Show Details)
eric_metricspace.net set the repository for this revision to rS FreeBSD src repository.
allanjude accepted this revision.Feb 20 2017, 12:16 AM

This is more of a project-wide question, hopefully @emaste or something can answer it:

Does it still make sense to uuencode binary files like this? SVN can handle binary files just fine.

This revision is now accepted and ready to land.Feb 20 2017, 12:16 AM

Does it still make sense to uuencode binary files like this? SVN can handle binary files just fine.

I would prefer we stopped uuencoding binary files, and just committed them directly. As far as I'm concerned it's a carryover from the CVS days, and there is no concern with any of the VCSes relevant to us today (svn/git/p4/hg, or esoteric ones like ClearCase used by some downstream consumers).

This revision now requires review to proceed.Jun 29 2017, 12:36 AM
allanjude commandeered this revision.Jul 1 2017, 6:02 PM
allanjude edited reviewers, added: eric_metricspace.net; removed: allanjude.

I am going to do the uuencode change as well.

allanjude updated this revision to Diff 30290.Jul 1 2017, 6:05 PM

Switch from uuencoded bzip to raw xz

As long as the max size is increased, it should work with my downstream changes.

This revision is now accepted and ready to land.Jul 1 2017, 8:40 PM
imp added a comment.Jul 12 2017, 2:52 PM

Why not 50MB instead of 512kb? That's stupidly small and precludes any and all future use of UEFI programs as well as boot block bloat. bz2 compressed, the size difference is trivial.

In D9680#239393, @imp wrote:

Why not 50MB instead of 512kb? That's stupidly small and precludes any and all future use of UEFI programs as well as boot block bloat. bz2 compressed, the size difference is trivial.

Fine by me. I think Allan was planning to do away with all of these pre-built images at some point anyway.

In D9680#239393, @imp wrote:

Why not 50MB instead of 512kb? That's stupidly small and precludes any and all future use of UEFI programs as well as boot block bloat. bz2 compressed, the size difference is trivial.

Note it's 800k right now (FAT_SIZE) not 512k. I agree this is rather suboptimal, but the FAT filesystem image is stored uncompressed in /boot and we don't want to bloat a standard install with a 50M image. It looks like good progress is being made on bsdinstall though so with any luck this will very shortly be a moot point.

Note that I ended up creating a version of this change after forgetting about this review - shall I commandeer and upload that?

sys/boot/efi/boot1/Makefile
128–129

This is gone as of rS323436.

138

I ended up writing a similar patch (I forgot about this one) and used xz -d
I also think -f is unnecessary here.

sys/boot/efi/boot1/generate-fat.sh
17

I would like to have room for 2 copies of the boot1.efi at least, to allow users to keep a backup etc.

How about 384k for now?

imp added inline comments.Sep 11 2017, 4:08 PM
sys/boot/efi/boot1/generate-fat.sh
17

Sure. I don't care since the installboot(8) script I'm working on will make all this stuff obsolete.

This revision now requires review to proceed.Sep 13 2017, 4:25 AM
tsoome accepted this revision.Sep 13 2017, 7:09 AM
This revision is now accepted and ready to land.Sep 13 2017, 7:09 AM
emaste accepted this revision.Sep 13 2017, 1:21 PM
This revision was automatically updated to reflect the committed changes.