Page MenuHomeFreeBSD

Loader: support booting OS from memory disk (MD)
ClosedPublic

Authored by yongbo.yao_dell.com on Mar 31 2021, 2:13 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Mar 22, 3:35 PM
Unknown Object (File)
Wed, Mar 6, 1:11 PM
Unknown Object (File)
Jan 12 2024, 7:13 AM
Unknown Object (File)
Dec 20 2023, 5:04 AM
Unknown Object (File)
Dec 14 2023, 9:53 PM
Unknown Object (File)
Dec 14 2023, 12:04 PM
Unknown Object (File)
Dec 12 2023, 2:16 PM
Unknown Object (File)
Dec 1 2023, 7:31 PM

Details

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
  1. 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

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

yongbo.yao_dell.com created this object with edit policy "Administrators".
yongbo.yao_dell.com edited the summary of this revision. (Show Details)
yongbo.yao_dell.com changed the edit policy from "Administrators" to "All Users".Mar 31 2021, 3:12 PM
vangyzen added subscribers: tsoome, kevans, imp.

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

This revision is now accepted and ready to land.Mar 31 2021, 3:17 PM
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.

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)

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.

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)?

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

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?

stand/efi/loader/main.c
592

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

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.

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.

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.

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).
This revision now requires review to proceed.Apr 7 2021, 12:47 PM
This revision is now accepted and ready to land.Apr 7 2021, 6:29 PM