RFD 156: SmartOS/Triton Boot Modernization about rfd HOT 24 CLOSED

from rfd.

Stupid bike-shedding here (sorry) but could we possibly rename "tools/build_image" to "tools/build_boot_image" just to make it clear what it's doing - RFD 145 is currently planning on introducing a build-tool called "buildimage", but I'm sure I could persuade the author to rename that to "build_triton_image" or something if we need to :-)

from rfd.

Can you add a note about testing the following:

• Booting smartos KVM inside smartos via iPXE
• Both physical and KVM booting in a RAN environment (presumably the new iPXE will behave the same as our current iPXE).

from rfd.

Can you add a note about testing the following:

* Booting smartos KVM inside smartos via iPXE

* Both physical and KVM booting in a RAN environment (presumably the new iPXE will behave the same as our current iPXE).

Yes, will do. Thanks!

from rfd.

Stupid bike-shedding here (sorry) but could we possibly rename "tools/build_image" to "tools/build_boot_image" just to make it clear what it's doing - RFD 145 is currently planning on introducing a build-tool called "buildimage", but I'm sure I could persuade the author to rename that to "build_triton_image" or something if we need to :-)

I'm happy to rename it to something else. Perhaps "build_disk_image" would be a more precise fit?

from rfd.

I have a nit or two with:

The UEFI specification reserved the first sector of the drive so that MBR-style boot code can be installed into it. This sector is known as the protected MBR (PMBR) and allows for the same disk to support booting in both legacy BIOS and UEFI modes. To continue to support legacy BIOS boot mode, a first stage loader will be installed into the PMBR. This code will jump to and execute a second stage loader (gptzfsboot) that will be intalled into a small boot slice. gptzfsboot will then mount the root partition and execute the legacy BIOS version of Loader.

PMBR is "Protective Master Boot Record". It is protective in that it has the right magic number at the proper offset and defines one partition that includes the whole disk. It is protective in that it protects the disk from being scribbled on by legacy OS's (e.g. Windows NT 4, perhaps later) that would see a disk without a partition table and would "fix it".

Since we intend to write some boot code to LBA 0, it will be a Legacy MBR (section 5.2.1), not a Protective MBR (section 5.2.3)

Also s/intalled/installed/.

from rfd.

from rfd.

Re ESP size: the root FS is already at 277Mb, so this isn't large enough for our standard SmartOS USB image. So we'd either need a smaller ESP in that case (and that's probably not a big deal), or a large USB image size.

from rfd.

Re ESP size: the root FS is already at 277Mb, so this isn't large enough for our standard SmartOS USB image. So we'd either need a smaller ESP in that case (and that's probably not a big deal), or a large USB image size.

We should use a larger image size. I think I put 512 MiB in the original version of build_image simply to make things faster as I was iterating on the script. The original build_iso script set it much larger (2GB).

I think a 256mb ESP seems reasonable and should leave enough headroom for firmware images and encryption keys and whatnot.

from rfd.

I recognize that this RFD pertains to the mechanisms in SmartOS and Triton to support UEFI booting. Outside of those two items, what BIOS configuration considerations should be made in preparation to support this RFD? Often we turn off UEFI booting and network stacks in some BIOS configurations might be off by default.

from rfd.

from rfd.

On 10/31/18 12:02 , Dale Ghent wrote: I recognize that this RFD pertains to the mechanisms in SmartOS and Triton to support UEFI booting. Outside of those two items, what BIOS configuration considerations should be made in preparation to support this RFD? Often we turn off UEFI booting and network stacks in some BIOS configurations might be off by default.
We shouldn't change anything for any existing hardware. We'll only want to make changes for future systems.

Correct. And just to add to this - we've tried to design this to minimize disruption to existing Triton installations. So existing hardware can simply continue on using the MBR/GRUB-based USB key. Alternatively, one can optionally use the new GPT/Loader-based USB key on an existing system that's running in legacy BIOS mode without having to make any BIOS configuration changes.

from rfd.

It appears, like with KVM, we gave up on synching-with-upstream with iPXE. Should we more actively engage with iPXE as a side-effect of this project? Or is it a Linux-like situation where we'll be frequently dismissed? A bit of documentation about the future of iPXE engagement may be helpful.

from rfd.

And speaking of upstream. Will this project also help Toomas get additional Loader changes upstream to illumos-gate?

from rfd.

from rfd.

I think they are really different issues and its incorrect to really phrase it that way. iPXE has been updated in the past, but like other things that need to be synced, it often isn't done regularly and just needs to be done on a more regular basis.

Okay, I'll buy that they are different issues, and yes, more frequent updates is generally a good idea.

from rfd.

John and I have made a number of changes to this RFD based on comments received here. For those of you that had previously provided feedback, if you could give it another look that would be greatly appreciated. Thanks!

from rfd.

thanks for the update, there are a couple of follow up questions that I have:

In the section on the USB key versioning, it seems that we're harcoding the current loader version to try and determine the version. But doesn't that version have nothing to do with the actual partition table format that we're using which is what we were originally trying to capture in the version? What happens if the loader wants to change that version for unrelated reasons? Won't that break all of our versioning detection. Similarly, just because we want to rev the version doesn't mean that revving the loader version to reflect a fundamental change in the partition table makes sense.

Next, I don't see much about iPXE and UEFI. While there are some tests, are there plans for trying to use UEFI drivers provided by firmware to reduce the need to have drivers for all parts that we want to boot from? Or is that just not really being addressed as part of this? Will we still be able to chainload the updated ipxe in a UEFI system and have that work?

from rfd.

I'll let John speak to the key versioning question.

WRT to ipxe and UEFI, I've actually been looking at that this week. We have Joyent-specific changes in Loader now to determine if we're booted in UEFI mode or BIOS mode and then either chainload the ipxe EFI binary or boot the ipxe kernel. So some of the plumbing is in place.

But right now we're not even building an ipxe EFI binary. Addressing that is covered by TRITON-1016 which I'm working on today. Once I've had a chance to build and test that I will followup here with a better answer.

from rfd.

Actually we are writing our own version into the MBR version slot. If it ever gets used by upstream, then we will have to diverge the version stream, but I don't see this likely to be a significant problem?

There's nowhere else in MBR (AFAICS) our own version could go. Maybe playing games with the UUID but that seems worse than using the slot.

And if not the MBR, where?

from rfd.

WRT to ipxe and UEFI, I've actually been looking at that this week. We have Joyent-specific changes in Loader now to determine if we're booted in UEFI mode or BIOS mode and then either chainload the ipxe EFI binary or boot the ipxe kernel. So some of the plumbing is in place.

But right now we're not even building an ipxe EFI binary. Addressing that is covered by TRITON-1016 which I'm working on today. Once I've had a chance to build and test that I will followup here with a better answer.

Just to follow-up on the above. Getting ipxe to function in UEFI mode ended up being quite a bit more work than we anticipated. Besides the changes needed to build ixpe.efi and snponly.efi - it turns out that ipxe didn't have support for booting from OS images that use the multiboot2 format - only multiboot1. The illumos kernel is built with both multiboot 1 and 2 headers and so today ipxe falls back to the multiboot1 support. The problem there is that the multiboot1 specification doesn't support UEFI mode.

John ended up adding multiboot2 image support to ipxe (see TRITON-1017).

We're not planning to add support for using firmware-provided UEFI drivers as part of this particular RFD as there doesn't seem to be a pressing need - the resync'd ipxe appears to support all the newest Intel NICs. But I don't think we're doing anything that would preclude us from going that route in the future.

from rfd.

I've updated the RFD to include more details on what we're changing wrt iPXE.

from rfd.

Seems like the discussion has died down here. Are there any other comments before we close this issue and move the RFD to the published state?

from rfd.

There are currently no outstanding comments and the discussion has been quiet for a couple months now. Furthermore, this project is dev-complete and nearing integration. Therefore, I am closing this issue and moving this RFD from the "draft" to "publish" state. Thank you everyone for the feedback - it was much appreciated.

from rfd.