Linux and Windows UEFI boot using Tianocore DUET firmware

[Keshav Amburay]

Thanks for your fast reply

I didn't try to boot DUET from HDD either.

I know Chameleon or PCEFI 10.6 can be installed on HDD without hassle but for my experiment I'm using my pendive .

No, sadly I'm not a programmer so I'm stuck with the DUET pendrive. Speaking of that, yesterday I made an acronis image backup of Win7 partition with it's "plus pack" for GPT HDDs. Perhaps just a coincidence, since then I can't boot into Win7 anymore .

In UEFI menu I can't find anymore my HDD's EFI in device list, just the EFI_DUET and EFI SECTOR of my DVD. So no way to "boot from file" -> bootmgfw.efi.

Any idea for solving this problem? Here's what I tried, to no avail:

- boot recovery from Win7 install DVD

- From Linux, deleted and recreated EFI partition with gdisk with the correct type : ef00 . then copied the necessary files in their original folders.

 

The only 2 possible problems I can think of now is either the SATA mode in the BIOS is set to AHCI or the filesystem in the EFI System Partition in corrupted or is not FAT32. If thats the case, either use efifmt.efi file in the DUET pendrive or

 

mkfs.vfat -F32 <efisys-part> in linux to format the partition to FAT32 and then copy the original contents back. I don't know anything about the backup software you mentioned so I cant correctly guess what went wrong.

 

My idea is -

 

1) From Linux, delete and recreate EFI partition with gdisk with the correct type : ef00 .

 

2) sudo mkfs.vfat -F32 <efisys-part>

 

3) Mount the partition and then copy the original files in their original folders.

 

4) Boot from Windows Install DVD from DUET and check for any start-up errors.

[heliox]

More on my troubleshooting:

Of course I've already tried the steps you suggested and more. I even reinstalled Windows.

All I could get back was the ability to "boot from file". But I kept getting this message, when I chose "<EFI_SYSTEM_PARTITION>/efi/microsoft/boot/bootmgrfw.efi":

Status: 0xc0000225

Info: The boot selection failed because a required device is inaccessible.

Finally solved the issue by disconnecting my second hard disk (MBR). Weird

[squallmat]

Hello everybody, i was searching for informations to install MacOS on my PC and after many research hours i found this interesting topic, first i have some questions :

1) Not counting the number of partitions, what are the benefits to install Mac on a GPT_HDD over a MBR_HDD ? (in terms of installation-ease, upgrading the OS after, etc...)

2) I've seen many infos/posts about "Hybrid MBR-GPT", a non traditional configuration. But if GPT is retrocompatible with MBR, then any "pure GPT" is a potential Hybrid configuration right ?

3) The emulated EFI DUET is used only to boot the OSes ? Or is there a "definitive replacement" of the BIOS by the EFI in the point of view of the OSes ?

I think it's the second proposition that is true.

But if it's that, there are possible regression right ? (not only for the AHCI mode)

For example :

if the BIOS implement USB 3, if the OS implement USB 3, then i can use USB 3 on a "normal" configuration. But if i now use EFI DUET to launch this OS now installed on a GPT disk, and assume that DUET don't implement USB 3 then USB 3 will not be usable ?

 

 

I will try to contribute to the discussion, but it's important to note that i've never tried to use EFI DUET, use a GPT_HDD and install Mac on a PC for the moment :

 

The person who have installed the EFI DUET on the HDD, have probably a "hybrid" configuration.

I don't think that there is another way to install it on the HDD, it have to be put in a partition that can be booted from the BIOS (like a USB drive).

There is a possibility to install the EFI DUET on another HDD, but it would make the GPT_HDD totally dependent of this one, this is not really a "solution".

 

But i was thinking about an idea that i don't know if it's possible :

We have to put the partition with UEFI DUET on a MBR-bootable partition on the disk. But if we configure a GPT_HDD with this idea we have to make attention to not alter this MBR partition by any GPT-scheme reconfiguration.

So, is there a way in the GPT scheme to definitely define a zone of the HDD (the zone corresponding of the MBR-defined partition with DUET) to be "inalterable" ?

So in other words, is there a way in a "hybrid configuration" to protect the MBR partitions from any GPT alteration (resizing, etc...) ?

 

some other questions :

Is there another way to have more than 4 active partitions ?

Is it possible to boot windows on an extended partition ? (maybe with grub or a dedicated boot loader)

[Keshav Amburay]

Hello everybody, i was searching for informations to install MacOS on my PC and after many research hours i found this interesting topic, first i have some questions :

1) Not counting the number of partitions, what are the benefits to install Mac on a GPT_HDD over a MBR_HDD ? (in terms of installation-ease, upgrading the OS after, etc...)

 

I think using GPT over MBR will ease OS upgrades in Mac (the installer/setup will not complain).

 

2) I've seen many infos/posts about "Hybrid MBR-GPT", a non traditional configuration. But if GPT is retrocompatible with MBR, then any "pure GPT" is a potential Hybrid configuration right ?

 

Pure GPT includes a 0xEF type MBR partition spanning the entire disk that shows disk utilities that do not understand GPT, that the disk is in use and not to be modified preventing partition table modification.

 

3) The emulated EFI DUET is used only to boot the OSes ? Or is there a "definitive replacement" of the BIOS by the EFI in the point of view of the OSes ?

 

The EFI DUET is a full UEFI firmware implementation minus the motherboard specific code (thats why chainloading from BIOS is needed).

 

I think it's the second proposition that is true.

But if it's that, there are possible regression right ? (not only for the AHCI mode)

For example :

if the BIOS implement USB 3, if the OS implement USB 3, then i can use USB 3 on a "normal" configuration. But if i now use EFI DUET to launch this OS now installed on a GPT disk, and assume that DUET don't implement USB 3 then USB 3 will not be usable ?

 

If there is support for newer hardware like USB 3 in BIOS and OS but not in DUET, you wont be able to boot the OS from USB 3 using DUET. Thats the same case with AHCI, both bios and windows support AHCI but DUET does not, so Windows boots in IDE mode in UEFI-GPT configuration.

 

The person who have installed the EFI DUET on the HDD, have probably a "hybrid" configuration.

I don't think that there is another way to install it on the HDD, it have to be put in a partition that can be booted from the BIOS (like a USB drive).

There is a possibility to install the EFI DUET on another HDD, but it would make the GPT_HDD totally dependent of this one, this is not really a "solution".

 

Read the second post of this topic, it is possible to boot DUET from a ramdisk/memdisk (emulated DUET floppy image) using memdisk module from syslinux. No need for a Hybrid MBR-GPT configuration to boot DUET from HDD.

 

But i was thinking about an idea that i don't know if it's possible :

We have to put the partition with UEFI DUET on a MBR-bootable partition on the disk. But if we configure a GPT_HDD with this idea we have to make attention to not alter this MBR partition by any GPT-scheme reconfiguration.

So, is there a way in the GPT scheme to definitely define a zone of the HDD (the zone corresponding of the MBR-defined partition with DUET) to be "inalterable" ?

So in other words, is there a way in a "hybrid configuration" to protect the MBR partitions from any GPT alteration (resizing, etc...) ?

 

There is no way to prevent GPT utilities from modifying hybrid configurations. It is also not possible to have more that 4 primary partitions in MBR setup. Even in case of hybrid setup, windows follows the MBR so there is no way you can go with many GPT partitions with any 3 of them in a hybrid setup.

 

some other questions :

Is there another way to have more than 4 active partitions ?

Is it possible to boot windows on an extended partition ? (maybe with grub or a dedicated boot loader)

 

It is possible to boot Windows in BIOS-MBR from a extended-logical partition as long as you have another 100-200 MB NTFS partition marked as active (or boot flag in parted) and make windows use that partition as the system partition.

Edited September 26, 2010 by Keshav

[squallmat]

Hello Keshav, thanks for the reply.

 

 

Pure GPT includes a 0xEF type MBR partition spanning the entire disk that shows disk utilities that do not understand GPT, that the disk is in use and not to be modified preventing partition table modification.

 

There is no way to prevent GPT utilities from modifying hybrid configurations.

 

Maybe i mistaken (my english is far to be perfect) but it seems you contradict yourself ?

Or i don't understand well the system.

 

 

The EFI DUET is a full UEFI firmware implementation minus the motherboard specific code (thats why chainloading from BIOS is needed).

 

Even in case of hybrid setup, windows follows the MBR so there is no way you can go with many GPT partitions with any 3 of them in a hybrid setup.

 

I was saying that there would be only one partition accessible by BIOS. This partition contains the UEFI DUET. Windows is installed in a GPT-referenced only partition.

So :

boot -> BIOS -> "chainload" -> partition 1 MBR -> "DUETloading" -> access to GPT partition (like windows).

 

 

If there is support for newer hardware like USB 3 in BIOS and OS but not in DUET, you wont be able to boot the OS from USB 3 using DUET. Thats the same case with AHCI, both bios and windows support AHCI but DUET does not, so Windows boots in IDE mode in UEFI-GPT configuration.

 

I used USB 3 for an example to technology usable by your installed OSes, i was not saying i would like to use an USB 3 to put DUET on him.

I am just questioning about the technologies that needs to be implemented not only in the operating system but also in the BIOS/EFI to be usable like USB ports.

Imagine i have my windows installed on a GPT_HDD, windows is launched : if my old BIOS was implementing USB 3.0 but not the UEFI DUET, i cannot use anymore the USB 3 technology in this windows, right ? (or i mistaken )

 

To extend the question. A BIOS is generally optimised for each motherboard model, i think this should be the same for EFI. Is there a list of compatibilities, differences between the MB/chipset that you have on your motherboard ? (example : Maybe used with an AMD chipset there would be some problems like parts of USB ports not functional, etc...)

 

 

Read the second post of this topic, it is possible to boot DUET from a ramdisk/memdisk (emulated DUET floppy image) using memdisk module from syslinux. No need for a Hybrid MBR-GPT configuration to boot DUET from HDD.

 

I just discovered the memdisk, and from what i've read it's sort of a "iso" of a system anywhere in a partition, that can be booted with a bootloader compatible like grub.

But maybe i'm completely wrong. Is that a memdisk ?

If yes, then to boot the UEFI, there is need to be a BIOS-accessible zone on the HDD to then "switch to EFI", no ?

 

 

It is possible to boot Windows in BIOS-MBR from a extended-logical partition as long as you have another 100-200 MB NTFS partition marked as active (or boot flag in parted) and make windows use that partition as the system partition.

 

I don't understand, if there is a need to have a primary partition with the "system".. that means that you have to install windows on a primary partition. So, it is not possible to install windows on

a extended partition.

 

 

 

PS : i'm new to GPT/EFI/Hackintosh, so if you can be very explicit in your answer that would help me

[srs5694]

1) Not counting the number of partitions, what are the benefits to install Mac on a GPT_HDD over a MBR_HDD ? (in terms of installation-ease, upgrading the OS after, etc...)

 

OS X assumes GPT, and some features don't work on MBR. You can't resize an HFS+ partition on an MBR disk using Disk Utility, for instance (at least, not AFAIK). Also (and again, AFAIK), a stock OS X 10.6 installer won't install directly to an MBR disk, although there are ways around this, and some Hackintosh "distributions" employ them by default. There are also all the usual advantages of GPT over MBR. The biggest of these is that GPT supports larger disks -- MBR tops out at 2 TiB, assuming the usual 512-byte sector size. Other advantages include a partition name, duplicates of the important GPT data structures as a hedge against disk errors, CRCs of the GPT data structures to help OSes and utilities detect disk errors, and the complete lack of the annoying primary/extended/logical partition distinction.

 

2) I've seen many infos/posts about "Hybrid MBR-GPT", a non traditional configuration. But if GPT is retrocompatible with MBR, then any "pure GPT" is a potential Hybrid configuration right ?

 

No. A pure GPT configuration includes a "protective MBR," which is an MBR data structure that contains a single type-0xEE partition (not type-0xEF, as Keshav stated; that's either a typo or confusion with the MBR's EFI System partition type code) that spans the whole disk. This is spelled out in great detail in the GPT specification, which is part of the EFI specification.

 

A hybrid MBR is a corruption of a GPT protective partition that shrinks the type-0xEE protective partition and adds from one to three more partitions in the remaining MBR primary partition slots. These partitions correspond to up to three GPT partitions, in terms of their locations on the disk. Hybrid MBRs violate the GPT specification. They're ugly and dangerous. Consider what happens when a user tries to resize an existing partition on a hybrid MBR. If the user employs a GPT-unaware partitioning tool, the MBR partition definition will be resized, but the GPT partition definition won't be. This will lead to trouble, possibly up to and including irrecoverable data loss. The same thing can happen if the disk utility is GPT-aware but doesn't understand hybrid MBRs.

 

if the BIOS implement USB 3, if the OS implement USB 3, then i can use USB 3 on a "normal" configuration. But if i now use EFI DUET to launch this OS now installed on a GPT disk, and assume that DUET don't implement USB 3 then USB 3 will not be usable ?

 

I'm not an expert on this, but I believe it depends on how the drivers are implemented in the OS. Most OSes do not rely on the BIOS for access to hardware. In some cases the BIOS may initialize the hardware or provide hooks that the OS's drivers can use to help get started, but there are certainly hardware devices that aren't supported in the BIOS but that get used fine anyhow. Examples include certain PCI Ethernet and SCSI cards.

 

The person who have installed the EFI DUET on the HDD, have probably a "hybrid" configuration.

I don't think that there is another way to install it on the HDD, it have to be put in a partition that can be booted from the BIOS (like a USB drive).

 

You're working under a false assumption, namely that the BIOS needs to understand the partitioning system. It doesn't. I've got several BIOS-based computers that boot just fine from pure-GPT configurations. In fact, I'm typing this on one. Hackintoshes can be configured this way, and so can Linux, FreeBSD, and probably others. Among major modern OSes, only Windows lags behind on this score; its boot loaders don't support GPT on BIOS hardware.

 

As further background, the BIOS boot procedure involves the BIOS reading the boot loader code from sector 0 of the hard disk or other bootable medium. (This is where the MBR resides, but the BIOS need not interpret the MBR partition table; it's just after the boot loader code.) The BIOS executes the boot loader code, which is then in charge of what happens next. The boot loader code may interpret the partition table or just load sectors from some location on the disk that's been computed and inserted into the code when the boot loader was installed. Either way, this is outside of the BIOS's control, except insofar as the boot loader uses the BIOS to read disk sectors -- but the boot loader tells the BIOS to get data by sector number, without reference to the partitions involved.

 

That said, some buggy BIOSes do seem to try to interpret the MBR partitions. Some Intel boards won't boot unless an MBR partition is flagged as being bootable, for instance. This, however, is a bug, not a feature.

 

So, is there a way in the GPT scheme to definitely define a zone of the HDD (the zone corresponding of the MBR-defined partition with DUET) to be "inalterable" ?

So in other words, is there a way in a "hybrid configuration" to protect the MBR partitions from any GPT alteration (resizing, etc...) ?

 

No. Anything you do to a partition can be undone, at least in principle. We're talking about data stored on a hard disk, after all, and every sector of a hard disk can be altered.

 

Is there another way to have more than 4 active partitions ?

 

In MBR terminology, an "active" partition is one with a particular flag set, which tells certain boot loaders to boot that partition. This is also known as the "boot flag." You're only supposed to have one partition with this flag set, although there's nothing in the data structures to prevent you from setting it on multiple partitions. Likewise, only primary partitions are supposed to be flagged in this way, although the data structures exist to flag logical partitions as active. Thus, the blindly literal answer to your question is that you just need a utility to flag as many partitions as active as you like. That's not what you meant, though; I suspect you meant "is there another way to have more than 4 primary partitions," and the answer to that is "no," albeit with some hedges. There have been MBR variants that support more than four primary partitions; however, these MBR variants aren't widely supported today. Also, there have been boot loaders that support storing data on more than four primary partitions and then swapping those partitions in and out of the MBR when the user chooses which OS to boot. Thus, for OS A, partitions 1, 3, 4, and 6 might be available; but in OS B, partitions 1, 2, 5, and 6 might be available. I've never used a boot loader like this, and AFAIK none of them is currently popular. (I heard about these roughly ten years ago, when DOS and Windows 9x/Me were current.)

 

Is it possible to boot windows on an extended partition ? (maybe with grub or a dedicated boot loader)

 

First, an extended partition is a special type of primary partition that holds logical partitions. You can't store any OS directly on an extended partition, although OSes can use the logical partitions contained in extended partitions.

 

You can store the bulk of Windows on a logical partition; however, AFAIK such configurations all require a primary partition to hold certain critical boot files. It's possible for two or more Windows installations to share a primary partition for this purpose, with each having its own logical partition.

[Keshav Amburay]

Hello Keshav, thanks for the reply. Maybe i mistaken (my english is far to be perfect) but it seems you contradict yourself ?

Or i don't understand well the system.

 

What I meant is the 0xEE (0xEF was a typo) type MBR entry prevents non-GPT partitioning utilities from modifying the drive but it is not possible to prevent GPT understanding utilities from modifying hybrid configurations (example - GNU Parted and GParted).

 

I was saying that there would be only one partition accessible by BIOS. This partition contains the UEFI DUET. Windows is installed in a GPT-referenced only partition.

So :

boot -> BIOS -> "chainload" -> partition 1 MBR -> "DUETloading" -> access to GPT partition (like windows).

 

The above method is not possible. I tried it many times. There is some problem n DUET bootsectors that prevent booting from a HDD.

 

Currently I boot in this sequence

 

Power on -> GRUB2 (Pure GPT - using BIOS Boot Partition) -> memdisk module (from syslinux) -> DUET floppy image dump emulated as a real floppy disk by the memdisk module -> DUET loading -> bootmgfw.efi -> Windows 7 x64 Pro in UEFI-GPT

 

No hybrid mbr is involved in my system nor is any usb flash drive.

 

I used USB 3 for an example to technology usable by your installed OSes, i was not saying i would like to use an USB 3 to put DUET on him.

I am just questioning about the technologies that needs to be implemented not only in the operating system but also in the BIOS/EFI to be usable like USB ports.

Imagine i have my windows installed on a GPT_HDD, windows is launched : if my old BIOS was implementing USB 3.0 but not the UEFI DUET, i cannot use anymore the USB 3 technology in this windows, right ? (or i mistaken )

 

I knew that USB 3 was just an example. In ur example, if the Windows is not installed in the USB 3 drive in question, you can very well boot into Windows and access the USB 3 drive. But unless DUET implements USB 3, you cannot boot Windows from a USB 3 disk. But once booted, nothing stops you from accessing USB 3 drives as that support is independent of firmware. FOr the purpose of booting, the respective technology support is required in the UEFI firmware. After booting, the firmware is irrelevant and then it only depend on whether the OS detects the ports and has the drivers for those ports.

 

To extend the question. A BIOS is generally optimised for each motherboard model, i think this should be the same for EFI. Is there a list of compatibilities, differences between the MB/chipset that you have on your motherboard ? (example : Maybe used with an AMD chipset there would be some problems like parts of USB ports not functional, etc...)

 

I do not have any native UEFI system. My laptop (Dell Studio 1537) has only BIOS firmware. DUET is like UEFI wrapper for BIOS which allows UEFI boot of OSes. I started using UEFI/DUET only because I wanted to boot Windows in GPT without any ugly hybrid configs and thats why I stopped direct BIOS-MBR booting of Windows. But I still boot Archlinux x86_64 in BIOS-GPT (and UEFI-GPT also) using GRUB2.

 

I just discovered the memdisk, and from what i've read it's sort of a "iso" of a system anywhere in a partition, that can be booted with a bootloader compatible like grub.

But maybe i'm completely wrong. Is that a memdisk ?

If yes, then to boot the UEFI, there is need to be a BIOS-accessible zone on the HDD to then "switch to EFI", no ?

 

For info on memdisk go to http://syslinux.zytor.com/wiki/index.php/MEMDISK . Yes there is no need for a special BIOS-accessible zone the HDD. GRUB2 is a very good boot-loader that even surpasses many bios features.

 

I don't understand, if there is a need to have a primary partition with the "system".. that means that you have to install windows on a primary partition. So, it is not possible to install windows on

a extended partition.

 

You need to understand what is a SYSTEM partition (where bootmgr and BCD files are stored - similar to /boot in linux) and a BOOT partition (the partition which contains the actual Windows OS - similar to linux root '/' filesystem).

The BOOT partition can be an extended-logical partition, as long as a primary partition is designated as SYSTEM partition for the purpose of storing the bootmgr (Windows Boot Manager) files.

 

The whole confusion regarding Windows cannot be installed to as extended partition is due to the fact that people do not understand that there can be a separate SYSTEM partition independent of C: .

 

PS : i'm new to GPT/EFI/Hackintosh, so if you can be very explicit in your answer that would help me

 

It is not wrong to ask questions, but if you are unsure of what I mentioned in the previous posts, I suggest that you read wikipedia articles on GPT, UEFI, EFI SYSTEM PARTITION, BIOS BOOT PARTITION, SYSTEM AND BOOT PARTITION IN WINDOWS etc., before arriving at any conclusions. Rod Smith's (srs5694) gdisk page http://rodsbooks.com/gdisk/ also includes excellent GPT info.

[squallmat]

Hello srs5694 and keshav, thanks, now i understand better the "system".

 

OS X assumes GPT, and some features don't work on MBR. You can't resize an HFS+ partition on an MBR disk using Disk Utility, for instance (at least, not AFAIK). Also (and again, AFAIK), a stock OS X 10.6 installer won't install directly to an MBR disk, although there are ways around this, and some Hackintosh "distributions" employ them by default. There are also all the usual advantages of GPT over MBR. The biggest of these is that GPT supports larger disks -- MBR tops out at 2 TiB, assuming the usual 512-byte sector size. Other advantages include a partition name, duplicates of the important GPT data structures as a hedge against disk errors, CRCs of the GPT data structures to help OSes and utilities detect disk errors, and the complete lack of the annoying primary/extended/logical partition distinction.

 

Is Gnu Parted (or any other tool) able to modify HFS+ on MBR ?

The features that don't work on MBR are just features like Disk Utility (tools directly depending of the HDD), but there is no risk that other more or less important features not directly related to the HDD don't work, right ?

 

I'm not an expert on this, but I believe it depends on how the drivers are implemented in the OS. Most OSes do not rely on the BIOS for access to hardware. In some cases the BIOS may initialize the hardware or provide hooks that the OS's drivers can use to help get started, but there are certainly hardware devices that aren't supported in the BIOS but that get used fine anyhow. Examples include certain PCI Ethernet and SCSI cards.

 

So, there is no chance that there would be regressions in the OSes utilisation if they're booted by UEFI ?

This was my principle preoccupation, i don't want to use a lot of times to make a stable system using UEFI/GPT and see months after that even little regression on specific OS/functions.

 

In fact i have the intention to install 4 systems (for the moment):

- Win 7 x64

- Archlinux x64

- FreeBSD x64

- Snow Leopard

And of course after some resaerch on hackintoshes i seen many methods, and what i would is a Hackintosh that would work exactly like i had really a MAC.

 

You're working under a false assumption, namely that the BIOS needs to understand the partitioning system. It doesn't. I've got several BIOS-based computers that boot just fine from pure-GPT configurations. In fact, I'm typing this on one. Hackintoshes can be configured this way, and so can Linux, FreeBSD, and probably others. Among major modern OSes, only Windows lags behind on this score; its boot loaders don't support GPT on BIOS hardware.

 

That said, some buggy BIOSes do seem to try to interpret the MBR partitions. Some Intel boards won't boot unless an MBR partition is flagged as being bootable, for instance. This, however, is a bug, not a feature.

 

So, not all MB can BIOS-boot on a GPT config. Is there anywhere a list of compatibilities ?

Personnally i have an ASUS P5Q PRO, is it compatible ?

 

The above method is not possible. I tried it many times. There is some problem n DUET bootsectors that prevent booting from a HDD.

 

Currently I boot in this sequence

 

Power on -> GRUB2 (Pure GPT - using BIOS Boot Partition) -> memdisk module (from syslinux) -> DUET floppy image dump emulated as a real floppy disk by the memdisk module -> DUET loading -> bootmgfw.efi -> Windows 7 x64 Pro in UEFI-GPT

 

No hybrid mbr is involved in my system nor is any usb flash drive.

 

Grub2 (and even grub1) need to be configured. Even if Grub2 as implemented a system to detect systems and reconfigure himself.

- But EFI System partition contains all info in a dedicated partition, so is grub2 capable of detect automatically the systems present on the GPT_HDD ? There is no more need to reconfigure grub 2 ?

- Where is your grub2 installed ? i assume in archlinux. Is there a way to install it in a separate partition dedicated for himself ? (GPT can have 128 active partitions that's it ?)

 

For info on memdisk go to http://syslinux.zytor.com/wiki/index.php/MEMDISK . Yes there is no need for a special BIOS-accessible zone the HDD. GRUB2 is a very good boot-loader that even surpasses many bios features.

 

About the memdisk that was the page that i read (but not completely) but i'm not sure to 100% understand the "concept" (i have sometimes difficulties to understand english texts/wordings).

But from what i understood it's a simple and small image of a system to "extend" the BIOS features.

Memdisk (when emulating a HDD) is for the BIOS what a virtual HDD if for an OS. Is that ?

 

I knew that USB 3 was just an example. In ur example, if the Windows is not installed in the USB 3 drive in question, you can very well boot into Windows and access the USB 3 drive. But unless DUET implements USB 3, you cannot boot Windows from a USB 3 disk. But once booted, nothing stops you from accessing USB 3 drives as that support is independent of firmware. FOr the purpose of booting, the respective technology support is required in the UEFI firmware. After booting, the firmware is irrelevant and then it only depend on whether the OS detects the ports and has the drivers for those ports.

 

So, once the OS is launched, no matter from what (EFI or BIOS) the OS will be not even a little "different"

 

Related question, imagine i make a system like you. many OSes, all bootable by DUET, win and mac only by DUET, the others by grub directly also :

Is there a risk to alter the "stablity" of this configuration if i update (flash) my BIOS for a newer version ?

 

 

An important goal for me :

I would that Windows 7 to be the "default" OS : if i turn on my computer and leave for a moment, i would like to be on the desktop of windows 7 when i'm back. Is this achievable ?

[Keshav Amburay]

Most of the questions are directed to srs5694 so I leave it to him for the answers.

 

Hello srs5694 and keshav, thanks, now i understand better the "system".

 

Grub2 (and even grub1) need to be configured. Even if Grub2 as implemented a system to detect systems and reconfigure himself.

- But EFI System partition contains all info in a dedicated partition, so is grub2 capable of detect automatically the systems present on the GPT_HDD ? There is no more need to reconfigure grub 2 ?

- Where is your grub2 installed ? i assume in archlinux. Is there a way to install it in a separate partition dedicated for himself ? (GPT can have 128 active partitions that's it ?)

 

One grammatical error, it is "itself" not "himself" (used only when directed to a human male).

 

Grub1 (or grub legacy) cannot be used for BIOS-GPT boot as it does not make use of the BIOS Boot Partition. GRUB2 as a BIOS boot-loader uses BIOS Boot Partition and as a EFI app, uses EFI System Partition. My grub2 is installed in the Archlinux /boot partition, but not through the package manager as I compile the bzr development version quite often. It is possible to setup grub2 in a dedicated partition outside the control of all your installed OSes.

 

About the memdisk that was the page that i read (but not completely) but i'm not sure to 100% understand the "concept" (i have sometimes difficulties to understand english texts/wordings).

But from what i understood it's a simple and small image of a system to "extend" the BIOS features.

Memdisk (when emulating a HDD) is for the BIOS what a virtual HDD if for an OS. Is that ?

 

Yes memdisk is analogous to a Virtual HDD in an OS.

 

So, once the OS is launched, no matter from what (EFI or BIOS) the OS will be not even a little "different"

 

Related question, imagine i make a system like you. many OSes, all bootable by DUET, win and mac only by DUET, the others by grub directly also :

Is there a risk to alter the "stablity" of this configuration if i update (flash) my BIOS for a newer version ?

 

Flashing the bios is no way related to the way grub2 boots OSes as long as the bios performs its basic (read POST) functions correctly.

 

An important goal for me :

I would that Windows 7 to be the "default" OS : if i turn on my computer and leave for a moment, i would like to be on the desktop of windows 7 when i'm back. Is this achievable ?

 

Right now it is not possible to set Windows 7 to boot all by itself by just switching on the computer. Although such a system exists, it caused blue screen errors and kernel panics (in Linux). There is a problem with EFI Runtime Services in unmodified EDK2 DUET which is required to set default efi boot application. Right now the variables are volatile (ie reside only in memory). If you want such a system you need to use EDK1 DUET UEFI64 firmware (not EDK2 DuetPkg X64 firmware). If you are adventurous, use the script at http://github.com/skodabenz/Tianocore_DUET_X64_memdisk to create a new ramdisk image with EDK1 DUET instead of EDK2 DUET. Happy Hacking.

[srs5694]

I started using UEFI/DUET only because I wanted to boot Windows in GPT without any ugly hybrid configs and thats why I stopped direct BIOS-MBR booting of Windows. But I still boot Archlinux x86_64 in BIOS-GPT (and UEFI-GPT also) using GRUB2.

 

FWIW, I've been seeing more and more problems posted about hybrid MBR configurations. Ubuntu's Apple Users subforum gets a new post every couple of days from somebody who has problems because some utility (I think something included with rEFIt) has a bug that produces bad hybrid MBRs. I really wish that Microsoft provided better GPT support in Windows, and/or that Apple had found a better way around the incompatibilities for its Boot Camp. Your approach is promising; I just wish it were easier to set up and use!

 

Is Gnu Parted (or any other tool) able to modify HFS+ on MBR ?

 

Yes; however, Parted is only able to shrink HFS+ partitions, not grow them. (Or maybe it's the other way around; I don't recall offhand.) I'm also a little bit wary, on principle of using cross-OS tools for partition resizing.

 

The features that don't work on MBR are just features like Disk Utility (tools directly depending of the HDD), but there is no risk that other more or less important features not directly related to the HDD don't work, right ?

 

I'm not entirely sure what you mean by this. If you mean that the filesystem itself will work on MBR, then yes, it will. It's a question of OS installation and partition/filesystem manipulations (resizing, etc.) being problematic.

 

So, there is no chance that there would be regressions in the OSes utilisation if they're booted by UEFI ?

 

There's a saying: "never say never." I can't promise that no driver will ever flake out if you use a (U)EFI boot. As Keshav is the one who's done this with Windows, he can probably better answer questions on this topic, though.

 

In fact i have the intention to install 4 systems (for the moment):

- Win 7 x64

- Archlinux x64

- FreeBSD x64

- Snow Leopard

 

Of those OSes, only Windows will give real problems booting from GPT, so you'll need either a hybrid MBR or some sort of (U)EFI workaround. I'm not sure what the current state of FreeBSD installation to GPT is, though. The last time I tried it, I had to jump through some extra hoops; see my Booting from GPT page for details.

 

Given that many OSes, I'd say your best option, if it's practical, is to use two disks. Put Windows 7 on one, using MBR; put OS X on the other, using GPT; and put Linux and FreeBSD on whichever is more convenient, since they can both handle both systems equally well.

 

And of course after some resaerch on hackintoshes i seen many methods, and what i would is a Hackintosh that would work exactly like i had really a MAC.

 

That's an impossible goal. You can get very close in terms of day-to-day operations, but in my experience, installation, upgrades, and some other mostly low-level functions won't be quite identical.

 

So, not all MB can BIOS-boot on a GPT config. Is there anywhere a list of compatibilities ?

Personnally i have an ASUS P5Q PRO, is it compatible ?

 

I don't know of any BIOS-based motherboard that can't be made to work; it's just that some require workarounds to do it, as detailed on my Legacy BIOS Issues with GPT page. That said, I've not tried every computer or motherboard in existence. It's entirely possible that there's a BIOS out there that's so buggy it can't boot from GPT. If so, though, I don't know what it is.

 

- But EFI System partition contains all info in a dedicated partition, so is grub2 capable of detect automatically the systems present on the GPT_HDD ? There is no more need to reconfigure grub 2 ?

 

To the best of my knowledge, GRUB 2 needs to be configured prior to its boot time; that is, it can't autodetect your OSes when it boots. That said, most Linux distributions that ship with GRUB 2 include scripts that perform such detection operations, so if everything works as intended, you'll get a reasonable boot menu once you install GRUB 2, after you upgrade a kernel, or after you run a reconfigure script in Linux.

 

So, once the OS is launched, no matter from what (EFI or BIOS) the OS will be not even a little "different"

 

Ideally and at a high level, yes; however, there are some subtle internal differences between BIOS-based and EFI-based installations.

 

Grub1 (or grub legacy) cannot be used for BIOS-GPT boot as it does not make use of the BIOS Boot Partition.

 

This is true of a "stock" GRUB Legacy; however, there are patched versions of GRUB Legacy that work fine with GPT disks. Many, but not all, Linux distributions ship with these patched versions of GRUB Legacy.

 

That said, it's probably safest to use GRUB 2 rather than GRUB Legacy when booting a GPT disk. This will eliminate the risk that an "update" to GRUB will eliminate the GPT patches because of an error or intentional decision by the package maintainer.

[Keshav Amburay]

FWIW, I've been seeing more and more problems posted about hybrid MBR configurations. Ubuntu's Apple Users subforum gets a new post every couple of days from somebody who has problems because some utility (I think something included with rEFIt) has a bug that produces bad hybrid MBRs. I really wish that Microsoft provided better GPT support in Windows, and/or that Apple had found a better way around the incompatibilities for its Boot Camp. Your approach is promising; I just wish it were easier to set up and use!

 

It is now easier to setup. You can see the second post of this topic for the links and if it is difficult to setup a bootable DUET USB drive, you can use the ramdisk that I have uploaded in the same link using grub2 linux16 and initrd16 command.

 

There's a saying: "never say never." I can't promise that no driver will ever flake out if you use a (U)EFI boot. As Keshav is the one who's done this with Windows, he can probably better answer questions on this topic, though.

 

I have seen no problems as far as Windows drivers are concerned. The only problem is that one might be forced to use IDE or Legacy SATA mode instead of AHCI and lose the additional advantages.

 

Of those OSes, only Windows will give real problems booting from GPT, so you'll need either a hybrid MBR or some sort of (U)EFI workaround. I'm not sure what the current state of FreeBSD installation to GPT is, though. The last time I tried it, I had to jump through some extra hoops; see my Booting from GPT page for details.

 

Can you try the updated Efildr binaries (use EDK2 DUET X64, not EDK DUET UEFI64) and tell me the issues you have if any?

 

Ideally and at a high level, yes; however, there are some subtle internal differences between BIOS-based and EFI-based installations.

 

The difference lies in how the boot-loader is setup, which partitions are used and the booting method. For example BIOS-MBR Windows boot involves 440 byte MBR boot code and the bootmgr etc. UEFI-GPT boot does not involve any boot-sectors or hidden sectors at all. It involves a simple efi app so it is easy to manage and manipulate.

 

This is true of a "stock" GRUB Legacy; however, there are patched versions of GRUB Legacy that work fine with GPT disks. Many, but not all, Linux distributions ship with these patched versions of GRUB Legacy.

 

That said, it's probably safest to use GRUB 2 rather than GRUB Legacy when booting a GPT disk. This will eliminate the risk that an "update" to GRUB will eliminate the GPT patches because of an error or intentional decision by the package maintainer.

 

I have heard of the GPT patches leading to boot failure in many systems. Archlinux also included the GPT patch but it has now been removed due to some file access problems (File not found and such errors).

[squallmat]

Hello, first thank you keshav and srs, thanks to this post i learned many things on GPT/... in few days.

 

One grammatical error, it is "itself" not "himself" (used only when directed to a human male).

 

thx

 

Right now it is not possible to set Windows 7 to boot all by itself by just switching on the computer. Although such a system exists, it caused blue screen errors and kernel panics (in Linux). There is a problem with EFI Runtime Services in unmodified EDK2 DUET which is required to set default efi boot application. Right now the variables are volatile (ie reside only in memory). If you want such a system you need to use EDK1 DUET UEFI64 firmware (not EDK2 DuetPkg X64 firmware). If you are adventurous, use the script at http://github.com/skodabenz/Tianocore_DUET_X64_memdisk to create a new ramdisk image with EDK1 DUET instead of EDK2 DUET. Happy Hacking.

 

I assume using the version 1 will see a lot of regressions than using the version 2.

There is no version EDK2.0.1 fixing this bug ?

If this is just a problem of implementation, maybe i can see the source code (i am developer).

 

Another, maybe really stupid, question : these EDK1 DUET UEFI64 firmware and EDK2 DuetPkg X64 firmware, can they boot 32 bits OSes ?

 

Yes; however, Parted is only able to shrink HFS+ partitions, not grow them. (Or maybe it's the other way around; I don't recall offhand.) I'm also a little bit wary, on principle of using cross-OS tools for partition resizing.

 

I assume that when you have so many differents file systems on a same HDD, whatever the tool used it's very risky to move/... any of them.

 

To the best of my knowledge, GRUB 2 needs to be configured prior to its boot time; that is, it can't autodetect your OSes when it boots. That said, most Linux distributions that ship with GRUB 2 include scripts that perform such detection operations, so if everything works as intended, you'll get a reasonable boot menu once you install GRUB 2, after you upgrade a kernel, or after you run a reconfigure script in Linux.

 

I was assuming, that when grub2 is loaded, it could be able to see the EFI System Partition and then propose an "auto-menu" extra to the traditional script-generated menu.

I don't see this impossible, but maybe it's just an option that nobody know, or even it's just not implemented yet.

(I'm personnaly still using Grub Legacy)

 

 

 

I'll buy a HDD, i'll try the UEFI system when i'll have the time (maybe this week-end).

I'll share the results here.

[squallmat]

Hello, no more responses ?

 

 

I've not received my HDD yet, so i have to report my tests to the next week

 

 

Anyway, some other questions :

i read this page "http://rodsbooks.com/gdisk/whygdisk.html" and i would like to know what do you think about gparted/gdisk today ?

gparted has evolved and fixed these problems with GPT ?

 

About this table : "http://gparted.sourceforge.net/features.php"

These features/compatibilities are for MBR and GPT disks ? Or are there limitations with GPT disks ?

[srs5694]

Another, maybe really stupid, question : these EDK1 DUET UEFI64 firmware and EDK2 DuetPkg X64 firmware, can they boot 32 bits OSes ?

 

I'm a little foggy on this myself, but my limited understanding is that the firmware normally boots an OS of like-bitness. I don't know if a boot loader can theoretically work around the limitation, or if any current boot loaders do.

 

I was assuming, that when grub2 is loaded, it could be able to see the EFI System Partition and then propose an "auto-menu" extra to the traditional script-generated menu.

I don't see this impossible, but maybe it's just an option that nobody know, or even it's just not implemented yet.

 

AFAIK, GRUB 2 can't do this. AFAIK, it's theoretically possible, but GRUB 2, like GRUB, is pretty wedded to its own configuration files.

 

i read this page "http://rodsbooks.com/gdisk/whygdisk.html" and i would like to know what do you think about gparted/gdisk today ?

gparted has evolved and fixed these problems with GPT ?

 

Some of the libparted problems have been fixed; for instance, the latest versions don't mark FAT partitions with the wrong partition type codes. It's still got a lot of limitations, though. For instance, you can't mark an arbitrary partition type code by GUID; it doesn't directly report the partition type code GUIDs (it reports the filesystem type and then some type codes get reported as "flags"); it has no hybrid MBR features; it can't convert between partition table types (except destructively); it doesn't work with partition tables that have anything but 128 entries; and it can't edit partition attribute flags (confusingly, it uses the word "flags" to refer to certain partition type codes). Broadly speaking, libparted tries to present GPT disks using libparted's own model of what partitions are, even though the fit isn't perfect. This results in some awkwardness, like reporting some partition type codes as "flags" and not reporting others directly at all.

 

About this table : "http://gparted.sourceforge.net/features.php"

These features/compatibilities are for MBR and GPT disks ? Or are there limitations with GPT disks ?

 

That's a table of filesystems and features. As far as I know, it's equally applicable to MBR and to GPT disks.

[Keshav Amburay]

Please check http://www.insanelymac.com/forum/index.php...t&p=1300176 for updated links.

[heliox]

Thanks a lot Keshav. You're the man. For various reasons I've given up GPT partitions but still monitoring this DUET stuff. I've downloaded your files already for future use.

Keep it up.

[Keshav Amburay]

@heliox: I have uploaded a new Efildr firmware with AHCI support implemented by VirtualBox. It is a mix of EDK2 and VBoxPkg from VirtualBox OSE. Can you try it and send in your comments? I also want to know how much of your RAM is consumed when using memdisk.

[migle]

Hello, Keshav, and first of all thank you for making a compiled version of DUET available.

 

My story is the following, I uninstalled Windows for some time, started using GPT, now I have 20 partitions and don't want to go back. Only then I found out about Windows not booting from GPT. The hybrid MBR technique doesn't help me get Windows to boot (if the protective partition is the first, Windows sees the disk as GPT and doesn't boot, if it's not, I can't use GRUB).

 

I was pretty much put away by the strange requirements for compiling DUET. The Windows DDK? What for? mingw on Linux? This thing doesn't use Win32! Something is wrong with whoever did that build system. Your pre-compiled version helped a lot.

 

However, your memdisk technique sounded a bit too complicated for me. I read the code for bootsect.asm and start.asm, so I saw their limitations. So, last weekend I wrote a replacement program for the boot sector of a FAT partition which is able to fully load both EFILDR and EFIVAR.BIN and execute EFILDR successfully (skipping the first part of it).

 

So far, I can only boot EFILDR, run the shell, and little more. I still can't reinstall windows because it doesn't seem to be able to read the DVD. Of the two versions you compiled, only one of them allows me to read the hard disk (AHCI) and load the shell. That version sees the DVD, but doesn't read it well.

 

I wonder if those are limitations of those versions of EFILDR or if they are some defect of my boot program?

 

I would be very happy if you tried my boot program and told me if it works well for you. It uses 32-bit LBA addressing and installs into the boot sector of a FAT12/16/32 partition. You'll see it was very difficult to squeeze the FAT chain loading code which works fully according to spec into those 448 bytes.

The code is very easily compilable (GNU make and GCC) and installable on Linux.

 

It's on github, https://github.com/migle/BootDuet.

 

After that, I would like to know more about how you managed to find your way around DUET and compile it. I'm pretty lost still.

[Keshav Amburay]

Hello, Keshav, and first of all thank you for making a compiled version of DUET available.

 

My story is the following, I uninstalled Windows for some time, started using GPT, now I have 20 partitions and don't want to go back. Only then I found out about Windows not booting from GPT. The hybrid MBR technique doesn't help me get Windows to boot (if the protective partition is the first, Windows sees the disk as GPT and doesn't boot, if it's not, I can't use GRUB).

 

I was pretty much put away by the strange requirements for compiling DUET. The Windows DDK? What for? mingw on Linux? This thing doesn't use Win32! Something is wrong with whoever did that build system. Your pre-compiled version helped a lot.

 

Glad to help. The build system of edk2 is a great improvement over edk1. I use this script https://github.com/skodabenz/Misc_Linux_She...ompile_setup.sh to compile duet and i patched the DuetPkg.dsc and fdf files slightly to make sure duet compiles successfully (like remove EBC to reduce size of image etc.).

 

Right now edk2 duet is able to compile in normal gcc 4.6 (Archlinux x86_64) and no need for mingw (it was required previously for msabi, which was added later in gcc 4.4 onwards).

 

I no longer compile edk1 duet. It is way too old and does not support AHCI. Did you try edk_uefi64 or edk2_x64?

 

However, your memdisk technique sounded a bit too complicated for me. I read the code for bootsect.asm and start.asm, so I saw their limitations. So, last weekend I wrote a replacement program for the boot sector of a FAT partition which is able to fully load both EFILDR and EFIVAR.BIN and execute EFILDR successfully (skipping the first part of it).

 

Its actually easy, just setup syslinux bootloader in your system and add the memdisk to syslinux config file.

Can the fat partition be a gpt one? Unfortunately i do not know programming to understand your code. Maybe you should discuss about this at http://sourceforge.net/mailarchive/forum.p...name=edk2-devel ML.

 

Right now duet does not boot from a gpt partition. I will try this one but i cannot give a timeframe since my exams are starting and it may take me 2 weeks or more to respond. Memdisk is just a workaround. I would prefer actual booting duet from a actual fat32 gpt partition anyday.

 

So far, I can only boot EFILDR, run the shell, and little more. I still can't reinstall windows because it doesn't seem to be able to read the DVD. Of the two versions you compiled, only one of them allows me to read the hard disk (AHCI) and load the shell. That version sees the DVD, but doesn't read it well.

 

Can you try (in the AHCI efildr one) this in efi shell

 

fs0:
cd efi\boot
bootx64.efi

 

I wonder if those are limitations of those versions of EFILDR or if they are some defect of my boot program?

 

I would be very happy if you tried my boot program and told me if it works well for you. It uses 32-bit LBA addressing and installs into the boot sector of a FAT12/16/32 partition. You'll see it was very difficult to squeeze the FAT chain loading code which works fully according to spec into those 448 bytes.

The code is very easily compilable (GNU make and GCC) and installable on Linux.

 

It's on github, https://github.com/migle/BootDuet.

 

After that, I would like to know more about how you managed to find your way around DUET and compile it. I'm pretty lost still.

 

Check this out -

http://sourceforge.net/mailarchive/forum.p...name=edk2-devel

[migle]

Right now edk2 duet is able to compile in normal gcc 4.6 (Archlinux x86_64) and no need for mingw (it was required previously for msabi, which was added later in gcc 4.4 onwards).

Oh? I must try it then.

 

I no longer compile edk1 duet. It is way too old and does not support AHCI. Did you try edk_uefi64 or edk2_x64?

I keep forgetting which one I just installed... I have two FAT partitions (FAT16 and FAT32). I put edk_uefi64 on one and edk2_x64 on the other.

edk_uefi64 seems to work only when I set BIOS to "Compatibility mode".

edk2_x64 seems to work in that case and when BIOS is set to AHCI.

 

Only one of them seems to be getting EFIVAR.BIN right. I see that when I change some setting such as boot timeout and then reset.

 

So, which one should I focus on? edk2_x64?

 

Can the fat partition be a gpt one? Unfortunately i do not know programming to understand your code.

Sure. It can also be an mbr one, but there isn't much point in that.

The program knows nothing about partitions, it needs that the Hidden Sectors field of the partition boot sector is filled in with the LBA at which the partition starts, so it can find it.

 

Right now duet does not boot from a gpt partition. I will try this one but i cannot give a timeframe since my exams are starting and it may take me 2 weeks or more to respond. Memdisk is just a workaround. I would prefer actual booting duet from a actual fat32 gpt partition anyday.

Well it works with my boot program.

 

Can you try (in the AHCI efildr one) this in efi shell

 

fs0:
cd efi\boot
bootx64.efi

Well, neither the "Boot from file" option nor the shell ever see anything in my Vista DVD.

Also, my Vista DVD doesn't have a bootx64.efi file, only cdboot.efi and cdboot_noprompt.efi.

(BTW, I'm not following your guide, installing Windows to an MBR partition and then converting to GPT also because my DVD doesn't seem to have the Repair option).

 

Right now, I copied those files from the DVD to one of my FAT partitions. Then, on the shell, I can type similar commands to load cdboot.efi.

Then, cdboot.efi loads but then complains about BCD.

 

So, after I changed my BIOS to "Compatibility mode" I had the impression that EFILDR actually sees and reads my DVD drive. But because it never sees the files in there, I assumed it could not understand the ISO file system in the DVD.

 

I discovered the "drivers" command of the shell. I see there is a driver for FAT but not for ISO.

So, my interpretation was it had no driver for ISO file system, and I will have to get one...

 

But are you saying you can read the ISO file system on a DVD with this thing?

 

Check this out -

http://sourceforge.net/mailarchive/forum.p...name=edk2-devel

Yes, they are talking about the error which occurs on bs32.asm. That would be the first error and if that one was corrected more limitations would step in. That one is related to bs32 using a BIOS function which is limited to 1023 cylinders.

My boot program safely replaces those and uses LBA. It also avoids having to compile all those tools that do automated cut&pasting of boot sector bits and which also have limitations of their own.

 

 

So, I got DUET to boot from a GPT FAT partition, but I have nothing to boot. Right now, I'm trying Linux and ELILO, still with no success. I wonder if I could replace GRUB with this thing, eliminating another step of the boot process.

[Keshav Amburay]

I keep forgetting which one I just installed... I have two FAT partitions (FAT16 and FAT32). I put edk_uefi64 on one and edk2_x64 on the other.

edk_uefi64 seems to work only when I set BIOS to "Compatibility mode".

edk2_x64 seems to work in that case and when BIOS is set to AHCI.

 

Only one of them seems to be getting EFIVAR.BIN right. I see that when I change some setting such as boot timeout and then reset.

 

So, which one should I focus on? edk2_x64?

 

efivar.bin == edk_uefi64 == no ahci and very old , not recommended

edk2_x64 == in memdisk but does not create efivar.bin (intentional) since that option creates blue screen in windows x64 and linux kernel panic (without 'noefi' kernel option)

 

In EDK2_X64 , I replaced DuetPkg/FSVariable/FSVariable.inf with MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf , otherwise it leads to Windows 7 x64 Blue Screen and Archlinux x86_64 Kernel Panic if FSVariable is used.

 

FSVariable produces efivar.bin which acts as storage for efi runtime services variables. EmuVariableRuntimeDxe creates a virtual store in memory everytime duet is run and gets erased when system is shutdown. There seems to be some problem in SetNextVariable of FSVariable in edk2 duet which causes the kernel panic http://sourceforge.net/mailarchive/message...msg_id=26027879 , http://sourceforge.net/mailarchive/message...msg_id=24967648 .

 

Well, neither the "Boot from file" option nor the shell ever see anything in my Vista DVD.

Also, my Vista DVD doesn't have a bootx64.efi file, only cdboot.efi and cdboot_noprompt.efi.

(BTW, I'm not following your guide, installing Windows to an MBR partition and then converting to GPT also because my DVD doesn't seem to have the Repair option).

 

Right now, I copied those files from the DVD to one of my FAT partitions. Then, on the shell, I can type similar commands to load cdboot.efi.

Then, cdboot.efi loads but then complains about BCD.

 

So, after I changed my BIOS to "Compatibility mode" I had the impression that EFILDR actually sees and reads my DVD drive. But because it never sees the files in there, I assumed it could not understand the ISO file system in the DVD.

 

I discovered the "drivers" command of the shell. I see there is a driver for FAT but not for ISO.

So, my interpretation was it had no driver for ISO file system, and I will have to get one...

 

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)

 

My boot program safely replaces those and uses LBA. It also avoids having to compile all those tools that do automated cut&pasting of boot sector bits and which also have limitations of their own.

 

Does this mean we can say good bye to GenBootSector and BootSectImage tools?

 

So, I got DUET to boot from a GPT FAT partition, but I have nothing to boot. Right now, I'm trying Linux and ELILO, still with no success. I wonder if I could replace GRUB with this thing, eliminating another step of the boot process.

 

I am able to boot linux x86_64 using grub2 (1.99~rc2)in edk2_x64.

[Keshav Amburay]

@migle: Your bootsector works perfectly (chainloaded from syslinux chain.c32 module) . I followed the instructions in the INSTALL file. I have not yet tried with Gpt.S though. I don't plan to replace a proper bios bootloader with duet alone. In case duet linux boot fails, i should have a proper bios bootloader to boot any OS. I plan to add these bootsectors in my EFI_DUET git repo if you have no objections (compiled binaries alone). I will try compiling duet with fsvariable to check whether it works with efivar.bin in the partition and whether the kernel panic still occurs.

[migle]

@migle: Your bootsector works perfectly (chainloaded from syslinux chain.c32 module) . I followed the instructions in the INSTALL file. I have not yet tried with Gpt.S though.

Glad to hear!

Gpt.S will work too, as all my BootDuet.S requires is that Gps.S passes it the BIOS drive number of the boot drive in DL, as is standard, and Gpt.S does that.

I didn't try it though, as I also didn't try 64-bit LBA (I don't have a >2TB disk), but it's a safe assumption that it will work.

 

I don't plan to replace a proper bios bootloader with duet alone. In case duet linux boot fails, i should have a proper bios bootloader to boot any OS.

Oh, but I think it would be a good idea. I can't boot anything yet and already think that this thing is a million times better than GRUB. It's extensible, has a powerful shell, there's the disk partitioning and formating tools from Microsoft. This is the ideal pre-boot and recovery environment. It will make people throw their old MS-DOS pen drives away (which are no longer useful for recovering anything).

 

This could be useful for many years, particularly as EFI becomes widespread and people may need it to keep older hardware working. Credits to Intel that made this available.

 

Someone must add an ISO 9660 and UDF driver to this thing...

If this becomes more generally available, there will be an explosion of new tools for rescue situations.

 

I plan to add these bootsectors in my EFI_DUET git repo if you have no objections (compiled binaries alone).

It's too late for objections, you already got it under GPL!

Seriously, it's better if people can get everything they need from a single repository, so please do.

You may consider including the source as well. Even though you can't change it, someone else might need to.

Otherwise, include a note somewhere indicating where people can get the source from.

 

I will try compiling duet with fsvariable to check whether it works with efivar.bin in the partition and whether the kernel panic still occurs.

I don't think the boot sector program has any part in that, so I wouldn't expect that to work.

 

But maybe we have to arrange that to work as well, that is a very needed feature, otherwise there's no way to have persistent boot options.

[Keshav Amburay]

Someone must add an ISO 9660 and UDF driver to this thing...

 

You have got it here http://www.virtualbox.org/browser/trunk/sr...oxPkg/VBoxFsDxe (don't know about UDF). But it doesn't compile with gcc, maybe Visual Studio might work. You should be familiar with how edk2 buildsystem works to compile this. See https://github.com/skodabenz/Misc_Linux_She...ompile_setup.sh on how it works.

 

I added FSVariable containing Efildr files in EFI_DUET repo https://github.com/skodabenz/EFI_DUET/tree/...Efildr/EDK2_X64 in case you want to test it. I also updated the normal Efildr20 and memdisk images. Linux kernel gives a panic message but continues booting with FSVariable (there are no files in /sys/firmware/efi/vars though).

 

But maybe we have to arrange that to work as well, that is a very needed feature, otherwise there's no way to have persistent boot options.

 

Yes, there is no way to make boot settings persistant because of this FSVariable bug. Tianocore devs seems to be in no hurry to check this, they concentrate more on OVMF than DUET.

[nnobody]

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.