BIOS Boot Support for Raw Images

[dnugmanov]

Issue Description

When attempting to deploy Kairos on Akamai Cloud (formerly Linode), the platform has specific requirements for bootable images:

• Must be a gzip-compressed RAW image
• Must have either:
  • DOS/MBR partition table, or
  • GPT partition table with legacy boot support
• UEFI booting is not supported

UEFI Raw Image Approach

Using auroraboot with --set "disk.raw=true" produces a GPT-partitioned image that appears to support BIOS booting (contains partition type EF02). However:

1. The BIOS boot partition (EF02) is completely empty (all 2mbs are zeroes)
2. The image fails to boot in BIOS mode

MBR Approach

Attempted to use undocumented option --set "disk.mbr=true" in auroraboot, but the build process stalls at:
2024-12-07T10:48:03Z INF Generating MBR disk '/tmp/auroraboot/build/disk.raw' from '/tmp/auroraboot/build/kairos.iso'

1. Legacy Boot Support with GPT

   • Are there plans to support GPT partition tables with legacy boot (EF02 partition)?
   • If yes, will this include proper GRUB installation into the BIOS boot partition?

2. MBR Image Generation

   • What is the current status of the disk.mbr=true option? Is this feature ready for use, given it's currently undocumented?
   • Can you help with a clue why the image generation got stuck at the ISO to raw conversion stage (qemu is just running vm and not stops it for saving disk )

[Itxaka]

IIRC:

• Out GPT images have legacy MBR support
• disk.mbr=true does something very special as we dont have a process to generate those images and its, it boots an iso with qemu and runs the install, then uses the disk from that qemu vm as the output.
• I dont think we tests this raw images geneartion anywhere so their status is unknown at the moment

A workaround could be to get a normal iso and qemu, run the install in the VM and get the resulting VM disk. That should contain a valid GPT-Legacy raw image that should be valid for Akamai once gzipped.

[dnugmanov]

Out GPT images have legacy MBR support

It looks like this AuroraBoot script is adapted from the Elemental Toolkit script. Interesting that the original has a TODO for legacy boot support—wonder if that's something carried over here.

[dnugmanov]

About MBR boot from @mudler:

when disk.mbr is set it will use QEMU to generate a raw image, and for that it needs a cloud config which has the following stanza:

# Automated install block
install:
  # Device for automated installs
  device: "auto"
  # Reboot after installation
  reboot: false
  # Power off after installation
  poweroff: true
  # Set to true to enable automated installations
  auto: true

My issue with being stuck on ‘Generating MBR disk’ was because I didn’t have poweroff: true after the install. The VM never stopped and didn’t return control to AuroraBoot.

[Itxaka]

Hey @dnugmanov !

Master aurora now uses a different, faster, more streamlined method to build the MBR raw images.

If you use the latest tag of auroraboot you will now not need the install part, as it wont create a qemu vm and install the iso to gednerate a bios raw image.

now "disk.mbr" or even better "disk.bios" should generate a pure raw image directly like the efi one.

Let me know if this would cover your use case.

Currently docs are not updated as this only landed on master recently so we are still trying to find bugs on it, but it will be updated very soon.

As you mentioned, the BIOS image now will have grub installed to the main disk image (sector 0). There is also now tests in mainline aurorare to build and test the BIOS image as well, so it should be safe enough to test this.