Bug 81313 - Phoebe: after firstboot, switching vc causes X to move to vc8
Summary: Phoebe: after firstboot, switching vc causes X to move to vc8
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: firstboot   
(Show other bugs)
Version: phoebe
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Brent Fox
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 79579
TreeView+ depends on / blocked
 
Reported: 2003-01-07 23:20 UTC by Chris Kloiber
Modified: 2008-05-01 15:38 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-29 16:02:00 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Chris Kloiber 2003-01-07 23:20:42 UTC
1. installed Phoebe on IBM x305
2. selections during firstboot:
forward
forward, yes
forward
forward, cancel

3. did NOT login.  switch to vc1.
4.  switch back to vc 7

result:  only an arrow appeared on a black screen in vc7.
gui had moved to vc8.

Comment 1 Marius Andreiana 2003-01-09 19:16:11 UTC
It happened to me too, but I couldn't reproduce it again after I started to use
the system.

Comment 2 Brent Fox 2003-01-09 21:18:29 UTC
I can reproduce it.  Should be fixed in firstboot-1.0.3-5.  QA, please verify.

Comment 3 Jay Turner 2003-01-10 17:28:15 UTC
Looks like things are all taken care of in firstboot-1.0.3-5.

Comment 4 Chris Kloiber 2003-01-13 22:07:05 UTC
Wendy Hung at IBM reports that she can still reproduce the problem with
firstboot-1.0.3-5.

Comment 5 Brent Fox 2003-01-29 16:02:00 UTC
I think the problem is that firstboot is sometimes exiting before the X server
has finished dying off.  Then when GDM tries to start it's X server, it appears
that VC7 is already in use, so it starts its server on VC8.

I've added a 1 second sleep that should give the X server time to die before
firstboot exits.  It's not the cleanest way to do it, but it should work.  See
if she can duplicate the problem with firstboot-1.0.4-6


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