fix: boot on qemu x86_64

[nokosaaan]

Description

I fixed an issue where QEMU on x86_64 would not start properly.
This was resolved by clearly separating the BIOS and UEFI boot paths using the features option.
With the current configuration, the build process generated numerous warnings and errors,
preventing the program from starting successfully.
Specifically, the error error: unknown -Z flag specified: json-target-spec was being displayed.
The -Z flag is used to specify unstable, experimental features of the Rust compiler. It appears the issue arose because an outdated or incompatible version of Rust Nightly was used during the build of the Bootloader package, causing the flag to go unrecognized.
Possible solutions include:

• Using a newer Nightly build
• Updating the bootloader
• Using a known compatible version
  The nightly build is already the latest version, and the Bootloader is also kept up to date. Since we confirmed that it works without issues when using a compatible version, rolling back the version would be preferable; however, the cost of rework and the impact on existing code are significant, making this impractical.
  Therefore, since the BIOS processing is not expected to run in the current implementation, I isolated it in features. After confirming that it behaves the same as the compatible version, we decided to implement this fix.

In addition, a compile_error! guard was added to x86bootdisk/src/main.rs to produce a clear, actionable compiler error when the crate is built with --no-default-features and neither the bios nor uefi feature is selected, preventing confusing missing-impl errors in misconfigured builds.

Related links

https://github.com/rust-osdev/bootloader

How was this PR tested?

Please refer to attached files.
Compile logs are showed.
bootloader-fix.log
main.log

Notes for reviewers

[Copilot]

Pull request overview

This PR adjusts the x86bootdisk helper tool and build scripts to split BIOS vs UEFI boot image generation using Cargo features, with the goal of making x86_64 QEMU boot reliably by avoiding incompatible bootloader build paths.

Changes:

• Introduces bios/uefi feature flags in x86bootdisk and gates bootloader usage accordingly.
• Updates x86_64 Makefile image targets to build x86bootdisk with --no-default-features and the appropriate boot feature.
• Removes multilingual = false from the mdBook configuration.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
x86bootdisk/src/main.rs	Feature-gates BIOS/UEFI boot paths and adjusts CLI defaulting behavior based on enabled features.
x86bootdisk/Cargo.toml	Adds bios/uefi features and disables bootloader default features to control build paths.
mdbook/book.toml	Simplifies mdBook config by removing the explicit multilingual setting.
Makefile	Builds BIOS and UEFI images by selecting the corresponding x86bootdisk feature set.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This target now relies on BootType's CLI default to select BIOS (since --boot-type bios is not passed). To make the build resilient to future changes in the Rust-side defaulting logic (or feature defaults), consider passing --boot-type bios explicitly here, similar to the UEFI target.

Suggested change

	RUSTFLAGS="$(RUSTC_MISC_ARGS)" cargo +$(RUSTV) run --release --package x86bootdisk --no-default-features --features bios -- --kernel $< --output $@
	RUSTFLAGS="$(RUSTC_MISC_ARGS)" cargo +$(RUSTV) run --release --package x86bootdisk --no-default-features --features bios -- --kernel $< --output $@ --boot-type bios

[nokosaaan]

Since bios is already set in the features configuration, specifying it again in boot-type seems redundant. What is the reason for proposing this addition?

[nokosaaan]

@copilot

[Copilot]

You're right that it's currently redundant. --features bios is a compile-time Cargo flag that controls which code is included in the binary (gating the Bios enum variant, the BiosBoot import, and the Default impl). --boot-type bios is a separate runtime CLI argument that tells the already-compiled binary which boot path to execute.

When only --features bios is active (no uefi), the BootType enum has a single Bios variant and Default::default() returns Bios, so the CLI argument is indeed unnecessary. The reviewer's suggestion was purely defensive — making the intent explicit in the Makefile so a future change to the Default impl or feature set wouldn't silently break this target. Whether to add it is a style/resilience tradeoff; the current code is correct as-is.

[nokosaaan]

@kobayu858
Copilot says, making the intent explicit in the Makefile so a future change to the Default impl or feature set wouldn't silently break this target but if we take this possibility into account, the CLI arguments in the Makefile become redundant. I would like to hear your opinions on whether we should accept this change.

[nokosaaan]

@copilot
I noticed that since the UEFI arguments on line 153 were configured as shown below, it would be better to adjust the BIOS settings accordingly. This suggestion has already been implemented.
RUSTFLAGS="$(RUSTC_MISC_ARGS)" cargo +$(RUSTV) run --release --package x86bootdisk --no-default-features --features uefi -- --kernel $< --output $@ --pxe x86_64_uefi_pxe_boot --boot-type uefi

[Copilot]

--boot-type bios is already present on the BIOS target line (added in commit e924fe6), matching the --boot-type uefi on the UEFI target. Both targets now explicitly declare their boot type.

[nokosaaan]

@kobayu858
I fixed it by following copilot's comment and resolved the issue on my own.
No need to answer the question above.