Bug 445974 - minstg2 installs fail - missing /usr/sbin/lspci
minstg2 installs fail - missing /usr/sbin/lspci
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: 447221 (view as bug list)
Depends On:
Blocks: F9Blocker
  Show dependency treegraph
Reported: 2008-05-10 16:32 EDT by Jon Stanley
Modified: 2008-08-04 11:13 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-08-04 11:13:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
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.

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