@@ -10,7 +10,7 @@
import os
-from avocado_qemu import Test
+from avocado_qemu import Test, SRC_ROOT_DIR
from avocado.utils import cloudinit
from avocado.utils import network
@@ -81,3 +81,23 @@ class BootLinuxX8664(BootLinux):
self.vm.set_machine('q35')
self.vm.launch()
self.wait_for_boot_confirmation()
+
+
+class BootLinuxAarch64(BootLinux):
+
+ chksum = '528f2659a410e3a8bd47d32a6ac4e6c5729f1d28dbad0763b4282a753ddcab1f'
+
+ def test_virt(self):
+ """
+ :avocado: tags=arch:aarch64
+ :avocado: tags=machine:virt
+ """
+ self.vm.set_machine('virt')
+ self.vm.add_args('-cpu', 'cortex-a53')
+ self.vm.add_args('-bios',
+ os.path.join(SRC_ROOT_DIR, 'pc-bios',
+ 'edk2-aarch64-code.fd'))
+ self.vm.add_args('-device', 'virtio-rng-pci,rng=rng0')
+ self.vm.add_args('-object', 'rng-random,id=rng0,filename=/dev/urandom')
+ self.vm.launch()
+ self.wait_for_boot_confirmation()
This boots a Fedora 30 guest using edk2. During the first Fedora 30 boot on aarch64, there's a filesystem resize operation. The typical output is similar to: [ 203.798938] EXT4-fs (sda2): resizing filesystem from 999168 to 999675 blocks [ 203.823032] EXT4-fs (sda2): resized filesystem to 999675 It was observed that, when using virtio-blk, it seems that random numbers are exhausted, unless an RNG device is given. Interestingly the same was *not* observed with virtio-scsi. In accordance with the other similar tests, this uses the default devices on the machine model used (virtio-blk here) and adds the necessary options to make it operation. In the future, other combinations (such as virtio-scsi) can, should and will be tested. Signed-off-by: Cleber Rosa <crosa@redhat.com> --- tests/acceptance/boot_linux.py | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-)