Jump to content











Photo
- - - - -

Need Help Setting Up UEFI DUET On Alienware M14X R1


  • Please log in to reply
62 replies to this topic

#51 cdob

cdob

    Gold Member

  • Expert
  • 1438 posts

Posted 07 April 2015 - 03:12 PM

What I need to know is, for BIOS/UEFI Windows booting to work, do I need to create *both* a System Reserved partition (for BIOS) *and* and EFI partition (for UEFI) for this to work?

No, one FAT32 partition can serve both \boot and \efi.

 

What do you have against Syslinux/GRUB2?

Full features, like fast startup, requires UEFI at GPT.
Use DUET. Chainloaded by Syslinux/GRUB2/grub4dos.

It's recommended to disable fast startup at a multi boot environment.
Hence you may use simplified BIOS/GPT without EFI emulation.
Grub2 is limited. How to map a partition to satisfy bootmgr (working bcd)? Grub4dos can do this.
Take both. Install your preference grub2 to hard disk, and chainload grub4dos grub.exe

Search and find bootmgr at same hard disk, launch files from FAT32 EFI partition
title GPT BIOS bootmgr
#bcdboot.exe c:\windows /s S: /f BIOS
cat --length=0 (,0)/bootmgr && map (,0)+1 (fd0)
cat --length=0 (,1)/bootmgr && map (,1)+1 (fd0)
cat --length=0 (,2)/bootmgr && map (,2)+1 (fd0)
cat --length=0 (,3)/bootmgr && map (,3)+1 (fd0)
map --hook
root (fd0)
chainloader /bootmgr

About RAM:
ftp://ftp.dell.com/Manuals/all-products/esuprt_laptop/esuprt_alienware_laptops/alienware-m14x_Setup%20Guide_en-us.pdf
Processor Second Generation Intel Core i5 or Core i7.
The notebook manufacturer supports 8 GB RAM.

Compare Memory controller possibilities.
Which CPU do you use?

Even a I3 supports 16 GB RAM.
http://ark.intel.com...-Cache-2_10-GHz

A i7-2670QM claims 32 GB RAM.
http://ark.intel.com...Hz?q= i7-2670QM

16 GB RAM should work at given two RAM sockets.
Be aware: without notebook manufacturer support.

#52 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 693 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 07 April 2015 - 05:07 PM

Hmm, for some reason IE wont let me use the board's quote function. So, anyway.......

 

I had suspected that I could use the EFI partition for both UEFI and BIOS booting, since my PC's seems to imply that it's possible. Unless there's some other info Wonko hasn't made known. To clarify, I'd like to test real UEFI booting (already tested without DUET a few hours ago, it works fine and Windows installs/boots in UEFI mode), while leaving open the possibility of *ALSO* booting Windows in BIOS mode as well. Which is where milind's approach will be useful. I neither need nor have to do this, I'm just doing it because I can. For the learning experience. I could just continue booting in UEFI mode and forget all this. This thread wasn't entirely useless, at the time I originally posted I really believed that real UEFI wasn't possible on my hardware, since the BIOS made mention of it nowhere. But now that I know the truth, I do still feel that I've learned a bit, so not an entirely useless thread. I'll still post my exact instructions later. I might even install DUET in the EFI/protective MBR anyway, just to continue playing with it.

 

 

Cdob, did you bother to read my above posts? I have no need for DUET anymore, it turns out Dell had hidden my BIOS's UEFI functionally in menus that only become visible if you flash a hacked BIOS (what I did). My motherboard was capable of UEFI all along, Dell just left on/off switch hidden, to the point that only advanced users would find it. None of their official BIOSes for my model mention UEFI anywhere. The last BIOS release was A08, and that was several years ago. Did you ever get around to trying Rod Smith's DUET approach? Follow it to a tee, see if your AMD is still unable to boot. He does also mention that some people will need to use the slightly older EDK duet-install, which doesn't support AHCI (only IDE, I think). There is a switch for it in the DUET-install scripts, by default the script installs whatever the newest is (what I used). That may work for you.

 

I know about the fast startup thing, it cause problems in Linux, Linux can only access the Windows volume in read only only, since it's in a sort of hibernation/sleep. Disabling fast startup stops that. It's another UEFI feature that's nice if you only use Windows, but I personally have no need for it.

 

Thanks for the booting tips, I'm going to see if your advice would work for booting Windows in BIOS mode on GPT. But I don't think it will, I'll probably have to resort to using one of the floppy-variant methods for BIOS booting.

 

As for the RAM upgrade, I know 8GB is what is officially supported by Dell on my PC. I'll have to research if 16GB is possible. My main interest is in being able to install a game or 2 in a RAM drive for faster performance (and faster than running them from an SSD, too). But I could care less what the manufacturers want me to do with my electronics, or what they support. Support or no supports, if something works, then it just does. When I buy hardware, I have the full expectation that I can and will do what I wish with it, since it is my personal property. I already root all my Android phones and do asinine stuff on my PCs that most others wont try.

 

My processor is an i7, I'm pretty sure I have 2 memory slots.


  • milindsmart likes this

#53 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14778 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 April 2015 - 05:49 PM

Thanks for the booting tips, I'm going to see if your advice would work for booting Windows in BIOS mode on GPT. But I don't think it will, I'll probably have to resort to using one of the floppy-variant methods for BIOS booting.

 

JFYI, what cdob suggested is still a ( nice BTW  :) ) YAVBFV (Yet Another Vista Boot Floppy Variant), this time making a combined use of GRUB2 and grub4dos.

What do you think that (fd0) means in a grub4dos menu.lst? :dubbio:

 

:duff:

Wonko


  • milindsmart likes this

#54 cdob

cdob

    Gold Member

  • Expert
  • 1438 posts

Posted 07 April 2015 - 05:58 PM

Cdob, did you bother to read my above posts?

Did you you bother to read my reply? ;) Didn't you asked about a way to boot from BIOS nontheless?
Yes, the reply was both for UEFI boot and BIOS boot.
 

I have no need for DUET anymore

Windows requires UEFI at GPT for full fuction. e.g. choose system restore for next boot. This saves settings to bcd file. The BIOS GPT booted Windows dosn't know file bcd, settigs can't be stored.
Of course you are free to ignore this and use BIOS GPT boot.
 

I'll probably have to resort to using one of the floppy-variant methods for BIOS booting.

It's working here at a virtual machine.
It's another floppy-variant method for BIOS booting, the floppy created on the fly by grub4dos.
  • milindsmart likes this

#55 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 693 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 07 April 2015 - 06:36 PM

@ Wonko: Thanks for the info.

 

@ Cdob, I'm not sure you completely understand what I'm saying. Yes I read your post and I get your point. However, *my* post was an attempt to convey the message that the unlocked BIOS mod I flashed *also* enabled the hidden (by Dell) UEFI options. So now UEFI is real and native for me, no more DUET emulation required (unless I choose to continue messing with it, of course) . So now I can choose to boot in UEFI both natively or with DUET. I was mostly contesting the part where you said "Full features, like fast startup, requires UEFI at GPT.

Use DUET. Chainloaded by Syslinux/GRUB2/grub4dos." This implied that you hadn't quite gotten the point of my previous posts. With native UEFI capabilities, DUET becomes unnecessary. Nor would I need to chainload DUET, now that I know the truth. And this, "Hence you may use simplified BIOS/GPT without EFI emulation". Not sure what that is supposed to mean, and how it relates to the (seemingly contradictory) sentences immediately preceding it. In one sentence you say I can use DUET and chainload it, but in the next few lines you seem to imply that I can use simplified BIOS/GPT without emulation. For one, DUET is technically BIOS/GPT, given that booting will start from a 512 byte boot sector before DUET. But to your OSes you are in UEFI/GPT mode. And DUET is obviously emulation designed to lie to the OSes about the booting mode.
 
And "Of course you are free to ignore this and use BIOS GPT boot." I'm not free to ignore that, for UEFI I will either need to use my PC's native capabilities or DUET, for BIOS/GPT I'll have to use the floppy variants approach to boot the same Windows install in that mode.

 

Obviously the native option is the best route, and it works, already tested with Windows 10 and Arch Linux. Just thought I'd clear things up.



#56 cdob

cdob

    Gold Member

  • Expert
  • 1438 posts

Posted 07 April 2015 - 06:49 PM

In one sentence you say I can use DUET and chainload it, but in the next few lines you seem to imply that I can use simplified BIOS/GPT without emulation.

No need for shouting.
Yes, you are free to use any approach: native UEFI, BIOS/DUET, BIOS only.
I don't know which option works best at given hardware.
I had the impression: you are at testing mode currently.
 

Obviously the native option is the best route, and it works, already tested with Windows 10 and Arch Linux. Just thought I'd clear things up.

Yes the native UEFI option is the best route to go. Validate real behavoiur, any timing lags at gaming so far?
Just thought I'd clear BIOS/GPT things up: BIOS/GPT has limitations.
Obviously prefer the native option in the long term.
  • milindsmart likes this

#57 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 693 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 08 April 2015 - 03:19 AM

I just noticed that some of the text in my previous post was larger than the rest. This was unintentional and not yelling. It must have happened whenI copy/pasted the text from your posts. IE seems to not like the board software reboot.pro uses.



#58 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 201 posts
  • Location:Bangalore
  •  
    India

Posted 08 April 2015 - 07:10 AM

  1. NO innovative method (actually no method at all) by milindsmart (he wanted to hack BOOTMGR but never finalized the approach/reported success with it)
  2. a not-so-innovative method reported by SaschaWeaver adapted/bettered through the suggestions of other members making use of Syslinux and grub2
  3. a not-so -innovative method half @§§edly developed by yours truly with the cooperation of cdob as an alternative to the above one, making use of grub4dos instead

I am calling them not-so-innovative because set apart a few (clever? :unsure:) tricks with any among Syslinux/memdisk Grub2 or grub4dos, they all revolve around the known concept of the "Vista boot floppy", see:

http://reboot.pro/to...o-gpt/?p=186766

 

 

Heh a little harsh, but mostly accurate. I did make it work with wimboot, which is not very innovative, it's still a Vista Boot Floppy Variant, but its not nothing :) http://reboot.pro/to...e-3#entry186400

 

The bootmgr hacking went into cold storage, because of the enormous amount of time dedication needed just to keep all of this in memory. You might not realize how much like gibberish this entire thread sounds if you stay away from it just for a couple of months. I might yet find a way to make time for this, because it's one of my eternal love-interests :-D



#59 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14778 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 08 April 2015 - 09:18 AM

Heh a little harsh, but mostly accurate. I did make it work with wimboot, which is not very innovative, it's still a Vista Boot Floppy Variant, but its not nothing :) http://reboot.pro/to...e-3#entry186400

 

The bootmgr hacking went into cold storage, because of the enormous amount of time dedication needed just to keep all of this in memory. You might not realize how much like gibberish this entire thread sounds if you stay away from it just for a couple of months. I might yet find a way to make time for this, because it's one of my eternal love-interests :-D

Sure :), sorry :( but it was an extremely simplified (and blunt :w00t:) way to try to re-focus Enigma83 AnonVendetta's attention on the relevant contents of the thread, to be fair it was started with a very definite title, but little by little it became "Several variants of the Vista boot floppy approach modified to boot Windows on GPT".

 

And, still to be fair, your mentioned reported success with wimboot is more similar to "a normal Windows install" with a separate boot and system partition, i.e. it is a "flattening" of the method Sascha Weaver already reported success with (and -  still to be fair - both were actually hinted/suggested by Sha0):

http://reboot.pro/to...o-gpt/?p=182083

 

 

 



Thinking about it some more, you could probably use wimboot without doing any hacking, just as some of your other options do...
  • Using a GPT partition as an MBR disk image or floppy disk image (GRUB4DOS could map this)
  • Using an MBR disk image or floppy disk image from some filesystem on some GPT partition (GRUB4DOS or MEMDISK could map this)

Using wimboot, you wouldn't have an disk image, but you could get the same result: You could boot BootMgr with an arbitrary BCD, then that BCD could refer to the actual GPT disk.

so, yep, strictly speaking, also not particularly "innovative".

 

:duff:

Wonko



#60 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 201 posts
  • Location:Bangalore
  •  
    India

Posted 08 April 2015 - 09:25 AM

Of course. Nothing totally original in all of this, except maybe the motivation driven by the strong suspicion that booting Windows on GPT is possible. Sha0's suggestion is what led me to wimboot in the first place. Basically I implemented what he suggested. I guess you call this as "software engineering", but in a different sense :D



#61 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 693 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 08 April 2015 - 11:10 PM

This topic is no longer about DUET, and hence off-topic. I already got it working (and have decided to keep it to play around, while still mainly booting in native UEFI), only to discover it's not needed.

 

It's already established that booting in BIOS mode will require some sort of floppy, unless someone has another innovative idea (which should be posted in milind's thread instead of here).

 

My only concern is that Windows will not be able to find/update its' boot files with a floppy method, if it needs to do so for whatever reason. It seems to be a read-only approach. And with wimboot the boot files vanish after Windows is booted. This is possible on real BIOS/MBR, and I feel it is a valid concern not addressed in Milind's thread.

 

I'm thinking that maybe something like a dedicated MBR partition on GPT would work best, kind of similar to GRUB's BIOS boot partition. This also reduces the possibility of accidental tampering by other tools. How can this be done? As another idea, maybe I can just use bcdboot's 'all' parameter and let the BIOS boot files live in the EFI alongside the UEFI boot files, in their own folder.

 

I suppose this thread should be left open for discussion of DUET and helping others who might need assistance with it in the future. I still think it's interesting enough to keep playing with.

 

I'm also interested in whether cdob has managed to get DUET working on his AMD board, and hopefully/eventually getting it to boot, if he plans to pursue it. Rod Smith's instructions should be tried first, then maybe Clover/XPC, etc.It's clear that what worked for me won't work for him. Or you could just boot in BIOS mode with a floppy.


Edited by AnonVendetta, 08 April 2015 - 11:10 PM.


#62 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 693 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 09 April 2015 - 02:29 AM

I just found out the SSD I wanted to buy (see link in above posts) might have issues with my model. Something about not always being seen by the BIOS. I'll either have to run in BIOS mode on MBR, try milind's BIOS on GPT approach, or find another 1TB SSD that works. It may be recognized by my BIOS's UEFI, or only in legacy, or not at all. I haven't made a purchase yet, but prefer not to have to return a product if it might not work.



#63 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14778 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 April 2015 - 08:36 AM

It's already established that booting in BIOS mode will require some sort of floppy, unless someone has another innovative idea (which should be posted in milind's thread instead of here).
 
My only concern is that Windows will not be able to find/update its' boot files with a floppy method, if it needs to do so for whatever reason. It seems to be a read-only approach. And with wimboot the boot files vanish after Windows is booted. This is possible on real BIOS/MBR, and I feel it is a valid concern not addressed in Milind's thread.
 
I'm thinking that maybe something like a dedicated MBR partition on GPT would work best, kind of similar to GRUB's BIOS boot partition. This also reduces the possibility of accidental tampering by other tools. How can this be done? As another idea, maybe I can just use bcdboot's 'all' parameter and let the BIOS boot files live in the EFI alongside the UEFI boot files, in their own folder.

 
Why don' t you try to actually UNDERSTAND what we have been saying till now?

 

Did you try to research on what is involved in the method cdob suggested to you?
http://reboot.pro/to...e-3#entry191914
 
Relevant snippets:
 

No, one FAT32 partition can serve both \boot and \efi.

Hence you may use simplified BIOS/GPT without EFI emulation.
Grub2 is limited. How to map a partition to satisfy bootmgr (working bcd)? Grub4dos can do this.
Take both. Install your preference grub2 to hard disk, and chainload grub4dos grub.exe

Search and find bootmgr at same hard disk, launch files from FAT32 EFI partition

title GPT BIOS bootmgr
#bcdboot.exe c:\windows /s S: /f BIOS
cat --length=0 (,0)/bootmgr && map (,0)+1 (fd0)
cat --length=0 (,1)/bootmgr && map (,1)+1 (fd0)
cat --length=0 (,2)/bootmgr && map (,2)+1 (fd0)
cat --length=0 (,3)/bootmgr && map (,3)+1 (fd0)
map --hook
root (fd0)
chainloader /bootmgr

The idea is to boot GRUB2 (that can boot BOTH in BIOS and UEFI) then use the SAME FAT32 "EFI" partition for BOTH BIOS boot files (BOOTMGR and \boot\BCD) and UEFI Windows boot files .
When UEFI these can be chainloaded directly from GRUB2.
When BIOS you need to chainload grub4dos, and from it map the SAME FAT32 "EFI" partition as first floppy and chainload the BOOTMGR.

Which parts are not clear to you? :unsure:

:duff:
Wonko






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users