Bug 742695

Did you do a text install?

yes; Anaconda text install is that is all that is offered in EFI boot here.

(there was a suggestion on IRC that this was because x did not recognize the video driver in Virtualbox 4.1.2 for OSX)

and that one could complete the install with

ifconfig eth0 up
dhclient eth0
yum groupinstall gnome

I have not tested this yet.

The conflict between grub1 and grub2 also looks like a bug.

ifconfig eth0 up
dhclient eth0
 works...

yum groupinstall gnome-desktop fails as there is not enough room on /
Note there is never an opportunity to select the formatting of the drive and it's partitions in EFI boot (text)

A text install only does a core group install and does not allow for custom partitioning, so the behavior you are describing is not a bug.  I guess the real problem here is why you did not get a graphical install.  Are you doing so from the live media?  Can you attach /tmp/X.log?

f16 RC4 Beta DVD (EFI Boot-Anaconda)
in Virtual Box 4.1.2 for OSX
Also see comment 4. the partitioning of /is too small to install gnome
The conflict between grub1 and grub2 also looks like a bug.
  https://bugzilla.redhat.com/show_bug.cgi?id=741781#c29

Please attach /tmp/X.log like I asked in comment #5 so we can see why you don't have a graphical installation.

Partitioning could be a bug or not.  You could have simply defined too small of an image for your VM to use.  Regardless, please only report one bug per bug report.

The behavior is the same in 15 Final, 16 Final, and 17 Alpha TC{1,2} in a VirtualBox 4.1.12 guest. For all later 17 TCs/RCs, it drops immediately to a grub prompt (see the first few comments in bug 816410).

Created attachment 580422 [details]
/tmp/X.log from attempted F16 EFI install in VirtualBox 4.1.12 guest

Is this related to bug 546166 (which was closed as NOTABUG)?

I filed bug 820797 for the problem of getting a grub prompt when EFI booting 17 Alpha RC1 or later in VirtualBox.

With recent F18 install images, we're back to this state - EFI boot works although X startup fails.

There is a workaround:
  add inst.usefbx and video=efifb to the linuxefi kernel line in grub2

this allows the X to see and use the framebuffer driver instead of failing with (the missing VGA/VESA) default.

X needs to detect that it is in a EFI environment and there is on BIOS VGA stuff to handle the initialization.

And, yes, the anaconda text mode sucks horribly.

(In reply to comment #13)
> There is a workaround:
>   add inst.usefbx and video=efifb to the linuxefi kernel line in grub2

Confirmed that this works. You filed bug 876787 which is similar, should one of these be marked as a dupe?

Can someone recommaned that this be added to the "Common Problems" in the Wiki?

I'm not convinced using UEFI on VBox is at all 'Common'...

Same behavior in 19 Alpha TC3 (the first one I checked).

Sorry, I meant 19 Alpha TC5.

Created attachment 761727 [details]
screenshot of where Live EFI boot stops

Although the workaround in comment 13 works for me with install images, it does not work with lives. Screenshot attached of where boot stops with Fedora-Live-Desktop-x86_64-19-TC3-1.iso, before coming up graphically.

(Note that I did see the plymouth splash screen, but then hit ESC to get rid of it.)

Fedora-Live-Desktop-x86_64-19-TC3-1.iso does not work with the kernel parameters in comment 13. There's no plymouth splash screen, and is a text only boot. tty1 doesn't end in a login prompt, but I can switch to other consoles to login.

Fedora-19-TC3-x86_64-netinst.iso works with additions in comment 13. I don't get a plymouth splash screen but I do get a graphical anaconda at the end.

Created attachment 761885 [details]
dmesg F19TC3-netinstl

Created attachment 761886 [details]
dmesg F19TC3 Live

Seems to be unrevealing what the problem is.

Created attachment 761887 [details]
journalctl F19TC3 Live Desktop

Seems more revealing. The first problem is with d-bus and gdm:


Jun 16 10:28:15 localhost dbus-daemon[482]: dbus[482]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.12" (uid=0 pid=780 comm="/usr/sbin/gdm ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination=":1.13" (uid=0 pid=808 comm="/usr/libexec/gdm-simple-slave --display-id /org/gn")

Jun 16 10:28:15 localhost dbus[482]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.12" (uid=0 pid=780 comm="/usr/sbin/gdm ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination=":1.13" (uid=0 pid=808 comm="/usr/libexec/gdm-simple-slave --display-id /org/gn")


Jun 16 10:28:16 localhost gdm[780]: GLib-GObject: g_object_ref: assertion `object->ref_count > 0' failed
Jun 16 10:28:16 localhost gdm[780]: GLib-GObject: g_object_unref: assertion `object->ref_count > 0' failed

Created attachment 761891 [details]
Xorg.0.log F19TC3 Live Desktop

Seems like X is expecting vboxvideo driver to be available even though I'm asking for it to use efifb. I'd say maybe an X bug?

[    14.121] (WW) Warning, couldn't open module vboxvideo

Obsolete

closing

Why is this obsolete? F19 is still supported. It's probably still present on F20 and I could check that if necessary. If you meant that it's intended to be fixed in F21, okay but I've heard nothing about that, plus in that case the Version should be bumped to 20.

I get GUI without special boot parameters in VirtualBox with UEFI enabled for both Fedora 20 and Fedora Rawhide. I had to use some boot parameter I can't remember right now for Fedora 19.

Yes, I confirmed that using EFI, it's possible to do a minimal GUI install of F20 x86_64 from the install DVD, then boot from the installed system. Thanks. I'll use VirtualBox to do some EFI testing for F21, commenting it as such, just to see if vbox EFI testing is worthwhile.

P.S. You were probably thinking of the boot options in comment 13.

F19 is still supported, but we can't re-roll its install media, so I don't think we could fix the problem for it...