Page MenuHomeFreeBSD

Allow mkimg to create empty partitions at specific offsets
ClosedPublic

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

Details

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
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

usr.bin/mkimg/mkimg.c
464 ↗(On Diff #40933)

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.

485 ↗(On Diff #40933)

this should be always. the additional padding needs to be adjusted.

usr.bin/mkimg/mkimg.c
464 ↗(On Diff #40933)

Would that be the track size? I'm happy to work that in. Or should that be in the scheme-specific code?

485 ↗(On Diff #40933)

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.

usr.bin/mkimg/mkimg.c
464 ↗(On Diff #40933)

I think it is one of the block scheme metadata callbacks.

485 ↗(On Diff #40933)

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.

benno marked 6 inline comments as done.
  • 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.
usr.bin/mkimg/mkimg.c
503 ↗(On Diff #41114)

Why isn't this done at the top of loop?

usr.bin/mkimg/mkimg.c
503 ↗(On Diff #41114)

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

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 11 2018, 3:34 AM
This revision was automatically updated to reflect the committed changes.