Linux and Windows UEFI boot using Tianocore DUET firmware

[heliox]

I can't understand these measures.either. I don't see any unfair competition between these 2 sites. Complete different fields here.

[Alessandro17]

OK guys, post reinstated to its original form.

[heliox]

Thanks mate! No hurt feelings . I like Keshav's findings but I can't find time to experiment those. And this forum is a nice place for sharing knowledge.

[Alessandro17]

Thanks mate! No hurt feelings . I like Keshav's findings but I can't find time to experiment those. And this forum is a nice place for sharing knowledge.

 

Thanks. Only idiots do not admit when they are wrong

[Aaron44126]

Hi, wanted to throw out some feedback. I referred to these directions to migrate a Windows system from BIOS to UEFI (including converting the disk from MBR to GPT using gdisk): https://gitorious.or...64_BIOS_to_UEFI

 

The system I was messing with is a Windows 8 Developer Preview install. The process went fine, pretty much like this:

• Switch system from BIOS to UEFI.
  
• Boot an Ubuntu LiveCD, install gdisk, and run the MBR->GPT conversion.
  
• Use GParted to shrink the system partition and add the EFI system partition.
  
• Boot the Windows DVD and use the recovery options to get to a command prompt and run bcdboot.
  
• Use the recovery options to tell it to "check for startup problems".
  
• After this it rebooted automatically and Windows started up fine.
  

One more note... this was all done in VMware Workstation 8. VMware won't boot Windows 7 via UEFI but it seems to work fine with the Windows 8 dev preview.

 

Just wanted to add this post because I'm not sure if anyone has tried it with Windows 8 yet, and that it works in VMware is interesting as well.

[nms]

Recent version from 10 March on motherboard Asrock M3A790GMH/128M with Athlon II X3 425 boot goes up to black screen with big red WELCOME TO EFI WORLD and then hangs.

[rancur]

So I'm trying to set up a duet install on a USB drive and I noticed

 

@copy %SHELL_DIR%\LoadFv.efi %EFI_BOOT_DISK%\LoadFv.efi

@copy %SHELL_DIR%\DumpBs.efi %EFI_BOOT_DISK%\DumpBs.efi

and

@copy %EFILDR_DIR%\*.fv %EFI_BOOT_DISK%\

fail under UDK_64 because those files don't exist in the latest master tar from the http://gitorious.org..._duet_installer

 

on the Parted Magic install method, I've gotten to "Welcome to EFI World", (stuck there) though I'm on an AMD system so, MMMV...

 

Can I get an updated master tar that has those files? Or perhaps a previous release that isn't missing them?

[cheshirekow]

Hey Guys,

 

So this DUET thing looks pretty cool, but I've spent the past couple of days reading about it and I'm a bit confused. I think the problem is that I'm reading things from multiple stages of it's development and I might be confused about what is "current". I'm a bit stumped and would greatly appreciate it if someone can help me out. I'm trying to triple-boot the big three... I'll describe what I've done so far:

 

First, my drive is partitioned as follows

 

partition   /dev/sda[x]  label        file system     size 
----------  -----------  -----------  --------------  -----------
0           1            BOOT         fat32           500 MiB
1           2            windows      ntfs            100 GiB
2           3            win_home     ntfs            100 GiB
3           4            linux_a      ext4            50  GiB
4           5            linux_b      ext4            50  GiB
5           6            nix_home     ext4            450 GiB
6           7            osx          hfs+            50  GiB
7           8            osx_home     hfs+            100 GiB
                        [empty]                      128 MiB
8           9            swap         swap            ~50  GiB

 

I did the partitioning (and all the following) from ubuntu 12.04 installed on /dev/sda, so this work is all being done on a separate physical disk (1TB). I later read that gparted incorrectly sets a flag for fat32 partitions, [q1] Do I need to fix this?

 

I wanted to be able to boot Ubuntu normally (i.e. without DUET) so I first installed ubuntu to sdb4, and installed GRUB to the MBR (/dev/sdb). [q2]newb question: it is still called the MBR? Even if the drive has a GPT? Or is it called something else?

 

Anyway, following "rodsbooks" (http://www.rodsbooks.com/bios2uefi/) I then downloaded the tianocore_uefi_duet_installer master .tar.gz and ran

 

$ sudo ./duet_install /dev/sdb1

 

It is my (potentially mis-) understanding that this installs "DuetBoot" to the boot record for that partition, and that "DuetBoot" will attempt to load EFILDR20 from the root of it's partion. [q3] is that right?

 

I then mounted the partition

 

$ sudo -i
# mkdir /tmp/boot
# mount /dev/sdb1 /tmp/boot

 

and copied Efildr/UDK_x64/Efildr20 to the drive and created an empty EFI/ directory.

 

# cp Efildr/UDK_x64/Efildr20 /tmp/boot/EFILDR20
# mkdir /tmp/boot/EFI

 

Then I created a new entry for grub to chainload it

 

# nano /etc/grub.d/40_custom

 

menuentry "DUET" {
   insmod part_gpt
   set root=(hd0,gpt1)
   chainloader +1
}

 

# update-grub

 

(note: I also tried "root=(hd0,1)" if that makes a difference).

 

After reboot I choose the "DUET" grub entry and I get the "Welcome to EFI World" Message with "ABCD" written at the top, but the system hangs here. In this case there were a bunch of dollar sign ("$") symbols on the left.

 

I then booted back to ubuntu and tried copying Efildr/EDK_UEFI64/Efildr20 to the root instead of the boot partition. This time the "Welcome to EFI World" message doesn't have all the dollar signs, but the system still hangs here.

 

So this is where I'm stuck. I'm expecting that after the welcome message, I should get some kind of boot menu as described on the rodsbooks page... but it just hangs. Here are some additional questions which may help me discover whats wrong (or if my system just can't handle DUET):

 

[q4] My disk is connected via a SATA cable so I should be using the UDK_x64 EFILDR20 right? Since the EDK one only supports ide?

 

[q5] The rodsbooks page makes it sound as if there should be more files on the boot partition, but he doesn't say which files to copy over. Should I copy more files over?

 

[q6] The system board is a SuperMicro x8dtg-qf with two intel xeon processors. Is that perhaps known to be incompatable?

 

[q7] I read something somewhere but lost the link about installing BootDUET using low level tools and there were instructions about copying binary data using "dd" and copying it to specific sectors and other things I didn't understand at all. I'm under the impression this is all done by "install_duet". Is that correct?

 

Ok, well, I think that's all the information that I have. I would greatly appreciate any help on the matter. Thanks in advance.

 

 

 

Edit:

 

Ok, some more information:

 

1) I bit the bullet and ran duet-install with a syslinux image. It overwrote grub (for some reason I thought it wouldn't do that) and when I rebooted I had the same thing. The system hung at the welcome message.

 

2) I re-read Totony's post and followed his path (since he is also trying to chainload) and using this method I still have the system hanging at the Welcome message.

 

I created the partion in gparted, it's 490 MiB (I had to drop off 10 MiB for a bios_grub boot partition, not sure how grub managed to boot with the initial installation without that... but it seems to be necessary for reinstalling it). Then I used

 

mkfs.vfat -F32 -h <LBA> /dev/sdb10

 

where I got <LBA> from running gfdisk /dev/sdb and then using the "p" option to

print the partition table, and taking the "start" entry for the last partition (the number is small though, like 22000 or something because it's the second partition on the disk).

 

Then I ran

dd if=bd32.bin of=/dev/sdb10 bs=1 skip=90 seek=90 count=420

Then I mounted it and ran the copy script

 

mount /dev/sdb10 /mnt
./copy_duet_files.sh /mnt UDK_X64

 

When I rebooted I changed my grub menu entry to the new partition "(hd0,gpt10)" and I get hanging at the welcome message.

[cheshirekow]

As a side note, I tried to recompile following the instructions in Usage_Linux.txt.

 

cd ${UEFI_DUET_DIR}/Linux_Source/C
ls -l
make clean
make
cd ${UEFI_DUET_DIR}
sudo ${UEFI_DUET_DIR}/Linux_Source/C/bin/GnuGenBootSector --mbr -o ${DEVICE} -i ${UEFI_DUET_DIR}/BootSector/Mbr.com 

 

At this point I get the error:

 

ERROR: It's not a floppy disk!
GnuGenBootSector: ERROR 1003: Invalid option value
 Output file can't be found.

 

Starting at line 144 of GnuGenBootSector.c

if (PathInfo->Path[5] == 'f' && PathInfo->Path[6] == 'd' && PathInfo->Path[8] == '\0') {
     PathInfo->Type = PathFloppy;
     strcpy (PathInfo->PhysicalPath, PathInfo->Path);

     return ErrorSuccess;
   } else {
   // Other disk types is not supported yet.
   fprintf (stderr, "ERROR: It's not a floppy disk!\n");
   return ErrorPath;
   }  

 

It looks like it requires the device path to be "/dev/fd"... This seems to contradict the example in usage_Linux.txt which gives "/dev/sdc" as an example device.

 

...more of an FYI than anything I guess.

[migle]

Hi,

 

You must be almost there.

 

I did the partitioning (and all the following) from ubuntu 12.04 installed on /dev/sda, so this work is all being done on a separate physical disk (1TB). I later read that gparted incorrectly sets a flag for fat32 partitions, [q1] Do I need to fix this?

 

There is something you need to fix that (see below, I saw it last).

 

I wanted to be able to boot Ubuntu normally (i.e. without DUET) so I first installed ubuntu to sdb4, and installed GRUB to the MBR (/dev/sdb). [q2]newb question: it is still called the MBR? Even if the drive has a GPT? Or is it called something else?

 

Hmmm. if you read rodsbooks, you should know that there still exists an MBR on GPT-partitioned disks, called the protective MBR.

However, GRUB should not be installed to the MBR.

As is said on section 3.4 of GRUB's manual, you should create a partition for GRUB, a small one (say, 64KiB) is enough.

That partition should have type EF02.

 

When you install grub, it will find this partition and install itself partly on the MBR and what doesn't fit in the MBR will go to that partition.

On MBR-only disks, grub used to use the sectors just after the MBR assuming they were free, this was less safe.

 

But this is not the reason why you can't boot DUET.

Read on...

 

It is my (potentially mis-) understanding that this installs "DuetBoot" to the boot record for that partition, and that "DuetBoot" will attempt to load EFILDR20 from the root of it's partion. [q3] is that right?

 

Yes, it is right.

Moreover, you already know for sure that BootDuet was loaded and executed properly and that it did its job right, which is loading and executing EFILDR20.

Because you saw "ABCD" and all those funky welcome messages, it must have loaded properly (there is no being half-correct here).

 

So, why does DUET hang?

There is not much else to check, but I have a couple of suggestions.

 

[q4] My disk is connected via a SATA cable so I should be using the UDK_x64 EFILDR20 right? Since the EDK one only supports ide?

 

I think Keshav says that's the one you use in any case.

However, there is a misconception there: your disk is connected via a SATA cable but BIOS may be faking it as an IDE disk.

In the BIOS setup, you have that "IDE compatible" or "AHCI" setting. AHCI is better and faster, however, if you installed Windows in "IDE compatible" then you have to stick to it.

But that is the setting that determines that from a software point of view (in early OS loading stages) your disk looks like IDE or SATA.

 

This could be one reason for you hanging, yes. You could try each of the settings in turn with each of the versions of EFILDR20.

That's four possibilities to try out.

 

However, you should only bother to do so, after: (read on)

 

[q5] The rodsbooks page makes it sound as if there should be more files on the boot partition, but he doesn't say which files to copy over. Should I copy more files over?

 

No, it's fine. You can copy EFI tools that you may like, such as the EFI shell, but that's for latter. Focus on booting Windows through DUET first.

 

[q6] The system board is a SuperMicro x8dtg-qf with two intel xeon processors. Is that perhaps known to be incompatable?

 

I'd have to check that on our 3-million entry Hardware Compatibility List, but that means I'd have to go across the campus to our Q-A department.

This was a joke.

 

[q7] I read something somewhere but lost the link about installing BootDUET using low level tools and there were instructions about copying binary data using "dd" and copying it to specific sectors and other things I didn't understand at all. I'm under the impression this is all done by "install_duet". Is that correct?

 

It must have been done, yes, otherwise you'd never have seen "ABCD".

That was all fine. Go back to BootDuet and forget syslinux, syslinux is more trouble than BootDuet.

 

Now, the first thing to try:

 

Even though you read rodsbooks, you still used gnu parted, and not Rod's gdisk. His' is much better.

So, first, stop using gnu parted.

 

What you call your BOOT partition, that 500 MiB FAT32, is what is called your EFI System Partition (ESP).

Your ESP should be marked with a special code in the GPT, which is EF00.

 

Gnu parted might have used another code. If it did, I don't remember, but maybe DUET does not find your ESP and maybe that's why it hangs.

 

Here is the partition table on my laptop (output of gdisk):

  1            2048       134219775   64.0 GiB    0700  vista
  2       134219776       136316927   1024.0 MiB  8301  gentoo-root
  3       136316928       153094143   8.0 GiB     8301  gentoo-usr
  4       153094144       157288447   2.0 GiB     8301  gentoo-var
  5       157288448       159385599   1024.0 MiB  8301  gentoo-portage
  6       159385600       167774207   4.0 GiB     8301  gentoo-distfiles
  7       167774208       192940031   12.0 GiB    8301  linux-opt
  8       192940032       201328639   4.0 GiB     8200  linux-swap
  9       201328640       218105855   8.0 GiB     8301  linux-tmp
 10       218105856       268437503   24.0 GiB    8301  linux-home
 11       335546368       343934975   4.0 GiB     A502  freebsd-swap
 12       343934976       352323583   4.0 GiB     A503  ufs-tmp
 13       352323584       360712191   4.0 GiB     A503  ufs-home
 14       360712192       364906495   2.0 GiB     A503  freebsd-distfiles
 15       364906496       369100799   2.0 GiB     A503  freebsd-ports
 16       369100800       377489407   4.0 GiB     A503  freebsd-local
 17       377489408       385878015   4.0 GiB     A503  freebsd-usr
 18       385878016       387975167   1024.0 MiB  A503  freebsd-root
 19       387975168       390072319   1024.0 MiB  A503  freebsd-var
 20       390072320       390334463   128.0 MiB   EF00  duet
 21       390334464       390596607   128.0 MiB   0C01  msr
 22       390721536       390721663   64.0 KiB    EF02  grub
 23       390721664       390721791   64.0 KiB    A501  freebsd-boot

 

The following are relevante:

- My "duet" partition is my ESP and has type EF00 (there should only be one on the disk). The files for booting Windows go in there. (the SOMETHNG.EFI stuff)

- GRUB is partly on the protective MBR and partly on my "grub" partition with type EF02.

- "msr" was created by Windows (he likes it there, even though its useless, I left 128MiB prepared for Windows to be able to create it)

- BTW, freebsd's gptboot code goes on the "freebsd-boot" partition with type A501 and "freebsd-root" has the "bootable" flag set (set by FreeBSD's own tool gpart)

 

If its not the EF00 type for your "BOOT" that it's missing, then it must be a matter of "IDE compatible" vs. "AHCI" or try different versions of EFILDR20.

[dmazar]

Since you guys have Duet working, you can probably boot OSX with Clover from it. Clover is two parts: "boot" file (and it's boot0, boot1 variants for BIOS boot) which is actually modified Duet and CloverX64.efi (UEFI application) which is a boot manager. You do not need "boot" part since you have Duet already, but can probably load CloverX64.efi and use it to start OSX. If I can use it on my Asus board (AMI Aptio UEFI) for UEFI boot, then it should probably work on your Duet implementation.

[migle]

Thanks, it's nice to know about that cloverefiboot project. They're using the BootDuet.S program I wrote and probably also read a lot from this topic here. I thought I had only 5 or 6 users, it would have been a day of work per user, or maybe more.

 

As to booting OSX, I have no space left for that on the disk (as you can see above).

[cheshirekow]

As is said on section 3.4 of GRUB's manual, you should create a partition for GRUB, a small one (say, 64KiB) is enough.

That partition should have type EF02.

 

Yeah, that is something that confused me. There was no such partition created and yet the ubuntu installer managed to get grub running just fine. When I tried the syslinux approach it overwrote grub so I had to reinstall grub. When I did that, I created a new partition for grub boot. Here is the output of gdisk for me now:

 

  1            2048           22527   10.0 MiB    EF02  (grub boot)
  2         1026048       210741247   100.0 GiB   0700  windows
  3       210741248       420456447   100.0 GiB   0700  win_home
  4       420456448       525314047   50.0 GiB    0700  linux_a
  5       525314048       630171647   50.0 GiB    0700  linux_b
  6       630171648      1636804607   480.0 GiB   0700  nix_home
  7      1636804608      1741662207   50.0 GiB    0700  (osx)
                                                        (note, 128MiB unallocated)
  8      1741924352      1846781951   50.0 GiB    0700  (osx_home)
  9      1846781952      1953523711   50.9 GiB    8200  (swap)
 10           22528         1026047   490.0 MiB   EF00  BOOT

 

 

Moreover, you already know for sure that BootDuet was loaded and executed properly and that it did its job right, which is loading and executing EFILDR20.

Because you saw "ABCD" and all those funky welcome messages, it must have loaded properly (there is no being half-correct here).

 

Ok great. I think I suspected that but I'm glad to know for sure.

 

I think Keshav says that's the one you use in any case.

However, there is a misconception there: your disk is connected via a SATA cable but BIOS may be faking it as an IDE disk.

 

Ok, thank you for clarifying that.

 

I'd have to check that on our 3-million entry Hardware Compatibility List, but that means I'd have to go across the campus to our Q-A department.

This was a joke.

 

Haha, I got it . It was a long shot to ask, but figured I'd put it out there.

 

 

That was all fine. Go back to BootDuet and forget syslinux, syslinux is more trouble than BootDuet.

 

Yup, already done.

 

 

What you call your BOOT partition, that 500 MiB FAT32, is what is called your EFI System Partition (ESP).

Your ESP should be marked with a special code in the GPT, which is EF00.

 

Ok, I understand much better now. Thank you for that. The list printed above is from gdisk, and it does appear that the ESP has the correct code (EF00).

 

If its not the EF00 type for your "BOOT" that it's missing, then it must be a matter of "IDE compatible" vs. "AHCI" or try different versions of EFILDR20.

 

Got it. Since "BOOT' has type EF00 I will assume this is the problem. Going to go fiddle with the BIOS now. I will report back any new information. Thanks so much for taking the time to read my post.

 

 

Edit:

--------

Ok, so my BIOS actually has an extra setting. Theres the IDE compatability mode, then under ACHI there's an option for "ACHI Codebase": ["BIOS Native AHCI", "Intel AHCI ROM"]. It was set to "Intel AHCI ROM". I tried both the EDK and the UDK against IDE, and both of the AHCI options (so 6 tests) and they all hang at the welcome screen... no success yet.

 

Just a dumb question, but I wait 60 seconds before giving up. I suspect that's more than enough time, could it perhaps take much longer to go from the welcome screen to the DUET menu?

 

 

[StoneTemplePilots]

So I'm trying to set up a duet install on a USB drive and I noticed

 

@copy %SHELL_DIR%\LoadFv.efi %EFI_BOOT_DISK%\LoadFv.efi

@copy %SHELL_DIR%\DumpBs.efi %EFI_BOOT_DISK%\DumpBs.efi

and

@copy %EFILDR_DIR%\*.fv %EFI_BOOT_DISK%\

fail under UDK_64 because those files don't exist in the latest master tar from the http://gitorious.org..._duet_installer

 

on the Parted Magic install method, I've gotten to "Welcome to EFI World", (stuck there) though I'm on an AMD system so, MMMV...

 

Can I get an updated master tar that has those files? Or perhaps a previous release that isn't missing them?

 

I agree, same issue for me, file not found ; )

[dmazar]

migle, just wanted to let you know that I have reused your BootDuet code in a solution for booting XPC bootloader from a USB stick that contains other hackintosh bootloaders (Chameleon, Clover, XPC). Here.

[migle]

migle, just wanted to let you know that I have reused your BootDuet code in a solution for booting XPC bootloader from a USB stick that contains other hackintosh bootloaders (Chameleon, Clover, XPC). Here.

 

Well you give such visible credit and everything, thanks...

Just tell me if someone changes it (maybe corrects a bug, supports a different case).

 

I agree, same issue for me, file not found ; )

 

About that "file not found", if the problem persists, maybe seek help for that on gitorious.

[nicholasdille]

Hi everyone,

 

I am also seeing a hang after "Welcome to EFI World" but in a slightly different situation.

 

I have built a USB stick from tianocore_uefi_duet_installer (http://www.gitorious.org/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer) as well as from the EDK2 sources according to http://pete.akeo.ie/2011/07/creating-bootable-uefi-duet-usb-stick.html.

 

This stick works as expected on my hardware but it fails after the welcome message in a virtual machine on VMware Workstation 9 as well as Hyper-V 3 (on Windows Server 2012).

 

Is this an expected behaviour? Is there anything I can do about this?

 

BTW, I am aware that VMware Workstation can be configured to use UEFI instead of BIOS.

 

Thanks in advance!

Nicholas

[m.savazzi]

Hi Everyone,

Sorry to bother but I have a problem with DUET.

Let me give you the background: I want to install and boot windows from a GPT disk on a raid controller on my PC.

Now using the info from A BIOS to UEFI Transformation http://www.rodsbooks...uefi/index.html I was able to create the partition, install SYSLINUX and DUET and boot from the USB dongle to begin installation.

The issue is that at the first reboot (when I remove the USB Stick) DUET does not boot and does not recognize the RAID card and partitions.

I’ve checked with the SYSLINUX community and the fact that DUET is loaded means that SYSLINUX is able to recognize the disks and loads DUET.

How can I have DUET recognize the disks on the raid controller? Raid is a Areca-1220 (http://www.areca.com...upport/main.htm) and there is an EFI bios for Mac Books here ftp://ftp.areca.com.tw/RaidCards/BIOS_Firmware/ARC1220/MacPro_EFI_BIOS/80429/

But I do not know how to try to load it or what to do.

 

Can anyone help me?

[migle]

Can anyone help me?

 

I can't. Anyway, I think your diagnostic is correct, that duet does not know your raid controller. Is there no chance of having it behave like an AHCI controller?

 

The EFILDR20 file is a bundle. It has the basic UEFI functionality and then it has many packages. There is nothing in DUET to support areca controllers. You see, DUET would be the toolkit to help areca developers run and debug their firmware.

I think understand that some packages that skodabenz has assembled come from VirtualBox, but I don't think there is anything in VirtualBox about areca controllers.

You would have to find such code and then compile it and assemble it into the EFILDR image.

 

I don't think you would be lucky enough to find such code. Anyway, the subversion repository for the EFI Developer's Toolkit is http://edk2.svn.sourceforge.net/svnroot/edk2/branches/UDK2010, otherwise search for tianocore.

 

The only viable option I see is try flashing that BIOS onto your areca card (provided you can go back to the BIOS you currently have) and hope that it magically works (maybe it emulates an AHCI controller).

 

If it doesn't work, I think your chances are not very good.

 

If you could find EFI code to support areca, you would then find help for compiling it at http://gitorious.org/tianocore_uefi_duet_builds.

 

That's all I can say.

[Antonio19]

Well, I managed to install succesfuly the latest version of tianocore_uefi_duet_installer on a brand new SATA drive GPT formatted.

I followed the instructions from http://www.rodsbooks.com/bios2uefi/index.html (from user srs5694).

 

I first installed Windows 7 then Ubuntu 12.04 both in UEFI.

 

However within DUET Boot Manager "Managing the Boot Process" it looks like there is no way to add permanently a new Boot Option. The same is true for modifying the Boot Order.

 

My EFI System Partition is mounted as /boot/efi then I have EFI folder which contains Boot, extras, Microsoft, Shell, ubuntu.

 

To be able to see the GRUB EFI menu at startup, I have to manually add, each time I boot my PC, a Boot Option that use the file /boot/efi/EFI/ubuntu/grubx64.efi, then to modify the Boot Order.

 

It looks like the default option is broadly set as the SATA GTP Disk [no specific file is given], which for me ends up to always booting Windows 7, the first OS I installed.

 

Is there anyway to make any of these manually added Boot Options stick for good ?

 

Or another way to set the default boot to GRUB EFI ?

 

Thanks for your feedback.

[migle]

Is there anyway to make any of these manually added Boot Options stick for good ?

 

Well, there should be, but there isn't right now.

Those boot options and your default choice, in a real UEFI, would be recorded in NVRAM.

In Duet, there is a module to emulate an NVRAM, which is EfiVar.

 

Your boot options would be recorded by this EfiVar module in a file called EFIVAR.BIN in the root directory of your ESP.

 

It happens that people (Keshav) have verified that when they compile this module in Duet, Windows does not work so well (or something like that, don't remember exactly).

So, the preliminary solution, I think still is to eliminate this module when compiling Duet.

Which means you don't get this EFIVAR.BIN file in your ESP.

 

Furthermore, I wrote the boot loader, BootDuet, which is responsible for loading EFILDR and EFIVAR.BIN into memory and jumping into EFILDR, and I never had the chance to see if EFIVAR.BIN was being loaded correctly (and its address passed correctly to EFILDR).

 

So, how have we been getting by?

 

First, you don't need to boot Linux through UEFI, it boots from a GPT disk using a regular BIOS just fine.

Actually, it's better not to use UEFI, because Duet takes a lot of time to boot.

 

You actually only need DUET for booting Windows.

And if that is your only EFI boot option, DUET will just boot it without asking.

 

So, myself, I have the regular GRUB installed, which boots from a GPT disk just fine. I have several options for booting Linux and FreeBSD, and then I have a single option to boot DUET, which boots Windows.

 

From a practical point of view, this works just fine.

 

If you are looking for the satisfaction of total UEFI emulation, then you know were to start: compile an EFILDR which has the EfiVar module in it, then check if anything gets stored in EFIVAR.BIN, and then we'll see if it gets loaded properly.

 

But really, there are more interesting things in life...

 

Greetings,

[Antonio19]

Thank you for your prompt reply. Thank you for your work as well on writing the Boot Loader BootDuet.

 

Seeping through the messages of this thread I realised after posting and as you suggest that the (latest) version from Keshav (gitorious repo) I installed is missing the EFIVAR.BIN file. Hence the trouble for not "remembering" the configuration.

 

The solution you describe using as well as the one used by Keshav, is to only boot Windows in UEFI through an option Boot DUET, the other OSes being installed outside DUET ? Do you use GRUB2 Legacy or GRUB2 EFI ? Then you add manually the option "Boot DUET" ?

 

Usually I add GRUB2 menu entries to /etc/grub.d/40_custom. Do you chainload the EFI System partition then ? to make the option of booting DUET from GRUB.

 

My current problem is that the PC boots in windows at startup and no GRUB2 booting options are first displayed.

 

May be as you suggest it is not worth to try to get through a full EFILDR compilation with the EFIVAR module.

 

However, after some testing on a pure GTP [EFI] hard drive I realized that if I only install a Linux with GRUB2 EFI, then DUET is stuck at its menu screen. I have to select the file to boot through the menu to make it launch Linux in EFI mode. But as soon as I add Windows 7 x64 entry in the boot/EFI partition (I installed Windows through DUET in EFI previouly - (on first DUET install) - then I re-installed DUET & installed Linux through it - And at last I did only add the entry for Windows 7 in the EFI partition) then DUET always launch directly Windows unless you press F12 at the tianocore welcome screen to enter its selection menu.

 

This behaviour looks "hardcoded" somewhere. What I would like is a similar "hardcode" to boot GRUB2 EFI. This should be a lot easier than sorting the issues of EFIVAR.

 

Furthermore I've seen that Keshav posted on 29 April 2011 that "I am able to boot linux x86_64 using grub2 (1.99~rc2)in edk2_x64.". This is exactly the behaviour I would like on my system.

 

Booting time for Linux is greatly reduced in EFI mode. Usually I get less than 5 sec. in EFI vs. 17 sec. in MBR. Same for Logging out.

 

I didn't had a look at the different repositories. I don't know if it is easy to get the version of that time back and running. May be only Keshav could have a quick answer on this ? ...

 

Greetings & Happy Holidays.

[migle]

I guess you edited this last post. My main motivation for replying was that you seemed to have understood that you had to have a hybrid MBR disk for Linux to boot without using EFI, and that is not the case. To be clear:

• Linux or FreeBSD boot just fine from an GPT-only disk without having EFI firmware. Actually, this is expected, GPT is a very simple partition table layout, easy to read from a boot-loader without any help from EFI firmware, or 32 or 64-bit address space. These OSes don't even have to care, because once the kernel is loaded into memory (e.g. by GRUB), everything is already solved.
  
• Only Windows requires the boot disk to be MBR when using the old BIOS, they were probably just lazy to write a couple of pages of assembly code.
  
• You can't have Linux booting faster through DUET than without it. DUET alone takes longer to boot than Linux (or almost).
  

 

Seeping through the messages of this thread I realised after posting and as you suggest that the (latest) version from Keshav (gitorious repo) I installed is missing the EFIVAR.BIN file. Hence the trouble for not "remembering" the configuration.

 

Not exactly. There shouldn't be any EFIVAR.BIN file. This file is only created by that module (which is actually called FsVariable, not EfiVar) after something is saved on "NVRAM".

 

 

Usually I add GRUB2 menu entries to /etc/grub.d/40_custom. Do you chainload the EFI System partition then ? to make the option of booting DUET from GRUB.

 

 

Yes. I use GRUB2, which is installed in a 64kB partition with code EF02. I have options for booting Linux and FreeBSD directly without going through DUET (and this is a GPT-only disk). Then, I have one option for chainloading the ESP which boots DUET.

 

...

This behaviour looks "hardcoded" somewhere. What I would like is a similar "hardcode" to boot GRUB2 EFI. This should be a lot easier than sorting the issues of EFIVAR.

 

 

I don't think there is any "hardcoded" behaviour. If it boots directly, it is because it only finds one boot option.

 

Furthermore I've seen that Keshav posted on 29 April 2011 that "I am able to boot linux x86_64 using grub2 (1.99~rc2)in edk2_x64.". This is exactly the behaviour I would like on my system.

 

Booting time for Linux is greatly reduced in EFI mode. Usually I get less than 5 sec. in EFI vs. 17 sec. in MBR. Same for Logging out.

 

I didn't had a look at the different repositories. I don't know if it is easy to get the version of that time back and running. May be only Keshav could have a quick answer on this ? ...

 

Access to older versions is easy at gitorious. You'd have to go there to contact Keshav too, I don't think he reads this any more.

However, you are a bit mistaken as to what your best option is.

 

Your quote from Keshav is old. It says he is able to boot Linux, it doesn't say it does so directly, without choosing an option...

Also, it was only latter that he realised that he had to leave the FsVariable module out, so that Windows worked properly.

 

I think you already understand that you can do everything without going through DUET and use it only for Windows.

Try it and you'll see that that's your best option.

 

Why load a several hundred kB firmware emulation, which is totally useless after Linux boots? If the only use for the firmware is to boot the OS...

 

Greetings,

[Antonio19]

Thank you for the details. I installed GRUB2 on a 1MiB partition with flag bios_grub on while installing Linux Ubuntu 12.04 by setting the boot loader on this partition.

 

Now Linux is working on GTP partitioning using bios_grub.

 

I was trying to make DUET USB like the Chinese poster at the beginning of this thread with no luck.

 

sh ./install-duet -m -s [path to]/syslinux-5.00/mbr /dev/sdg2

 

Afterwards I would copy through "dd" to a partition on my HD and chainload in GRUB2.

 

Should I use a bootable BIOS FAT32 USB ? how to install DUET to get a bootable USB DUET stick ?

 

Or using the memdisk compiled img ? [This looks very different from the poster I mentioned].

 

Regards.

 

EDIT: It looks like I found a text file Usage_Linux which details "Setting up DUET USB flash drive in Linux" within the master.tar.gz I will give it a try. However I would like to know if you did use the method of the Chinese poster.

[migle]

I was trying to make DUET USB like the Chinese poster at the beginning of this thread with no luck.

 

sh ./install-duet -m -s [path to]/syslinux-5.00/mbr /dev/sdg2

 

Afterwards I would copy through "dd" to a partition on my HD and chainload in GRUB2.

 

Should I use a bootable BIOS FAT32 USB ? how to install DUET to get a bootable USB DUET stick ?

 

Or using the memdisk compiled img ? [This looks very different from the poster I mentioned].

 

Well, you should forget those old posts and follow what's on gitorious and github.

I never used those install scripts, so I don't know what is wrong.

 

There is very little to do in preparing a bootable USB drive with DUET.

You need only:

• Partition the USB drive in GPT. Pay attention to the initial sector of your ESP partition, take note of it, let's assume it is 1234.
  
• Format that partition in FAT32, filling in the "hidden sectors" field of the BPB, with a command such as: mkfs.msdos -F 32 -h 1234 /dev/sdb1
  
• Install the boot sector program, BootDuet, with dd if=bd32.bin of=/dev/sdb1 bs=1 skip=90 seek=90 count=420 (or follow the instructions on the INSTALL file of BootDuet)
  
• Copy DUET, that is, the EFILDR20 file to the root directory of the partition you just created.
  
• Now it should work, you can additionally copy any *.EFI files you want, such as EFI Shell, etc.
  

 

If you can follow these instructions yourself, all you need is BootDuet, which is on https://github.com/migle/BootDuet.

Otherwise, you have a lot of info on gitorious and github, but I agree, there are so many options that it is confusing.

For instance, Rod Smith (the author of gdisk), wrote an install script which does what I said, which you can find here, https://github.com/the-ridikulus-rat/duet-install.

 

I no longer keep bootable USB drives with DUET... I once found it appealing, having the EFI shell and all, providing me some error recovery tools...

But it is so limited, compared to a bootable USB drive with a free OS, that I'm no longer willing to waste time setting it up.

 

 

Greetings,