Bug 597291

(In reply to comment #0)
> I'm trying to install a Xen PV guest with latest snap #6 (0527.2). Loader
> starts and I can proceed to stage2.

I don't understand ... you mean you tried to start RHEL-6 as paravirtualized guest? Why do you think RHEL-6 should be able to run paravirtualized? Should it?

(In reply to comment #0)
> - vnc and text mode start fine (add vnc or text on the command line)

Whoops, you are right RHEL-6 should run paravirtualized http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html/Beta_Release_Notes/virtualization.html#id569407 and it apparently worked for you in text mode.

If the computer is not completely frozen when installation fails, switch to the console (Ctrl+Alt+F2) and copy /tmp/X* and /var/log/anaconda.xlog to some other place -- USB stick, some other computer via network, somewhere on the Internet, and please attach it to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

If the computer is completely useless after installation fails, you can also install Fedora with a VESA mode driver (see https://fedoraproject.org/wiki/Documentation_Beats_Installer
for more information on that). Then after successful installation you can collect /var/log/anaconda.xlog, /var/log/Xorg.0.log, and the output of the program dmesg instead.

Or you can install Fedora in a text mode completely, and then start X after that. If it fails, still /var/log/Xorg.0.log and the output of dmesg program from the failed attempt to start X would be useful.

We will review this issue again once you've had a chance to attach this information.

Thank you very much in advance.

(In reply to comment #2)
> (In reply to comment #0)
> > - vnc and text mode start fine (add vnc or text on the command line)
> 
> Whoops, you are right RHEL-6 should run paravirtualized
> http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html/Beta_Release_Notes/virtualization.html#id569407
> and it apparently worked for you in text mode.
> 
> If the computer is not completely frozen when installation fails, switch to the
> console (Ctrl+Alt+F2) and copy /tmp/X* and /var/log/anaconda.xlog to some other
> place -- USB stick, some other computer via network, somewhere on the Internet,
> and please attach it to the bug report as individual uncompressed file
> attachments using the bugzilla file attachment link above.
> 

I can't switch tty's at all. 

> If the computer is completely useless after installation fails, you can also
> install Fedora with a VESA mode driver (see
> https://fedoraproject.org/wiki/Documentation_Beats_Installer
> for more information on that). Then after successful installation you can
> collect /var/log/anaconda.xlog, /var/log/Xorg.0.log, and the output of the
> program dmesg instead.

Booting with xdriver=vesa on the command line failed to start X. The last lines in X.log are:

(II) VESA: driver for VESA chipsets: vesa
(WW) Falling back to old probe method for vesa
(EE) No devices detected.

Fatal server error:
no screens found


Will attach all logs from stage2 environment.

> 
> Or you can install Fedora in a text mode completely, and then start X after
> that. If it fails, still /var/log/Xorg.0.log and the output of dmesg program
> from the failed attempt to start X would be useful.

After install, I've installed X and the system was able to start in runlevel 5 and login to GNOME. So no problems here.

Created attachment 418701 [details]
X.log from failed attempt ("no screens found")

Created attachment 418703 [details]
dmesg output

Created attachment 418704 [details]
anaconda.log

Created attachment 418706 [details]
program.log

Created attachment 418708 [details]
syslog

Created attachment 418710 [details]
storage.log

The X log doesn't show any PCI devices right afetr the "using VT number" line.  Which indicates to me that you don't have any video devices in your Xen guest.  I'm very sorry about that, but I don't think it's something X can be expected to fix.

Check 'lspci' output for VGA or Multimedia devices, and if they're not there, you need to have added them to the guest before booting it.

Actually, there's another case there, which is if we've got a /dev/fb0 for xenfb.  We should get that right, afaik, but forcing xdriver=vesa will prevent that.  Can you attach an X log from normal startup too?

Hi Adam,
sorry for late reply. 

When I start the Xen guest so that it shows black screen I can't get any output out of it. I can't switch to tty2 and type commands or do anything else. 

If I start it with the vnc parameter lspci shows nothing. Empty output. There is however /dev/fb0 device.


X log from normal operation will be attached shortly.

Created attachment 423364 [details]
Xorg.0.log from already running system

lspci on th erunning system also produced empty output.

What exactly does "when [you] start the Xen guest so that it shows black screen" mean?  Does that mean "when I start with xdriver=vesa" ?  Because that's not expected to work for Xen guests.

I should have been more verbose. 

When I start the PV guest without any additional parameters I hit the black screen. When that happens I can't switch to tty2 or any other tty and I cat get you any log files.

When I start it with the xdriver=vesa X fails and I'm offered to start vnc ot text mode. X.log says:
(EE) No devices detected.

Fatal server error:
no screens found


As you say above this is not expected to work. I can attach the X.log from this install if needed.

Are you still trying with the 0527 snapshot?  I can't reproduce this with the 0616 workstation iso.

Nope, comment #15 was with 0622.1/Server/x86_64. Dom0 is RHEL5.5-Server GA (without updates)-x86_64

Server, eh.  I've been trying with Workstation.  If that's the difference, I'm going to be quite upset.

That _is_ the difference.  I am quite upset.

Actually, I can repro it on Workstation too, which is good.  The problem is it's a cascade of two bugs.

Aside: to debug problems like this, do a network install of the Xen guest with 'sshd' on kcmdline.  Inspect the arp cache on the host with 'arp -n' to find the IP address of the guest, and then ssh in once stage2 starts.

One of the bugs is a bug in the fbdev driver where it segfaults on server regeneration:

Backtrace:
0: Xorg (xorg_backtrace+0x28) [0x4adf38]
1: Xorg (0x400000+0x629e9) [0x4629e9]
2: /lib64/libpthread.so.0 (0x7f2b38f19000+0xf440) [0x7f2b38f28440]
3: Xorg (DamageUnregister+0x53) [0x4de543]
4: /usr/lib64/xorg/modules/libshadow.so (shadowRemove+0x33) [0x7f2b352e02c3]
5: /usr/lib64/xorg/modules/libshadow.so (0x7f2b352df000+0x1784) [0x7f2b352e0784]
6: Xorg (0x400000+0xafc29) [0x4afc29]
7: Xorg (0x400000+0x152f0c) [0x552f0c]
8: Xorg (0x400000+0x2209c) [0x42209c]
9: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7f2b37b6ac5d]
10: Xorg (0x400000+0x21bb9) [0x421bb9]
Segmentation fault at address (nil)

This is pretty straightforward to fix, we had a similar bug in the vesa code.

But the second bug is that we're getting to this at all; the X server should not be regenerating while anaconda is running.  I suspect this is a race condition introduced by the change to metacity from mini-wm; we used to wait for mini-wm to connect before running xrandr(1), but now since we don't, if xrandr beats metacity to the display (and it will, since metacity requires a lot of libraries to load), then when it disconnects the server will regenerate.  The server shouldn't fault when regenerating; but anaconda should also be careful to wait for metacity to initialize before proceeding.

Probably the reason I couldn't reproduce it with Workstation before is that I was initially creating the guest with 1 VCPU, which would mitigate some races.  Live, learn.

2560662 build (RHEL-6-candidate, /cvs/dist:rpms/xorg-x11-drv-fbdev/RHEL-6:xorg-x11-drv-fbdev-0_4_2-1_el6) completed successfully

MODIFIED

This now works for me with snapshot #7 which has xorg-x11-drv-fbdev-0.4.2-1.el6.

(In reply to comment #20)

> But the second bug is that we're getting to this at all; the X server should
> not be regenerating while anaconda is running.  I suspect this is a race
> condition introduced by the change to metacity from mini-wm; we used to wait
> for mini-wm to connect before running xrandr(1), but now since we don't, if
> xrandr beats metacity to the display (and it will, since metacity requires a
> lot of libraries to load), then when it disconnects the server will regenerate.
>  The server shouldn't fault when regenerating; but anaconda should also be
> careful to wait for metacity to initialize before proceeding.    


Hi Adam,
how can I reproduce this in anaconda now that X doesn't crash? I want to file a bug against anaconda for this behavior.

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.