Bug 143222
| Summary: | xconfig causes "Red Hat Ready" kickstart to reboot on Unisys ES7000/540 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Ready Certification Tests | Reporter: | Daniel W. Ottey <daniel.ottey> | ||||
| Component: | ispec | Assignee: | Will Woods <wwoods> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Rob Landry <rlandry> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | beta | CC: | jturner, richardl, shillman | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2005-04-28 21:13:00 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 137160, 142571, 143442 | ||||||
| Attachments: |
|
||||||
Created attachment 108804 [details]
A screen capture of the error
I apologize for the poor quality of this screen capture. I do not know how to
capture the logs of this error, since the system reboots automatically. If you
can tell me how to further gather data, I would be happy to do so.
The error message is from anaconda, the system installer. Reassigning to the 'anaconda' component, for review of the traceback. (P.S. XFree86 has been replaced by X.Org X11 in Red Hat Enterprise Linux 4 beta, which is the "xorg-x11" component in bugzilla.) The hwcert tests are assuming pc-like hardware and thus try to configure X for the machine. This isn't entirely accurate for the unisys boxes which are headless. rhr2 hasn't started yet; instead it appears ispec isn't accounting for zero heads or user error in the spec submission where more than zero heads where assigned. This is a bug in iSpec. Your workaround in changing the kickstart file is correct. Reassign to wwoods to fix in iSpec's ks generation (and UI, since the UI assumes at least 1 head if a video controller is present). Code is in CVS that does the following: - change UI to allow headless video controllers (i.e. allow heads=0) - only run VIDEO if testing a video controller that supports one or more heads - ks.cfg now only includes 'xconfig' if we are running the VIDEO test i've verified on my test case. marking QA_READY for verification by unisys. We would be happy to test/verify this. Could I please be pointed in the direction of the CVS server (if available), or another location for download of this latest version? Oops, that would help ;-). I've put a temporary RPM up here: http://people.redhat.com/richardl/ispec-0.96-1.12.noarch.rpm (You should be able to rpm -Uvh the RPM and choose 0 for number of video controllers). Any feedback here? Seems to work well. Thanks. Placing in PROD_READY based on comment 12. |
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322) Description of problem: We are attempting to run the "Red Hat Ready" beta hardware certification on our Unisys ES7000/540 system, installing RHEL4. The hardware certification creates a kickstart file with the following line in it: xconfig --depth=16 --resolution=1024x768 --defaultdesktop=GNOME When this command runs on our system, anaconda reports an error and reboots. There is no way to capture the log, but I have gotten a screen capture. We narrowed the problem to this command because the error goes away when we change the "xconfig" line to "skipx." The Unisys ES7000/540 uses a proprietary video controller called "Console Manager 2" that enables remote viewing of system video. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Use "Red Hat Ready" beta hardware certification on an ES7000/540 2. 3. Actual Results: System reboots Expected Results: No error Additional info: