Loader: support booting OS from memory disk (MD)

[yongbo.yao_dell.com]

Summary

Until now, the boot image can be embedded into the loader with /sys/tools/embed_mfs.sh, and memory disk (MD) is already supported in loader source. But due to memory disk (MD) driver isn't registered to the loader yet, the boot image can't be boot from embedded memory disk.

Test Plan

Tried PXE boot from the loader includes mfsbsd image

1. Embedding mfsbsd image into the loader
   • Determine the size of the mfsbsd image: ls -l rootfs.ufs | awk '{print $5}'
   • Build the loader with extra space: make MD_IMAGE_SIZE=${BOOTFS_SIZE_PLUS_SAFETY}
   • Embed mfsbsd image in the loader: ./embed_mfs.sh loader.efi rootfs.ufs

2. PXE boot from the loader - According to below logs, currdev was set to md0a, which meant all the kernel and kernel modules were loaded from memory disk.

Consoles: EFI console
    Reading loader env vars from /efi/freebsd/loader.env
FreeBSD/amd64 EFI loader, Revision 1.1
(Thu Apr  1 04:52:32 CST 2021 root@vm-yongbo)

   Command line arguments: loader.efi
   Image base: 0x7719f000
   EFI version: 2.70
   EFI Firmware: American Megatrends (rev 5.14)
   Console: efi (0x1000)
   Load Path: loader.efi
   Load Device: PciRoot(0x0)/Pci(0x1D,0x2)/Pci(0x0,0x0)/MAC(00604860738A,0x1)/MAC(00604860738A,0x1)
   BootCurrent: 0005
   BootOrder: 0001 0002 0003 0004 0005[*] 0006 0007 0008 0009 000a 000b 000c
   BootInfo Path: PciRoot(0x0)/Pci(0x1D,0x2)/Pci(0x0,0x0)/MAC(00604860738A,0x1)/IPv4(0.0.0.0)
   BootInfo Path: VenHw(2D6447EF-3BC9-41A0-AC19-4D51D01B4CE6,5000580045002000490050003400200030003600300030002000420072006F006100640063006F006D0020004E006500740058007400720065006D00650020004700690067006
1006200690074002000450074006800650072006E006500740020002800420043004D00350037003200370029000000)
Ignoring Boot0005: No Media Path
Trying MD
Setting currdev to md0a:
Loading /boot/defaults/loader.conf
Loading /boot/device.hints
Loading /boot/loader.conf
Loading /boot/loader.conf.local
Loading kernel...
/boot/kernel/kernel text=0x1490f20 data=0x4c9e00+0x1b46b70 syms=[0x8+0x241008+0x8+0x343ed3]
...
Type '?' for a list of commands, 'help' for more detailed help.
OK show
currdev=md0a:
loaddev=md0a:
vfs.root.mountfrom=ufs:/dev/md0

[vangyzen]

I would like a review from at least one of these fine folks: @imp @kevans @tsoome

[dab]

LGTM

[kevans]

stand/efi/loader/main.c

592

I suspect md is pretty niche and we have no problem with this in concept, but md probe should likely move down since it's effectively "searching other disks" and we haven't exhausted all of the partitions on "this disk" yet.

[kevans]

stand/efi/loader/main.c

592

(The problem is that you don't want to subvert the boot protocol if you otherwise did everything right to configure a partition to boot, e.g., maybe some kind of

592

(The specific problem I'm thinking of here is that you might accidentally subvert the boot protocol if you have an md setup but wanted to configure the firmware to boot off of, e.g., some kind of static rescue partition)

[imp]

I'm fine with this, but think we need to document it somewhere and also discuss any limitations relative to other boot methods there might be.

stand/efi/loader/main.c

592

Yea, I'm not sure this code would handle the case where we want root to be the md disk, but there's also another partition that could be root available. For the usecase with pxeboot, this won't matter, but might if we're booting off stable media that has other UFS partitions on it.

[tsoome]

Since md case is depending on build options and is not part of generic build, this feature should not generate problems for general public. I do agree, it should get documented. Do we want to provide feature parity with i386 tree (BIOS loader)?

[yongbo.yao_dell.com]

stand/efi/loader/main.c

592

It can not be moved down. As Warner said, If md moves down, it can not handle the case where we want root to be the md disk, but there's also another partition that could be root available

592

md in loader stands for embedded memory disk, it is a specific case and not built in loader by default. In generic build, it wouldn't subvert the boot protocol.

592

There are three choices rootdev/uefi_rootdev/do_bootmgr before md. If they are not assigned, it will boot from md

[yongbo.yao_dell.com]

In D29512#661559, @imp wrote:

I'm fine with this, but think we need to document it somewhere and also discuss any limitations relative to other boot methods there might be.

Thanks Warner. Should it be documented to loader.8? if so , can I update it in this patch?

[kevans]

stand/efi/loader/main.c

592

Yup, sorry, I've re-read the context below-

[yongbo.yao_dell.com]

In D29512#661895, @tsoome wrote:

Since md case is depending on build options and is not part of generic build, this feature should not generate problems for general public. I do agree, it should get documented. Do we want to provide feature parity with i386 tree (BIOS loader)?

Thanks Toomas. I suspect that this feature is rarely used in legacy BIOS so did not add it in i386 tree. But I'm fine if you think it's worth to be added.

[tsoome]

In D29512#662063, @yongbo.yao_dell.com wrote:

In D29512#661895, @tsoome wrote:

Since md case is depending on build options and is not part of generic build, this feature should not generate problems for general public. I do agree, it should get documented. Do we want to provide feature parity with i386 tree (BIOS loader)?

Thanks Toomas. I suspect that this feature is rarely used in legacy BIOS so did not add it in i386 tree. But I'm fine if you think it's worth to be added.

nono, I just wanted to be sure it is mentioned:) I'm totally fine with UEFI only approach.

[vangyzen]

In D29512#662047, @yongbo.yao_dell.com wrote:

In D29512#661559, @imp wrote:

I'm fine with this, but think we need to document it somewhere and also discuss any limitations relative to other boot methods there might be.

Thanks Warner. Should it be documented to loader.8? if so , can I update it in this patch?

Yes, loader.8 is probably the best place. Feel free to add it to this review.

[yongbo.yao_dell.com]

Add MD section to loader(8).

MD
     Memory disk (MD) can be used when the loader was compiled with
     MD_IMAGE_SIZE.  The size of the memory disk is determined by
     MD_IMAGE_SIZE.  If MD available, a file system can be embedded into the
     loader with /sys/tools/embed_mfs.sh.  Then, MD will be probed and be set
     to currdev during initialization.

     Currently, MD is only supported in loader.efi(8).