• Now all s390x cases are blocked by agama_boot. only agama_default works. but not auto test.

hjluo wrote in #note-10:

JERiveraMoya wrote in #note-8:

hjluo wrote in #note-7:

• Now all s390x cases are blocked by agama_boot. only agama_default works. but not auto test.

I restarted in the morning after renaming in O3, every day you work with new builds you need to run as geekotest to make it pass the boot phase.

cd /var/lib/openqa/factory/repo/
mv agama-installer.s390x-10.0.0-openSUSE-Build<version>.iso agama.s390x-10.0.0-Build<version>.iso

due to character limitation in s390x zVM.
https://openqa.opensuse.org/tests/4558965
https://openqa.opensuse.org/tests/4558964

OK, thanks for the information.

Any reason to put it back on Workable? otherwise it makes not sense to assign yourself this ticket if you are not working on it.

• Tried to rename iso to make it shorter and boot up,it failed with send_key not defined.

Test died: Can't call method "send_key" on an undefined value at /usr/lib/os-autoinst/consoles/ttyConsole.pm line 12.¶

at /usr/lib/os-autoinst/testapi.pm line 1690.
testapi::select_console("installation", "timeout", 600) called at /var/lib/openqa/pool/103/os-autoinst-distri-opensuse/tests/yam/agama/../../installation/bootloader_s390.pm line 346
bootloader_s390::run(boot_agama=HASH(0x560c9e4342e8)) called at /var/lib/openqa/pool/103/os-autoinst-distri-opensuse/tests/yam/agama/boot_agama.pm line 30

hjluo wrote in #note-13:

• Tried to rename iso to make it shorter and boot up,it failed with send_key not defined.

Test died: Can't call method "send_key" on an undefined value at /usr/lib/os-autoinst/consoles/ttyConsole.pm line 12.¶

at /usr/lib/os-autoinst/testapi.pm line 1690.
testapi::select_console("installation", "timeout", 600) called at /var/lib/openqa/pool/103/os-autoinst-distri-opensuse/tests/yam/agama/../../installation/bootloader_s390.pm line 346
bootloader_s390::run(boot_agama=HASH(0x560c9e4342e8)) called at /var/lib/openqa/pool/103/os-autoinst-distri-opensuse/tests/yam/agama/boot_agama.pm line 30

Few tips here that cross my mind:

• Instead of reporting that your custom job run doesn't work applying that simple step, it would more clear to report that our production job run doesn't work. For example I restarted
  https://openqa.opensuse.org/tests/4565364. So you can see if it is your branch code which creates the issue or something else has changed. In this case it seems to be on your side or at the moment that you tried because in prod the system boots fine applying the rename.
• To report progress in your ticket you could use a better approach IMO, just summarize blockers, findings, etc. but for a technical doubt like that above it makes no sense to report it only here, you can use our slack channel and get help from anyone, not only (because not the whole squad receive notifications about tickets, only creator and partipants and watchers in progress tickets). It will be faster and more effective and you can still report back here if you consider it is needed.
  I hope that helps.
  I saw you also reported in #eng-testing, https://suse.slack.com/archives/C02CANHLANP/p1729050967190499 that is good, I missed this info here, too many channels! :) , that is why slack is more optimal than writing here more than summaries, still my advice above might be useful.

• Try to use agama log store to store the agama log

• Then try to check agama-auto.out.log and wait following line

  [3/3] Configure the system
agama-auto.service: Deactivated successfully.

or in /var/log/YaST2/y2log
Error output: Installation finished. No error reported.

• Then reboot the system.

• PR: WIP: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/20426

hjluo wrote in #note-15:

• PR: WIP: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/20426

what will be your approach, did you find something useful to wait for the installation finishes?
we can always take a look before implementation.

• For the implementation discusssion.
• Now move to OSD for shorten url to avoid weird workarounds on O3.

• Now on OSD it failed with Could not select the base product 'SLES'.
• Verified shorten_url is work on OSD
  • you can see the profile is actually same as our default_sle.json. so I can see the shorten_url is actully works now.

• Asked in #prog-agama

From Ladislav Slezak

Ah, found it, the x86_64 and aarch64 use HTTP URL while s390 and PPC HTTPS.
We should switch all to plain HTTP. The repositories are GPG checked anyway it is not a problem.
I'll fix that.

JFYI: fixed in https://github.com/agama-project/agama/pull/1688

• Now ask in #proj-agama for which message shoud we check to check for profile fail.

• Still failed in 2.9 for same failure: https://openqa.suse.de/tests/15807707#step/agama_auto/5

I guess we gave a try here (25 days) and now there are product issues that stop us to keep up testing/developing automation.
Are you ok with return the ticket to backlog to evaluate later and give the opportunity to someone else.
That would mean:

• Unassigned yourself from the ticket.
• Set status New.
• Remove Tag.
• Add a summary with your finding and draft code, you can close the PR but leave the branch accessible.

JERiveraMoya wrote in #note-23:

I guess we gave a try here (25 days) and now there are product issues that stop us to keep up testing/developing automation.
Are you ok with return the ticket to backlog to evaluate later and give the opportunity to someone else.
That would mean:

• Unassigned yourself from the ticket.
• Set status New.
• Remove Tag.
• Add a summary with your finding and draft code, you can close the PR but leave the branch accessible.

OK.

https://trello.com/c/kdvo6Dtw/447-agama-add-an-agama-monitor-command

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: agama_auto_default
https://openqa.suse.de/tests/16024964#step/agama_auto/1

To prevent further reminder comments one of the following options should be followed:

1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

We will try this first: https://progress.opensuse.org/issues/170434 due to checking the logs could have helped us for a while to file bugs, but we need to clarify better solutions. We will check for feedback/new updates here: https://jira.suse.com/browse/PED-10808

I believe that it is not s390x specific. Any(x86_64, s390x, powervm) bare metal installation also uses VNC to connect and proceed with system install.

pcervinka wrote in #note-32:

I believe that it is not s390x specific. Any(x86_64, s390x, powervm) bare metal installation also uses VNC to connect and proceed with system install.

this is a hack, even better than this is to listen the socket was suggested in Jira, this ticket most likely will be rejected but ok if we can link it to see all the spectrum of possibilities:

You can use the WebSocket from our HTTP API to monitor the progress. However, we plan to add a new `agama monitor` command to the CLI to make things easier. Actually, we had a PoC a few months ago, but other things had got higher priority.