Currently, there is a /etc/grub.d/60_darch script that is included that will generate additional menu entries for each staged image.
When booting a staged image, users typically don't have access to the /boot/grub/grub.cfg file to regenerate it (grub-mkconfig). You could mount the real boot partition to /boot, but you risk ruining your boot within in your staged image. For example, in arch, if you are mkinitcpio, it will update files in /boot, but that directory doesn't belong to the booted image.
The solution is to include a /etc/grub.d/60_arch file that doesn't generate staged image boot entries, but prints out what is required to load a /etc/darch/grub.cfg file. Booted images can feel free to update this file, knowing that it will never mess with the main boot of your system.
Typically, you'd want to mount a custom partition to /etc/darch for each staged image. This allows users to persist their hook configuration and have them available in every booted staged image.
pauldotknopf
commented
6 years ago
Currently, there is a
/etc/grub.d/60_darchscript that is included that will generate additional menu entries for each staged image.When booting a staged image, users typically don't have access to the
/boot/grub/grub.cfgfile to regenerate it (grub-mkconfig). You could mount the real boot partition to/boot, but you risk ruining your boot within in your staged image. For example, in arch, if you aremkinitcpio, it will update files in/boot, but that directory doesn't belong to the booted image.The solution is to include a
/etc/grub.d/60_archfile that doesn't generate staged image boot entries, but prints out what is required to load a/etc/darch/grub.cfgfile. Booted images can feel free to update this file, knowing that it will never mess with the main boot of your system.Typically, you'd want to mount a custom partition to
/etc/darchfor each staged image. This allows users to persist their hook configuration and have them available in every booted staged image.