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 iutil.cpuFeatureFlags(): 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).
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.
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.
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
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 447221 has been marked as a duplicate of this bug. ***
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.