So the last screen of tty 4 gives me:
*******************
<6>Floppy drive(s): fd0 is unknown type 15 (usb?) ....
<3>IRQ handler type mismatch for IRQ 6
<3> current handler: vkbd
<4>Pid: 468, comm: modprobe Not tainted 2.5.25-0.2.rc4.fc9xen #1
... a stack trace - I can reproduce for you if you want ...
<4>floppy: Unable to grab IRQ6 for the floppy driver
<6>BIOS EDD facility ....
<6>EDD information ont available.
<6>input: PC Speaker ....
<6>squashfs: version ....
<5>iscsi: registered transport (tcp)
<6>NET: Registered protocol family 10
<6>lo: Disabled Privacy Extensions
<6>Initialising Xen virtual etherenet driver.
<6> xvda: xvda1 xvda2
<4>modprobe used greatest stack depth: 2312 bytes left
********************

And tty3 gives me:
********************
[time omitted] INFO   : kernel command line:
method=http://mirrors/kernel.org/fedora/

[time omitted] INFO   : anaconda version 11.4.0.52 on i386 starting
[time omitted] INFO   : text mode forced due to serial/virtpconsole
[time omitted] INFO   : 508004 kB are available
FATAL: Error inserting floppy
(/lib/modules/2.6.25-0.2.rc4.fc9xen/kernel/drivers/block/floppy.ko): Device or
resource busy
**********************

Shame of shames, it is going to text mode then failing - but I don't want text
mode.  Hopefully this is a good bit more helpful than "black screen" :-).

The fb driver should probably continue to be built-in rather than built as a module

The fb driver is built in currently

Markus: could you take a look?

i'm seeing the same problem running RHEL5.2 beta (w/ latest packages) trying to
install rawhide

As far as I can see, both vfb and vkbd initialize just fine, and displays a
blank screen (as the reporter wrote).  Looks like pvfb works, but guest user
space doesn't use it.

If I complete the text install and reboot into the newly installed system, pvfb
works.  Same kernel, isn't it?

Also note this line from comment#1:
[time omitted] INFO   : text mode forced due to serial/virtpconsole

This seems to suggest that anaconda forces a text install.  Why does it do that?

Aha, that line is the key.  This is just the second part of bug 434763 (but
going to leave it separate for now)

It looks like what's going on is that the kernel is setting up hvc0 as the
console rather than the framebuffer.  And so when we do auto-console detection
in anaconda, we find that there's hvc0 and that the kernel has set it up as the
console.  If you have the framebuffer set up, then it needs to be the console as
far as the kernel is concerned.  This is what some of the original pain involved
in the xenfb code was all about.

Back to kernel-xen for now

*** This bug has been marked as a duplicate of 434763 ***

Whoops, did not mean to close

So, the logic we're talking about here is:

 --
    static struct termios orig_cmode;
    struct termios cmode, mode;
    int cfd;
    
    cfd =  open("/dev/console", O_RDONLY);
    tcgetattr(cfd,&orig_cmode);
    close(cfd);

    cmode = orig_cmode;
    cmode.c_lflag &= (~ECHO);

    cfd = open("/dev/console", O_WRONLY);
    tcsetattr(cfd,TCSANOW,&cmode);
    close(cfd);
    ...
    char * consoles[] = { "/dev/xvc0", "/dev/hvc0", NULL };
    ...
    for (i = 0; consoles[i] != NULL; i++) {
        if ((fd = open(consoles[i], O_RDWR)) >= 0 && !tcgetattr(fd, &mode) &&
            !termcmp(&cmode, &mode)) {
            printf("anaconda installer init version %s using %s as console\n",
                   VERSION, consoles[i]);
            isSerial = 3;
            console = strdup(consoles[i]);
            break;
        }
        close(fd);
    }

    cfd = open("/dev/console", O_WRONLY);
    tcsetattr(cfd,TCSANOW,&orig_cmode);
    close(cfd); 
    ...
        if (isSerial == 3) {
            *argvp++ = "--virtpconsole";
            *argvp++ = console;
        }
  --

i.e. we only force --virtpconsole if /dev/hvc0 is what underlies /dev/console

and pvfb is what *should* underly /dev/console

Right.  This was the root of a log of the register_console/unregister_console
stuff in the early pvfb patches.  

I believe the culprit is
linux-2.6-xen-0004-xen-Make-hvc0-the-preferred-console-in-domU.patch
We put that in to make the Xen console just work.  It sets the default
preferred console to hvc0.  But with PVFB compiled in, we want the
preferred console to be PVFB, i.e. tty0.  It is when I take out that
patch in an upstream kernel.  I haven't tried with an f9 kernel, or an
actual install.

Yes, we only want  hvc0  to be the primary console, when the guest is not
configured to use PVFB in xenstore. eg, so 'virt-install --nographics' gets
anaconda text mode sent to hvc0, while 'virt-install --vnc' gets anaconda
graphical mode to pvfb.

Consoles tty, hvc and ttyS register in this order.

The framebuffer isn't up yet then, and tty is still the dummy console.

Unless the kernel command line dictates otherwise, the first one to
register becomes *the* console (the one behind /dev/console).  This is
tty.  Except we patched things so that hvc wins over tty in dom0.

We want to use tty if we have PVFB, else hvc.

If we have PVFB, xenfb_probe() gets to run.  But by the time that
happens, the console game's over.

I'll dig some more.

Err, wins over tty in *domU*.

Right.  Some of the various ppc and ia64 platforms where this matters can check
the firmware info early in the boot sequence to see if they should change their
preferred to the serial-ish console.  The problem with having xen domU do so is
that it required xenstore which can't be accessed early. 

I've dropped "prefer hvc0" patch again in kernel-xen-2.6-2.6.25-0.12.rc7.git6.fc9

bug #437761 should track getting hvc0 to be preferred if there's no pvfb

Okay, now with kernel-xen-2.6-2.6.25-0.12.rc7.git6.fc9 I'm seeing:

  INFO: No video hardware found, assuming headless

ajax -- how did you want to handle fbdev devices in rhpxl now?

rhplx seems to be filtering on pci.device_class, which pvfb doesn't have:

class VideoCardInfo:
    def __init__ (self, forceDriver = None):
        ...
        pdevs = [x for x in pdevs if x.GetPropertyInteger('pci.device_class') == 3]

lshal shows the following for pvfb:

udi = '/org/freedesktop/Hal/devices/xen_vfb_0'
  info.linux.driver = 'vfb'  (string)
  info.parent = '/org/freedesktop/Hal/devices/computer'  (string)
  info.product = 'Xen Device (vfb)'  (string)
  info.subsystem = 'xen'  (string)
  info.udi = '/org/freedesktop/Hal/devices/xen_vfb_0'  (string)
  linux.hotplug_type = 2  (0x2)  (int)
  linux.subsystem = 'xen'  (string)
  linux.sysfs_path = '/sys/devices/vfb-0'  (string)
  xen.bus_id = 'vfb-0'  (string)
  xen.path = 'device/vfb/0'  (string)
  xen.type = 'vfb'  (string)

Just seems like the xen support got lost when moving from probing with kudzu,
which used to do:

    snprintf(path,64,"/sys/class/graphics/fb%d/name",i);
    name = __readString(path);
    if (!name)
        break;
    if (!strcmp(name, "xen")) {
        xendev = xenNewDevice(NULL);
        xendev->desc = strdup("Xen Virtual Framebuffer");
        xendev->type = CLASS_VIDEO;
        xendev->driver = strdup("xenfb");
        xendev->classprivate = (void *)strdup("fbdev");
        if (devlist)
            xendev->next = devlist;
        devlist = (struct device *) xendev;
    }

Moving to rhpxl

Fix for this (I hope) built as rhpxl 1.4.  Please test, and reopen if this isn't
resolved.

Thanks, seems to be working fine now with the 2008-04-10 install tree

(i.e. rhpxl-1.7-1.fc9)