Bug 1552401 - Installation failure should catch: The following software marked for installation has errors
Summary: Installation failure should catch: The following software marked for installa...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Beaker
Classification: Retired
Component: general
Version: develop
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: 25.1
Assignee: Roman Joost
QA Contact: Matt Tyson 🤬
URL:
Whiteboard:
: 1413827 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-03-07 04:49 UTC by Roman Joost
Modified: 2018-04-11 05:19 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2018-04-11 05:19:57 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Beaker Project Gerrit 6031 0 None ABANDONED Adjust installation failure detection pattern 2020-04-23 07:48:35 UTC

Description Roman Joost 2018-03-07 04:49:30 UTC
Description of problem:

During testing of Bug 1413827 I ran into a new error which Beaker would not detect:


      
Error      
  The following software marked for installation has errors.  This is likely 
  caused by an error with 
  your installation source. 
   
   
   Problem: conflicting requests 
    - nothing provides libisl.so.15()(64bit) needed by gcc-7.3.1-2.fc27.x86_64      
      
Press ENTER to exit: [-- MARK -- Wed Mar  7 04:35:00 2018] 

Version-Release number of selected component (if applicable):
develop

How reproducible:
100%

Steps to Reproduce:
1. Create a new job
2. Use the <distro /> tag to provide an installation source:

      <distro>
        <tree url="http://download.eng.bos.redhat.com/redhat/released/F-27/GOLD/Workstation/x86_64/os/"/>
        <kernel url="images/pxeboot/vmlinuz"/>
        <initrd url="images/pxeboot/initrd.img"/>
        <arch value="x86_64"/>
        <osversion major="Fedora27" minor="0"/>
        <variant value="Workstation"/>
      </distro>

3. Do not supply additional repos

Actual results:
EWD is fired

Expected results:
Installation failure detector detects and aborts the job

Additional info:

Comment 2 Anwesha Chatterjee 2018-03-07 05:09:11 UTC
I cannot seem to find this pattern in our install failure patterns. So I think that would be the issue.

Comment 3 Dan Callaghan 2018-03-07 05:18:14 UTC
Looks very similar to this existing one in the test suite:

https://git.beaker-project.org/cgit/beaker/tree/IntegrationTests/src/bkr/inttest/labcontroller/install-failure-logs/f20-package-errors.txt

Comment 4 Roman Joost 2018-03-07 06:09:36 UTC
I copied the log as 'f27-package-failure.txt' into our integration tests and the test fails with:

======================================================================                                                
FAIL: bkr.inttest.labcontroller.test_watchdog.test_anaconda_failure_samples('f27-package-failure.txt',)
----------------------------------------------------------------------                                                
Traceback (most recent call last):                         
  File "/usr/lib/python2.6/site-packages/nose/case.py", line 197, in runTest                                          
    self.test(*self.arg)     
  File "/home/rjoost/works/beaker/IntegrationTests/src/bkr/inttest/labcontroller/test_watchdog.py", line 343, in check_anaconda_failure_sample
    raise AssertionError('No failure found')               
AssertionError: No failure found 

Comparing the two strings from the error log in comment 3 with the one I posted here does not show any visible difference, except being broken up by different new lines at different stages.

Will investigate more.

Comment 5 Anwesha Chatterjee 2018-03-07 06:10:54 UTC
> Looks very similar to this existing one in the test suite:
> 
> https://git.beaker-project.org/cgit/beaker/tree/IntegrationTests/src/bkr/
> inttest/labcontroller/install-failure-logs/f20-package-errors.txt

Yes, but thats a logfile, rather than a pattern? Don't we need a pattern to identify the error?(In reply to Dan Callaghan from comment #3)

Comment 6 Roman Joost 2018-03-07 06:17:58 UTC
(In reply to Anwesha Chatterjee from comment #5)
> > Looks very similar to this existing one in the test suite:
> > 
> > https://git.beaker-project.org/cgit/beaker/tree/IntegrationTests/src/bkr/
> > inttest/labcontroller/install-failure-logs/f20-package-errors.txt
> 
> Yes, but thats a logfile, rather than a pattern? Don't we need a pattern to
> identify the error?(In reply to Dan Callaghan from comment #3)

The test checks if the installation failure detector finds an error with all failure samples in the directory. The f20-package-errors.txt has the same error string as the console.log for this bug, yet an error is found for f20-package-errors, but not the console.log for this bug, even tho the error pattern is the same? (Based on the assumption that the current F20 packaging error is detected by the same pattern).

Comment 7 Roman Joost 2018-03-07 06:42:17 UTC
I've found the difference. The pattern which matches the F20 packaging error is:

  'Press enter to exit\\.'

because the error ends with:

  Press enter to exit.

In this reported case the error ends with:


  Press ENTER to exit: [-- MARK -- Wed Mar  7 04:35:00 2018]

In case you haven't noticed, there is now a colon instead of a full stop.

Comment 8 Dan Callaghan 2018-03-07 07:07:31 UTC
I guess this might be some wording tweak in recent Anaconda. It would be good to confirm if that is true (and maybe, roughly which Anaconda versions it changed).

If it is just an intentional wording tweak in recent Anaconda, then I would suggest to just add this as a new sample and tweak the pattern to match this new wording as well.

If it feels like we're fighting a losing battle, trying to keep up with every change in wording in Anaconda's serial console output... well yes, we are. But unless someone does something nicer like bug 893075 this is the best we can do.

Comment 9 Roman Joost 2018-03-15 23:42:44 UTC
*** Bug 1413827 has been marked as a duplicate of this bug. ***

Comment 11 Matt Tyson 🤬 2018-04-06 05:37:02 UTC
I've tested with the supplied beaker snippet and beaker will abort when the error happens, instead of waiting for the watchdog timeout.

Comment 12 Roman Joost 2018-04-11 05:19:57 UTC
Beaker 25.1 has been released:

https://beaker-project.org/docs/whats-new/release-25.html#beaker-25-1


Note You need to log in before you can comment on or make changes to this bug.