release: Fix booting on aarch64 in Azure by adding the BOOTPARTSOFFSET

[imp]

So this is a bit tricky for why we're doing this and how it solves the problem. See suggestion for a comment.

release/tools/vmimage.subr

367

I'd lose the TARGET_ARCH here. We generally should define BOOTPARTSOFFSET unless we really need it. And all azure targets would need it.

368

So what we're really trying to do is skip the first 1MB. This creates a partition that is 1MB. This is a subtle difference. Maybe it's fine, maybe it matters. Also, the partition type is arbitrary: we're not actually using this partition for anything. It's just a placeholder. The structure of the code makes it hard, though to really do this right. It's really the offset for the first partition. But since the code structure doesn't make it easy.

So I'd drop a comment in here that explains two things. (1) That freebsd-boot is just an empty placeholder partition and (2) gpt overhead means we'll start the next partition a little after this offset, and that's OK since azure is the only config that uses it.

[lwhsu]

release/tools/vmimage.subr

368

Thanks @brd I'm also checking this today and fortunate I see this first.

I'm also unsurt that if a 1MB partition is acceptable by Azure Marketplace and I am worried more that if they really write anything in this partition might mess our image. So having an offset added to the first real partition we want would be safer. I'm still thinking what's the not-that-dirty way to add it in this, or maybe we just add a condition and modify ROOTFSPART line.

[brd]

release/tools/vmimage.subr

368

I agree with both of you, this was just the first way I got things working.. With more reading of mkimg I think there is a better way.. will update the patch after some testing.

[lwhsu]

release/tools/vmimage.subr

368

Thanks. I'm also thinking what's the good or acceptable way for this. Note that it will always boot in the aarch64 Azure VM but only got rejected during the manual validation step when publishing to the Azure marketplace. (And aarch64 didn't check it until recently, while x86 started checking it long ago

[brd]

New approach to Azure padding

[brd]

Prior to this change on aarch64 we have:

=>     34  6358973  md0  GPT  (3.0G) [CORRUPT]
       34    66584    1  efi  (33M)
    66618  6291456    2  freebsd-ufs  (3.0G)
  6358074      933       - free -  (467K)

After this change we have:

=>     34  6361021  md0  GPT  (3.0G) [CORRUPT]
       34     2014       - free -  (1.0M)
     2048    66584    1  efi  (33M)
    68632  6291456    2  freebsd-ufs  (3.0G)
  6360088      967       - free -  (484K)

[lwhsu]

Oh, right, I was thinking how to deal with the cases of ${ESP} = "yes" and ${ESP} != "yes", but currently we only need to deal with amd64 and aarch64 and they both have ESP=yes so this should be better than the current situation, which only handles amd64. Thanks!

[imp]

release/tools/vmimage.subr

390

I think this breaks x86 since the first partition isn't offset and in the 2mb header. Fix by putting BOOTPATS last i think.

[brd]

release/tools/vmimage.subr

390

@imp I am building on x86 so not tested yet, waiting for that.. But I see what you mean, so you are suggesting this?

BOOTPARTS="-p efi/efiboot0:=${espfilename}${BOOTPARTSOFFSET} ${BOOTPARTS}"

[brd]

release/tools/vmimage.subr

390

With this change it looks like this.. Is it OK to but freebsd-boot in the middle like that?

x86 v3 changes:

md0
=>      34  10555325  md0  GPT  (5.0G) [CORRUPT]
        34      2014       - free -  (1.0M)
      2048     66584    1  efi  (33M)
     68632       122    2  freebsd-boot  (61K)
     68754  10485760    3  freebsd-ufs  (5.0G)
  10554514       845       - free -  (423K)

aarch64 v3 changes:

md0
=>     34  6361021  md0  GPT  (3.0G) [CORRUPT]
       34     2014       - free -  (1.0M)
     2048    66584    1  efi  (33M)
    68632  6291456    2  freebsd-ufs  (3.0G)
  6360088      967       - free -  (484K)