My attempts have failed so far. I used the full Imera 64bit DVD and created a VM using the alternate Vbox EFi firmware.

Aptosid boots OK but a VBox error leaves you at a console. I added a "fbdev" xorg conf to /usr/share/X11/xorg.conf.d and was able to start X.

Following the instructions in the manual I created the GPT EFI partition etc. THe system appeared to install OK. The fstab created contained the /boot/efi mount and the /boot/efi directory seemed to have the correct files in it.

But on re-boot Vbox just goes to an EFI shell.

I then reinstalled grub-efi-amd64 via the chroot method which appeared to run OK. But on the next re-boot was again left at the EFI shell.

So to summarise, the 64bit LiveCD will boot with EFI Firmware, the system appers to install coorectly on a GPT disk, but it fails to boot when the VM is restarted.

Any ideas?

Last edited by krisbee on 09.11.2011, 17:56; edited 1 time in total

slh

Post subject: RE: EFI Install In Vbox Posted: 09.11.2011, 13:19

Joined: 2010-08-25
Posts: 919

Status: Offline

You might need to check the boot order with efibootmgr (I don't know if or how virtualbox is able to store this, as this usually goes into persistent nvram on real hardware).

My own experiments with virtualbox for EFI emulation (I don't have access to UEFI hardware and only run virtualbox on old hardware without hardware virtualization support) were not overly promising, with no EFI capable distro/ OS I could find. What does work is qemu-kvm with OVMF (tianocore), while this has its own share of problems as well (no network, many quirks, etc. pp.) it allows testing of basic EFI related features.

At the current state of the different FOSS virtualization options, I would suggest to avoid virtual UEFI for now. On real hardware, UEFI is supposed to work quite well though - at least on standard x86_64 hardware.

krisbee

Post subject: RE: EFI Install In Vbox Posted: 09.11.2011, 16:10

Joined: 2011-04-25
Posts: 49
Location: London
Status: Offline

Thanks for your comments and advice. Vbox does have its own bootmanager when used in EFI mode which is accessed by simply exiting from its EFI shell prompt. Nothing I changed here made a difference.

My whole reason for this test was to give me some confidence that I would succeed in installing aptosid Imera on real sandy brige hardware. Asus/Asrock m/boards appear to have an UEFI that allows the selection of a BIOS-MBR boot mode which sounds as if you could perform a standard BIOS install without the need for GPT. But I have no practical experience of these new UEFI firmwares and how any BIOS-MBR option might work.

After 5 years, my Athlon 64 x2 hardware seems pretty dated, and while prices are still relatively high in the UK , Sandy Bridge seems to offer the best performance per watt.

krisbee

Post subject:Posted: 09.11.2011, 17:56

Joined: 2011-04-25
Posts: 49
Location: London
Status: Offline

Success! I went through more of the options in Vbox's EFI boot screens. Using the "boot from fle" option works.

On real hardware, or in kvm+OVMF, you directly get to grub2, because UEFI remembers your boot priority (efibootmgr) in nvram; visually it's exactly the same as using BIOS based booting (including boot options for other operating systems).

All currently sold mainboards (except Apple Mac) still offer a BIOS personality and usually even default to it, but UEFI mode is supposed to work[1] - although we only have a limited testing scope in the team.

[1] Apple Macs are special, also depending on their age. Older ones only offering 32 bit UEFI are not supported (without bootcamp), newer ones with 64 bit UEFI support "should" work, but we don't have any positive feedback, nor any means to test or debug and there are known issues with compatibility.

krisbee

Post subject:Posted: 09.11.2011, 20:40

Joined: 2011-04-25
Posts: 49
Location: London
Status: Offline

If/when I take the plunge and build a sandy bridge system I'll be sure to post my feedback on UEFI etc with aptosid and hope I can get mulitbooting to work.

One concern I have, perhaps unfounded, is the effect of m/board UEFI/BIOS upgrades on any existing UEFI install as far as booting is concerned. If you do a UEFI install and then later want to upgrade the m/board's UEFI/BIOS, is this going screw up your boot files?

Hopefully, in the worst case you could use the chroot method and re-install grub-efi-amd64.

slh

Post subject:Posted: 09.11.2011, 21:01

Joined: 2010-08-25
Posts: 919

Status: Offline

Today's harddisk sizes (ignoring the recent price explosion after the floodings in Thailand) definately emphasize the need for mainboards to boot from >2 TiB block devices, which is where UEFI becomes mandatory (and is therefore a strongly recommended for new mainboards[1]).

Upgrading or even replacing an UEFI mainboard shouldn't provide any problems (you might only have to reconfigure your preferred boot order, given that the nvram pointer is lost), given that the EFI executable are just plain/ standardized files on a vfat partition with according GPT partition numbers. From a user's point of view, there is no visible difference between grub2 booting from a BIOS (grub-pc) or using UEFI (grub-efi-amd64), even switching between the two just needs minor hassle[2] (having the EFI system partition at the right place and using the correct directory structure).

Regardless if you pick AMD or Intel, I would consider UEFI support to be an important feature (certainly more important that the availability of USB 3.0 ports at this time), even if you don't intend to use it yet (all currently sold mainboards still offer a BIOS CSM, so you don't even need to enable UEFI).

[1] How likely do you consider the odds of connecting a 3 TB disk during the life time of your system - and to use it as boot drive (unless you use SSDs).

[2] It's not something I'd actually want to document or support actively (because stuff can go wrong), but it's not difficult either (if you know about a few minor quirks).

krisbee

Post subject:Posted: 10.11.2011, 09:06

Joined: 2011-04-25
Posts: 49
Location: London
Status: Offline

Slh,

Thanks for the clarification which dispels any misconceptions I had. Really, if you want to buy into this year's tech, be it Sandy Bridge, FM1 or Bulldozer, then you can't avoid having UEFI on the m/board, whether you wish to use it or not.

But I have a proplem picking my ideal m/board. For years I stuck with Abit, from the BH6, KT-133, NF7-s to the KN9s. For 5 years my hardware has not changed, and I still need to use a couple of PCI cards in any new system.

An ASUS, or possibly an ASROCK, Sandy Bridge m/board might be my choice. Of course there are no floppy or IDE ports now, but it is essential I have reliable PCI slots. Yet, PCI is not native to the H67 or Z68 chipset and ASUS boards have problems in Linux with irqs when the PCI slots are populated as shown by a quick google on "irq 16 nobody cared". Added to this, ASUS have a habit of using Linux incompatible controllers on their m/boards.

AMD might still offer decent bang per buck, but Intel seem to be well ahead on performance per watt. Bulldozer appears disappointing and I'm not sure I want to wait around for FM2 and "Trinity", should AMD even overcome their problems. Otherwise, going for Athlon II or Phenon seems like picking old tech.

bfree

Post subject:Posted: 10.11.2011, 13:35

Team Member

Joined: 2010-08-26
Posts: 267

Status: Offline

I went for an Intel motherboard (H67) mainly because I wanted a bunch of PCI slots and it was about the only suitable board I could find available at the time.

It's been a pleasantly boring experience during which I received great support for a pebkac issue related to memory timings and had a little smile when I could update to a new board firmware without using any OS just by throwing the firmware onto a suitable (i.e. I'm sure it had to be FAT) usb stick and hitting the correct Fn button at boot time.

I think MSI boards are also safe enough bets.

This Intel board was actually the board I used as the real hardware to help get the UEFI support into aptosid, though most work was done using kvm with OVMF which while buggy and missing features was sufficient for hacking away at what needed to be done.

... ASUS boards have problems in Linux with irqs when the PCI slots are populated as shown by a quick google on "irq 16 nobody cared". Added to this, ASUS have a habit of using Linux incompatible controllers on their m/boards.

Possibly I'm just lucky, but my Asus P6X58D-E board has been quite a good platform for my main aptosid system. I wanted the Marvell 9128 SATA controller for a btrfs 2-disk array, and it works very well.

I only have two PCI devices installed -- a SSD and an Nvidia GPU. But I don't have IRQ issues.

krisbee

Post subject:Posted: 10.11.2011, 15:59

Joined: 2011-04-25
Posts: 49
Location: London
Status: Offline

That should have read "Some ASUS boards have problems in Linux with irqs ..."

For example, the P8H67-V, a m/board I was interested turned out to have this problem and a VT IDE controller that was useless in Linux.

My old workstation mobo (M3N78) is from this list and 100% supported (also being a long-term support one with design intended for corporate use).
My ASUS laptop (intel-based, model UL20FT) obviously is not in the list, but is fully supported too - so choosing from this just gives some confidence on top.

krisbee

Post subject:Posted: 11.11.2011, 09:36

Joined: 2011-04-25
Posts: 49
Location: London
Status: Offline

manul,

Thanks for that reference. Actualy, I've seen the list and I have my doubts. Whilst I'm sure that many ASUS boards are 100% compatible with Linux, it's more recent boards that concern me. ASUS seem to have habit of adding various controller chips (e.g. Marvell, JMicron, VIA ..) which have been, or still are, not fully functional in Linux.

Back to that list. Take two examples: P8H67-M evo and M4A88TD-v evo.

The first is a Sandy Bridge board that appears to have that irq issue.

The second is an AMD board with a VIA VT6330 controller which provides an IDE port. Any Linux user buying this with the hope of using their non-SATA optical drives would be disappointed.

Frankly, I'm more inclined to put my trust in the hardware compatibilty reports found in various Linux Community web pages or result posted at openbenchmark.org which often have dsmeg, lspci and lsusb listings.

Perhaps I should take bfree's lead and take a closer look at Intel and MSI boards.

manul

Post subject:Posted: 18.11.2011, 19:50

Joined: 2010-09-13
Posts: 111

Status: Offline

krisbee,

Sure thing, one should always check with some personal/community compatibility report and not 100% trust the vendors.
I was merely suggesting a way to narrow the models you further check on.

With regards to Asus, another good approach to narrow the choice is to look for boards/laptops with Express Gate fast boot up - it is based on Linux so assumes most of the crucial components should be operational without glitches.
A google search like this would do: motherboard +"express gate" +"i7" site:www.asus.com

Also getting the very recent boards/hardware is a bit risky; apart of that it might have not been well tested with Linux, it could have BIOS or other hw glitches.
Usually after some time elapses, there are next BIOS/hardware revisions for same boards where many of the initial issues are fixed.
So chosing not the very-latest but somewhat older for me is usually a good bet.

Here is what I do in brief:
- Chose between models which are not the top-notch and very-latest, but say released ~1 year ago
- Check if they have support/bios updates
- Check/google the preselected models community reports for Linux compatibility. Unfortunately there is no single good Linux HW compatibilty site, so I usually google one by one the preselected models....

Will be nice if you post here what model you got, how does it go, and and how did you come to it.

krisbee

Post subject:Posted: 03.12.2011, 09:06

Joined: 2011-04-25
Posts: 49
Location: London
Status: Offline

Manul,

Your check list is great advice and is exactly what I have always done when selecting hardware.

In the end I gave up on Sandy Bridge, there just seemed to be too many doubts about 100% Linux support at the moment with m/board problems, Intel graphic driver problems and kernel problems. So for now I took the easy route and choose a cheap AM3 platform.

AM3 must be near end of life as there are m/board bargains to be had. I wanted a quad core CPU and in the last few weeks the Phenom II x4 960T BE had become available in the UK. I didn't need USB 3 or 6gb/s SATA, so my final choice was a gigabyte GA-880GM-UD2H m/board with 8GB of Corsair RAM. I picked the hyper 212+ for CPU cooling.

I don't use games so have no need of a high end gfx card. I've kept my G210 as I believe NVIDIA drivers can offer better performance than the on board HD4250 with ATI driver. But I will test this later.