Bug 1691832 - NFSISO test failed on f30 (20190320)
Summary: NFSISO test failed on f30 (20190320)
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 30
Hardware: powerpc
OS: Linux
high
high
Target Milestone: ---
Assignee: Jiri Konecny
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Keywords:
Depends On:
Blocks: PPCTracker F30FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2019-03-22 15:53 UTC by Michel Normand
Modified: 2019-04-12 23:43 UTC (History)
12 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2019-04-11 02:14:07 UTC


Attachments (Terms of Use)
nfsiso_variation_check_install_source_packaging.log (16.61 KB, text/plain)
2019-03-22 15:53 UTC, Michel Normand
no flags Details
nfsiso_variation_check_install_source_anaconda.log (17.67 KB, text/plain)
2019-03-22 15:55 UTC, Michel Normand
no flags Details
nfsiso_variation_check_install_source_journalctl.log (379.95 KB, text/plain)
2019-03-22 15:56 UTC, Michel Normand
no flags Details

Description Michel Normand 2019-03-22 15:53:42 UTC
Created attachment 1546947 [details]
nfsiso_variation_check_install_source_packaging.log

NFSISO test failed on f30 (20190320) 

The packaging log reports failure to access repodata from iso.
===
10:48:12,798 ERR packaging: base repo (nfs/file:///run/install/source/image.iso) not valid -- removing it
===

as per this log I am not sure anaconda is really mounting the iso accessible via nfs.

expecting to match the NFSISO variation test as per
https://fedoraproject.org/wiki/QA:Testcase_install_repository_NFSISO_variation

Comment 1 Michel Normand 2019-03-22 15:55 UTC
Created attachment 1546948 [details]
nfsiso_variation_check_install_source_anaconda.log

Comment 2 Michel Normand 2019-03-22 15:56 UTC
Created attachment 1546949 [details]
nfsiso_variation_check_install_source_journalctl.log

Comment 3 Michel Normand 2019-03-26 12:12:48 UTC
I do not know what additional data you need for investigation, what else do you need ?

I verified that same test is still working for f29 (so problem only since f30)

Comment 4 Michel Normand 2019-03-26 15:00:19 UTC
as per anaconda log extracts and source line, I assume not a problem of iso mount, 
but probably get_base_repo_metadata (1) reporting None as repo_md
Do not have lines in anaconda.log to explain why.

Is there a way to have more info ?
                                                 
=== extract anaconda.log
10:47:40,272 DBG payload: Setting up nfs install device
10:47:40,275 INF payload: mounting 10.0.2.110:/iso:nfsvers=4 on /run/install/source            
10:47:41,261 INF threading: Thread Done: AnaTimeInitThread (140735478428032)
10:47:41,280 DBG image: Checking /run/install/source/image.iso
10:47:41,291 DBG image: mounting /run/install/source/image.iso on /mnt/install/cdimage         
10:47:41,359 DBG image: Reading .discinfo
10:47:41,375 DBG image: discArch = ppc64le
10:47:41,388 WRN image: /run/install/source/image.iso doesn't have repodata, skipping          
10:47:41,511 DBG payload: retrieving treeinfo from file:///run/install/source/image.iso (proxy: None ; ssl_verify: True)
...
10:48:12,760 WRN payload: Install tree metadata fetching failed: Can't get .treeinfo file from the url file:///run/install/source/image.iso
10:48:12,761 DBG payload: getting release version from tree at file:///run/install/source/image.iso (30)
10:48:12,761 DBG payload: using default release version of 30
===

(1) 
===
./anaconda.upstream/pyanaconda/image.py:100:        if not _check_repodata(mount_path):
./anaconda.upstream/pyanaconda/image.py:135:def _check_repodata(mount_path):
    install_tree_meta = InstallTreeMetadata()
    repo_md = install_tree_meta.get_base_repo_metadata()
===
https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/payload/install_tree_metadata.py#L188

Comment 5 Adam Williamson 2019-04-01 15:27:05 UTC
this test case backs a Final criterion and this bug doesn't seem to be especially arch-specific so far, so proposing as a Final blocker.

Criterion: "The installer must be able to use all supported local and remote package and installer sources." - https://fedoraproject.org/wiki/Fedora_30_Final_Release_Criteria#Package_and_installer_sources

Comment 6 Geoffrey Marr 2019-04-02 08:23:07 UTC
Discussed during the 2019-04-01 blocker review meeting: [1]

The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criteria:

"The installer must be able to use all supported local and remote package and installer sources."

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-04-01/f30-blocker-review.2019-04-01-16.00.txt

Comment 7 Jiri Konecny 2019-04-05 15:42:57 UTC
PR: https://github.com/rhinstaller/anaconda/pull/1937

Comment 8 Fedora Update System 2019-04-09 16:03:48 UTC
anaconda-30.25.5-1.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-e2e3cfdb2b

Comment 9 Lukas Ruzicka 2019-04-10 13:44:43 UTC
I built a new iso with Anaconda 30.25.5-1 and I was able to select an ISO file on a NFS share, Anaconda sucessfully installed the server from the DVD iso and the system booted up withou issues. Unfortunately, I did not keep any logs from the installation, if needed I could install again and keep them this time.
However, I think that problem is FIXED.

Comment 10 Fedora Update System 2019-04-10 14:37:53 UTC
anaconda-30.25.5-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e2e3cfdb2b

Comment 11 Fedora Update System 2019-04-11 02:14:07 UTC
anaconda-30.25.5-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

Comment 12 Adam Williamson 2019-04-12 06:59:48 UTC
with the new anaconda it seems https://bugzilla.redhat.com/show_bug.cgi?id=1699179 happens instead. openQA is seeing that as well as Geoff.

Comment 13 Adam Williamson 2019-04-12 23:43:50 UTC
The thing openQA was seeing was something different, a bug in the test; with that fixed it seems to be working now. Thanks.


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