Bug 48027 - anacona fails to start xserver
Summary: anacona fails to start xserver
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 7.3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Aaron Brown
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-07-09 14:31 UTC by Gerald Teschl
Modified: 2007-04-18 16:34 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2001-08-07 14:18:52 UTC

Attachments (Terms of Use)

Description Gerald Teschl 2001-07-09 14:31:55 UTC
Description of Problem:
Tried a nfs install on my laptop (beta hw #12).  Anaconda will try to start
the xserver
but seems to fail and exits. No usable errors (anaconda exited abnormally).
Moreover, since
everything is stopped and unmounted it is hard to figure out
what is going wrong.

This is a SMI 910 card which works with both the fbdev and the XF86_SVGA

Comment 1 Michael Fulbright 2001-07-09 14:39:57 UTC
Did you try with the 'nofb' boot option?

Comment 2 Gerald Teschl 2001-07-10 09:36:29 UTC
Just found some time to do further testing:
(1) Tried a regular cd install -> makes no difference
(2) "nofb" -> no difference

Messages from anaconda:
Silicon Mation Lynx (generic)
Monitor: unable to probe
..X started succesfully
<snip - traceback>
runtime error: cannot open display

GUI install worked fine under 7.1 on this laptop.

Comment 3 Glen Foster 2001-07-13 19:47:51 UTC
This defect considered MUST-FIX for Fairfax gold-release.

Comment 4 Jeremy Katz 2001-07-22 20:45:20 UTC
Have you tried this laptop with beta2 + the update disk that msf posted to
testers-list?  That _should_ fix the problem I believe, but if not, it'd be good
to know because that would mean there's something else lingering there.

Comment 5 Gerald Teschl 2001-07-24 17:59:12 UTC
I just came back and tested beta2 (I booted from cdrom) and the problem

Comment 6 Michael Fulbright 2001-07-25 21:41:13 UTC
Did you use the update disk?

Comment 7 Gerald Teschl 2001-07-30 22:29:26 UTC
Works in beta 3 if I boot from cdrom. But if I use the pcmcia.img and
do an nfs install it will still fail to start the X server.

Comment 8 Michael Fulbright 2001-08-01 15:45:05 UTC
The NFS install fails because it was not trying to use framebuffer. Try adding
'vga=791' and try the NFS install again.

Also the traceback you snipped out would be important to have to proceed further
with this issue.

Comment 9 Gerald Teschl 2001-08-01 20:03:16 UTC
Yes, there is no "vga=.." option in the bootnet.img. Isn't this a bug?

Now I understand why it cannot start the X server. The SVGA server will
fail in 800x600 on this laptop since the X server reports invalid
mode 800x600 for panel size 1024x768!

Comment 10 Michael Fulbright 2001-08-03 19:16:28 UTC
Brent please review the syslinux config files to verify we have not lost any
vga=xxx magic for the various images.

Comment 11 Brent Fox 2001-08-03 19:53:25 UTC
I'm looking at the syslinux.cfg file on the bootnet.img from beta3 and this is
what I see for the default boot entry:  

label linux
  kernel vmlinuz
  append initrd=initrd.img lang= devfs=nomount ramdisk_size=7168 vga=788

Looks like 'vga=788' is there to me.  Are you using a non-English boot disk? 
Please attach the syslinux.cfg file from the bootdisk that does not work.

Comment 12 Gerald Teschl 2001-08-06 13:03:33 UTC
This is the content of syslinux.cfg from the bootnet.img I have downloaded from
the beta ftp site:

default linux
prompt 1
timeout 600
display boot.msg
F1 boot.msg
F2 general.msg
F3 expert.msg
F4 param.msg
F5 rescue.msg
label linux
  kernel vmlinuz
  append initrd=initrd.img lang=ja devfs=nomount ramdisk_size=7168
label text
  kernel vmlinuz
  append initrd=initrd.img lang=ja text devfs=nomount ramdisk_size=7168
label expert
  kernel vmlinuz
  append expert initrd=initrd.img lang=ja devfs=nomount ramdisk_size=7168
label ks
  kernel vmlinuz
  append ks initrd=initrd.img lang=ja devfs=nomount ramdisk_size=7168
label nofb
  kernel vmlinuz

Comment 13 Gerald Teschl 2001-08-06 13:08:34 UTC
This is strange: It says "lang=ja" but this is the file

and not the one from the "ja" subdir!?

Comment 14 Brent Fox 2001-08-06 18:21:09 UTC
Aack!  The Japanese boot disk is somehow in the root of the Roswell tree.  This
is not supposed to happen.  I pointed this out to the guys in QA who run the ftp
site, and they said they would fix it.  I'm transferring ownership of this bug
to abrown.

Comment 15 Michael Fulbright 2001-08-07 14:18:47 UTC
Has this been resolved? This is a serious problem.

Comment 16 Michael Fulbright 2001-08-07 14:22:22 UTC
This has been fixed according to abrown.

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