The type attribute force_mbr allows to convert a system selected
for use with a GPT to use an MBR (msdos table). The attribute
only takes effect on image configurations which would select the
GPT partitioner. This Fixes#236
If specified as such the bootloader configuration and
installation will be skipped. However the editbootinstall
and editbootconfig scripts will still be called. This
Fixes#235
The vboot firmware setup was a workaround on arm for the
chromebook platform several years ago. From a todays
perspective the setup and the way to boot would be different
and obsoletes the special case implementation. Thus this
is gone now. Related to Issue #234
The parameter for the uuid is not enough to handle all
supported disk geometries. If the disk has an extra boot
partition the bootloader setup must read the boot data
from the boot partition but must set the root for the
kernel cmdline to the root partition. Therefore the
interface needs to change and must provide both the
boot_uuid and the root_uuid in oder to allow the method
to setup the correct values
The Kernel instance is the only correct place to ask
for the kernel name. This class has the responsibility
to know information about the selected kernel. The
additional arch based assumption on the kernel name
in the disk builder were wrong. This fixes bnc#1011936
If dracut is used as initrd system an unused config.partids
file is generated. The partition id information is only used
by kiwi boot code not by dracut boot code. Related to
bnc#1005246
Change BootImageDracut class to call dracut in the specified
system root directory and not in a self prepared new root environment.
dracut reads scripts and dracut module configurations from the
installed system components, e.g kdump. Therefore calling it
from an isolated runtime environment creates an initrd which is
not matching the system components. Fixes bnc#1005246
If there are volumes below /boot they need to be mounted before
grub2-install / shim-install is called in order to make sure all
data is available in the volume
The DiskBuilder class is able to build a disk its corresponding
format and the installation image to install this disk by using
the InstallImageBuilder. However all three tasks were handled
in a row which lead to the problem that resources like active
mount processes were still open when e.g the disk format is
created. The race conditions produced here lead to an undefined
state of the resulting disk format and/or install image. In
order to avoid this the DiskBuilder class has been refactored
in a way that each tasks is an atomic operation which is
freeing its resources after success
Instead of creating the fstab at boot time, those entries which
are generic and not depending on an unknown device name can be
created as part of the image building process.
If dracut is requested as initrd_system in combination with
building an installiso we have to overrule the initrd_system
setup for building the install image. The code to install
an image is kiwi's oem install code and unknown to dracut.
The process will end up using dracut as initrd in the system
image but kiwi's initrd on the install image
overlay disk images uses a readonly root partition and are
overlayed using overlayfs to hook in a cow based read-write
space. This commit implements the basic disk setup.
Implementation to boot such a disk in the kiwi boot code
is still missing, as well as the investigation if dracut
is able to boot such a disk too. References #65
Add a generic store_to_result method which allows to store
the format result files into an instance of Result. This
allows to customize result handling per format when needed
Systems using SELinux require the filesystem data to be labeled
according to a security context configuration. kiwi now checks
for the presence of /etc/selinux/targeted/contexts/files/file_contexts
and labels accordingly if it exists. This Fixes#52
For the partition setup the Disk class uses dictionaries
to map the partition name to the partition number. However
there are public partition names such as 'kiwi_BootPart'
and kiwi internal partition names such as 'boot'. The code
should make it more clear which mapping table is used
Triggered by the firmware="vboot" setup an EFI setup plus a
raw partition without filesystem is created as first partition.
The size of the partition can be controlled by the vbootsize
attribute. The vboot feature is used by the arm architecture
to provide a space in the partition table for custom code as
required by e.g the chromebook. The final customization of the
vboot space is board specific and can't be implemented in a
generic way in kiwi. For finalizing the vboot space the script
hooks editbootconfig and editbootinstall can be used
This is related to Issue #17
Embedding an MBR into a GPT is required for a collection of
boards, e.g arm rapberry PI. The kiwi configuration provides
a new attribute called
<type ... gpt_hybrid_mbr="true|false"
which allows to control if the GPT should be hybrid or not.
On build procedures which do not create a GPT the attribute
has no effect. This references Issue #17
EFI support was target specific to the x86_64 architecture
This commit changes the structure to allow more architectures
supporting EFI. Thus the arm64 EFI support has been added
as a plus
For the oem image type the requested volume sizes are applied
on first boot of the appliance. Therefore inside of the image
the volumes only needs to be created with their minimum required
size
If dracut is used as initrd system we should not use the
kiwi one shot names linux.vmx, initrd.vmx but stick with
the official naming convention for kernel and initrd which
is kernel-<version>, initrd-<version>
As of today only the kiwi initrd could be used with an image
build. This commit adds a new initrd_system attribute and
allows to select between kiwi and dracut as initrd system.
Please note the dracut initrd does not support all features
of the kiwi initrd. This fixes#25
