72c3157162
Background: grub2 works in three stages: - The first stage is found in the first 440 bytes of the master boot record, and its only purpose is to load and execute the second stage. This stage is static, and just copied from the rpm without modification. - The second stage is found in the gap between the MBR and the first partition, and may be up to 31kB in size. This stage is specific to the host and must contain the instructions for finding the right file system and subdirectory for the grub2 config and modules on the host, as well as the modules needed to do this. - The third stage is found in the `normal` module, which loads grub2.conf, which in turn may load more modules and perform arbitrary instructions. Problem: grub2-install is responsible for installing all these stages on the target image. This goes against our design, as modifications outside the filesystem should happen in the assembler, but modifications to the filesystem should happen in a stage. In particular, we don't want the contents of the image to differ in any way from the output tree that is stored in our content store (the output of our last stage). This causes a practical problem at the moment, as our selinux stage is ran before the assembler, and as such the grub modules do not get selinux labels applied. It turns out that we could split grub2-install in two as we want, by passing `--no-bootsector` to it to install only the modules, and copy/genereta the two first stages as files under /boot and then run `grub2-bios-setup` to write the stages from /boot into the image where they belong. Regrettably, this does not work as both `grub2-install` and `grub2-bios-setup` introspect the system and block devices they are being run on to generate the right configuration. This is not what we want, as we would like to specifcy the config explicitly and run them independently of the target image. The specific bug we get in both cases is that the canonical path containing our object store cannot be found. Before osbuild this was not a problem, as other installers would instal and assemble everything directly in the target image as a loopback device. Something we explicitly do not want to do. Solution: This patch essentially reimplements grub2-install, or rather the parts of it that we need. One change in behavior from the upstream tool is that we no longer write the level one and level two boot loaders to /boot before moving them into place, but just write them directly where they belong (so they do not end up on the filesystem). The parts that copy files into /boot are now in the grub2 installer and the parts that write the level one/two bootloaders are in the qemu assembler. This achieves a few principles I think we should always adher to: - never run tools from the target image (no chroot) - don't read/copy files from the target image that was written by other stages. We already try to avoid sharing state, and by treating the image as write-only, we avoid accidentally sharing state through the target tree. Based-on-suggestions-from: Javier Martinez Canillas <javierm@redhat.com> With-god-like-debugging-and-fixes-by: Lars Karlitski <lubreni@redhat.com> Signed-off-by: Tom Gundersen <teg@jklm.no> |
||
|---|---|---|
| .. | ||
| integration_tests | ||
| pipelines | ||
| testing-rpms | ||
| .gitignore | ||
| __init__.py | ||
| __main__.py | ||
| Makefile | ||
| osbuildtest.py | ||
| README.md | ||
| test_boot.py | ||
| test_osbuild.py | ||
| Vagrantfile | ||
Setup
To run the tests in vagrant virtual machine, please follow this tutorial: https://developer.fedoraproject.org/tools/vagrant/vagrant-libvirt.html
(run also sudo systemctl start libvirtd)
Using Vagrant
To start a Vagrant box by hand, run vagrant up in this directory. To stop and remove all volumes run vagrant destroy again in this directory.
Troubleshooting
In case you accidentally deleted .vagrant directory, you can use some of these commands in order to get rid of running instance:
$ virsh list # this should display test_default
$ virsh managedsave-remove test_default
$ virsh undefine test_default
# or using vagrant cli tool
$ vagrant global-status
$ vagrant destroy <id>
$ vagrant global-status --prune