This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 244006 - firstboot hangs with cross-hatched background and mouse-pointer
firstboot hangs with cross-hatched background and mouse-pointer
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: firstboot (Show other bugs)
7
i386 Linux
low Severity high
: ---
: ---
Assigned To: Chris Lumens
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-13 06:28 EDT by Richard Dawe
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-10 16:44:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
firstboot crash on 2007-07-10 20:24 (495 bytes, text/plain)
2007-07-10 15:42 EDT, Richard Dawe
no flags Details

  None (edit)
Description Richard Dawe 2007-06-13 06:28:07 EDT
Description of problem:


Version-Release number of selected component (if applicable):

firstboot-1.4.35-1.fc7

How reproducible:

Happened every time after I upgraded my i386 box.

Steps to Reproduce:
1. Upgrade to Fedora 7
2. Reboot
  
Actual results:

When boot sequence reaches firstboot, it seems that X has started. There is a
cross-hatched (grey) background and a mouse pointer. Nothing happens. I could
not switch virtual terminals using Ctrl+Alt+F1 (or others). Only option was to
reboot.

When I rebooted in interactive mode (pressed "I" at the right moment), I could
skip the firstboot service. Everything worked fine (including X).

I think I had this problem with Fedora Core 6 too.

Expected results:

I was hoping firstboot would do something.

Additional info:

It's a seven year-old PC.

Athlon Thunderbird 850MHz
640MB memory

NVidia video controller, configured to use the "nv" driver that ships with the
X.org X server. The NVidia binary driver was too unstable.

lspci output for my video controller:

01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] 
(rev a1) (prog-if 00 [VGA])
        Subsystem: Guillemot Corporation Unknown device 7100
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
        Latency: 64 (1250ns min, 250ns max)
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at d5000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: Memory at d8000000 (32-bit, prefetchable) [size=128M]
        Expansion ROM at d7ff0000 [disabled] [size=64K]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [44] AGP version 2.0
                Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA- ITACoh- GART64- HTrans- 64
bit- FW+ AGP3- Rate=x1,x2,x4
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<n
one>

Let me know if you'd like more details.
Comment 1 Chris Lumens 2007-07-10 12:34:16 EDT
When you get to the background and mouse pointer, is the machine completely
unresponsive?  You mention you cannot ctrl-alt-f1.  Are the lights on the
keyboard flashing?  Can you press ctrl-alt-backspace to kill X, and then see if
there are any /tmp/firstboot* or /root/firstboot* files present?
Comment 2 Richard Dawe 2007-07-10 15:41:00 EDT
Yes, it's unresponsive.

No lights flash on the keyboard. Pressing Caps, Num Lock or Scroll Lock gives no
change in the lock lights at the top of the keyboard. Ctrl+Alt+Backspace doesn't
kill the X server.

It's as if the keyboard is not working anymore.

However, the mouse pointer does move when I move the mouse.

There is a firstboot crash log:

[rich@katrina ~]$ ls -la /tmp/firstboot-crash.log 
-rw-r--r-- 1 root root 495 2007-07-10 20:24 /tmp/firstboot-crash.log

I'm running Fedora 7 + the latest updates (as of 2007-07-10 20:37 BST).

[rich@katrina ~]$ uname -a
Linux katrina.int.phekda.gotadsl.co.uk 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12
15:37:31 EDT 2007 i686 athlon i386 GNU/Linux

[rich@katrina ~]$ rpm -q kernel firstboot xorg-x11-drv-nv
kernel-2.6.21-1.3194.fc7
kernel-2.6.21-1.3228.fc7
firstboot-1.4.35-1.fc7
xorg-x11-drv-nv-2.0.96-2.fc7
Comment 3 Richard Dawe 2007-07-10 15:42:25 EDT
Created attachment 158887 [details]
firstboot crash on 2007-07-10 20:24
Comment 4 Richard Dawe 2007-07-10 15:53:47 EDT
" import rhpl.mouse as mouse
ImportError: No module named mouse"

"rpm -V rhpl" did not come up with any errors. I dug a little deeper and found
that rhpl.mouse was removed in 0.186-1. The source for 0.185-1 has this code:

warnings.warn ("rhpl.mouse is deprecated; import rhpxl.mouse instead.",
               DeprecationWarning, stacklevel=2)

I'll try patching firstboot, to see if changing "rhpl.mouse" to "rhplx.mouse" works.
Comment 5 Richard Dawe 2007-07-10 16:10:25 EDT
I've managed to fix this problem. It turned out that I had an old
system-config-mouse rpm installed, dating from 2005 -- presumably Fedora Core 5?
Anyway, I removed that rpm, rebooted and firstboot completed successfully.

I think I had the same problem with Fedora Core 6, but worked round it by
uninstalling firstboot.

So this looks more like a problem with the upgrade support in the Fedora Core 6
/ Fedora 7 installer.

I'm happy for this bug to be resolved with NOTABUG or WONTFIX, depending on what
you think is appropriate.

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