2

I tried installing Ubuntu in UEFI mode to VirtualBox. The installation was fine, but after rebooting, OS started correctly while the graphic environment didn't start. This problem itself was reported many times in forums, and my question is NOT to solve this. I started to be instersted in what causes this phenomenon.

I thought, once OS starts out of UEFI, the OS system configurations and drivers are exactly same as the BIOS mode. If so, Ubuntu graphical environment should start normally, but it seems wrong. My question is, what's different between BIOS and UEFI after OS boot finishes? Drivers and configurations used by OS are the same? Does UEFI offer graphics drivers to OS? if so Ubuntu was using different graphics drivers?

1 Answer 1

4

Hardware (even virtual hardware) is often initialized by firmware (the BIOS, pre-EFI hardware-initialization code in the firmware, or the firmware built into a device itself). This is especially true of video hardware and some other devices that are built into motherboards. Furthermore, the EFI provides a framebuffer driver for accessing video devices, which BIOS doesn't provide. This can influence how Linux accesses the video hardware.

In the case of VirtualBox, the entire firmware stack is different for BIOS vs. EFI modes. This influences how the Linux drivers interact with the (virtual) video hardware, because it will be initialized in different ways. FWIW, I run Xorg -configure to create a new /root/xorg.conf-sample file (or whatever it's called), copy that to /etc/X11/xorg.conf, and adjust it to use the fbdev driver. The VirtualBox guest drivers also sometimes now work under VirtualBox, but that's relatively recent and doesn't work for all guest OSes.

Something similar can happen on real hardware, too, although on real hardware, BIOS/CSM/legacy mode boots are usually done atop the EFI, so there could be more similarity between boot modes than under VirtualBox. Nonetheless, there can be differences between BIOS/CSM/legacy-mode boots and EFI/UEFI-mode boots. Because the former have historically been more common, the latter produce more problems, on average. This is especially true when using proprietary video drivers; for whatever reason, ATI and Nvidia have been slow to provide EFI support for their proprietary Linux drivers. IMHO, this is just another reason to avoid those drivers. (I've never been big fans of them, since they've always created more problems than they've solved for my uses.)

There are some other post-boot BIOS-vs.-EFI differences, too. In particular, EFI remains more accessible than BIOS, with something called "runtime services." The OS can communicate with the EFI to set NVRAM variables, use the EFI's framebuffer driver, and so on. At the moment, you're unlikely to use most of these features (except maybe the EFI framebuffer driver), but they may become more important in the future. One EFI feature that is important is the ability to set boot options via the Linux efibootmgr utility. Most Linux distributions use this tool transparently as part of GRUB installation, but you can use it manually to change boot loaders, to reboot directly into another OS on a one-time basis, or whatnot.

2
  • Thank you for reply and useful information. And now I have an additional question. If OSs use EFI drivers, confliction may happen between EFI drivers and OS drivers, which made me think that OSs discard all configurations after booting at first (and configurations are exactly same as BIOS). For example, supposing EFI offers drivers for drawing the frame buffer and OSs don't discard it, windows nVidia drivers can't handle the frame buffer. Do you know the mechanism about this cofliction problem? Mar 17, 2014 at 5:45
  • Few EFI drivers are used by OSes. The framebuffer video device is one of the few that can be. I don't know the details of how OS drivers manage to coexist with the EFI's framebuffer driver.
    – Rod Smith
    Mar 18, 2014 at 0:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .