10 replies to this topic

[sir_bootalot]

Need similar to this BIOS-setup, but with UEFI:

 

Possibility to make new Windows7/8/10 installations to partitions, preferably combined system/boot for easy cloning/imaging and deploying Windows to another partition.

 

Possibility to select OS from several Windows and linux operating system partitions when booting.

 

What I had in systems without UEFI:

 

MBR-disk, with minimal 128 MB hidden first primary partition used only for grub4dos files.

 

Second (and third) primary partitions were used for installing Windows so, that it is combined system/boot partition, with all the boot files. I generalized BCD before making an image, and after that I could deploy it to another primary or logical partition, and grub4dos was able to boot them (re-specializing the BCD on-the-fly during the first boot from the new partition).

 

And of course grub4dos also booted linuxes from another partitions.

 

Now with my new setup I have Intel 600p SSD that claims it needs UEFI, so I guess I can't use grub4dos anymore, right?

 

1) Going the modern route with GPT partitioning scheme: what are my options to get the setup similar to the above to work? I really want to boot several instances (or versions) of both Windowses and linuxes.

First, can I install Windows OS to single partition, combined system/boot (like hiding or setting the first small partition to a type not familiar to Windows, and filling the disk with partitions so, that Windows has no space to make that EFI system partition or recovery partition)? Still to figure out if there are some MSR considerations.

Alternate ways to multiboot my UEFI-setup with some other boot manager?

 

2) The MBR route. Similar to my BIOS-setup partitionwise, but I guess I need EFI folder inside the tiny first primary partition (or do I need that, and if yes, do I need that only for \EFI\boot\bootx64.efi - what I want is combined system/boot partition for easy cloning/imaging and deploying the Windows to another partition(s)). Yes, I do need that for grub4dos files, and possibly for some other boot manager's files so that they won't be overwritten when doing a new Windows installation to primary partition with Windows installer (or they would have to be copied there afterwards, if I don't use that small hidden primary reserved only for those), but how about bootx64.efi or some other Windows boot files, or can they all be located to the combined system/boot partition like in my non-UEFI setup?

Aaand, no grub4dos working with UEFI, even UEFI with MBR, right?

So I suppose I need some other boot manager with this route too.

 

Ideas?

​

​Bear with me if I have some misunderstandings with UEFI or GPT. I'm mostly familiar with BIOS and MBR only. Also if there are some SSD considerations different to HDD's, please mention.

Edited by sir_bootalot, 22 November 2016 - 02:49 AM.

[wimb]

See here http://www.msfn.org/...comment-1117324

 

and here http://reboot.pro/to...ve/#entry168079

 

and here http://www.msfn.org/...comment-1120509

[Wonko the Sane]

Now with my new setup I have Intel 600p SSD that claims it needs UEFI, so I guess I can't use grub4dos anymore, right?

Please provide some links to this claim.

 

Which PC is that?

Most if not all UEFI implementations have a CSM (Compatibility Support Mode) which is actually a BIOS.

 

Please consider how you are all in all asking to have a full tutorial on booting, on UEFI vs. BIOS, on GPT vs. MBR, and all possible combinations of those.

 

In a nutshell (to your questions):

1) use GRUB2

2) it makes little sense to have UEFI with MBR (though it is possible) it greatly depends on the OS(es) you want to boot, if you go for the UEFI route you are anyway limited to OS that understand anyway  the GPT partitioning "style".

grub4dos (JFYI) in recent versions can work in BIOS with GPT partitioning "style", but it makes really little sense to have BIOS and GPT as "standard" on internal hard disk (or SSD).

 

Please consider that the only actual "advantage" of GPT over MBR right now is to be able to access volumes larger than 2.2 Tb (of which you probably have none) whilst the advantages of UEFI over BIOS are "none" if not compatibility with some peculiar standards like "Secureboot" and similar overengineered stuff.

Once a "modern" OS (NT based or Linux) is loaded and running it makes no real difference whether it was booted through BIOS services or UEFI services, the OS runs on it's own HAL and drivers.

Wonko

[sir_bootalot]

Please provide some links to this claim.

Booting from an NVMe SSD is not guaranteed to work on every system configuration. Specific
requirements must be met for a successful boot. To support the required UEFI NVMe driver, your system’s
firmware must be based on UEFI 2.3.1 or later. If your system was purchased after 2012 or shipped with
Windows* 8.1 or Windows 10 pre-installed, it most likely supports UEFI.

UEFI BIOS Compatibility
Booting from an NVMe PCIe SSD is only supported on a system that supports UEFI, a new system firmware
that endeavors to improve upon legacy BIOS and standardize system processes, such as booting, loading
drivers, and more.

http://www.intel.com...nstallGuide.PDF

Can I migrate my operating system to the Intel® SSD 600p/6000p Series drive?
* The UEFI drivers and BIOS settings must be used with the NVMe devices. Existing OS installs may not have these settings. We recommend a fresh install.

http://www.intel.com.../000022378.html
 

Most if not all UEFI implementations have a CSM (Compatibility Support Mode) which is actually a BIOS.

I'll prolly not be using CSM if I can avoid it due to some problems it would bring.
 

Please consider how you are all in all asking to have a full tutorial on booting

A strange statement.
 

, on UEFI vs. BIOS, on GPT vs. MBR

Like I said, because I haven't messed with those before, I thought getting some info on differences regarding the type of multiboot environment I'm planning would be useful. I only yesterday started having a closer look on UEFI, GPT, and Windows installations using those compared to BIOS and MBR. I don't need tutorials, I have found my way with multibooting before during many years, so I'll prolly can do it with UEFI and GPT too. What would have been nice and possibly time saving, is to know what is possible and what is not with UEFI and GPT.
 

1) use GRUB2

That's what I thought as one possibility. But I'll look into others before deciding.
 

2) it makes little sense to have UEFI with MBR (though it is possible) it greatly depends on the OS(es) you want to boot, if you go for the UEFI route you are anyway limited to OS that understand anyway  the GPT partitioning "style".

Like I said, that would make my cloning and deploying procedure similar to my non-UEFI setups, and I know it works. (Multiple Windowses and linuxes on the same hard disk)
 

grub4dos (JFYI) in recent versions can work in BIOS with GPT partitioning "style", but it makes really little sense to have BIOS and GPT as "standard" on internal hard disk (or SSD).

Now there was something useful, confirmation that grub4dos doesn't work with UEFI.
 

Please consider that the only actual "advantage" of GPT over MBR right now is to be able to access volumes larger than 2.2 Tb (of which you probably have none)

Volumes? You mean volumes as an OS specific logical concept? I don't know about different OS's volume limitations, but GPT brings the possibility to use bigger hard drives (of which I do have).
 

whilst the advantages of UEFI over BIOS are "none" if not compatibility with some peculiar standards like "Secureboot" and similar overengineered stuff.

BIOS is a 30 years old system, and I think it's prolly a good idea to finally try to do without it. Besides bigger drives with GPT, one thing that comes to mind, is when I was trying to upgrade one of my Windows licenses to Windows 10 by doing an install image instead of updating the system in use, it couldn't be done obviously because I was in BIOS mode. I'm sure there are other reasonings, or will be in the future.

Things that I'm still not sure of are if it is possible or not to create a setup with several completely isolated Windows installations in the GPT scheme, like with MBR I was able to do, so that the boot files like BCD in "system partition" - that Microsoft calls it - are at the same partition than the rest of the OS. So when you deploy from an image, you boot, and that's it. That might be impossible because of the differences with Windows's use of ESP and MSR compared to it's "system partition" on MBR, and possibly GPT's (and the (U)EFI boot loader or boot manager that I will be using) use and handling of hidden partitions and partition types compared to the MBR scheme. But let's see.

Edited by sir_bootalot, 22 November 2016 - 11:47 PM.

[cdob]

UEFI supports FAT, but not NTFS. UEFI requires a FAT ESP partition.
Contrary some manufacturer UEFI implementation supports NTFS nowadays.
Do you search a general solution?

A Windows 10 update installation creates a rescue partition.
The windows partition is resized at a single windows boot disk, and a rescue partiton added.
No idea about a multi boot environment.

[Wonko the Sane]

Now I see . it is one of those newish Nvme/PCIe/M2 thingies.

 

From the manual the "requirement" is not really-really that one (for Windows 7 the UEFI/CSM is seemingly used), but there are seemingly a whole lot of other ones, like the Intel 6 platform (or whatever is it), but more generally a specific motherboard capable of booting from the PCIe bus/M2 connector is not easy-peasy to find, and it has to be seen if it works.

You would be much better off (with a slight performance hit) with a more common SATA SSD, that is more "compatible" with everything.

Otherwise you will need to research in detail the motherboard you are going to use.

 

Now, let's clear the usual confusion about disks, drives, partition and volumes.

The volume is what in windows gets a drive letter. <- this confusion between drive (in the sense of hard disk drive) and drive (in the sense of whatever gets a drive letter in windows and has a file system applied) is a long standing one.  

 

The traditional way was MBR that used a partition table with four entries inside the MBR or first sector of the hard disk drive *like* device.

Each entry can address the extents of a partition as a 32 bit number of sectors. which means that anything going beyond 2^32-1=4294967295 wouldn't work.

Since the normal sector size is 512 bytes this means 4294967295*512=2,199,023,255,040 or roughly 2.2 Tb.

A partition entry can refer to either a primary partition, where the partition extents are the SAME extents of the volume or a logical partition, which may contain one or more volumes.

The GPT is NOT in any way different conceptually, the main difference is that the partition table has been moved to following sectors (from sector 2 onwards) and has wider fields, capable to address much more sectors.

As a side advantage, all partitions are primary, i.e. all partitions are also volumes and there can be lots of them, though in most implementations they are limited to max 128 (which is however a lot).

The volume(s) is EXACTLY the same, no matter how it is indexed or addressed.

 

 

The way the BIOS (which knows nothing about GPT) boots is to simply chainload the first sector (the MBR) of the device and execute instructions it finds in it.

 

The way the UEFI boots (no matter if from a MBR or GPT disk) is to:

1) look for a particular partition (this partition volume should be normally formatted as FAT32 but a number of motherboards now have UEFI versions including NTFS drivers and there is also a third party UEFI driver)

2) look inside the filesystem of this particular volume filesystem for a certain EFI boot file

3) chainload this boot file

 

No matter how the boot is initiated, once a (modern) OS has loaded it doesn't make any difference whether the booting was initiated from UEFI or from BIOS, as the OS itself will use its drivers to access and drive *everything*, including the mass storage devices, of course the OS needs to support the GPT partitioning scheme in case of GPT.

 

In a nutshell, the only issues are in booting.

A particular BIOS (please read as UEFI/CSM), on a particular motherboard, may make available the PCIe/M2 device (as it seems the case of the specific Asus motherboard given as example in the Intel manual you posted when it talks of windows 7 install - but it is not as clear as I would like it to be) or it may make it not.

As well a UEFI may or may not have an option to boot from that device.

 

Normally nothing prevents you from using BIOS and a compatible MBR boot device and have any other disk drives GPT "style", as long as you only boot operating systems that "understand" GPT.

 

There is IMHO no (or very little) advantage in practice today running a PCIe/M2 SSD when compared to a "normal" SATA SSD and a whole lot of issues with it (depending on the motherboard and its features in UEFI and CSM), it is newer technology and it will take some time before everything will be as smooth as with the more traditional SATA devices (BTW I have seen some reports of M2 SSD's that tend to heat a lot, possibly because of the less amount of airflow around them).

 

Wonko

[cdob]

First, can I install Windows OS to single partition, combined system/boot (like hiding or setting the first small partition to a type not familiar to Windows, and filling the disk with partitions so, that Windows has no space to make that EFI system partition or recovery partition)?

Let's try: Given:
Grub 2 at a GPT EFI FAT32 partition and a free ntfs partition c:

Windows 10
DISM.exe /Apply-Image /ImageFile:d:\sources\install.wim /Index:1 /ApplyDir:c:
bcdboot.exe C:\windows /s C:
 

menuentry "Windows UEFI - /efi/Microsoft/Boot/bootmgfw.efi" {
 insmod ntfs
 search --file --no-floppy --set=root /efi/Microsoft/Boot/bootmgfw.efi
 chainloader (${root})/efi/Microsoft/Boot/bootmgfw.efi
}

Window 10 does boot, setup starts, but failes finally: configuration failed
read: the config file bcd can't be saved.
Does setup expect the bcd file at the GPT EFI partiton?

Compare (missing bcd file)
http://reboot.pro/to...in-bios-to-gpt/


Next one: Windows EFI boot files at EFI partition.
Dism apply-image files to c: And bcdboot to volume S: (the EFI partition)
Window 10 does boot, setup finishes.
A WinPE booted and Windows EFI files moved from s: to c:. Window 10 does boot, but bcdedit dosn't find the bcd file.

A combined system/boot is possible, but will get strange behaviour in real life.
Avoid a combined system/boot at UEFI, Store the windows boot files at the EFI partition.

[ner0]

Please consider that the only actual "advantage" of GPT over MBR right now is to be able to access volumes larger than 2.2 Tb (of which you probably have none) whilst the advantages of UEFI over BIOS are "none"

 

A few weeks ago I installed Windows 7 on a machine that had been using XP for a few years (despite the OEM license being Win7 all along). I installed Windows 7 in GPT through UEFI, I usually don't do this but I just thought I might as well get used to it since it is becoming "the norm". Fast-forward one week and I get a call from the office, where that machine is, saying they couldn't get into Windows, "screen is black and has white text on it" they tell me. I get over there and the screen is really black with white text on it.

 

The "white text" said that it couldn't find a bootable medium.

I immediately assumed the disk went kaput... even more so after I used the Windows 7 setup DVD to run a diagnostic and it tells me there was no Windows installation found. I then booted into WinPE and the disk contents were apparently intact, including the system reserved partition holding the boot data. So why wasn't it booting? As I found out, the setup DVD wasn't locating any Windows installation because I booted it in legacy mode (CSM/BIOS) instead of UEFI, which I wasn't aware would result in the setup claiming that no installation existed. Then, I find that some Windows update changed some "stuff" overnight that made the Secure Boot not recognize Windows as a trusted system anymore. The only way I got the system to boot was to go into the BIOS and unload the PK (Platform Key), either that or completely disable Secure Boot.

 

TL;DR I probably will never use UEFI ever again unless forced to.

Edited by ner0, 30 November 2016 - 09:21 PM.

[Wonko the Sane]

 

TL;DR I probably will never use UEFI ever again unless forced to.

Welcome to the club !

 

Wonko

[sir_bootalot]

What I wanted, was an UEFI/GPT solution that would work similar to my earlier BIOS/MBR solution with isolated and independent Windows partitions for easy imaging/cloning (of several instances of the same or different versions of Windows'es) to another partitions, and booting them from third-party boot manager, not the Windows one. The way I have done it for many years.

 

It seems, however, that with UEFI (without CSM), that bootmgr is dependent on boot files (BCD especially) located in ESP, so there would be no way combined system/boot partition would be possible with UEFI&GPT (meaning /Boot with BCD being at the main OS partition - that is possible and is the way I did it with my BIOS/MBR multiboot configurations). That's what I've been reading anyway. If somebody has other information (that would be, it is possible with UEFI&GPT), I'm interested to listen. When there's no way, there's a will.

 

There are EFI NTFS drivers available, so - the boot manager allowing or making it to allow - possibly by moving the boot files and bootmgfw.efi to the "main" OS partition (that MS calls Boot partition for some reason, when everybody else calls it system partition), and changing the Windows Boot Manager entry's device to partition=\Device\HarddiskVolume3 (or whatever) in BCD would work. Maybe I will be experimenting with this when I have more time. Or if those WinPE experts here want to try, that would be interesting.

 

So I figured BCD would need to reside at ESP, that would mean only one BCD for all the bootable Windows partitions, and the need to multiboot Windows'es via Windows Boot Manager. Or... to use separate BCD's anyway for all the Windows instances - at the ESP this time. Seems to work, all fine and dandy. Hopefully those cloned instances know where the MSR is - if not, maybe some registry editing is needed. Opinnions on the latter subject is appreciated (MSR, that I have only one, and that is the second GPT partition aka HarddiskVolume2).

 

No secure boot here (and no CSM). I'll prolly not be using secure boot unless Microsoft makes it required some day. Or some computer doesn't allow disabling it. But it's UEFI-only time anyway, at least with one machine now. Took me a few years to catch up. I wonder what's the next big thing, and if I'm jumping the bandwagon quicker then.

 

One question: anybody has an idea if it is possible to hide somehow the other Windows OS partitions from the one that is running, like by changing the GUID's of the other partitions (with an EFI program)? That's probably the only way besides encrypting them (or otherwise altering something so that even the file system wouldn't be recognized by the Windows), but I'm not sure if it prevents Windows to mess with them in some situations if it wants, because they would get mounted. At least they wouldn't get the drive letter then. MS says:

 

Any OEM-specific partitions or partitions associated with other operating systems are not recognized by Windows. Unrecognized partitions with recognizable file systems are treated like the ESP. They will be mounted, but not exposed. Unlike MBR disks, there is no practical difference between OEM-specific partitions and other operating system partitions; all are "unrecognized."

 

Btw, I found some interesting discussion here when I was googling around, with developers of EasyBCD and some other similar type program. I think it was from 2013 or so. Please continue it. Very entertaining.

Edited by sir_bootalot, 07 December 2016 - 11:18 PM.

[cdob]

It seems, however, that with UEFI (without CSM), that bootmgr is dependent on boot files (BCD especially) located in ESP, so there would be no way combined system/boot partition would be possible with UEFI&GPT (meaning /Boot with BCD being at the main OS partition

Well, a installed Windows 10 does boot from UEFI&GPT and BCD at OS partition.
It's not supported by OS manufacturer. This is a a way with limitations.
E.g. a windows repair installation fails, default at Windows Update 10 Build upgrade. Add BCD to ESP partition temporarily, upgrade the Build number and delete BCD at ESP partition.

Do you search a solution used by yourself? Try BCD at OS partition
Do you search a solution used by others? Recommend BCD at ESP parition