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

From my notes (I'm not an expert in transactional-systems).

Grab a test with the default SLEM5.5 image: sle-micro-5.5-Default-Updates-x86_64-slem_image_default@64bit

# 1. activate the system
$ transactional-update register -r %regcode%
$ reboot
# dup
$ transactional-update dup
$ reboot
# migrate
$ transactional-update migration
$ reboot
# check that we're on the new version
$ zypper products -i

josegomezr wrote in #note-3:

From my notes (I'm not an expert in transactional-systems).

Grab a test with the default SLEM5.5 image: sle-micro-5.5-Default-Updates-x86_64-slem_image_default@64bit

# 1. activate the system
$ transactional-update register -r %regcode%
$ reboot
# dup
$ transactional-update dup
$ reboot
# migrate
$ transactional-update migration
$ reboot
# check that we're on the new version
$ zypper products -i

Thanks @josegomezr, actually the migration is already automated, but the rollback part I guess is that only that command described in the ticket, right?

No, it should be a normal system rollback, adding to my notes before (I didn't got to the stage of running a rollback before cuz I hit some other roadblocks).

[...]
$ zypper products -i
$ transactional-updates rollback <snapshot-number-of-the-previous-version>
$ reboot
# check we're on 5.5 again
$ zypper products -i

with this I think it should be possible to do 5.5 -> 6.0 -> 5.5

if you skip the journal check, does the rollback work for aarch64 and x86_64?
https://openqa.suse.de/tests/overview?distri=sle-micro&version=6.0&build=5.12&groupid=510

JERiveraMoya wrote in #note-12:

if you skip the journal check, does the rollback work for aarch64 and x86_64?
https://openqa.suse.de/tests/overview?distri=sle-micro&version=6.0&build=5.12&groupid=510

Yes, I remember I had excluded a few modules from the schedule and rollback worked.

syrianidou_sofia wrote in #note-13:

JERiveraMoya wrote in #note-12:

if you skip the journal check, does the rollback work for aarch64 and x86_64?
https://openqa.suse.de/tests/overview?distri=sle-micro&version=6.0&build=5.12&groupid=510

Yes, I remember I had excluded a few modules from the schedule and rollback worked.

today is failing only for 2 architectures:
https://openqa.suse.de/tests/overview?result=failed&result=incomplete&result=timeout_exceeded&distri=sle-micro&version=6.0&build=7.3&groupid=510

JERiveraMoya wrote in #note-14:

syrianidou_sofia wrote in #note-13:

JERiveraMoya wrote in #note-12:

if you skip the journal check, does the rollback work for aarch64 and x86_64?
https://openqa.suse.de/tests/overview?distri=sle-micro&version=6.0&build=5.12&groupid=510

Yes, I remember I had excluded a few modules from the schedule and rollback worked.

today is failing only for 2 architectures:
https://openqa.suse.de/tests/overview?result=failed&result=incomplete&result=timeout_exceeded&distri=sle-micro&version=6.0&build=7.3&groupid=510

The problem seems to be that grub2 is not displayed when the system reboots. Even though we can see it here: https://openqa.suse.de/tests/13972705#step/suseconnect_scc/27
I tried here with QEMURAM=2048 and it failed again. I thought it's a timeout issue, thus I paused and connected via vnc. Grub was perfectly visible, but the openqa screen was not updated accordingly. So, the issue seems quite strange, most likely infra problem. I will ask in #eng-testing

syrianidou_sofia wrote in #note-15:

JERiveraMoya wrote in #note-14:

syrianidou_sofia wrote in #note-13:

JERiveraMoya wrote in #note-12:

if you skip the journal check, does the rollback work for aarch64 and x86_64?
https://openqa.suse.de/tests/overview?distri=sle-micro&version=6.0&build=5.12&groupid=510

Yes, I remember I had excluded a few modules from the schedule and rollback worked.

today is failing only for 2 architectures:
https://openqa.suse.de/tests/overview?result=failed&result=incomplete&result=timeout_exceeded&distri=sle-micro&version=6.0&build=7.3&groupid=510

The problem seems to be that grub2 is not displayed when the system reboots. Even though we can see it here: https://openqa.suse.de/tests/13972705#step/suseconnect_scc/27
I tried here with QEMURAM=2048 and it failed again. I thought it's a timeout issue, thus I paused and connected via vnc. Grub was perfectly visible, but the openqa screen was not updated accordingly. So, the issue seems quite strange, most likely infra problem. I will ask in #eng-testing

Does it make any difference to use process_reboot(trigger => 1) in the same way that suseconnect_scc does? Looks like the problem is even before the rollback, so a normal reboot is needed.

JERiveraMoya wrote in #note-16:

syrianidou_sofia wrote in #note-15:

JERiveraMoya wrote in #note-14:

syrianidou_sofia wrote in #note-13:

JERiveraMoya wrote in #note-12:

if you skip the journal check, does the rollback work for aarch64 and x86_64?
https://openqa.suse.de/tests/overview?distri=sle-micro&version=6.0&build=5.12&groupid=510

Yes, I remember I had excluded a few modules from the schedule and rollback worked.

today is failing only for 2 architectures:
https://openqa.suse.de/tests/overview?result=failed&result=incomplete&result=timeout_exceeded&distri=sle-micro&version=6.0&build=7.3&groupid=510

The problem seems to be that grub2 is not displayed when the system reboots. Even though we can see it here: https://openqa.suse.de/tests/13972705#step/suseconnect_scc/27
I tried here with QEMURAM=2048 and it failed again. I thought it's a timeout issue, thus I paused and connected via vnc. Grub was perfectly visible, but the openqa screen was not updated accordingly. So, the issue seems quite strange, most likely infra problem. I will ask in #eng-testing

Does it make any difference to use process_reboot(trigger => 1) in the same way that suseconnect_scc does? Looks like the problem is even before the rollback, so a normal reboot is needed.

Indeed, if I remove all modules between migration and rollback, the reboot works. I tried the suggestion from Marrius to reset_consoles but that doesn't help. I will try to replace the reboot and see if it helps.

It works indeed, even for s390x. I have made a PR here and waiting for second VRs to pass