Containers: " No module named subprocess" error found in load (20190312T163454Z)

Bug #1819964 reported by Peng Peng
This bug report is a duplicate of:  Bug #1819941: STX installation failed. Edit Remove
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
StarlingX
Fix Released
Critical
Scott Little

Bug Description

Brief Description
-----------------
When install new load to lab, "ImportError: No module named subprocess" was found

Severity
--------
Critical

Steps to Reproduce
------------------
boot up lab from new load

Expected Behaviour
------------------
installer start

Actual Behaviour
----------------
Failed

Reproducibility
---------------
Reproducible
100%

System Configuration
--------------------
all system

Branch/Pull Time/Commit
-----------------------
master as of 20190312T163454Z

Timestamp/Logs
--------------
7m[anaconda] 1:main* 2:shell 3:log 4:storage-log 5:program-log ^[[m^[(B^[[24;1H^[[1;24r^[[H^[[24;1H^[[7m[anaconda] 1:main* 2:shell 3:log 4:storage-log 5:> Switch: Alt+Tab or Ctrl-o ^[[m^[(B^[[1;1H^[[1;23rStarting installer, one moment...^[[1;24r^[[H
^[[1;23r^[[H
Traceback (most recent call last):
  File "/sbin/anaconda", line 826, in <module>^[[1;24r^[[H^[[3B^[[1;23r^[[H^[[3B from pyanaconda import geoloc^[[1;24r^[[H^[[4B^[[1;23r^[[H^[[4B File "/usr/lib64/python2.7/site-packages/pyanaconda/geoloc.py", line 109, in <module>
    ^[[1;24r^[[H^[[7;5H^[[1;23r^[[H^[[7;5Hfrom pyanaconda import network
  File "/usr/lib64/python2.7/site-packages/pyanaconda/network.py", line 28, in <module>
    from pyanaconda import iutil
  File "/usr/lib64/python2.7/site-packages/pyanaconda/iutil.py", line 40, in <module>^[[1;24r^[[H^[[13;1H^[[1;23r^[[H^[[13;1H import subprocess32 as subprocess
ImportError: No module named subprocess32^[[1;24r^[[H^[[15;1H^[[1;23r^[[H^[[23;1H^[[1mPane is dead^[[H^[[m^[(BTraceback (most recent call last):^[[K
  File "/sbin/anaconda", line 826, in <module>^[[K
    from pyanaconda import geoloc^[[K
  File "/usr/lib64/python2.7/site-packages/pyanaconda/geoloc.py", line 109, in <module>^[[K
    from pyanaconda import network^[[K
  File "/usr/lib64/python2.7/site-packages/pyanaconda/network.py", line 28, in <module>^[[K
    from pyanaconda import iutil^[[K
  File "/usr/lib64/python2.7/site-packages/pyanaconda/iutil.py", line 40, in <module>^[[K
    import subprocess32 as subprocess^[[K
ImportError: No module named subprocess32^[[K

Revision history for this message
Ghada Khalil (gkhalil) wrote :
Ghada Khalil (gkhalil)
Changed in starlingx:
importance: Undecided → Critical
tags: added: stx.2019.05 stx.distro.other
Ken Young (kenyis)
Changed in starlingx:
assignee: nobody → Scott Little (slittle1)
Revision history for this message
Ghada Khalil (gkhalil) wrote :
Revision history for this message
Scott Little (slittle1) wrote :

The CENGN build does not delete stx-tools/centos-mirror-tools/output between build. This speeds builds by reusing rpms, tarballs and other files downloaded by prior builds. This works great for versioned files like rpms. It dos not work at all for non-versioned files like squashfs.img. 'download_mirrors.sh', via it's daughter script 'dl_other_from_centos_repo.sh', was happy to say 'Already downloaded' and left us with the 7.4 version of squashfs.img, rather than replace it with the 7.6 version.

Sort term work around will be to delete all the non-versioned files created by 'dl_other_from_centos_repo.sh' as found in the CENGN build directories.

A longer term solution will be to fix dl_other_from_centos_repo.sh. Possibilities are ...
1) checksum the file vs a checksum stored in a modified other_downloads.lst
2) Store the files in a versioned subdirectory. Perhaps add symlinks to bridge the gap from old non-versioned path to versioned path so that the rest of the build scripts can stay as is.

Ghada Khalil (gkhalil)
tags: added: stx.build
removed: stx.distro.other
Revision history for this message
Scott Little (slittle1) wrote :
Revision history for this message
Scott Little (slittle1) wrote :

Workaround is to delete directories ...
   .../stx-tools/centos-mirror-tools/output/stx-r1/CentOS/pike/Binary/EFI
   .../stx-tools/centos-mirror-tools/output/stx-r1/CentOS/pike/Binary/images
   .../stx-tools/centos-mirror-tools/output/stx-r1/CentOS/pike/Binary/isolinux
   .../stx-tools/centos-mirror-tools/output/stx-r1/CentOS/pike/Binary/LiveOS

and then re-run the 'download_mirrors.sh' step.

The installer is now building correctly, and has been verified in several labs.

A longer term fix will be tracked by https://storyboard.openstack.org/#!/story/2005234

Revision history for this message
Ghada Khalil (gkhalil) wrote :

This has been addressed. See notes in https://bugs.launchpad.net/starlingx/+bug/1819941

Changed in starlingx:
status: New → Fix Released
Ken Young (kenyis)
tags: added: stx.2.0
removed: stx.2019.05
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.