Jump to content











Photo
- - - - -

Need Help Setting Up UEFI DUET On Alienware M14X R1


  • Please log in to reply
62 replies to this topic

#1 AnonVendetta

AnonVendetta

    Silver Member

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

Posted 04 March 2015 - 06:51 AM

So, I recently bought an Alienware M14X R1 on Craigslist. It was manufactured in early 2011. And I just now discovered that it has no support for UEFI whatsoever. I had looked through the BIOS before purchasing and noticed that UEFI options weren't present anywhere, but the laptop was in such good condition and it was a really good deal for the price, that this wasn't a dealbreaker for me. The seller was honest and didn't try to up the price at all. And so far it has exceeded my expectations in terms of playing games, even newer titles seem to run pretty well on it. I haven't had any major issues thusfar. Installing Windows 8.1 Pro was easy enough, the biggest issue I had was finding the right drivers. But now everything is running like a dream.

 

However, I would now like to experience the benefits of booting Windows on GPT partitioning, and I now realize that emulating Windows via DUET will be the only viable option for doing so on my hardware. I recently found milindsmart's post here on reboot.pro (http://reboot.pro/to...in-bios-to-gpt/). But using that method isn't desirable, since it won't allow for repairing Windows via the native options available on the setup USB. And I am uncertain of how to get it working in conjunction with an Arch Linux dualboot scenario, which preferably will boot in UEFI mode on GPT partitioning.

 

I have also noticed a few other things, which are, namely, that DUET supposedly doesn't support AHCI mode. I have read that using IDE mode will be necessary. Now that 2015 is here, is this still the case?

 

If I can get some assistance in getting this set up, and what I will need to do so, then I would be very grateful. I know that I will at least need one USB drive, a Windows setup USB/disc (for dual-boot), and (preferably) some flavor of Linux to initially set up DUET, as well as SysLinux or GRUB2.

 

I also apologize in advance if I posted this in the wrong area of the forum, I'm relatively new here. Feel free to relocate it to the correct area if neccessary.

 

Thanks in advance!



#2 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 04 March 2015 - 02:02 PM

However, I would now like to experience the benefits of booting Windows on GPT partitioning,

Would you be so kind to enumerate those benefits? :unsure:
 

... and I now realize that emulating Windows via DUET will be the only viable option for doing so on my hardware. I recently found milindsmart's post here on reboot.pro (http://reboot.pro/to...in-bios-to-gpt/). But using that method isn't desirable, since it won't allow for repairing Windows via the native options available on the setup USB. And I am uncertain of how to get it working in conjunction with an Arch Linux dualboot scenario, which preferably will boot in UEFI mode on GPT partitioning.

Well, the WHOLE point of this:
http://reboot.pro/to...o-gpt/?p=186656
is that the method allows for a GPT disk to be bootable on BIOS, and do so in such a way that the same disk, unmodified, can boot on UEFI as well.

If your machine has EFI/UEFI, it has EFI/UEFI (and may optionally have a Compatibility Mode - please read have additionally a BIOS embedded in the UEF/UEFI Firmware), if it has BIOS, it has BIOS (and nothing else).

 

:duff:

Wonko



#3 AnonVendetta

AnonVendetta

    Silver Member

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

Posted 04 March 2015 - 10:28 PM

I really don't feel a need to "enumerate those benefits" to you, I have nothing to prove. If you post count here is any indication of your knowledge, then we both know full well what the benefits of GPT partitioning are, VS the old MBR/BIOS standard. Nor do I need to justify my reasons for pursuing this, I have my reasons for doing what I do, as do you. It's none of my business what others' motivations are, and I expect the same in return.

 

I understand full well what milindsmart wanted to accomplish, he wanted to boot *Windows* on *GPT* in *BIOS* mode. I, on the other hand, want to boot *Windows* on *GPT* in *UEFI* mode, or at least some kind of UEFI emulation layer, which is what UEFI DUET is. Please read those 2 sentences twice. I read a great deal on the topic you linked, months before I ever posted or even registered here. But until now I have had no real need to pursue what it is I'm doing. It eventually occured to me, that, for reasons I don't understand and don't care to understand, that you guys were, in essence, trying to defeat booting in UEFI mode, by opting to boot Windows in BIOS mode on GPT instead. And so I decided that, while interesting, it wouldn't be the right approach in my case. DUET, hackish or not, at least will go further towards my goal of *emulating* a UEFI environment. And that is exactly what it is primarily intended for, for UEFI developers and people like myself with older hardware that don't support UEFI. If my hardware did support UEFI, DUET wouldn't be a consideration, and I wouldn't be posting here at all.

 

And besides all of that, UEFI is slowly becoming the future for booting computers. BIOS is dying out. UEFI's bugs are being ironed out. What you guys were trying to do, seemed at best an interesting yet complicated project, yet still fighting against the tide in a losing battle.

 

Also, I succinctly stated that my hardware doesn't support UEFI in any way whatsoever. No options in the BIOS for "legacy/compatibility" mode, "Secure Boot", etc. Perhaps you you could have taken my word for it and we could have worked from there.

 

With all that said, if your only purpose in posting in my thread is to attempt to convince me that the approach in the thread you linked is the best way for me to proceed, then please kindly move along, I'm not interested. But if you're interested in helping me get DUET set up, then you're welcome to continue this line of conversation with me. I apologize if I sound rude or standoffish, I can be that way sometimes without being aware of it or meaning to do it, so take it how you want.

 

Thanks in advance!



#4 cdob

cdob

    Gold Member

  • Expert
  • 1438 posts

Posted 04 March 2015 - 11:02 PM

May be you can adopt a virtualbox approach to real hardware.
Tianocore DUET is used. And AHCI mode is used too.
https://forums.virtu...php?f=1&t=61886

#5 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 05 March 2015 - 10:51 AM

Hmmmm :dubbio:, to put that question into a wider context, and just for the record, I asked what I thought being an innocent enough question because I was interested in the answer, as from the little I know (almost nothing about UEFI/EFI but quite something about BIOS), once a Windows NT OS has been loaded the HAL makes the way it was booted (i.e. through which kind of firmware and subsequent steps the OS loader was reached for execution) bear no difference.

As well from the not-so-little I know about MBR and GPT partitioning schemes, the only difference in practice is the possibility to go beyond the 2.2 Tb limit, which is NOT actually a "benefit", it is either a "need" if you have a larger than 2.2 Tb boot media and you want to access it all or mostly a "senseless feature" if you have a smaller than 2.2 Tb boot media.

But it is entirely possible that such benefits exist :unsure: and I am unaware of them :blush: , hence the question.

 

But if you're interested in helping me get DUET set up, then you're welcome to continue this line of conversation with me.

I really don't feel a need to continue this line of conversation, let alone a need to help you in *anything*, given how graciously you addressed me.

 

I apologize if I sound rude or standoffish, I can be that way sometimes without being aware of it or meaning to do it, so take it how you want.

To clear this doubt, I can assure you that you did sound extremely rude and standoffish.
As my good friend Mr. Spock would have noted, this is fascinating, as only Ferengis were thought to be capable to mix to this degree of perfection ignorance, unmotivated aggressivity and arrogance.

:duff:
Wonko


  • alacran likes this

#6 milindsmart

milindsmart

    Frequent Member

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

Posted 09 March 2015 - 07:05 PM

Despite the offensive level of aggression that was entirely unneeded, I think a few things need to be cleared up (which Wonko might have explained if you hadn't lost your cool like a rabid shrew).

UEFI is a *firmware* interface - it is a superior way of interacting with the hardware as compared to BIOS. The vast majority of the point of UEFI is to establish a baseline functionality in the machine that an operating system or boot-time utility can utilise and build on.

When UEFI is not present, much of the benefits of the firmware interface are lost if you emulate it : it will still ultimately start up through a 512-byte boot sector, which also (can) contain 4 partitions squeezed in, along with a measly 4-byte disk signature.

There can still be some benefit to using emulated UEFI as a way to let all OSes start from a uniform platform, but I'm unaware of the existence of any other concrete OR theoretical benefits. Meanwhile this approach causes the OS to depend on the UEFI implementation, which is a GENERIC application meant to be customised further for actual hardware. Using a tianocore reference implementation with a real hardware board with no customisation for your machine sounds like a pointless abstraction.

#7 AnonVendetta

AnonVendetta

    Silver Member

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

Posted 12 March 2015 - 12:10 AM

Perhaps this topic got off on the wrong foot, although I prefer to think of it as a misunderstanding. At this point I was about ready to just forget about this DUET thing and move on. But I don't give up so easily, and, DUET or not, I wasn't about to let this topic die without at least clarifying a few things. So..........

 

What you guys see as agressiveness, actually isn't. I just felt that Wonko was asking an unnecessary question, which was, in a nutshell, that he had asked to me explain the benefits of GPT. I took that as him asking me as a way to try to get an insight into why I'm pursuing this, i.e. questioning my motivations. In tech forums, motivations generally don't matter, it is the knowledge that matters, and those 2 things are entirely separate from each other. Knowledge is one thing, what one does with that knowledge is his own business. And I clearly have no unethical motivations here (or at least it should be fairly obvious, anyway).

 

2nd, as of his first post, I felt really had no intention of advising how I could accomplish a DUET setup, but rather that he was really only planning to ask questions and try to convince/explain to me why I shouldn't bother going about this. I already have my mind made up, help or no help,  and I'm of the opinion that an individual really has no business posting in a topic if he has no useful info to contribute right from the get-go, without questioning or trying to convince otherwise, etc. If there is nothing that can be contributed, then it's best to refrain from posting in the topic at all.

 

To give you a better oversight of how I think, it goes something like this:

 

1. Person A asks question

 

2. Person B comes along, know's the answer to A's question, or possesses other info that can at least help bring about a solution. If on the other hand B has no relevant info or has other intentions, etc, then it's best for him/her to not post at all.

 

Things really are that simple to me, I'm a straightforward, no-BS type of guy, and I have no patience for runarounds and beating around the bush with people. I tend to get annoyed by others very easily, and prefer not to deal with them at all if it can be avoided.

 

@ Wonko: You can look at going beyond the 2.2TB limit as a need rather than a benefit, in this world everything is a matter of perspective. HDDs/storage are getting ever bigger these days, so in reality being able to use disks larger than 2.2TB really is a benefit. You have a very strange definition of "senseless feature".

 

@ Milind: I'm well aware that UEFI is a firmware interface, in much the same way that BIOS is a firmware interface of sorts, albeit much older. I also understand UEFI is probably largely useless in hardware such as mine, which doesn't natively support it. I'm not concerned about losing benefits, I really have nothing to lose, and knowledge to gain.

 

So, I'll go ahead and give you and Wonko a roundabout explanation of why I'm doing this. As of a few months ago, I had always booted all OSes in BIOS/MBR mode. But then I made the jump to UEFI, after reading up on the benefits of UEFI and GPT and clearing up a few misconceptions I had (such as, Secure Boot and UEFI are one and the same, they obviously arent, but I didnt understand this until recently. I had numerous issues dualbooting with Linux as a result of this, and viewed SB as a PITA to be avoided at all costs). But anyways, long story short, my old PC grew legs and walked away, so now I'm temporarily stuck with older hardware until I can buy something much better.

 

I also like to learn, and I'm determined to continue using UEFI or some form of it on my current hardware, even if it's only emulated, for the purpose of getting hands-on experience and understanding it better. And of course there are practical benefits to booting OSes on GPT, I would rather go about it the officially supported way of installing Windows (GPT on UEFI) rather than the methods outlined in your thread (GPT on BIOS). So this is really more of a pet project and a personal interest more than anything. It's certainly not absolutely necessary to pursue, I could always settle for booting Windows on BIOS/MBR, with the 4 partition limit thing. And I also understand that DUET isn't even guaranteed to work. But I do have an Intel i7 CPU and presumably a motherboard that might work with DUET, so I'd like to give it a shot anyways. I have read that AMD generally doesn't work well with DUET, if at all, if that were the case for me I wouldn't bother.

 

Well, hopefully I was able to clear some things up now.



#8 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 12 March 2015 - 10:31 AM

Well, the whole point of the question was about the "benefits of booting Windows on GPT partitioning", and I asked which benefits you expected and that I was unaware of.

 

GPT style of partitioning gives definitely the advantage of providing a way to access more than 2.2 Tb, but ironically on a modern machine your boot and system device (i.e. where Windows is installed) is (or should be) a SSD that - at least for some time - are and will be much smaller than that, while most modern Windows versions are able to access (not boot from) a large GPT partitioned disk without problems.

 

Besides Windows NT, as said, once you have gone past the "strictly initial parts of booting" will boot and use in it's functioning a HAL (Hardware Abstraction Layer) i.e. it will access the hardware only through it's own drivers, and thus *whatever* was used in that "early" steps of booting will make no real difference.

 

DUET is a nice thing, but it is "generic" and, as Milindsmart explained, since the intended scope of EFI/UEFI is to better leverage the potentiality of the specific hardware using a "generic" thing as a replacement for something that should be specifically tailored to the specific hardware cannot provide those (of little practical use) features.

 

If your scope is instead to learn and to gets your hands on, the suggestion by cdob :worship: makes a lot of sense.

 

:duff:

Wonko



#9 alexanderq

alexanderq
  • Members
  • 7 posts

Posted 12 March 2015 - 11:04 AM

You can allways use this method http://www.insanelym...-with-yosemite/with many other benefits  guaranted to work as i am using it for long time but if many people see you as agresive  maybe you have to observe your self better in what you think and haw you say it.



#10 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 12 March 2015 - 11:47 AM

You can allways use this method http://www.insanelym...-with-yosemite/ with many other benefits  guaranted to work as i am using it for long time ....

 

Good :), and may I ask to you too which are these "many other" benefits?

 

In case one wants to use the (very nice :thumbsup: ) Clover, there is also a nice tutorial by Steve6375 on RMPREPUSB site:

http://www.rmprepusb.com/tutorials/122

and an article on his blog:

http://rmprepusb.blo...os-to-uefi.html

 

:duff:

Wonko 



#11 alexanderq

alexanderq
  • Members
  • 7 posts

Posted 12 March 2015 - 01:59 PM

OS X  of course for those who are interested.

 

P.S.The only reason that I'm still  using mbr in my other older computer is because my resque environment and some other tools are not supporting GPT.


Edited by alexanderq, 12 March 2015 - 02:04 PM.


#12 AnonVendetta

AnonVendetta

    Silver Member

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

Posted 12 March 2015 - 10:44 PM

@ alexanderq: I'm not using any bootloader that's even remotely related to OS X, much less Clover. Grub2 is my preference. If you ask me, OS X is just a prettied-up Unix-like OS with a glorified interface. My dad switched to it after getting fed up with XP years ago, now he absolutely insists that getting a virus on it is impossible, but he just doesn't understand that you can get malware on any OS. I even tried setting up a Hackintosh dualboot awhile ago, it didn't go as planned, mainly because the gaming laptop I had then used NVIDIA Optimus graphics technology, and Optimus apparently isn't compatible with OS X at all. It installed fine, but the system had a kernel panic and couldn't figure out which video card to use (NVIDIA or the onboard Intel), and so booting couldn't proceed.

 

So, this now leaves me with several choices. Since I will never be able to realize the practical benefits of UEFI on my current hardware, even by emulating it, then maybe DUET makes little sense. But it would still be an interesting experiment nonetheless. I now realize that my real interest is in the benefits of GPT rather than UEFI itself, and so now Milind's approach is starting to look much more attractive. I've always hated the 4 partition limit that BIOS has, and having to separate everything up into primary/logical partitions just to accomodate that limitation.

 

My current plan is to install Windows 8.1 and Arch Linux with GRUB2 as the ideal bootloader. Windows will be encrypted with BestCrypt, Arch will ideally have 2 partitions (a root partition and a home partition). Another NTFS partition is also desired so that I can isolate my games from the other partitions, and store my Windows backups. This will allow me to restore Windows with DriveSnapshot or whatever, without having to reinstall games even if reinstalling/repairing Windows becomes necessary. And to boot Windows on a BIOS/GPT config, a BIOS boot partition is required by GRUB. This is where the 4 partition limit becomes a major hassle. I will need a minumum of 5 partitions if I stick to this plan, and GPT is the more clean approach for this. I currently have 750GB to work with, next month I'm going to replace the optical disc slot with an optical disk drive caddy, and shove another 1 to 1.5 TB drive in there for games, etc. This will also give me a way to play around with more OSes and generally have more available space.

 

For me it's basically going to come down to which approach will be easiest and least time-consuming to set up, and which will pose the least potential unforeseen issues in the future. I read milind's thread and it just got so complicated, and with things splitting off in so many different directions with different methods, so I initially decided to forego his approach. Another issue is that it seems that approach will require a USB drive to boot. I know that it can be done without it but you guys listed way too many approaches to accomplishing that, so I'm confused how to proceed. I will also need a USB (ideally) to set up DUET, which I don't currently have. I have an app on my phone called DriveDroid that can boot most ISOs, and some IMG files as well. The general idea was to create a DUET floppy img, transfer it to the phone, and boot DUET from there, then find a way to install it on the HDD (probably in the EFI partition, I'm guessing). As for installing Windows, well, I can either use a disc, or create a temp FAT32 partition on the HDD, make it bootable, and install 8.1 into another partition on the same physical drive from there. I was hoping to play around with EFI shells and UEFI variables, etc, to get a feel for how things work, but in the end I just want a usable PC that I can enjoy using instead of fixing **** all the time. I have a bad habit of crashing my PC and doing risky stuff that forces me to fix stuff alot. On the other hand, I suppose I could play around with UEFI in a VM until I've saved enough money to buy what I really want.

 

I'll go ahead and issue an apology in advance to Wonko, my previous comments never should have gone as far as they did, and even though I generally don't give a **** what people think of me, I also realize it wont bode well for my future reputation on this site if I'm viewed as an ***hole.

 

Just thought I'd try to solicit some ideas before proceeding.



#13 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 13 March 2015 - 10:58 AM

Hmmm. :dubbio:

 

It seems to me, with all due respect that you have already an agenda with a number of "fixed" points derived more from what you fancy or hate than from actual objective technical reasons, since of course the best thing in the world is freedom, that's perfectly fine, I will only address this point:

 

 

And to boot Windows on a BIOS/GPT config, a BIOS boot partition is required by GRUB. 

 

 

Which, as I already tried to explain to you how the above is not accurate:

 

 

Well, the WHOLE point of this:
http://reboot.pro/to...o-gpt/?p=186656
is that the method allows for a GPT disk to be bootable on BIOS, and do so in such a way that the same disk, unmodified, can boot on UEFI as well.
 

, as it is possible on BIOS to have a disk GPT compliant capable of booting grub4dos (which can boot - on BIOS, NOT on UEFI -  almost *anything* including the GRUB2 you wish to use).

 

:duff:

Wonko



#14 AnonVendetta

AnonVendetta

    Silver Member

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

Posted 13 March 2015 - 11:37 AM

https://wiki.archlin...rtition_schemes

That section of the Arch Wiki says that a BIOS boot partition is needed for GRUB2, to boot Arch on BIOS/GPT. It also says elsewhere in the wiki that Arch must follow the same firmware booting mode as Windows if you plan to dualboot.

Still a bit confused on where to begin and which method to use...

Thanks!

Edited by Enigma83, 13 March 2015 - 11:38 AM.


#15 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 13 March 2015 - 12:27 PM

https://wiki.archlin...rtition_schemes

That section of the Arch Wiki says that a BIOS boot partition is needed for GRUB2, to boot Arch on BIOS/GPT. It also says elsewhere in the wiki that Arch must follow the same firmware booting mode as Windows if you plan to dualboot.

Still a bit confused on where to begin and which method to use...

Thanks!

Let's see if I can clear this aspect.

On BIOS, and on a MBR disk:

The "normal" way to boot through Syslinux is to have:

  • a "special" MBR able to load the bootsector of a volume
  • a special bootsector able to load the actual Syslinux loader/bootmanager

The "normal" way to boot through GRUB2 is to have:

GRUB2 installed to the MBR and to a number of hidden sectors

the above installed code is able to load the actual core.img, i.e. the actual GRUB2 loader/bootmanager

 

The "normal" way to boot through grub4dos is to have:

  • grub4dos installed to the MBR and to a number of hidden sectors
  • the above installed code is able to load the actual grldr, i.e. the actual grub4dos loader/bootmanager

BUT grub4dos boot can also be configured to have

  • a "special" MBR able to load the bootsector of a volume
  • a special bootsector able to load the actual actual grldr, i.e. the actual grub4dos loader/bootmanager

Since the stupid GPT specifications use senselessly a few  among the hidden sectors and the stupid - as often happens diverging from the specifications or plainly  wrong - implementations on different operating systems allow NOT to move these GPT used sectors to other sectors, BOTH "normal" installs of GRUB2 and grub4dos cannot work as they generate a conflict when the disk is GPT or "hybrid MBR/GPT".

 

The Author of Syslinux has developed another MBR code, specific for GPT disks, to load Syslinux, hence the ArchWiki note about it not needing a dedicated partition.

 

The developers of GRUB2 have implemented a way making use of a "special" GPT partition using (or abusing) of the GPT partition ID's, assigning to it an ID of "21686148-6449-6e6f-744e656564454649" i.e. if seen in a hex editor !haHdInotNeedEFI, and calling it - in order to make things more simple - "BIOS Boot partition" which when discussed in a context of BIOS vs. UEFI and BIOS/MBR vs. UEFI/GPT can lead the reader to believe that it is a MBR partition and not a GPT one.

 

Now, one of the features of the GPT specifications is to be able to have as much as 128 (actually more) primary (GPT) partitions so it is not at all an issue to have one of the at least 128 available "slots" assigned to a small "BIOS boot partition" dedicated to GRUB2.

 

The mentioned thread contains a lot of related info, that you should digest before making a choice:

http://reboot.pro/to...in-bios-to-gpt/

Particularly  posts starting from around:

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

are largely about this common enough confusion with GPT partition ID's and corresponding "friendly names" and how the one (or the other) OS "sees" them once booted.

 

The proposed alternative solution is that of loading grub4dos through a special MBR code that is NOT a "hybrid MBR/GPT" (i.e. the partition table entry remains fully GPT compliant) from a small partition that can be either totally hidden (and not interfering with either BIOS or UEFI access/booting) or made visible in the GPT partition table assigning to it an unused GPT ID (there are so many of them, and I have prer-booked  :w00t:  "57745348-616C-6640-7373-656450617274" ;)) or abusing of the "024DEE41-33E7-11D3-9D69-0008C781F39F" or "MBR Partition scheme" ID, which has the advantage that it is part of the UEFI/GPT specs (though aimed to a different use that never was) and  Windows ignores it.

 

:duff:

Wonko



#16 alexanderq

alexanderq
  • Members
  • 7 posts

Posted 14 March 2015 - 09:18 PM

@ alexanderq: I'm not using any bootloader that's even remotely related to OS X, much less Clover. Grub2 is my preference. If you ask me, OS X is just a prettied-up Unix-like OS with a glorified interface. My dad switched to it after getting fed up with XP years ago, now he absolutely insists that getting a virus on it is impossible, but he just doesn't understand that you can get malware on any OS. I even tried setting up a Hackintosh dualboot awhile ago, it didn't go as planned, mainly because the gaming laptop I had then used NVIDIA Optimus graphics technology, and Optimus apparently isn't compatible with OS X at all. It installed fine, but the system had a kernel panic and couldn't figure out which video card to use (NVIDIA or the onboard Intel), and so booting couldn't proceed.

 

You do understand that i offered an easy way for booting efi windows on bios allmost as real efi and not something about OSX


#17 AnonVendetta

AnonVendetta

    Silver Member

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

Posted 21 March 2015 - 10:23 PM

So, I've decide to try DUET as the initial approach, since it just seems so interesting and tempting anyway, and will revert to the GPT on BIOS method later if DUET either fails, or succeeds but proves to be problematic. I've only waited this long because I don't have a USB to work with yet, and because of uncertainly in regards to whether it is best to boot DUET as a memdisk image or some other way (the notes in the readme for the DUET download mention that it is out of date and unsupported, and states that a newer method is available).

 

I decided to give the DUET in VirtualBox a shot today, as suggested by cdob, even though I'm aware that it may not work on my physical hardware even if it can be replicated in VB. I figured getting a little familiarity with the overall process wouldn't hurt anything. And of course, ran into snags.

 

Without a USB, I instead created a VHD on a SATA controller, figuring I could mount it a drive letter, give VB access to that, and boot it as if it were a virtual USB. The first issue, as mentioned in the link by cdob, and quote:

 

 

 

set drive_letter=g
md %drive_letter%:\[boot]\syslinux
syslinux.exe --mbr --active --directory /[boot]/syslinux/ --install %drive_letter%:

 

I formatted the 5GB VHD as FAT32, and assigned it a drive letter of Z, then copy/pasted the above commands line by line, replacing %drive_letter% with Z. And syslinux.exe complained that the syntax was incorrect. So I used an alternate approach of installing syslinux to USB/VHD (Google). Afterwards I copied tiano.img and memdisk into the given locations, created syslinux.cfg, then attached the VHD to the VM as a virtual HDD. And VirtualBox complained that it was read-only, even though I can manually go to Z and create files/folders.

 

I'm pretty much stumped at this point.


Edited by Enigma83, 21 March 2015 - 10:25 PM.


#18 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 22 March 2015 - 01:03 PM

I am not sure to understand your report. :unsure:

Are you having the SAME .vhd file mounted as Z: and attached to the VM at the SAME time? :w00t: :dubbio:

 

:duff:

Wonko



#19 AnonVendetta

AnonVendetta

    Silver Member

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

Posted 24 March 2015 - 04:46 AM

Well............at the time I had tried to access the VHD in VirtualBox, it was also mounted in Windows with Z: letter. I had completely forgotten (but already knowing) that a device generally can't be attached to a VM unless it is first disconnected from the host. I'll try again here in a bit and see if I get the read-only error again. But I still don't think booting the VHD will work, I suspect I followed incorrect instructions for installing Syslinux to the VHD. The instructions I used are at http://www.syslinux....ws_XP_and_Vista .

 

The instructions provided by the OP at the VirtualBox forums were unclear in regards to how to install Syslinux (i.e. copying the code line by line, all 3 lines at once, whether or not to substitute %drive_letter% with your chosen drive letter, etc).



#20 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 24 March 2015 - 05:56 PM

Are you joking or serious? :unsure:

This line:

set drive_letter=g

sets the variable "drive_letter" to value "g".

When you put the name of a variable inside two percent signs the result is the value of the variable.

Once:

set drive_letter=g

has been issued this:

md %drive_letter%:\[boot]\syslinux

will result EXACTLY the same as:

md g:\[boot]\syslinux

and this:

syslinux.exe --mbr --active --directory /[boot]/syslinux/ --install %drive_letter%:

will result EXACTLY the same as:

syslinux.exe --mbr --active --directory /[boot]/syslinux/ --install g:

 

:duff:

Wonko



#21 cdob

cdob

    Gold Member

  • Expert
  • 1438 posts

Posted 24 March 2015 - 11:18 PM

I decided to give the DUET in VirtualBox a shot today

A idea not tested:
create a GPT disk, with a 100 MB EFI partition. Post #35 http://reboot.pro/to...e-2#entry182109
Apply syslinux to MBR and EFI partition.

Load tinacore/DUET from a floppy image, interpret and adjust Post#37

#22 AnonVendetta

AnonVendetta

    Silver Member

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

Posted 25 March 2015 - 08:56 AM

@ Wonko: Not everyone is as well versed in coding and boot methods as you, what with terms like variable, etc. I've studied a little Python and messed around with Linux a bit, but not as much as I would like. I'm not sure I understand your post, I'll try to go back and chew through it a bit at a time (I have to process things that way or else I lose train of thought, and I get distracted easily).

 

@ cdob: that seems like an excellent approach, but I would still like to get the method listed in your first post working, just for the sake of messing around. It also seems that what you're suggesting now seems like a hybrid MBR, since you say "apply syslinux to MBR and EFI partition". That's exactly what I want to avoid, if it is indeed as dangerous as 'milindsmart' stated (in his other topic). I would like to stay as close to the UEFI specs as possible, emulated or not. But in the end, whatever works with the least issues will do. I also have no knowledge of how to copy bytes with a hex editor from gptmbr.bin to the MBR, or how to use a hex editor at all, for that matter. I've always thought that true GPT partitioning doesn't have an MBR. I plan to make my EFI partition closer to 500MB or so, since I'm going to be dual-booting multiple OSes (Arch Linux, maybe FreeBSD/PC-BSD, etc). Can you also clarify whether you were successful with wimboot, or a raw floppy, since posts #35 and #37 from the topic you linked aren't clarified?

 

As if that weren't enough, I'd also like to encrypt Windows and, eventually, Linux. I'm going to be using BestCrypt Volume Encryption, since it's currently the only thing that works with UEFI. I suspect it might also work with DUET. Others like TrueCrypt, VeraCrypt, DiskCryptor, etc, only work with MBR. I would like to avoid proprietary solutions in the long run, but I've had no major issues with BC thusfar. Maybe I'm complicating things a bit too much with this one, but I've always been one to push limits and do crazy stuff to/with my PC that most others won't try.

 

Not having a USB handy is really hampering me, once I get an optical disk drive caddy in a week or so I'll have more space to work with, and more potential booting methods. It too will be GPT, primarily for storing data, not OSes. And the notebook's primary HDD will be replaced with an SSD, testing indicates that the current HDD should be fine for awhile longer, but may die soon. I know that GPT is better for SSDs than MBR.

 

My last issue is that I would like to make the transition from MBR to UEFI without having to reinstall Windows. I think that making a compressed backup with Drive Snapshot or TeraByte Image for Windows and then restoring it to the Windows system partition (not EFI, obviously) should work, as long as I recreate the proper boot files in the EFI? I'll probably just convert my current partition table with gptgen, then resize the beginning of the disk to make room for the EFI.

 

Thanks!


Edited by Enigma83, 25 March 2015 - 09:18 AM.


#23 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 25 March 2015 - 10:55 AM

Assigning a value to a variable and retrieving it (the value) by expanding the variable is a very, very, basic concept in any programming or scripting language.
The given three lines represent a very simple example of BATCH (the scripting language historically associated withe DOS and Windows command processor, either command.com or cmd.exe, with some striking resemblances with very common and basic languages like BASIC and FORTRAN ), though normally you don't need to be specifically an expert in BATCH language (let alone BASIC or FORTRAN) to use a computer, the three lines are just an implementation of a concept that you will find in any and all programming or scripting languages, including PYTHON (corresponding to BATCH on Linux there are generally BASH scripts) and you will IMHO need to get very familiar with these concepts as they are commonly used in connection with *any* advanced tutorial or however piece of info related to computing.

I know that GPT is better for SSDs than MBR.

Interesting piece of news, care to expand on this? :unsure:
 
:duff:
Wonko

#24 cdob

cdob

    Gold Member

  • Expert
  • 1438 posts

Posted 25 March 2015 - 05:27 PM

It also seems that what you're suggesting now seems like a hybrid MBR

I've always thought that true GPT partitioning doesn't have an MBR.

GPT request a protective MBR.
http://en.wikipedia....Partition_Table

No, it's not a hybrid partition table: synchronized (potential different) MBR and GPT partition entries.
It's a GPT disk with a protective MBR partition table.

The boot code is added to the protective MBR. This is not specified at GPT.
A BIOS may read the MBR boot code.
This code is required to BIOS boot from this disk.
Be aware: a BIOS may fail at this combination.
Or another classic MBR disk is required in addition.

 

Can you also clarify whether you were successful with wimboot, or a raw floppy

#35 wimboot approach did fail back then.
#37 does work. A BIOS GPT Windows does boot.
 

As if that weren't enough, I'd also like to encrypt Windows and, eventually, Linux.

That's another level of complexity.
May work or fail, I don't known.
Make small steps.
 

My last issue is that I would like to make the transition from MBR to UEFI without having to reinstall Windows.

Converting Windows BIOS installation to UEFI
http://social.techne...ful&PageIndex=1

Cross your fingers and then restart your computer!



#25 AnonVendetta

AnonVendetta

    Silver Member

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

Posted 27 March 2015 - 08:44 AM

I'm not even going to bother trying this out in VirtualBox anymore, since (even if it does work), there is still no guarantee that it will work on my hardware. If cdob is correct, then it will all come down to whether my BIOS is "friendly" or not.

 

My current plan:

1. Back up Windows partition and other data to external source

2. Delete partition table (instead of converting with gptgen)

3. create GPT partition table, then create 512MB EFI partition, NTFS partition for Windows, and a few additional (empty) partitions for Linux/swap and game data/backups

 

This is where I lose track and get confused:

Installing syslinux (post #35 in your link says to install it to the EFI with 'syslinux64.exe --force --directory /boot/ --install E:'. Is there any reason why syslinux.exe cant be used as opposed to syslinux64.exe?

 

As for the hex editor part, I'll check into it, hopefully copying bytes wont be a matter of rocket science. But it says to copy it to HDD MBR. I know you mentioned a GPT protective MBR. But exactly where is this located? I have heard of a 'GPT protective partition', but that implies an actual partition, and I presume it's not the same as the EFI partition. Your Wikipedia link states "In a GPT, the first sector of the disk is reserved for a "protective MBR" such that booting a BIOS-based computer from a GPT disk is supported, but the boot loader and operating system must both be GPT-aware. Regardless of the sector size, the GPT header begins on the second logical block of the device." So it sounds as if the first first 440 bytes of gptmbr.bin need to be copied to the first sector of the HDD in a hex editor (after the GPT partition table is created, which I will use GParted to do). 

 

And then you posted this:

 

 

# Boot Windows7 from floppy
LABEL Windows7
LINUX memdisk
INITRD W7
.img
APPEND raw

 

Where did you get the floppy image from? And how to copy the above lines to the IMG (except I'll be using Windows 8.1 instead of 7)?

 

Thanks!






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users