QA (public) » openQA Project (public) » openQA Tests (public) » qe-yam

Notes on what I'm doing¶

• Using Build 10.1 for d-installer 0.8 now
• first tests in a KVM show that the entry screen offers a selection between "ALP-Bedrock" and "ALP-Micro".
• Tried to follow the example instructions abobve, but this raises a few questions
  • Q1: The "terminal" that we see here, do we have testapi methods to use this?
  • Q2: We have no root privileges assigned. Tried to do a manual install (this time still with build 9.1) and then a d-installer-config´show, but even here root pivileges are not shown?
  • Q3: Should the automation process take the "shell command" approach or do we need to make needles and click ourselves through the d-installer?

When root passowrd is set then d-installer config show shows this JSON:

{"user":{"fullName":"joe","userName":"joe","password":"doe","autologin":false},"root":{"sshPublicKey":""},"software":{"product":"ALP-Bedrock"},"storage":{"lvm":null,"encryptionPassword":null,"devices":[]}}

Please sync with Lemon about that, we are not going to use the Cockpit console, but the method editing kernel parameter:
https://github.com/yast/agama/pull/495/files#diff-497cb1ae0275e84faab89f44cfc9c9027678f18fbf279098df5afd9ddf7e7cd6R16

Notes¶

Tried this script approach with a shell skript:

set -ex

/usr/bin/dinstaller config set software.product=ALP-Bedrock
/usr/bin/dinstaller config set user.userName=joe user.password=doe
/usr/bin/dinstaller config set root.password=nots3cr3t
/usr/bin/sleep 30
/usr/bin/dinstaller install
/sbin/reboot

Installation is then really rebooting after the install part. The sleep seems to be needed to trigger installation.
Remaining "problem" is that the installation does not change the boot order, so the reboot boots again from the ISO and launches the installer if we don't intervene manually.

Also in this way I was able to set a root password which didn't work with the JSON approach.

Asked about the reboot issue on the Slack channel.

Notes¶

Goal for this step was to put the automatic installation on openqa.opensuse.org and make it work for aarch64 and x86_64.

So here is what I did:

• posted the d-installer-0.8.3-Build-11.1 iso images to O3.
• tweaked the "Development Agama" job group:
  • CASEDIR now points to my branch alp-automation
  • Schedule is adapted to auto-installation
  • The dinst.auto parameter is submitted as EXTRABOOTPARAMS. To avoid ths headache with how to integrate this in openQA I just pointed to the configuration shell script on github (note that you need the raw.githubuserconten..-URL, with the URL copied from the Raw button in GitHub it does not work because this URL is redirected).
  • Good news is that after the installation openQA reboots directly into the installation and not back into the install media.
  • To finish the test the wait_auto_reboot checks for the final login prompt in textmode with tag tty6-selected.

With this setup those simple tests are successful.

I created [#127349] to implement the code for handling the agama.auto parameter as a possible next action to this ticket.

dinst.auto is outdated in last snapshot for qa (march prototype), we shouldn't work with that iso but instead use the one in YaST Head project, please ensure latest iso generated by the upstream project in obs (YaST Head) is in fixed directory in openQA.
Flavor should be Agama and test suite name for example "agama_autoinstallation_default".
Does it work with 2G of RAM?
We definitely need to see the steps with screenshot and some logic that tell us where we are, grub, etc, not just arrive to the final destination.
For aarch64 we are not installing anything yet apparently.
Check explicitly for a custom tty needle shouldn't be required, select console should give us that, perhaps we need some needle for that as we don't have the needle for the product that we install.

Accessed the test on O3 now for aarch64. Today we end up in the installation, but the bad news is that all that stuff seems to run while we're still in bootloader_start, so the first thing you see now in the next test is the login screen for the already installed system.

At the moment I cannot explain why

• we are successful now, but the installation part happens during bootloader_start.
• the installation didn't work 8 days ago (we changed nothing in the job group, image or whatever)

Now I finally understand what went "wrong" on aarch64. Practically nothing, but the problem was that aarch is terribly slow.

So in a normal run we're booting the Live CD which then boots to a login prompt and then starts X and the D-Installer. Unfortunately in our wait_auto_reboot we're triggering exactly on that login prompt and then finish with the test. So when I didn't try to debug, it looked like the test failed. When I tried to debug and stopped at the beginning of the wait_auto_reboot testmodule of course the worker stopped waiting for my commands, but the SUT was doing what it was supposed to do, installing the system. So in that case we saw the installer doing its job, in the runs without human intervention we dropped out at the first text login that appeared (which on aarch was the wrong one).

Now wait_auto_reboot is refactored and looks for 3 needles to see if

• we see the installer screen
• we see that it is installing
• the final "Welcome to ALP Bedrock" message.

This seems to work on both architectures.

PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/16927