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.
Details
Details
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
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - 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. |
Comment Actions
- 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. |
Comment Actions
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.
Comment Actions
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.
Comment Actions
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.