27a326dafb
As of grub2 >= 2.02-95 on redhat family distros, calling grub2-install on an EFI partition will fail with: "this utility cannot be used for EFI platforms because it does not support UEFI Secure Boot." This version of grub is now in centos8-stream and non-eus repos of RHEL-8. It is not currently possible to build whole-disk UEFI images on these distros, and when this package is promoted this will also affect centos8 and RHEL-8 eus. The grub maintainers made this change because the grub2-install generated /boot/efi/EFI/BOOT/BOOTX64.EFI will never be capable of booting with Secure Boot. This change defines a $EFI_BOOT_DIR for every distro element. When directory /boot/efi/$EFI_BOOT_DIR exists a grub.cfg file in will be generated there. This change also installs the shim package on redhat family distros, which installs a copy of the shim bootloader to /boot/efi/EFI/BOOT/BOOTX64.EFI. Using centos as an example, this allows UEFI to boot the shim /boot/efi/EFI/BOOT/BOOTX64.EFI which then chains to /boot/efi/EFI/centos/grubx64.efi. If /boot/efi/$EFI_BOOT_DIR doesn't exist (such as for Ubuntu, /boot/efi/EFI/ubuntu) the current behaviour of running grub-install to generate /boot/efi/EFI/BOOT/BOOTX64.EFI will continue. For distros such as Ubutnu where packaging does not populate /boot/efi/EFI/ubuntu with .efi files, secure boot can be added in the future by copying .efi files to /boot/efi/EFI/ubuntu and copying the shim file to /boot/efi/EFI/BOOT/BOOTX64.EFI. Change-Id: I90925218ff2aa4c4daffcf86e686b6d98d6b0f21 |
||
|---|---|---|
| .. | ||
| bin | ||
| cleanup.d | ||
| environment.d | ||
| extra-data.d | ||
| finalise.d | ||
| pre-finalise.d | ||
| pre-install.d | ||
| root.d | ||
| test-elements/build-succeeds | ||
| README.rst | ||
| element-deps | ||
| element-provides | ||
| package-installs.yaml | ||
README.rst
Gentoo
Use a Gentoo cloud image as the baseline for built disk images. The images are located in profile specific sub directories:
As of this writing, only amd64 and arm64 images are available.
Notes:
There are very frequently new automated builds that include changes that happen during the product maintenance. The download directories contain an unversioned name and a versioned name. The unversioned name will always point to the latest image, but will frequently change its content. The versioned one will never change content, but will frequently be deleted and replaced by a newer build with a higher version-release number.
In order to run the package-installs element you will need to make sure dev-python/pyyaml is installed on the host.
In order to run the vm element you will need to make sure sys-block/parted is installed on the host.
Other profiles can be used by exporting GENTOO_PROFILE with a valid profile. A list of valid profiles follows:
default/linux/amd64/17.1 default/linux/amd64/17.1/no-multilib default/linux/amd64/17.1/hardened default/linux/amd64/17.1/no-multilib/hardened default/linux/amd64/17.1/systemd default/linux/arm64/17.0 default/linux/arm64/17.0/systemd
You can set the GENTOO_PORTAGE_CLEANUP environment variable to False to disable the clean up of portage repositories (including overlays). This will make the image bigger if caching is also disabled.
Gentoo supports many different versions of python, in order to select one you may use the GENTOO_PYTHON_TARGETS environment variable to select the versions of python you want on your image. The format of this variable is a string as follows "python2_7 python3_6".
You can enable overlays using the GENTOO_OVERLAYS variable. In it you should put a space separated list of overlays. The overlays must be in the official overlay list and must be git based.
GENTOO_EMERGE_ENV is a bash array containing default environment variables for package install, you can override it with another bash array.
GENTOO_EMERGE_DEFAULT_OPTS can be set to control the default options passed to emerge for all package actions, this includes operations like depclean and preserved-rebuild.