Skip to content

Conversation

@Wasabi375
Copy link
Contributor

Right now it is difficult to use this bootloader with more than just the basic disk-images create by this crate, e.g. it is currently not possible to create a boot-image with multiple partitions.

It can be achieved but that requires a somewhat complex build script that installs "bootloader-x86_64-uefi" or the bios variants and then creates the fat-partition by hand.

This change exposes some functionality of DiskImageBuilder to make some of those things easier.
The bootloader crate already has a buildscript that installs the necessary uefi/bios creates and extracts those files into byte arrays. Those are now public.
I also extracted the functionality to create a boot-able FAT-partition into it's own function and marked it as pub.

The goal of this PR is not to create a fully configurable system to add partitions to the boot image, but to expose the necessary data, for consumer of this crate to build their own partitioning scheme.

Copy link
Member

@Freax13 Freax13 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your contribution!

Sorry for the delay.

I'm not too sure about this. AFAICT the newly exposed APIs are primarily meant for expert users who want to have more control over the disk images. I'd expect that such users are capable of creating FAT images themselves (and probably prefer to do so), so I'm not sure how much of a help the new functions are.

Comment on lines +48 to +58
/// The byte data of the BIOS boot sector
pub const BIOS_BOOT_SECTOR: &[u8] = include_bytes!(env!("BIOS_BOOT_SECTOR_PATH"));
#[cfg(feature = "bios")]
const BIOS_STAGE_2: &[u8] = include_bytes!(env!("BIOS_STAGE_2_PATH"));
/// The byte data of the second stage of the BIOS bootloader
pub const BIOS_STAGE_2: &[u8] = include_bytes!(env!("BIOS_STAGE_2_PATH"));
#[cfg(feature = "bios")]
const BIOS_STAGE_3: &[u8] = include_bytes!(env!("BIOS_STAGE_3_PATH"));
/// The byte data of the third stage of the BIOS bootloader
pub const BIOS_STAGE_3: &[u8] = include_bytes!(env!("BIOS_STAGE_3_PATH"));
#[cfg(feature = "bios")]
const BIOS_STAGE_4: &[u8] = include_bytes!(env!("BIOS_STAGE_4_PATH"));
/// The byte data of the fourth stage of the BIOS bootloader
pub const BIOS_STAGE_4: &[u8] = include_bytes!(env!("BIOS_STAGE_4_PATH"));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there use-cases where it's useful to have access to the raw stages?

I'm a bit worried about forward-compatibility here: If we ever decide to change number of stages or decide to change what each stage does, this will cause problems for users that directly use these constants.

I don't have this concern for the UEFI bootloader because it's just a single binary and I'm guessing that that's less likely to change.

}

#[cfg(feature = "bios")]
/// create a bootable fat-partition for a BIOS system.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// create a bootable fat-partition for a BIOS system.
/// Create a bootable fat-partition for a BIOS system.

///
/// Note that for the partition to work as a boot-partition [BIOS_BOOT_SECTOR] and [BIOS_STAGE_2]
/// have to be properly loaded into the MBR disk image.
pub fn create_bios_fat_partition(&self, partition_path: &Path) -> anyhow::Result<()> {
Copy link
Member

@Freax13 Freax13 Feb 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this intended to be used without calling create_bios_image? Do we expect users to figure out themselves how to build the MBR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants