QA (public) » openQA Project (public) » openQA Tests (public)

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

This bug is still referenced in a failing openQA test: update_Leap_42.1_kde
https://openqa.opensuse.org/tests/935316

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

This bug is still referenced in a failing openQA test: update_Leap_42.1_kde
https://openqa.opensuse.org/tests/945390

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

This bug is still referenced in a failing openQA test: update_Leap_42.3_kde+system_performance
https://openqa.opensuse.org/tests/959088

latest occurence: https://openqa.opensuse.org/tests/975173#step/logs_from_installation_system/2

Hi @riafarov , you last comment in #50615#note-14 indicates a temporary problem? https://openqa.opensuse.org/tests/1067386#step/await_install/5 shows a recent failure with same symptoms but for sure not related to UEFI upgrade or legacy boot. What do you think about my suggestion in #50615#note-5 to "to accept the fact when we found a successfully booted system instead that we do not even need the installation logs from the next module."? That should be even easier now as it is possible to dynamically change the test schedule from the test itself. However it might be better to explicitly record the "skipping" in each test module that comes before grub_test, i.e. "logs_from_installation_system" and "reboot_after_installation".

I still see as alternative what was discussed in https://bugzilla.suse.com/show_bug.cgi?id=1122493 , managed by the YaST development team: https://trello.com/c/CDedArHx , to have an option to have indefinite timeout at the end of the installation.

EDIT: Trying myself with a suggestion for the YaST installer: https://github.com/yast/yast-installation/pull/823

riafarov wrote:

Hi @okurz. I would not call a problem which is there for a month temporary.

Yes, for sure, that's my point. But you updated the ticket status to "Workable" so that's what I meant, thanks! :)

Have you checked the failure in the job mentioned here?

Yes, I have checked. Did I miss something?

Also, as being said there is no easy way out, as our tools cannot handle this scenarios properly, meaning are unreliable. For what you are suggesting, there is already variable called GRUB_TIMEOUT.

Of course, I know about the variable. What I meant with "successfully booted system" is when we reached the grub menu, not a booted Linux system.

Alternative would be to use startshell=1 boot parameter which provides console before the reboot and doesn't require sync on the pop-up.

Yes, we discussed this already. It might be a bit too different from a normal test flow though.

As you are part of the tools team now, maybe you could take a look why we cannot match the pop-up which is there for 10 seconds?

The reason is simple: Linux is not a realtime operating system and we can not guarantee that we are able to interact with a system within time. Also see #20914 for more details. It is unfortunate that we can not make it work even within 8s but all save alternatives would come with a severe slowdown which we can not take lightly.

The bug you are referring to is against SLE 15 SP1 and about general performance, so please, do not mix everything in the single issue.

You know just the same as I do that the installer in SLE15SP1 is hardly any different from Tumbleweed so I don't know why you don't see this connect. However I mentioned the bug because the proposed solution is in there: To give a possibility to not have a timeout at all. Maybe you have an idea how we could hot-patch a live system to change https://github.com/yast/yast-installation/blob/master/src/lib/installation/clients/inst_finish.rb#L155 within the installer? In the end, it should be all ruby code, not compiled C code, right?

As now we have some job where we can reproduce the job, it can be worked on.

Hm, I doubt we have a more reproducible problem. At least this one is back to "works often, not always".

I resolved both https://bugzilla.suse.com/show_bug.cgi?id=1157476 and https://bugzilla.suse.com/show_bug.cgi?id=1122493 , now waiting for https://build.opensuse.org/project/show/openSUSE:Factory:Staging:E to be accepted for https://build.opensuse.org/request/show/751336. Afterwards we can apply the new linuxrc parameter "reboot_timeout=0" for all but older products, i.e. Tumbleweed.

EDIT: 2019-12-16: The according SRs for all Tumbleweed, Leap 15.2 and SLE15SP2 are accepted now, we can set reboot_timeout=0 for all tests on newer products:

openqa-clone-job --within-instance https://openqa.opensuse.org/tests/1113903 BUILD= _GROUP= CASEDIR=https://github.com/okurz/os-autoinst-distri-opensuse.git#feature/install_timeout TEST=minimalx_no_reboot_timeout_okurz_poo50615

Created job #1114648: opensuse-Tumbleweed-DVD-x86_64-Build20191214-minimalx@64bit -> https://openqa.opensuse.org/t1114648

-> https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/9176

Also happening for SLE15-SP2: https://openqa.suse.de/tests/3722762#step/await_install/3