Jump to content

Linux and Windows UEFI boot using Tianocore DUET firmware


  • Please log in to reply
158 replies to this topic

#21
rajkosto

rajkosto

    InsanelyMac Protégé

  • Members
  • PipPip
  • 73 posts
i can see the uefi menu (DUET: PRODUCT NAME HERE), however, looks like my usb keyboard and mouse arent working...

usb legacy support is enabled in bios

#22
srs5694

srs5694

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 541 posts
  • Gender:Male
  • Location:Woonsocket, RI

i can see the uefi menu (DUET: PRODUCT NAME HERE), however, looks like my usb keyboard and mouse arent working...

usb legacy support is enabled in bios


It's possible that UEFI DUET has crashed. That's what it does for me, and I'm using PS/2 keyboards and mice.

#23
heliox

heliox

    InsanelyMac Protégé

  • Members
  • PipPip
  • 70 posts
  • Gender:Male
  • Location:Nice,FRANCE

The DUET firmware does not support AHCI SATA mode. I already mentioned that in the readme file in EDK_DUET folder. Change the SATA mode to IDE in the BIOS to make DUET recognise the HDD and the DVD drive. I personally do not suggest using Hybrid MBR ( it defeats the very reason for using GPT - multiple primary partitions ). To install Windows in UEFI boot mode, change back to Protective MBR using gdisk, boot DUET, insert the Windows 7 x64 setup disk and then select EFI DVD/CD option in BOOT MANAGER in DUET. Also make sure the EFI SYSTEM PARTITION is formatted as FAT32 ( not NTFS and not HFS or HFS+ ).

Hi Keshav from Chennai, here's Christian from Pondy (in France now)!
Thanks a lot for your tutorial and the USB key trick for emulating UEFI on my BIOS only Asus P5Q3 Deluxe motherboard. I managed to install a dual boot UEFI-GPT system (Snow Leopard/Windows 7 Ultimate 64bit) on a brand new Sata SSD.

Pure UEFI-GPT scheme:
0: GUID_partition_scheme *64.0 GB disk0
1: EFI 209.7 MB disk0s1 (FAT32 - created automatically by Snow Leopard Installation, updated automatically by Win7 Installation)
2: Apple_HFS Snow 32.0 GB disk0s2 (HFS+ - for Snow Leopard)
3: Microsoft Reserved 134.2 MB disk0s3 (FAT32 - created automatically by Win7 Installation)
4: Microsoft Basic Data 31.7 GB disk0s4 (NTFS - for Windows 7 Ultimate 64 bit)

For the time being, for SL I have to boot in "AHCI" mode with a chameleon USB key, and for Win7 I have to switch to "Enhanced IDE" mode with your UEFI USB key.
Is there no way to compile an "AHCI" compatible EFI_DUET? If you can do that I'll be pleased not to switch between AHCI and IDE mode, then I'll try to have a single USB key with both Chameleon and UEFI in it (if that's possible at all).

#24
Keshav Amburay

Keshav Amburay

    InsanelyMac Protégé

  • Members
  • PipPip
  • 56 posts
  • Gender:Male
  • Location:Indiana, USA
  • Interests:Arch Linux
Hi heliox, I corrected the mistake you pointed out in http://www.insanelym...ndex.php/t43689 page. About AHCI, I do not know even a tiny bit of programming, to help you. I have been unable to boot DUET from HDD (by chainloading it from grub2). If you know programming you can talk to tianocore guys about AHCI support.

Chameleon, on the other hand, does not need a separate bootable USB like DUET. Just follow their instructions on installing Chameleon manually. It is safe to overwrite the first 440 bytes MBR boot code of your HDD. In UEFI-GPT mode Windows will not bother about any MBR or its boot code. So you can do away with atleast one pen-drive.

Even if you want to continue booting Chameleon from USB, I don't think its possible to have both DUET and Chameleon in the same pendrive. The booting of DUET depends heavily on its bootsectors which load it, unlike Chalemeon. The hindrance here is the DUET bootsectors, not Chameleon.

#25
heliox

heliox

    InsanelyMac Protégé

  • Members
  • PipPip
  • 70 posts
  • Gender:Male
  • Location:Nice,FRANCE
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.

#26
Keshav Amburay

Keshav Amburay

    InsanelyMac Protégé

  • Members
  • PipPip
  • 56 posts
  • Gender:Male
  • Location:Indiana, USA
  • Interests:Arch Linux

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

#27
heliox

heliox

    InsanelyMac Protégé

  • Members
  • PipPip
  • 70 posts
  • Gender:Male
  • Location:Nice,FRANCE
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 :P

#28
squallmat

squallmat

    InsanelyMac Protégé

  • Just Joined
  • Pip
  • 5 posts
  • Gender:Male
  • Location:Calais, France
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)

#29
Keshav Amburay

Keshav Amburay

    InsanelyMac Protégé

  • Members
  • PipPip
  • 56 posts
  • Gender:Male
  • Location:Indiana, USA
  • Interests:Arch Linux

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 by Keshav, 26 September 2010 - 07:28 PM.


#30
squallmat

squallmat

    InsanelyMac Protégé

  • Just Joined
  • Pip
  • 5 posts
  • Gender:Male
  • Location:Calais, France
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 ? :D
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 :P )

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

#31
srs5694

srs5694

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 541 posts
  • Gender:Male
  • Location:Woonsocket, RI

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.

#32
Keshav Amburay

Keshav Amburay

    InsanelyMac Protégé

  • Members
  • PipPip
  • 56 posts
  • Gender:Male
  • Location:Indiana, USA
  • Interests:Arch Linux

Hello Keshav, thanks for the reply. Maybe i mistaken (my english is far to be perfect) but it seems you contradict yourself ? :unsure:
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 :P )


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.zyto...dex.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. :huh:


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.

#33
squallmat

squallmat

    InsanelyMac Protégé

  • Just Joined
  • Pip
  • 5 posts
  • Gender:Male
  • Location:Calais, France
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.zyto...dex.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 ?

#34
Keshav Amburay

Keshav Amburay

    InsanelyMac Protégé

  • Members
  • PipPip
  • 56 posts
  • Gender:Male
  • Location:Indiana, USA
  • Interests:Arch Linux
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.

#35
srs5694

srs5694

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 541 posts
  • Gender:Male
  • Location:Woonsocket, RI

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" :P


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.

#36
Keshav Amburay

Keshav Amburay

    InsanelyMac Protégé

  • Members
  • PipPip
  • 56 posts
  • Gender:Male
  • Location:Indiana, USA
  • Interests:Arch Linux

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

#37
squallmat

squallmat

    InsanelyMac Protégé

  • Just Joined
  • Pip
  • 5 posts
  • Gender:Male
  • Location:Calais, France
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 :D

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. :P
(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.

#38
squallmat

squallmat

    InsanelyMac Protégé

  • Just Joined
  • Pip
  • 5 posts
  • Gender:Male
  • Location:Calais, France
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...k/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.sourc...et/features.php"
These features/compatibilities are for MBR and GPT disks ? Or are there limitations with GPT disks ?

#39
srs5694

srs5694

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 541 posts
  • Gender:Male
  • Location:Woonsocket, RI

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


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.../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.sourc...t/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.

#40
Keshav Amburay

Keshav Amburay

    InsanelyMac Protégé

  • Members
  • PipPip
  • 56 posts
  • Gender:Male
  • Location:Indiana, USA
  • Interests:Arch Linux
Please check http://www.insanelym...p...t&p=1300176 for updated links.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy