Bug 445974

Summary: minstg2 installs fail - missing /usr/sbin/lspci
Product: [Fedora] Fedora Reporter: Jon Stanley <jonstanley>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: neomjp
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-08-04 11:13:59 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 235706    

Description Jon Stanley 2008-05-10 16:32:56 EDT
I was testing another bug and allocated a VM a very low amount of RAM, forcing
minstg2.img to be used (booted via PXE).  The install fails, complainignt hat it
couldn't read group data.  tty3 says /usr/sbin/lspci not found.  Thinking this a
little odd, I went and explored:

in yuminstall.py (in doGroupSetup):

if iutil.inXen() or \
                iutil.inVmware() or \
                rpmUtils.arch.getBaseArch() == "i386" and "pae" not in
            if self.ayum.comps._groups.has_key("virtualization"):
                del self.ayum.comps._groups["virtualization"]

and in iutil.py:

def inVmware():
    out = execWithCapture("/usr/sbin/lspci", ["-vvv"])
    if "VMware" in out:
        return True
    return False

Being that this code is in a critical path of setting up groups, and installs
using minstg2 will fail, we probably need to do an updates.img to remove the
dependence on inVmware().  My quick suggestion is to remove the conditional
above, and just remove the virtualization comps group, and direct users that
have problems to this updates.img.  It's unlikely that anyone who needs to use
minstg2 actually needs/wants/can use virtualization anyway.

For the future, we should probably have a testcase using minstg2.img.  I
*really* wish we would have noticed this sooner.  It is with a heavy heart that
I put this on F9Blocker (knowing that we won't actually block since we can't,
but we need a solution before release).
Comment 1 Jeremy Katz 2008-05-10 16:58:48 EDT
Can you try http://katzj.fedorapeople.org/updates-f9-minstg2.img ?

And *sigh* -- this been there for like 3 weeks at this point.  I think that more
of the point is that we need to stop having as many stupid differences between
minstg2 and stage2.  The only difference should really be the presence of all of
the X and font stuff.  Anything else should be the same.  Maybe I'll see how
much that impacts the size of the image later this week.
Comment 2 Jon Stanley 2008-05-10 19:19:17 EDT
Works in the sense of doesn't barf anymore, but when it would present the
package selection, it just sits there at a blue screen and spins the CPU.  I
can't quite tell what it's doing, the last thing on tty3 is 'moving (1) to step
basepkgsel'.  The shell on tty2 is fairly well unresponsive as well.
Comment 3 Jeremy Katz 2008-05-12 16:36:23 EDT
Are you trying on i386 or x86_64?  I just tried on i386 and it was fine...
x86_64 will need a different image since we don't include the multilib pairs in
the install images.  And the failure mode you're seeing is what I'd sort of
expect on x86_64
Comment 4 Bug Zapper 2008-05-14 06:58:31 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 5 Chris Lumens 2008-05-19 09:25:06 EDT
*** Bug 447221 has been marked as a duplicate of this bug. ***
Comment 6 Brennan Ashton 2008-06-07 23:43:32 EDT
Reporter, could you please reply to the previous question? If you won't reply in
one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.