{{Header}}
{{title|title=
Development of System Image Creation and Bootstrapping Tools
}}
{{dev_image_mininav}}
{{#seo:
|description=Installing GRUB onto a disk image is a bit of a black art.
}}
{{intro|
Installing GRUB onto a disk image is a bit of a black art.
}}
{{quotation|quote=
Installing GRUB onto a disk image is a bit of a black art. I haven't found any good documentation for it. This plugin is written based on de-ciphering the build_openstack_image script. Here is an explanation of what I _THINK_ is happening.
|context=[https://gitlab.com/larswirzenius/vmdb2/-/blob/main/vmdb/plugins/grub_plugin.py Lars Wirzenius, Debian Developer]
}}

{{quotation|quote=
The crucial command is grub-install. It needs a ton of options to work correctly: see below in the code for the list, and the manpage for an explanation of what each of them means. We will be running grub-install in a chroot so that we use the version in the Debian version we're installing, rather than the host system, which might be any Debian version.

To run grub-install in a chroot, we need to set up the chroot in various ways. Firstly, we need to tell grub-install which device file the image has. We can't just give it the image file itself, since it isn't inside the chroot, so instead we arrange to have a loop block device that covers the whole image file, and we bind mount /dev into the chroot so the device is available.

grub-install seems to also require /proc and /sys so we bind mount /sys into the chroot as well. /proc is already mounted otherwise.

We install the UEFI version of GRUB, and for that we additionally bind mount the EFI partition in the image. Oh yeah, you MUST have one.

We also make sure the right GRUB package is installed in the chroot, before we run grub-install.

Further, there's some configuration tweaking we need to do. See the code. Don't ask me why they're necessary.

For cleanliness, we also undo any bind mounts into the chroot. Don't want to leave them in case they cause trouble.

Note that this is currently assuming that UEFI and either the amd64 (a.k.a. x86_64) or arm64 (a.k.a. aarch64) architectures are being used. These should probably not be hardcoded. Patch welcome.
|context=[https://gitlab.com/larswirzenius/vmdb2/-/blob/main/vmdb/plugins/grub_plugin.py Lars Wirzenius, Debian Developer]
}}

Example projects to demonstrate technical challanges:

* Systemd developers did not implement since 2022 [https://github.com/systemd/mkosi/issues/1220 mkosi ISO support] (closed ticket but not implemented, the actual missing ticket to implement is [https://github.com/systemd/systemd/issues/28798 repart: Support booting via CD-ROM]).
* Nobody answered [https://github.com/systemd/mkosi/discussions/2103 Build a bootable non-UEFI ARM64 image (e.g. Raspbian for RPi 4B) with mkosi?]
* grml-debootstrap did not implement [https://github.com/grml/grml-debootstrap/issues/114 Rasberry PI (RPI) support] since 2018.

{{reflist|close=1}}
{{Footer}}
[[Category:Development]]