Linux and Windows UEFI boot using Tianocore DUET firmware

[migle]

migle:

I installed BootDuet/bd32.bin in EFI partition's FAT32 bootsector, in MBR - Gpt.com from Tianocore/Duet.

Gpt executes BootDuet, but BootDuet halts after int13 in first call of read function (called from fread, which is called from readroot). Return code from int13 is 0x01 (in AH).

Arguments to read function - ecx: 0x02, eax: 0x2800 (points to LFN entry of Efildr20), edi: 0x8000.

On MBR partitioned drive with Mbr.com from Duet and FAT32 primary partition BootDuet starts efildr20 as expected.

i.e. the same behaviour as bs32.bin from Duet (which prints BError! on GPT drive and halts).

I tried all of it on WMware virtual machine.

May be the problem with Gpt.com, and not with bootsector code?

I can produce more specific debug output if needed.

 

I'm amazed by the amount of debug info you already got, however, I'm still in the dark. The arguments of the read function are not supposed to be what you said. They're supposed to be: EDX:EAX LBA address of the sector to read (which will be the first sector of the root directory), ECX number of sectors to read (2 sounds fine, your FAT32 file system has 1024 byte clusters, right?), ES:EDI = 0000:8000, right. Assuming EAX is right, and EDX is zero, can you confirm that the LBA of the first sector of your root directory is 0x2800 (absolute, from the beginning of the disk)?

 

But if CX is 2, then that can't be the first call of the read function. It would have to be the second. In the first call of the read function, a single FAT sector would be read and CX would be 1. So, I assumed that if CX is 2, that's after reading FAT and it's the read of the first sector of root.

 

That's all supposed to be right, I'll try to make more intelligent questions:

- Do you happen to know what that AH=01 return code means? (My old books are not at hand)

- Are you reading from a hard disk?

- Can you determine if the BIOS drive number is in DL at the beginning of BootDuet (supposedly passed by Gpt)?

- Is that BIOS drive number over 0x80 ? (0x00 is the first floppy, A:, 0x01 is B:, 0x80 is the first hard drive, C:, etc) I wonder if VMWare's BIOS doesn't support LBA on a floppy, quite possible.

 

Maybe I can try the same thing here, but I must use VirtualBox.

 

A more obvious question, just to rule that out, is the hidden sectors field of your FAT32 boot sector correct?

 

Also, you can use the email address on the source file for this subject. This thread is already long enough and is not about my tiny boot program.

 

EDIT: Ok, I know what the problem is. Gpt.com doesn't leave the drive number on DL as I thought it did. So, when I try to read from the unknown value it passes on DL (maybe 0), BIOS says invalid command.

The reason Gpt.com doesn't leave the drive number in DL is that its ReadBlocks function begins and ends with push all/ pop all (I saw it putting the drive number on DL, but the pop all that follows destroys that).

 

What would be a good solution for this? Well, we could change Gpt.com to leave the drive number in DL (it has room for many more bytes of code). Gpt.com knows the drive number from a value it has hardcoded (the partition to boot from is also hard coded). For now, I think the best solution is to use a compilation option on BootDuet for using the drive number hard coded on the BPB. I will add that in a minute.

 

A better solution would be to change Gpt.com entirely so that the boot drive and partition don't have to be hard coded and then also make it leave the drive number in DL.

 

I will commit the minimal change to BootDuet to github in an hour or so.

[nnobody]

1. I can't find calculation of root directory sector, but at 0x2800 is directory entry,

first 32 byte is LFN entry and after it 32 byte FAT entry of EFILDR20 (the only file on filesystem,

there is no dirs except of root)

 

2. Does BootDuet read first FAT sector? It seems that first sector read by MBR record

that places it to 0x7c00, from this addres BootDuet gets FAT parametrs, isn't it?

 

3. answers for inteligent questions:

a. According to _ttp://www.delorie.com/djgpp/doc/rbinter/id/14/7.html, 0x01 in AH means invalid function or its parameters

 

b. Yes, it's SCSI hard drive (tried to change type to IDE with no luck).

In VirtualBox(on windows host) it's all the same, no matter of controller type

 

c,d. I tried to movb bDrive,%al and call printn, just before int13, output is 0.

movb %dl,%al in main, after movb %dl,main_bDrive(%bp), output is 0.

seems Gpt.com do not not pass disk index, as it done by Mbr.com

I hardcoded $0x80(passed by Mbr.com on same machine) in main instead of %dl and int13 work ok, but I get Missing EFILDR20. I need further investigation...

[migle]

1. I can't find calculation of root directory sector, but at 0x2800 is directory entry,

first 32 byte is LFN entry and after it 32 byte FAT entry of EFILDR20 (the only file on filesystem,

there is no dirs except of root)

 

On FAT32, the root directory is read like any other file, through the fread function. The first cluster of the root directory is in the EBPB.

 

2. Does BootDuet read first FAT sector? It seems that first sector read by MBR record

that places it to 0x7c00, from this addres BootDuet gets FAT parametrs, isn't it?

 

I'll correct myself: BootDuet will only need to read the first sector of FAT to find out if there is a "next cluster" in the root directory.

The first cluster number of the root directory is in the BPB and is usually 2, the first cluster in the file system. The relative sector number is a direct function of the cluster number, such as:

 

LBA = hidden-sectors + reserved-sectors + n-FATs*sectors-per-FAT + (cluster - 2) * (sectors-per-cluster)

 

The first FAT sector will be read afterwards, to determine if there is a "next cluster" to cluster 2.

I don't expect to have a bug in that logic in any of the FAT versions, otherwise it would be unlikely that I could ever read the entire EFILDR file.

 

3. answers for inteligent questions:

a. According to _ttp://www.delorie.com/djgpp/doc/rbinter/id/14/7.html, 0x01 in AH means invalid function or its parameters

 

b. Yes, it's SCSI hard drive (tried to change type to IDE with no luck).

In VirtualBox(on windows host) it's all the same, no matter of controller type

 

c,d. I tried to movb bDrive,%al and call printn, just before int13, output is 0.

movb %dl,%al in main, after movb %dl,main_bDrive(%bp), output is 0.

seems Gpt.com do not not pass disk index, as it done by Mbr.com

I hardcoded $0x80(passed by Mbr.com on same machine) in main instead of %dl and int13 work ok, but I get Missing EFILDR20. I need further investigation...

 

Ok. You can use my new version that uses the drive number hard coded on the BPB (it just skips that line).

Now, missing EFILDR20... I also don't expect the logic of the scanning of the root directory to have any bug.

Use more printns, step by step. Check how your root directory starts. You can use the print function to print the content of the root directory buffer, which is at 0000:8000.

 

What format tool did you use? Do you want me to look at the data you have on the BPB? (tomorrow...)

 

EDIT: back to:

 

LBA = hidden-sectors + reserved-sectors + n-FATs*sectors-per-FAT + (cluster - 2) * (sectors-per-cluster)

 

This is computed by steps, sFat (first LBA of first FAT) = hidden-sectors + reserved-sectors, you can confirm with printn; sData (first LBA of data area) = sFat + n-Fats*sectors-per-FAT, again printn; the root directory is typically cluster 2 and starts at sData (one cluster). If you look at your FAT, you'll see that typically, at position 0x08 you'll see the end-of-file marker, meaning that the root directory only takes one cluster.

If, at the beginning of scanroot, you print the first 64 bytes of 0000:8000, you should see what you have at your sector sData. The LFN entry will be ignored by scanroot.

 

If you got at "Missing EFILDR20", I can't think of anything that could be wrong (other than a bug, or the file really not being there, or the short file name not being what I would expect, note that I expect the short file name entry to be upper case even if the long file name entry is not).

[nnobody]

I think I can solve missing EFILDR by myself, just stuck on int13, but it's behind now. I'll report back later

seems that problem in LFN or something like that

I use diskpart from WinPE3.0 for partitioning and formatting

[nnobody]

setup.1 is in #if !defined(DEBUG) - #endif clause, so DEBUG version of BootDuet don't jmp to Efildr

Just recompiled BootDuet without -DDEBUG and it works great now (with hardcoded drive number)

Also works with VMware SCSI and VirtualBox AHCI hard drives

[migle]

setup.1 is in #if !defined(DEBUG) - #endif clause, so DEBUG version of BootDuet don't jmp to Efildr

Just recompiled BootDuet without -DDEBUG and it works great now (with hardcoded drive number)

Also works with VMware SCSI and VirtualBox AHCI hard drives

 

Good to hear. No other changes needed on what's now on github.

Sorry about the -DDEBUG inconvenience, you see, the printn function takes up a few bytes, the far jump section is removed to save space for that (when debugging, I want to print something and see it, not jump into EFILDR).

 

Anyway, booting works, but Duet itself still needs changes to be a Users' UEFI emulation instead of a Developer's UEFI emulation.... and I've still not gone past compiling Duet...

[nnobody]

1. I found what is wrong with Gpt - it saves dl to 7C00:01B6 after relocation to 0600:0000 occurs and later loads bootsector to 7C00:0000, and not even try to pass dl to bootsector. If I save dl to 0600:01B6 and restore it before jump to bootsector code all works without hardcoded bDrive.

2. I can't produce working gpt.com with gcc(compiles without erros, but binary totaly corrupted), only ntddk(with ml/link16) build works, so I can only make patch for .asm and share binary.

 

BTW, I've checked Mbr code and algorithm there is the same, can't figure why it works from stock

gpt.zip

[migle]

1. I found what is wrong with Gpt - it saves dl to 7C00:01B6 after relocation to 0600:0000 occurs and later loads bootsector to 7C00:0000, and not even try to pass dl to bootsector. If I save dl to 0600:01B6 and restore it before jump to bootsector code all works without hardcoded bDrive.

 

I don't think that's due to error. They save DL to 0x7db6, but they always keep the frame pointer BP at 7c00. Accessing that variable through the frame pointer allows them to save one byte on each instruction that references that address.

They work at Intel. They don't pass the drive number in DL because their spec doesn't say they should. I was the one who mistakenly assumed they did, and didn't see the POPA instruction at the end of ReadBlocks that eliminates that from DL.

 

2. I can't produce working gpt.com with gcc(compiles without erros, but binary totaly corrupted), only ntddk(with ml/link16) build works, so I can only make patch for .asm and share binary.

 

BTW, I've checked Mbr code and algorithm there is the same, can't figure why it works from stock

 

I think it's a matter of specification. It became standard practice for MBR programs to pass DL, see http://www.dewassoc.com/kbase/hard_drives/...boot_record.htm. However, the MBR program for a GPT partition table, what specification specifies its behaviour? It's neither something from the old BIOS world nor something from the UEFI world.

They wrote the program they needed and they didn't foresee what we are trying to do with it.

 

We could re-write Gpt.com from scratch. It's easier to write than this one, I had a very hard time getting the FAT code to fit so few bytes. I am also bothered about the boot partition number being hard-coded. Maybe it would be better that it always booted from the ESP partition?

It could also do a fake MBR partition entry in memory as some other boot managers do, so as to pass SI pointing to that fake entry, thus allowing the VBR program to know where its partition is located.

[balta2ar]

Hello, everyone!

 

I'm owner of EFI-based ASUS P8P67 Deluxe. I was experiencing some difficulties during OS installation, so let me share my experience with you. I wanted to install Windows 7 64-bit and ArchLinux x64 on my new PC. Of course, in EFI mode. That's where the problems began.

 

My PC configuration is:

 

   ASUS P8P67 Deluxe
   OCZ Vertex 3 120 Gb
   Intel Core i5-2500K
   NVIDIA GTX 580 Gainward
   16Gb RAM

 

I didn't have a CD/DVD drive so I had to prepare a bootable copy of Windows on a USB pen. I tried different programs but finally I ended up with UltraISO. However, when I tried to boot widows from USB, installer refused to accept my partitions. Many encountered this message when windows says that disk is GPT-formatted. That means that installer was run not in EFI mode.

 

After that I tried to run windows installer in EFI by all means I could think about. Firmware of my motherboard does not seem to contain any built-in EFI shell, nor does it allow to "Boot from file". After some googling I found out that copying a shell_full.efi from EDK-1.06 (later I also tried EDK2 and it also worked) in /efi/boot/bootx64.efi helps: usb stick obtained UEFI prefix in boot menu in BIOS interface and looked like "UEFI: Kingston II". When I tried to boot from it, I got into shell.

 

In parallel, I also tried to install ArchLinux from another USB stick. I burned latest archboot-2011.05 and followed the standart installation procedure. At the end I choose grub2-efi-x64. However, I didn't see a way to boot it automatically. The only way I could boot grub2 is from EFI shell. That was the first glimmer of hope. Unfortunately, I was dependent on USB srick and couldn't boot anything without it. More googling again and I resolved the problem by puttin the shell to <EFI_SYSTEM_PARTITION>/shellx64.efi. After that "Launch EFI shell" option in BIOS dropped me into shell. USB was not necessary anymore. I could boot ArchLinux from harddisk with lots of hand actions.

 

I tried to launch all the efi files I could found on the windows 7 usb. Launching bootmgr.efi, memtest.efi always resulted in error sayng that the specified binary is not a recognized command or batch or a file. cdboot.efi and cdboot_noprompt.efi seemed to have started loading, but few seconds later it crashed and I was dropped back to the shell. So I couldn't install windows in EFI mode, not even run the installation. An interesting note here is that cdboot.efi and cdboot_noprompt.efi do not autocomplete in EFI shell. All other efi files do.

 

Yesterday I borrowed an external USB DVD ROM drive in hope to install windows from it. However, the drive didn't contain UEFI prefix in the BIOS boot menu and result was the same: windows installer complained about GPT. I also noticed one thing: when I connected my Cowon J3 audio player to USB in order to charge it, it also appeared in BIOS and it contained UEFI prefix. That was weird, because I didn't copy any of efi files to the player. I didn't try to boot from it, though.

 

Finally, I managed to install Windows 7 in EFI mode by accident. Unintentionaly, I left USB DVD drive plugged in and booted into the EFI shell. My USB stick with Windows 7 was also plugged in. I was fooling around on the available drives and tried to launch EFI files I collected from different sources. During that process I run cdboot.efi from USB Windows 7 again and... surprise, surprise, installation started! It didn't drop back to the shell as previously. I also heard DVD disk spinning in the USB DVD driver! Few seconds later Windows accepted my GPT disk and I continued with installation. I went away from the PC for about ten-fifteen minutes but when I got back, Windows was already installed! How amazingly fast! It didn't recognize some of my hardware including network card, though. I rebooted and discovered "Windows boot manager" in BIOS boot menu. From now on I could boot Windows without a problem.

 

Let me summarize my experience in form of current problems and questions:

 

1. [Why can't I/How do I] boot Windows DVD in UEFI mode without all this magic with same USB stick? I saw on youtube people running the same Windows 7 in UEFI from DVD without a problem. They got UEFI: DVD in Boot menu. I don't. Why?

 

2. What does Windows installer do so special that "Windows boot manager" appears in the boot menu? How do I do the same for grub2? How do I add it to the BIOS Boot menu? I tried to reproduce folder structure for grub on ESP: I copied contents of grub folder to /efi/grub/boot on the analogy to /efi/microsoft/boot/ folder. It didn't work - grub didn't appear in BIOS Boot menu.

 

3. Is there any document describing ASUS P8P67 specific EFI behaviour? What conditions should be met in order to boot device in UEFI mode? FAT32 Partition type, certain files availble, partition flags?

 

4. Note: I tried to run rEFIt EFI files in the shell but failed: 'refit.efi' is not recognized as an internal or external command, operable program, or batch file.

 

5. Note: I get kernel panic when I reboot ArchLinux: http://img.flashtux.org/img132dcbc19160x584317ed.jpg. Shutdown is fine, though. That's very unpleasant because I cannot reboot my PC remotely - I need to push Reset button in order to reboot the machine.

 

6. Note: My primary harddisk OCZ Vertex 3 SSD does not have UEFI prefix in Boot menu. Only USB sticks obtain such prefix provided they contain FAT32 partition.

 

7. Note: I didn't manage to run cdboot.efi from Windows DVD. When I booted into EFI shell, DVD wasn't mapped to some drive name like fs1: or something. I had to manually do "map fs1 blkA" - blkA was printed in the output of map command in the EFI shell. This mapping, however, didn't help: I changed drive to fs1 but 'ls' gave me an error. I coudn't browse the Windows DVD filesystem.

 

8. Note: SATA mode is set to AHCI in BIOS.

 

I really want to make this post useful to someone. I'm ready to provide all the necessary logs and infos to help with investigation of mentioned problems. Bellow I post all the information I collected and which I belive might be of any interest and use.

 

Info:

lshw output:

http://paste.pocoo.org/show/394135/

 

gdisk output:

   Command (? for help): p
   Disk /dev/sdc: 234441648 sectors, 111.8 GiB
   Logical sector size: 512 bytes
   Disk identifier (GUID): D3A460D9-0C5C-4121-8838-E63ED027269E
   Partition table holds up to 128 entries
   First usable sector is 34, last usable sector is 234441614
   Partitions will be aligned on 2048-sector boundaries
   Total free space is 2925 sectors (1.4 MiB)

   Number  Start (sector)	End (sector)  Size	   Code  Name
	  1			2048		  411647   200.0 MiB   EF00
	  2		  411648		  432127   10.0 MiB	EF02
	  3		  821248		62261247   29.3 GiB	0700
	  4		62261248	   129845247   32.2 GiB	0700
	  5	   129845248	   148277247   8.8 GiB	 0700
	  6	   150325248	   150734847   200.0 MiB   0700
	  7	   148277248	   150325247   1000.0 MiB  8200
	  8	   150734848	   234440703   39.9 GiB	0700
	  9		  432128		  821247   190.0 MiB   0700

   Command (? for help): i
   Partition number (1-9): 1
   Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)
   Partition unique GUID: 58471815-D914-4133-894A-7E80927727F6
   First sector: 2048 (at 1024.0 KiB)
   Last sector: 411647 (at 201.0 MiB)
   Partition size: 409600 sectors (200.0 MiB)
   Attribute flags: 0000000000000000
   Partition name: ''

 

EFI shell commands output:

dh.txt - http://paste.pocoo.org/show/394158/

dmpstore.txt - http://paste.pocoo.org/show/394159/

guid.txt - http://paste.pocoo.org/show/394160/

help.txt - http://paste.pocoo.org/show/394161/

map.txt - http://paste.pocoo.org/show/394162/

pci.txt - http://paste.pocoo.org/show/394163/

run.txt - http://paste.pocoo.org/show/394164/

ver.txt - http://paste.pocoo.org/show/394165/

vol.txt - http://paste.pocoo.org/show/394166/

 

 

EDIT: I duplicated post here: https://bbs.archlinux.org/viewtopic.php?pid=938691#p938691

EDIT: fixed typos and added 7.

EDIT: I've just found this: https://help.ubuntu.com/community/UEFIBooti...%20as%20default. This seems to be a solution for the problem #2. I will check it by evening at home.

[nnobody]

migle:

Anyway thanks for your work, now I can boot Windows from GPT drive without USB flash drive.

[Keshav Amburay]

I didn't have a CD/DVD drive so I had to prepare a bootable copy of Windows on a USB pen. I tried different programs but finally I ended up with UltraISO. However, when I tried to boot widows from USB, installer refused to accept my partitions. Many encountered this message when windows says that disk is GPT-formatted. That means that installer was run not in EFI mode.

 

Although this is technically not related to linux, setting up Windows 7 x64 iso to boot from USB for a BIOS boot sets up the USB as NTFS, not FAT32. Thats why the firmware fall-back to BIOS boot since it did not find any UEFI bootable disk/drive .

 

In parallel, I also tried to install ArchLinux from another USB stick. I burned latest archboot-2011.05 and followed the standard installation procedure. At the end I choose grub2-efi-x64. However, I didn't see a way to boot it automatically. The only way I could boot grub2 is from EFI shell. That was the first glimmer of hope. Unfortunately, I was dependent on USB srick and couldn't boot anything without it. More googling again and I resolved the problem by puttin the shell to <EFI_SYSTEM_PARTITION>/shellx64.efi. After that "Launch EFI shell" option in BIOS dropped me into shell. USB was not necessary anymore. I could boot ArchLinux from harddisk with lots of hand actions.

 

2. What does Windows installer do so special that "Windows boot manager" appears in the boot menu? How do I do the same for grub2? How do I add it to the BIOS Boot menu? I tried to reproduce folder structure for grub on ESP: I copied contents of grub folder to /efi/grub/boot on the analogy to /efi/microsoft/boot/ folder. It didn't work - grub didn't appear in BIOS Boot menu.

 

https://wiki.archlinux.org/index.php/Unifie...face#UEFI_Shell and https://wiki.archlinux.org/index.php/GRUB2#...re_Boot_Manager . For this to work you should have booted in UEFI mode. By standard procedure i suppose you used isohybrid (dd the iso to the usb) option and booted in BIOS mode.

 

I tried to launch all the efi files I could found on the windows 7 usb. Launching bootmgr.efi, memtest.efi always resulted in error sayng that the specified binary is not a recognized command or batch or a file. cdboot.efi and cdboot_noprompt.efi seemed to have started loading, but few seconds later it crashed and I was dropped back to the shell. So I couldn't install windows in EFI mode, not even run the installation. An interesting note here is that cdboot.efi and cdboot_noprompt.efi do not autocomplete in EFI shell. All other efi files do.

 

Finally, I managed to install Windows 7 in EFI mode by accident. Unintentionaly, I left USB DVD drive plugged in and booted into the EFI shell. My USB stick with Windows 7 was also plugged in. I was fooling around on the available drives and tried to launch EFI files I collected from different sources. During that process I run cdboot.efi from USB Windows 7 again and... surprise, surprise, installation started! It didn't drop back to the shell as previously. I also heard DVD disk spinning in the USB DVD driver! Few seconds later Windows accepted my GPT disk and I continued with installation. I went away from the PC for about ten-fifteen minutes but when I got back, Windows was already installed! How amazingly fast! It didn't recognize some of my hardware including network card, though. I rebooted and discovered "Windows boot manager" in BIOS boot menu. From now on I could boot Windows without a problem.

 

Let me summarize my experience in form of current problems and questions:

 

1. [Why can't I/How do I] boot Windows DVD in UEFI mode without all this magic with same USB stick? I saw on youtube people running the same Windows 7 in UEFI from DVD without a problem. They got UEFI: DVD in Boot menu. I don't. Why?

 

http://ubuntuforums.org/showpost.php?p=106...mp;postcount=76

 

3. Is there any document describing ASUS P8P67 specific EFI behaviour? What conditions should be met in order to boot device in UEFI mode? FAT32 Partition type, certain files availble, partition flags?

 

The instructions are common for any UEFI systems (excluding Intel Macs which are actually weird in UEFI booting)

 

4. Note: I tried to run rEFIt EFI files in the shell but failed: 'refit.efi' is not recognized as an internal or external command, operable program, or batch file.

 

rEFIt is specific to Intel Macs. It does not work for non-Mac UEFI systems.

 

5. Note: I get kernel panic when I reboot ArchLinux: http://img.flashtux.org/img132dcbc19160x584317ed.jpg. Shutdown is fine, though. That's very unpleasant because I cannot reboot my PC remotely - I need to push Reset button in order to reboot the machine.

 

https://bugs.archlinux.org/task/23067 . Add

reboot=a

to the kernel command line in the bootloader. If it does not work try

reboot=a,w

.

 

6. Note: My primary harddisk OCZ Vertex 3 SSD does not have UEFI prefix in Boot menu. Only USB sticks obtain such prefix provided they contain FAT32 partition.

 

You should have a <EFI_SYSTEM_PARTITION>/efi/boot/bootx64.efi file for your SSD to have UEFI prefix in the boot menu.

 

7. Note: I didn't manage to run cdboot.efi from Windows DVD. When I booted into EFI shell, DVD wasn't mapped to some drive name like fs1: or something. I had to manually do "map fs1 blkA" - blkA was printed in the output of map command in the EFI shell. This mapping, however, didn't help: I changed drive to fs1 but 'ls' gave me an error. I coudn't browse the Windows DVD filesystem.

 

Most of the UEFI firmwares do not have support for reading ISO9660 or UDF iso/cd/dvd .

 

Info:

lshw output:

http://paste.pocoo.org/show/394135/

 

EFI shell commands output:

map.txt - http://paste.pocoo.org/show/394162/

pci.txt - http://paste.pocoo.org/show/394163/

ver.txt - http://paste.pocoo.org/show/394165/

 

EDIT: I duplicated post here: http://www.insanelymac.com/forum/index.php...p;#entry1687860

EDIT: I've just found this: https://help.ubuntu.com/community/UEFIBooti...%20as%20default. This seems to be a solution for the problem #2. I will check it by evening at home.

 

Actually it is possible to have Windows 7x64 ISO UEFI, Archboot ISO BIOS (using syslinux) and Archboot ISO UEFI in the same USB. I have done it before.

 

Just extract Windows 7 x64 iso and Archboot iso contents to the FAT32 formatted USB drive. Then extract the <WINDOWS_7_ISO>/efi/microsoft/boot/efisys.bin file using p7zip, it will contain <EFISYS.BIN>/efi/boot/bootx64.efi . Copy this bootx64.efi file to <USB>/efi/Microsoft/boot/bootmgfw.efi .

Similarly extract <ARCHBOOT_ISO>/efi/grub2/grub2_efi.bin and copy <GRUB2_EFI.BIN>/efi/boot/bootx64.efi to <USB>/efi/grub2/grub.efi . Copy the UEFI Shell to <USB>/efi/boot/bootx64.efi .

 

PS: I posted the same in insanelymac forums just in case. I am surprised though, you didn't read UEFI info available in Archwiki (UEFI and GRUB2 pages) and instead searched everything using Google.

[Keshav Amburay]

@migle: I managed to make DUET boot into windows directly, without efivar.bin support and without the blue screen (using EmuVariableRuntimeDXE). This was made possible by http://tianocore.git.sourceforge.net/git/g...242d5b39cdc040a .

 

Just copy (ESP)/EFI/Microsoft/Boot/bootmgfw.efi to (ESP)/EFI/boot/bootx64.efi and the firmware will add a boot option in the firmware. If you allow DUET to try booting the available boot options in the Boot Manager (5 seconds timeout), after actual CD/DVD drive, the (ESP)/EFI/boot/bootx64.efi will be the second boot option and it will boot automatically. I guess this allows booting Windows UEFI-GPT via DUET without interruption. For this download the latest Efildr20 DUET file ( git commit 27-May-2011 ).

[Laqk]

You guys are lucky to be able to boot your Windows in EFI mode from your hard drive. I've been trying for days now without success. Migle's bootduet just doesn't work for me.

 

First, let me say I used Keshav's package to build an MBR DUET USB stick, and it works perfectly. I've used it to install Windows 7 x64 several times now on my GPT formatted hard disk. But so far I've failed in setting it up so it can boot without the USB stick.

 

Whatever I try I get the same result: I get the message "GPT Started!" on screen, then a blinking cursor in the upper left corner of the screen, then nothing. The problem is not with gpt.com, I confirmed that it does load and execute the boot sector of the EFI system partition by making the boot sector invalid on purpose (I compiled bootduet with -DWITH_VALIDATION and wrote zeros for the hidden sectors value) and I did get the "Bad" message, so I know the boot sector load and at least starts to execute. But when I compile bootduet with the -DDEBUG option I don't even get any number display on the screen, and I know that EFILDR20 is not only not loaded, it's not even searched for because even when the EFI system partition is completely empty, I don't get any "Missing EFILDR20" message.

 

I've created my GPT disk in several ways (let Windows create it itself during setup starting from a completely blank and unformated disk, created the GPT partition in Mac OS X, created it in Linux using gparted, and in this last case, letting windows create the EFI system partition itself, or creating it manually before windows setup using gparted and gnome disk manager). I tried a FAT32 EFI system partition using bd32hd.bin, and also a FAT16 one using bd16hd.bin, to no avail. Whatever I do I get the same result: the boot sector loads and starts executing, but somehow crashes along the way, doesn't even get to the debug code (when -DDEBUG is specified) and doesn't even try to load EFILDR (no "missing EFILDRXX" message when the file is not even on the disk).

 

In desperation, I began to suspect that maybe there was something wrong with my internal hard drive, so I took an 8 GiB USB stick and used gparted and gnome disk manager to format it in GPT, create two FAT32 4 GiB partition, and set the first one as an EFI system partition. Then I tried installing gpt.com on the master boot record and bootduet on the boot sector and tried booting with this USB stick, and got exactly the same result as always: "GPT Started!" message, and then the dreaded blinking cursor, then nothing.

 

I've tried every test, every configuration I could think of, but now I'm completely out of ideas. Maybe one of you guys could steer me in a new diection of investigation, or else I guess I'll just have to accept the fact that I'll have no choice but booting my machine with a USB stick...

[Keshav Amburay]

Whatever I try I get the same result: I get the message "GPT Started!" on screen, then a blinking cursor in the upper left corner of the screen, then nothing. The problem is not with gpt.com, I confirmed that it does load and execute the boot sector of the EFI system partition by making the boot sector invalid on purpose (I compiled bootduet with -DWITH_VALIDATION and wrote zeros for the hidden sectors value) and I did get the "Bad" message, so I know the boot sector load and at least starts to execute. But when I compile bootduet with the -DDEBUG option I don't even get any number display on the screen, and I know that EFILDR20 is not only not loaded, it's not even searched for because even when the EFI system partition is completely empty, I don't get any "Missing EFILDR20" message.

 

The problem is with gpt.com in not passing the partition info to BootDuet bootsector. Gpt.com chainloads BootDuet fine but without the partition info (partition number or starting sector etc), BootDuet will fail to access the ppartition and load Efildr20. BTW did you try the memdisk method? Or instead of using gpt.com use some normal bios bootloader with gpt support like grub2 or syslinux in the MBR and then chainload the EFI System Partition from that. I currently use syslinux+BootDuet to boot into Windows 7 and linux (both direct from syslinux and via DUET using grub2-efi).

[Laqk]

Thanks for your reply Keshav. But I'm not sure I understand what you mean when you say that gpt.com doesn't pass partition info properly. If I read bootduet's source code correctly, all that it needs is the BIOS drive number of the boot drive, and the LBA of the boot sector of the EFI partition, and the "hd" versions of bootduet seem to read both of these directly from to boot sector itself (and I've made sure this information is present and accurate in the boot sector of the EFI partition). So it shouldn't need any information from gpt.com.

 

As for syslinux, I'll look into it. Besides syslinux and grub2, is there any other gpt-aware boot loader ?

 

 

 

 

 

@migle:

 

I think I found a discrepency in your bootduet source code.

 

In the comment, you say:

 

* 0x006000 - 0x007000 Room for several FAT sectors (4k) (FAT12)

...

 

* 0x007e00 - 0x008000 Room for one FAT sector (FAT32 and FAT16)

 

 

Yet, in the code, the following:

 

#if FAT == 32 || FAT == 16

.equ FatOffset, 0x6000 # Offset address for the FAT buffer

#else

.equ FatOffset, 0x7e00 # Offset address for the FAT buffer

#endif

 

 

seems to do the exact opposite. Is it a mistake in the comments ?

[migle]

Thanks for your reply Keshav. But I'm not sure I understand what you mean when you say that gpt.com doesn't pass partition info properly. If I read bootduet's source code correctly, all that it needs is the BIOS drive number of the boot drive, and the LBA of the boot sector of the EFI partition, and the "hd" versions of bootduet seem to read both of these directly from to boot sector itself (and I've made sure this information is present and accurate in the boot sector of the EFI partition). So it shouldn't need any information from gpt.com.

 

As for syslinux, I'll look into it. Besides syslinux and grub2, is there any other gpt-aware boot loader ?

 

 

 

 

 

@migle:

 

I think I found a discrepency in your bootduet source code.

 

In the comment, you say:

 

* 0x006000 - 0x007000 Room for several FAT sectors (4k) (FAT12)

...

 

* 0x007e00 - 0x008000 Room for one FAT sector (FAT32 and FAT16)

 

 

Yet, in the code, the following:

 

#if FAT == 32 || FAT == 16

.equ FatOffset, 0x6000 # Offset address for the FAT buffer

#else

.equ FatOffset, 0x7e00 # Offset address for the FAT buffer

#endif

 

 

seems to do the exact opposite. Is it a mistake in the comments ?

 

You are right, that is a bug. It is only of consequence for the FAT12 version.

The thing is there is no room for more than one sector at 7e00, but there is room for plenty at 6000.

Only the FAT12 code needs room for more than one, specifically for 3, because 3*sector-size is the lowest common multiple of the size of each FAT12 pointer (3 bytes) and the sector size, and that's the only way to keep the code simple.

 

That is not the bug which is causing you trouble.

 

The bug which is causing you trouble was one I introduced in commit 60cac65, one with a message like "Saved 5 bytes".

Apparently, neither Keshav nor nnobody ran into it, or if they did, they didn't tell me. They are using some previous version.

 

I haven't been using this (yet), so I didn't see it myself. It was a very stupid thing in the read function.

If you look at it, you'll see I push si, then the whole DAP structure, and after the int 13h, I only restore the si register, I forgot to skip those 16 bytes on top of the stack.

 

You see, I was eager to save those 5 bytes, and only truly saved 2.

I was so careful looking at the code listing, that I stupidly felt confident to commit the result without testing.

 

Sorry for the inconvenience.

Also, I didn't see your message earlier because (I just found out) I'm not subscribed to the entire topic, only to the threads I replied to (I think...).

 

Both the bug you pointed out and the very stupid and serious bug I just mentioned are now corrected in the repository.

 

...

ah!

and I took the time to test it this time...

 

 

 

 

You guys are lucky to be able to boot your Windows in EFI mode from your hard drive. I've been trying for days now without success. Migle's bootduet just doesn't work for me.

 

...

 

You know, I was wondering myself why was bootduet hanging with only a blinking cursor when I tried to run it once or twice....

But with so much updates on my laptop (I use Gentoo) I just overlooked and left it for latter.

 

 

I'll try to subscribe to the entire topic this time. If I had known before... this was a very easy fix.

[migle]

Duet does not have iso9660 fs driver. It has only fat12/16/32 driver. For bootx64.efi, extract /efi/microsoft/boot/efisys_noprompt.bin , and copy the /EFI/BOOT/BOOTX64.efi from that dir. Best method would be to simply extract the iso to a FAT32 usb pendrive and extract this file and set it up inside that pendrive. You can boot this pendrive instead of using iso, (which is slower)

 

I still don't have Windows running (it's also a new record, being able to do without Windows for a few months).

 

I'm trying to install Windows directly to the GPT partition using EFI again, because my installation media doesn't seem to have the repair option which is needed to generate the BCD.

 

I'm trying your suggestion now, copying everything to a USB pen. I formatted the pen in FAT32, installed BootDuet and EFILDR20 in it, copied the entire CD contents, extracted BOOTX64.EFI to EFI\Boot, all on the pen drive.

I tried two ways: having a single partition on the pen drive and using no partitions: using the entire drive for the FAT32 file system.

 

When DUET boots, I use "Boot from file" to try to boot BOOTX64.EFI, however it never seems to work. I always return to the previous screen.

 

Did you actually get this to work?

What did I do wrong?

 

Miguel

[Laqk]

Works perfectly now, thank you !

 

You see, I was eager to save those 5 bytes, and only truly saved 2.

I was so careful looking at the code listing, that I stupidly felt confident to commit the result without testing.

 

Don't be too hard on yourself, It's just the "But I made only one minor and obvious modification, what could possibly go wrong ?" syndrome. I was plagued with it extensively in my programming days.

 

By the way, did you know that if you removed the check on the hiddensectors value (either in the code or by removing -DWITH_VALIDATION in the makefile), you can use your bootduet on an unpartitionned usb "superfloppy" (by placing it directly on sector 0) and it works splendidly ? Much simpler that way.

 

And as a small token of my appreciation, I've solved your EFI Windows 7 USB stick issue. Do the following:

 

1. Format your USB stick using the FAT32 format (an unpartitionned "superfloppy" works fine);

 

2. Install Bootduet on it;

 

3. Copy EFILDR20 to the root;

 

4. Copy the entire content of the Windows 7 x64 install DVD to the USB stick;

 

5. In folder EFI, create a folder named BOOT;

 

6. In that folder, copy the BOOTX64.EFI file that I included in this post.

 

And voila ! A perfectly functional EFI Windows 7 installation USB stick. I tested it and it works. I read your previous post and the problem was that the BOOTX64.EFI file included in the EFISYS.BIN and EFISYS_NOPROMPT.BIN don't work. They're only for the el-torito partition of a bootable DVD. The one I included in my post comes directly from the EFI system partition of an already installed and working Windows 7 x64 installation on an EFI GPT disk.

 

Enjoy ! And thanks again for your help.

 

bootx64.zip

[migle]

By the way, did you know that if you removed the check on the hiddensectors value (either in the code or by removing -DWITH_VALIDATION in the makefile), you can use your bootduet on an unpartitionned usb "superfloppy" (by placing it directly on sector 0) and it works splendidly ? Much simpler that way.

 

Of course I know! ...

I also tried the superfloppy thing when trying to boot the installation.

 

I'm ready to remove the HiddenSectors != 0 check if there is consensus.

That check however tests for the most likely installation error: the user not reading the TXT file and forgetting to set the HiddenSectors.

 

I know, people are having other problems instead of those I anticipated: nnobody found that it didn't work with Gpt.S and you ran into that bug, however...

 

And as a small token of my appreciation, I've solved your EFI Windows 7 USB stick issue. Do the following:

 

1. Format your USB stick using the FAT32 format (an unpartitionned "superfloppy" works fine);

 

2. Install Bootduet on it;

 

3. Copy EFILDR20 to the root;

 

4. Copy the entire content of the Windows 7 x64 install DVD to the USB stick;

 

5. In folder EFI, create a folder named BOOT;

 

6. In that folder, copy the BOOTX64.EFI file that I included in this post.

 

And voila ! A perfectly functional EFI Windows 7 installation USB stick. I tested it and it works. I read your previous post and the problem was that the BOOTX64.EFI file included in the EFISYS.BIN and EFISYS_NOPROMPT.BIN don't work. They're only for the el-torito partition of a bootable DVD. The one I included in my post comes directly from the EFI system partition of an already installed and working Windows 7 x64 installation on an EFI GPT disk.

 

Enjoy ! And thanks again for your help.

 

bootx64.zip

 

Well, thanks. It will be a clue, if nothing else. It's Vista 64 I'm trying to install. That's what came with my laptop, and I'm not interested in having the latest and greatest version...

Your explanation is what I expected. Maybe that BOOTX64 works with Vista install, if not, I'll get the BOOTX64 from a Vista installation (or install disk... it will be there).

 

The more long term solution is what Keshav said: using the iso 9660 driver from Virtual Box. I'm trying to avoid the trouble of understanding that complicated build process.

[Keshav Amburay]

I checked bootx64.efi from efisys.bin and bootmgfw.efi from my Windows installation and they were indeed different. It is possible to take the bootx64.efi (actually bootmgfw.efi) file attached by laqk from "C:\Windows\Boot\EFI" from a Windows x64 installation or from the "install.wim" file in the "sources" folder of the Windows x64 ISO (Use 7-zip to extract the wim file).

[Keshav Amburay]

@balta2ar: https://bbs.archlinux.org/viewtopic.php?pid=944722#p944722

[srs5694]

Hi all,

 

I finally got around to doing some serious testing with UEFI DUET. I'd tried it several months ago, and also several months before that, with limited success -- it hung most of my test machines at the time, and was impractical with others because of weird keyboard problems.

 

This time I've had more luck, and the new BootDuet helps a lot. I quickly got frustrated with all the manual fiddling when I wanted to re-install or try a different version, though. I therefore put together a Linux Bash script that does all the tricky stuff. I'll give it its own formal Web page eventually, but for now, here's a direct download link (edited for latest version -- 6/14/2011):

 

http://www.rodsbooks.com/duet-install-0.1.2.tgz

 

Launch the script with a -h or --help option to see a help summary. For convenience, you may want to edit the paths to the SYSLINUX, BootDuet, and UEFI DUET directories.

 

What it does, in summary:

 

• Optionally creates a FAT filesystem on the target partition (hard disk or USB flash drive) and changes the partition type code to that for an EFI System Partition when creating a filesystem.
  
• Adjusts the "hidden sectors" value in the FAT filesystem.
  
• Sets the "BIOS bootable" GPT flag or the "boot/active" MBR flag, as appropriate.
  
• Optionally installs SYSLINUX (for GPT or MBR) to the MBR's boot code area.
  
• Installs BootDuet to the specified partition's boot sector. It installs the LBA-32 version by default, but the LBA-64 version is an option.
  
• Installs the Efildr file from Keshav's UEFI DUET package. It installs the Efildr20 file from the UEFI 2.3 directory by default, but it will install the 2.1 version or 2.3's Efildr*_FSVariable version on request.
  
• Copies various .efi support files into an EFI directory on the target partition.
  

 

In summary, if you start with a disk with a FAT partition you want to preserve or any type of partition you're willing to sacrifice, you should get a bootable UEFI DUET disk out of it, although it will only boot to UEFI DUET.

 

What it does not do, in summary:

 

• Does not compile software. At a minimum, you'll need to compile BootDuet yourself. You may also need to install and perhaps compile SYSLINUX if you want to install it.
  
• Does not back up existing MBR or boot sector code. (That's on my to-do list.)
  
• Does not create or delete partitions.
  
• Does not clear other partitions' "BIOS bootable" or "boot/active" flags.
  
• Does not use the Gpt.com or Mbr.com MBR boot loader from Keshav's UEFI DUET distribution.
  
• Does not support the "hardcoded drive" method of BootDuet installation.
  
• Does not support UEFI variants other than Keshav's UEFI DUET. The issue is mainly one of locating files; the script assumes files are in certain locations. Of course, you could copy the Efildr file and supporting .efi files manually.
  
• Does not install any EFI boot loader other than the UEFI DUET software -- if you want ELILO, GRUB 2, rEFIt, etc., you'll need to install them yourself. Fortunately, that's fairly easy -- just copy some files.
  

 

Speaking of boot loaders, rEFIt is compatible with UEFI; however, you need a 64-bit-only binary, at least with UEFI DUET. The most common rEFIt binaries are 32/64-bit. I've successfully used the binaries that ship with Ubuntu with UEFI DUET, the UEFI in VirtualBox, and an Intel board with UEFI booting.

 

So far I've tested my duet-install script on USB flash drives. It certainly makes testing with UEFI DUET easier. I haven't yet gotten around to testing it on hard disks.

 

Keshav and migle, you're both welcome to include this script in your packages. IMHO, a single binary package with everything needed to install UEFI DUET on a hard disk would help make it a viable tool for people who need it. Unfortunately, my script makes heavy use of Linux-specific programs and features, so it's not likely to be very portable. (I'm not even sure how portable it is across Linux distributions -- so far I've tested it only on Gentoo.)

 

Naturally, I welcome any comments you might have.

[Keshav Amburay]

• Installs the Efildr file from Keshav's UEFI DUET package. It installs the Efildr20 file from the UEFI 2.3 directory by default, but it will install the 2.1 version or 2.3's Efildr*_FSVariable version on request.
  
• Copies various .efi support files into an EFI directory on the target partition.
  

 

I actually renamed the EDK2_X64 to UDK_X64 to follow upstream naming (http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome). I suggest people use the copy_duet_files.sh script in EFI_DUET dir instead of copying the files in duet-install.sh . You can also call the copy_duet_files script within duet-install.sh .

 

• Does not support UEFI variants other than Keshav's UEFI DUET. The issue is mainly one of locating files; the script assumes files are in certain locations. Of course, you could copy the Efildr file and supporting .efi files manually.
  

 

Same as above.

 

Keshav and migle, you're both welcome to include this script in your packages. IMHO, a single binary package with everything needed to install UEFI DUET on a hard disk would help make it a viable tool for people who need it. Unfortunately, my script makes heavy use of Linux-specific programs and features, so it's not likely to be very portable. (I'm not even sure how portable it is across Linux distributions -- so far I've tested it only on Gentoo.)

 

Naturally, I welcome any comments you might have.

 

1) Is it possible for you to host this script in a git repo somewhere with version history?

 

2) Please do not use UEFI 2.1 and UEFI 2.3 as options for Efildr. Use EDK_UEFI64 and UDK_X64 .

 

EDK_UEFI64 FSVariable works properly but is slow in booting and does not support USB Keyboards and AHCI. It causes no Blue screen in Windows x64. This happens to support Spec version at 2.1 .

 

EDK2_X64 supports AHCI, USB Keyboards (I modified the Makefile to include USB KB module) and is currently at UEFI Spec 2.31 (it usually matches the latest spec version at http://www.uefi.org/specs which is not necessarily only 2.3). With FSVariable it causes Windows Blue Screen but without FSVariable (using EmuVarRuntimeDxe instead) it boot successfully. I suggest removing copying FSVariable option in duet-install since i included them mainly to help migle test its the FSVariable problem. I suggest copying the FSVariable UDK_X64 Efildr20 manually if required.

 

3) Many stuff like fatBitness=`file -s $targetPart | sed 's/FAT (/\nFAT /' | grep bit | sed 's/)/\n/' | grep bit | sed 's/FAT //' | sed 's/ bit//'` (line 145)

 

can be done by

 

keshav_pr@my-comp ~ % blkid -p -i -o udev /dev/sda1
ID_FS_LABEL=EFISYS
ID_FS_LABEL_ENC=EFISYS
ID_FS_UUID=1BF5-7E28
ID_FS_UUID_ENC=1BF5-7E28
ID_FS_VERSION=FAT32
ID_FS_TYPE=vfat
ID_FS_USAGE=filesystem
ID_IOLIMIT_MINIMUM_IO_SIZE=512
ID_IOLIMIT_PHYSICAL_SECTOR_SIZE=512
ID_IOLIMIT_LOGICAL_SECTOR_SIZE=512
ID_PART_ENTRY_SCHEME=gpt
ID_PART_ENTRY_NAME=EFI_SYSTEM_PART
ID_PART_ENTRY_UUID=ed5cd10c-939a-49c1-ae67-b7f2a76949dd
ID_PART_ENTRY_TYPE=c12a7328-f81f-11d2-ba4b-00a0c93ec93b
ID_PART_ENTRY_NUMBER=1
ID_PART_ENTRY_OFFSET=2048
ID_PART_ENTRY_SIZE=819200
ID_PART_ENTRY_DISK=8:0

 

This is util-linux blkid, not e2fsprogs one. See http://git.kernel.org/?p=linux/hotplug/ude...0e25f0d8923d302 .

 

I am using udev-171 and util-linux-2.19 .

 

Also

 

   # Find partition number & whole-disk device node
  partNum=`udevadm info -q property -n $targetPart | grep UDISKS_PARTITION_NUMBER | cut -f 2 -d "="`
  echo "Partition number is $partNum"
  sysfsPath=`udevadm info -q property -n $targetPart | grep UDISKS_PARTITION_SLAVE | cut -f 2 -d "="`
  targetDiskNode=`cat $sysfsPath/uevent | grep DEVNAME | cut -f 2 -d "="`
  targetDisk="/dev/$targetDiskNode"
  echo "Target disk (for storing MBR boot code) is $targetDisk"

  # Find offset to partition
  partStartSector=`cat $sysfsPath/$targetDiskNode$partNum/start`

 

udevadm info -q property -n $targetPart | grep UDISKS returns only

 

keshav_pr@my-comp ~ % udevadm info -q property -n /dev/sda | grep -i UDISKS
UDISKS_PRESENTATION_NOPOLICY=0
UDISKS_ATA_SMART_IS_AVAILABLE=1
keshav_pr@my-comp ~ % udevadm info -q property -n /dev/sda1 | grep -i UDISKS
UDISKS_PRESENTATION_NOPOLICY=0

 

So obviously there is no UDISKS_PARTITION_SLAVE etc.

 

Also I only host Efildr20 (FAT32 specific file) in EFI_DUET. How will it work with BootDuet in FAT12/FAT16 even if you rename the files to EFILDR or EFILDR16 respectively?

[srs5694]

I actually renamed the EDK2_X64 to UDK_X64 to follow upstream naming (http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome). I suggest people use the copy_duet_files.sh script in EFI_DUET dir instead of copying the files in duet-install.sh . You can also call the copy_duet_files script within duet-install.sh .

 

OK. I was working from a 6-day-old version that didn't include the copy_duet_files.sh script. One issue is that I see no way to specify the *_FSVariable variants of Efildr20 with that script. Since you say later that this version has limited appeal, though, it might not be a great loss.

 

1) Is it possible for you to host this script in a git repo somewhere with version history?

 

Possible? Certainly. Will I do it? I'm not sure. For me, this was a relatively quick hack, and I'm not sure I want to put a lot of effort into maintaining it over time.

 

2) Please do not use UEFI 2.1 and UEFI 2.3 as options for Efildr. Use EDK_UEFI64 and UDK_X64 .

 

Why? The problem with those names is that they're completely unclear as to which one is more recent. Somebody who's as immersed in UEFI DUET as you are no doubt knows the difference, but for everybody else, "2.1" and "2.3" are much more intuitive.

 

3) Many stuff like fatBitness=`file -s $targetPart | sed 's/FAT (/\nFAT /' | grep bit | sed 's/)/\n/' | grep bit | sed 's/FAT //' | sed 's/ bit//'` (line 145)

 

can be done by

 

keshav_pr@my-comp ~ % blkid -p -i -o udev /dev/sda1

 

That might be a bit neater and possibly more reliable. I'll look into it.

 

This is util-linux blkid, not e2fsprogs one.

 

That could be an issue, though, if the e2fsprogs version is likely to be installed in some common environment.

 

udevadm info -q property -n $targetPart | grep UDISKS returns only

 

I was afraid the udevadm stuff might break on some distributions. I was using it in an effort to avoid assumptions about device names, but maybe it would be better to do that -- assume a device name in the form /dev/[sh]d?##, and work from that....

 

Also I only host Efildr20 (FAT32 specific file) in EFI_DUET. How will it work with BootDuet in FAT12/FAT16 even if you rename the files to EFILDR or EFILDR16 respectively?

 

It's worked fine in my tests, although I've only tried FAT12 a couple of times. FAT16 is much more common because I've been testing with 100-200MiB partitions (typical sizes for EFI System Partitions), and mkdosfs uses FAT16 on partitions of that size by default.

 

What is it about those files that's filesystem-specific? That is, is there something about how they begin to load themselves that makes assumptions about the filesystem, or do they assume they're running from a particular filesystem after they've been booted, or what? If you think problems are likely to result, even on some systems, from using a FAT32-specific build on a FAT16 filesystem, I recommend building both (and FAT12, too, for completeness), since it's hard to guarantee that the target filesystem will use a particular FAT level.

[Keshav Amburay]

OK. I was working from a 6-day-old version that didn't include the copy_duet_files.sh script. One issue is that I see no way to specify the *_FSVariable variants of Efildr20 with that script. Since you say later that this version has limited appeal, though, it might not be a great loss.

 

Actually I made those changes locally in my system and pushed it only yesterday.

 

Possible? Certainly. Will I do it? I'm not sure. For me, this was a relatively quick hack, and I'm not sure I want to put a lot of effort into maintaining it over time.

 

Its just that I prefer to have a version history, both for viewing how the script has evolved and to revert any changes made whenever necessary.

 

Why? The problem with those names is that they're completely unclear as to which one is more recent. Somebody who's as immersed in UEFI DUET as you are no doubt knows the difference, but for everybody else, "2.1" and "2.3" are much more intuitive.

 

The 2.3 won't stay 2.3 forever. But its your call. AFAIK there is no noticable difference between the 2.1 and 2.3 firmwares except when AHCI and USB keyboards are involved.

 

That could be an issue, though, if the e2fsprogs version is likely to be installed in some common environment.

 

The e2fsprogs blkid has been deprecated by e2fsprogs devs a long time back. Although I use Archlinux which is rolling release with always the recent version in the repos, I don't think even Debian users will need to bother about blkid.

 

It's worked fine in my tests, although I've only tried FAT12 a couple of times. FAT16 is much more common because I've been testing with 100-200MiB partitions (typical sizes for EFI System Partitions), and mkdosfs uses FAT16 on partitions of that size by default.

 

You can explicitely specify mkfs.vfat -F32 or -F16 to define the FAT bitness.

 

What is it about those files that's filesystem-specific? That is, is there something about how they begin to load themselves that makes assumptions about the filesystem, or do they assume they're running from a particular filesystem after they've been booted, or what? If you think problems are likely to result, even on some systems, from using a FAT32-specific build on a FAT16 filesystem, I recommend building both (and FAT12, too, for completeness), since it's hard to guarantee that the target filesystem will use a particular FAT level.

 

The EDK and EDK2 build system create 3 firmware files Efildr (FAT12 - mainly for floppy or the memdisk image), Efildr16 (FAT16) and Elildr20 (FAT32). I copy only the Efildr20 compiled file to the EFI_DUET git repo. This link https://github.com/migle/BootDuet/blob/master/README explains clearly how the three files are setup. I suppose when it comes to BootDuet, any file can work with any FAT fs (haven't tested this myself).