Allow mkimg to create empty partitions at specific offsets
ClosedPublic
Actions

Authored by benno on Mar 30 2018, 11:07 PM.

Details

Reviewers

imp
mav

Commits

rS332436: Add the ability to specify absolute and relative offsets to size partitions.

Summary

UEFI boot needs an EFI System Partition. UEFI-bootable ISOs contain one of these in their El Torito boot catalog. To allow easy hybrid booting (i.e. booting an ISO image that's been dd'ed to a USB stick) we can re-use this ESP by pointing a GPT partition entry at it. This allows mkimg to create such an entry by specifying an offset that an empty partition should be at.

Test Plan

Created a GPT image using mkimg and this change, dd'ed the result to the front of an ISO image and booted it as an HDD under UEFI.

Ran mkimg kyua tests (all passed).

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 16085

Event Timeline

benno created this revision.Mar 30 2018, 11:07 PM

Harbormaster completed remote builds in B15904: Diff 40933.Mar 30 2018, 11:07 PM

imp added inline comments.Mar 30 2018, 11:29 PM

usr.bin/mkimg/mkimg.c
516	I almost wonder if we need to have an adjustment here to make sure that the partition starts at an acceptable location. Some partitioning scheme get fussy if you don't do things on a cylinder boundary.
531	this should be always. the additional padding needs to be adjusted.

benno added inline comments.Mar 31 2018, 7:42 PM

usr.bin/mkimg/mkimg.c
516	Would that be the track size? I'm happy to work that in. Or should that be in the scheme-specific code?
531	Except that if I do this the next partition is placed after the absolutely-located one I just placed which throws a whole bunch of things off. If we're going to do this I'd probably prefer to come up with a whole new format for -p which specifically indicates a synthetic partition that we're not actually feeding anything in to and for which all placement rules are relaxed. i.e. we'll create the entry and it's up to you to provide the "truth" of it in some other way.

imp added inline comments.Apr 3 2018, 11:57 PM

usr.bin/mkimg/mkimg.c
516	I think it is one of the block scheme metadata callbacks.
531	then that next one needs to have its start adjusted as well, or rejected as not possible. But we have to have the proper structure even when specifying things at offsets.

Make sure we give the scheme a chance to round off any offsets we bring in.
Do a pass to make sure we haven't created any overlapping partitions.

Harbormaster completed remote builds in B15983: Diff 41114.Apr 4 2018, 11:12 PM

imp added inline comments.Apr 5 2018, 6:15 PM

usr.bin/mkimg/mkimg.c
518	Why isn't this done at the top of loop?

benno added inline comments.Apr 5 2018, 10:12 PM

usr.bin/mkimg/mkimg.c
518	Because we don't know the value of abs_offset until the switch statement.

OK. I'm uneasy. However, if there's bugs in the abs stuff, you'll fix them later I suppose. I can't come up with the exact case that I'm worried about, so I'll click OK. So if this comes with some kind of guarantee to fix bugs downstream, I'm good with it.

This revision is now accepted and ready to land.Apr 6 2018, 4:54 PM

So after imp signed off I noticed that the EBR tests were failing in Kyua. This prompted me to take a closer look at what I was doing and I've gone back and reworked the partition size/offset code to try and better clarify how it all works.

This revision now requires review to proceed.Apr 9 2018, 11:22 PM

Harbormaster completed remote builds in B16085: Diff 41311.Apr 9 2018, 11:22 PM

benno edited the test plan for this revision. (Show Details)Apr 9 2018, 11:28 PM