152 replies to this topic

[Totony]

migle, on Oct 27 2011, 09:39 PM, said:

I think you already tried all of these:

- using the same EfiLdr that is on your syslinux image,
- setting SATA mode in BIOS to AHCI, then to "IDE Compatibility",
- then maybe use a simpler partition layout (maybe with a spare disk),
- having only one EFI System Partition (you can just change the type of the other ESP to something else temporarily),

... I can't think of anything else...

What CPU do you have?

- Yes
- When I tried that, there wasn't even a pixel mixup.
- I will probably try using a USB stick with BootDuet.
- That's what I did in my "I tried using only gdisk" post.

I have a Dell Inspiron 1545 with a Intel® Pentium® Dual CPU T3400 @ 2.16Ghz cpu.

Weirdly enough, I just re-tried everything, and it didn't work at first (no pixel mixup), but I got it to "work" playing around with it...

EDIT : Ohhh, I just found out that the memdisk EFILDR does not seem to even boot, as BootDuet's bd32.bin doesn't seem to be geared to boot it.
EDIT2 : I just tried using a FAT12 filesystem and it just printed random unicode characters. Same thing for FAT16.

[n01d3a]

I have read this entire thread and have found it very educational, and I admit, I don't understand most of the in depth details explained. A huge thanks to everyone that has made this as simple as it is.

Now, to get to the main reason why I am posting.
I am using BIOS_to_UEFI by following one of the guides provided by srs5694. I can get into the menu when using Efildr20 from the EDK_UEFI64 folder. I can also get to the menu if I rename Efildr20_FSVariable (from the UDK_X64) to Efildr20 . However, the original Efildr20 that is provided in UDK_X64 freezes at "Welcome to UEFI World."

I prefer to use SATA, so I would like to use the Efildr20 from UDK_X64. What is the difference between the FSVVariable and the normal Efildr20? I noticed it was mentioned earlier in the thread but did not understand the the difference between the two.

I have everything installed on my HDD. I used PartedMagic to create the partition tables and reformat the drive. I am using GPT on my HD, which was originally MBR. It has one 300MB Fat32 partition to put Efildr20 and EFI folder into. The rest of the space is not partition. I did not convert the drive or anything, everything should have been wiped clean and started the tutorial completely blank.

My computer specs.
Asus laptop G50V-X1.

Processor: Intel Centrino2 P8400 Dual Core 2.26 GHz
RAM: 4GB DDR 800Mhz
HDD: 300GB SATA
BIOS  Version: 213

BIOS Settings (That seem relevant):
Intel Virtualization: Enabled
Intel VT-d: Disbaled
IDE Config (SATA/PATA): Enhanced(AKA AHCI)

[n01d3a]

Ok, so to follow up on my post and maybe provide some information for the people who are like me and don't understand the in depth details of this project.

I have successfully installed windows 7 in two configurations. Both were completely fresh installs. I followed the guide posted by srs5694, and after that was done I had to replace one file. Explained below. After that, everything seems to work.

First:
Using the Efildr20 from EDK_UEFI64. Your HDD must be IDE or in IDE mode for this to work. I put the windows install files on a 16GB flash drive because for some reason the CD/DVD drive is not recognized at all. Windows does take a little longer than normal to boot, I almost thought it froze at first. I read somewhere, I think from the wiki that is posted on the GIT website that this is known and is expected to be fixed in the future. Performance once inside windows was alright. I will be honest, it felt slower than it should have. Every now and then menus and windows would hang for a split second. Not sure if this is because my drives are in IDE mode, if this is because of using boot duet, or if it is part my imagination.

Edit: When I say for this to work, I mean for the UEFI environment to see your HDD and boot into windows. Assuming you have a working Efildr file, the Uefi environment will work in either AHCI or IDE mode.

Second (with SATA)
Unfortunately when using files from the newest version, the Efildr20 file that is in UDK_X64 hangs for me at "Welcome to UEFI," but as mentioned in a previous post the older version works. Use the version from the commit that starts with 55c55d.... Just replace the Efildr20 that is in your ESP/EFI/200MB (or whatever you named it) partition with the older one. After that I re-enabled AHCI. I had to re-install windows after this because I was getting BSOD. Still used the flash drive to install. Windows boots quite a bit faster this way and the performance in windows is better however still seems slow every now and then.

I could not get Efildr20_FSVariable to work with windows. I don't know the difference between the two so I am not really worried about it...

@srs5694 Your guide was very helpful in getting me setup. However the folder names are a little outdated now. It would be nice if you could update the site again. Or at very least maybe edit in there saying that there may be an issue with Efildr20 and what to do to get that working.

I do realize that it has been a short while since anybody has posted in thread,so maybe it is dead, but hopefully this basic knowledge I put here will assist others as they glance over when looking for solutions.

Once again I appreciate all the help and information provided in this forum. I posted all this because I felt like the information was scattered between this thread and the Git website. Everything that I mentioned here was relevant to me in order to get the UEFI environment and windows running.

[Alessandro17]

Keshav P R, on 14 September 2009 - 09:59 AM, said:

EDIT: The page has been moved.

I have just seen your post and I don't like it at all. Basically you are using InsanelyMac to advertise somebody else's site.

Link removed

[migle]

Alessandro17, on 05 December 2011 - 12:05 AM, said:

I have just seen your post and I don't like it at all. Basically you are using InsanelyMac to advertise somebody else's site.

Link removed

Alessandro17, are you serious? Do you really see that as a form of advertisement?

Did you read the topic?
Don't you see that on-par with the discussion on this forum, scripts and code was developped to address the issues?
Isn't gitorious more adequate for collaborating on code and scripts?

To me it seems that the discussion on this forum had items suited to be discussed on a forum and others which were not as much.

Advertisement?
Do you think Keshav, me, Rod and everybody else have any interest in this whatsoever?
Don't you think the contributions given on this topic, in particular by Keshav, deserve acknowledgement and maybe even gratitude for the amount shared for the pure benefit of others?

Is that really an advertisement of gitorious on your site?

Honestly!

Miguel

[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]

heliox, on 05 December 2011 - 05:10 PM, said:

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.

cheshirekow, on 25 July 2012 - 09:15 PM, said:

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).

cheshirekow, on 25 July 2012 - 09:15 PM, said:

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...

cheshirekow, on 25 July 2012 - 09:15 PM, said:

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.

cheshirekow, on 25 July 2012 - 09:15 PM, said:

[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)

cheshirekow, on 25 July 2012 - 09:15 PM, said:

[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.

cheshirekow, on 25 July 2012 - 09:15 PM, said:

[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.

cheshirekow, on 25 July 2012 - 09:15 PM, said:

[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]

migle, on 26 July 2012 - 12:43 PM, said:

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

migle, on 26 July 2012 - 12:43 PM, said:

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.

migle, on 26 July 2012 - 12:43 PM, said:

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.

migle, on 26 July 2012 - 12:43 PM, said:

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.

migle, on 26 July 2012 - 12:43 PM, said:

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

Yup, already done.

migle, on 26 July 2012 - 12:43 PM, said:

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).

migle, on 26 July 2012 - 12:43 PM, said:

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?

[BonBon6]

rancur, on 27 April 2012 - 03:55 AM, said:

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.