Planning unusual dual-boot setup

m_square · 2017-11-27 15:38:20

Hi there,
in a few days I will get a new machine and I'm planning a somewhat unusual dual-boot setup. My question is, if something like this is even possible. Please read on:
The new box will have 3 drives. A NVME I want to use as system drive for arch-root. A SSD/HDD Hybrid for my home and 3rd HDD I want to put Windows on. I don't want Windows to interfere in any way with my arch install (even the boot loader.) As I will use Windows only seldom (for instance for performance comparison and configuration of some hardware via their proprietary tools ).
I know, that normally Win should be installed first on the first drive. Than being called from a bootloader.
I wonder if I could install it the above mentioned way and influence via BIOS boot device order which is the first device. Since I really don't want any Win data on the NVME but want it to be the boot device for everyday use.

I hope this makes any sense to you and there are some people out there who can tell if my plan is worth trying.

Thanks in advance,
Markus.

Slithery · 2017-11-27 15:48:04

Does your new machine actually use BIOS? I'd expect it to use UEFI.
What you're suggesting is possible, but one of the main design considerations for UEFI wast that you only use one EFI partition for all installed OS's, no matter how many drives you have.

Off topic - Just out of interest, which SSHD are you buying? It's not a WD Black SSHD is it?

Last edited by Slithery (2017-11-27 15:49:06)

m_square · 2017-11-28 04:24:38

Yap, that's why I said it's somewhat unusual. It migt also be a foolish idea. I don't know. Somehow I just don't want to have any trace of Win on the NVME when just needing it, let's say once vor twice a year.
By the way, the SSHD's going to be a Seagate Firecuda.

cfr · 2017-11-28 04:59:46

How do you plan to handle secure boot?

m_square · 2017-11-28 11:13:39

I wanted to disable secure boot.

V1del · 2017-11-28 13:08:33

Secure boot isn't going to be relevant if this is really to be a BIOS system. Having a different harddrive and using them from the BIOS boot order loader is absolutely possible and no problem at all, both OS (Windows and whatever bootloader you choose) will write into the MBR of their designated harddisk. However if this is really possible as a BIOS system is the actual question you will want to be asking, I'm not sure how well nvme drives will handle a BIOS boot if at all.

Lone_Wolf · 2017-11-28 14:43:12

m_square,
I think you should look for motherboards that come with coreboot & nmve2 support .
That will give you the flexibility needed to separate windows and linux, while also supporting latest technologies.

m_square · 2017-11-28 18:39:13

Hm, should have done more homework on UEFI before ordering the parts. It's so very different from BIOS based systems.
But if I get this right, it should be pretty easy. I'll try to first connect only the HDD supposed to have WIN on it. Then install there. After that I'll plug in the NVME and install arch there. If I understood correctly, that should give both Disks a ESP and they should be bootable independently via UEFI loader. Of course there's a big chance I completely got the whole thing wrong.
BTW. The boards going to be a Aorus X370 Gaming 5 with a Ryzen 7 1800x. As I understand AMD is merely evaluating if they will support Coreboot on Ryzen in the future. At least that's what I found out with a quick search and therefore shouldn't be an option.

cfr · 2017-11-29 01:37:01

m_square wrote:

Hm, should have done more homework on UEFI before ordering the parts. It's so very different from BIOS based systems.
But if I get this right, it should be pretty easy. I'll try to first connect only the HDD supposed to have WIN on it. Then install there. After that I'll plug in the NVME and install arch there. If I understood correctly, that should give both Disks a ESP and they should be bootable independently via UEFI loader. Of course there's a big chance I completely got the whole thing wrong.

The UEFI loader expects a single ESP. So, if you mean that you'll then have 2 disks plugged in, that's likely to be a problem. UEFI firmware varies a great deal. Some will wipe entries for devices not found at boot. (Most won't, I think, but some will.) So plugging/unplugging isn't guaranteed either.

While the goal of having no-thing-Windows touching your Arch disk may seem appealing, I would urge you to reconsider. By all means keep Windows off the rest of the disk, but keeping the bootloader on the ESP there will make life much easier - not to say, possible. After all, you're already committed to formatting part of the disk with a FAT file system and placing EFI binaries there. Not keeping the Windows EFI there just seems silly to me. If you need Windows, you need Windows. Why make dealing with things MS even more annoying than they are anyway?

m_square · 2017-11-29 03:06:09

OK, I'm getting more and more the feeling that I'm completely of track.
@cfr: Iwouldn't have any problem with only one ESP on the M.2 and chainloading Windows from the other Disk.
Anyways since I didn't doe a Windows install in a long time I might remember the procedure incorrectly. I'm under the impression, that Windows will occupy any space that I specify during setup in it's entirety for creating an ESP and install itself directly afterwards. Which would leave me with a Win-install on the M.2. I never made a UEFI install. Am I able to specify different drives for the ESP and the Win- install itself during setup? That would really make things much easier.

V1del · 2017-11-29 09:20:33

IIRC might be off base here, the Windows bootloader has to reside on the same drive of the ESP as the windows install. -- Done some searching, this is definitely possible.

However what I'm pretty sure of is that the UEFI loader expecting only a single ESP in your entire system is incorrect, or at least should be incorrect from a specification standpoint, how a vendor interprets these are a whole different ballpark. So I'm fairly certain that using two seperate ESPs on different disks to satisfy your desire of having them separated cleanly should very much be doable. What motherboard have you ordered? Maybe it helps in figuring out it's capabilities.

Last edited by V1del (2017-11-29 09:25:46)

m_square · 2017-11-29 10:00:12

Hi V1del, I'm exactly at the position as you describe it. I also did some research on UEFI Windows installation, but what I found at Microsoft's site is not very descriptive about the possibilities in customizing your install. Therefore I guessed it would be the old: "I see a disk! Will grab it all!" Thingy. I think I'll just have to wait for the parts to arrive and then do some experimentation. The board's gonna be a Aorus x370 Gaming 5 by the way. Didn't find and anything particular about it's way of handling ESPs or boot order. I think it's going to be a fun time figuring out the best (read: most suitable) configuration.
Hm, might make an interesting post on a blog...

Last edited by m_square (2017-11-29 10:03:26)

cfr · 2017-11-29 19:06:27

However what I'm pretty sure of is that the UEFI loader expecting only a single ESP in your entire system is incorrect, or at least should be incorrect from a specification standpoint,

Do you have a reference for this? Everything I've read says that the spec requires the firmware to recognise only one ESP. If there are multiple ESPs, the firmware may not look beyond the first and ignore the others entirely. I'm not sure what you mean by 'should'? Do you mean that the spec says what you claim? Or do you claim that the spec should require what you say, even though it doesn't?

So I'm fairly certain that using two seperate ESPs on different disks to satisfy your desire of having them separated cleanly should very much be doable.

Do you have a reference for this? Nothing I've read suggests this is the case at all and there are certainly threads on this forum in which problems are resolved in ways which involve removing additional ESPs.

Theoretically, this seems right. If you switch the disk order for boot, you'd expect the firmware to find the ESP on the first disk in the list. But how does that interact with the EFI boot menu entries in nvram? That is, usually, you don't just list a disk as an entry - for that to work, you need to have an EFI executable with the default name, in the fallback location - and you need your firmware to support that, even though it is on a hard rather than a removable disk. I guess I'm not clear how those are expected to interact, given the UEFI spec.

Scimmia · 2017-11-29 19:13:20

cfr, you're placing way too much importance on the ESP. If you're booting from NVRAM entries (which would be the case here), the ESP doesn't mean shit.

Last edited by Scimmia (2017-11-29 19:14:38)

cfr · 2017-11-30 00:48:21

Scimmia wrote:

cfr, you're placing way too much importance on the ESP. If you're booting from NVRAM entries (which would be the case here), the ESP doesn't mean shit.

I thought the idea was to use those when the need arose to boot Windows.

V1del · 2017-11-30 08:59:26

@cfr

UEFI spec 2.7 wrote:

13.3.3 Number and Location of System Partitions
UEFI does not impose a restriction on the number or location of System Partitions that can exist on a system. System Partitions are discovered when required by UEFI firmware by examining the partition GUID and verifying that the contents of the partition conform to the FAT file system as defined in Section 13.3.1.1. Further, UEFI implementations may allow the use of conforming FAT partitions which do not use the ESP GUID. Partition creators may prevent UEFI firmware from examining and using a specific partition by setting bit 1 of the Partition Attributes (see 5.3.3) which will exclude the partition as a potential ESP.
Software installation may choose to create and locate an ESP on each target OS boot disk, or may choose to create a single ESP independent of the location of OS boot disks and OS partitions. It is outside of the scope of this specification to attempt to coordinate the specification of size and location of an ESP that can be shared by multiple OS or Diagnostics installations, or to manage potential namespace collisions in directory naming in a single (central) ESP.

Source: http://www.uefi.org/specifications

That said, as Scimmia points out, once the NVRAM entries are made, "they" will know where to find their UEFI entry.

cfr · 2017-11-30 16:14:14

V1del wrote:

@cfr
UEFI spec 2.7 wrote:
13.3.3 Number and Location of System Partitions
UEFI does not impose a restriction on the number or location of System Partitions that can exist on a system. System Partitions are discovered when required by UEFI firmware by examining the partition GUID and verifying that the contents of the partition conform to the FAT file system as defined in Section 13.3.1.1. Further, UEFI implementations may allow the use of conforming FAT partitions which do not use the ESP GUID. Partition creators may prevent UEFI firmware from examining and using a specific partition by setting bit 1 of the Partition Attributes (see 5.3.3) which will exclude the partition as a potential ESP.
Software installation may choose to create and locate an ESP on each target OS boot disk, or may choose to create a single ESP independent of the location of OS boot disks and OS partitions. It is outside of the scope of this specification to attempt to coordinate the specification of size and location of an ESP that can be shared by multiple OS or Diagnostics installations, or to manage potential namespace collisions in directory naming in a single (central) ESP.
Source: http://www.uefi.org/specifications
That said, as Scimmia points out, once the NVRAM entries are made, "they" will know where to find their UEFI entry.

Thanks. I don't see that that requires UEFI implementations to recognise multiple ESPs, though. It just says they may. Or is the 'Software installation may ...' supposed to impose a requirement on firmware i.e. software may X or Y [so firmware should support X and Y]?

V1del · 2017-11-30 17:32:02

Found another one

1.6.1 UEFI Driver Model Goals wrote:

Flexible – The UEFI Driver Model must support the ability to enumerate all the devices, or to enumerate only those devices required to boot the required OS. The minimum device enumeration provides support for more rapid boot capability, and the full device enumeration provides the ability to perform OS installations, system maintenance, or system diagnostics on any boot device present in the system.

So yeah it absolutely is required.

nexx1 · 2017-11-30 20:41:54

Hi Markus,

i am almost exactly doing it like you want to
NVME SSD -> Arch (ext4)
SATA HDD -> media (ext4)
SATA SSD -> Win10

I installed the systems with each corresponding drive installed and the others disconnected at the time, it works flawless and without hassle. You just loose the opportunity to use grub for choosing which system to boot; instead you have to manually choose the boot-device in your UEFI at system start.
My primary boot device is the arch-SSD so i only need to do this when i really want to use windows (solely for gaming)

cfr · 2017-11-30 23:29:09

V1del wrote:

Found another one
1.6.1 UEFI Driver Model Goals wrote:
Flexible – The UEFI Driver Model must support the ability to enumerate all the devices, or to enumerate only those devices required to boot the required OS. The minimum device enumeration provides support for more rapid boot capability, and the full device enumeration provides the ability to perform OS installations, system maintenance, or system diagnostics on any boot device present in the system.
So yeah it absolutely is required.

If you say so. I wouldn't read it that way, but perhaps I'm too influenced by the behaviour of actual implementations.

m_square · 2017-12-01 11:35:15

Thank you all for your input,
unfortunately I have to wait until next week to play with the new stuff.

@nexx1 That's exactly what I had in mind! I will try it like you described.

Arch Linux

#1 2017-11-27 15:38:20

Planning unusual dual-boot setup

#2 2017-11-27 15:48:04

Re: Planning unusual dual-boot setup

#3 2017-11-28 04:24:38

Re: Planning unusual dual-boot setup

#4 2017-11-28 04:59:46

Re: Planning unusual dual-boot setup

#5 2017-11-28 11:13:39

Re: Planning unusual dual-boot setup

#6 2017-11-28 13:08:33

Re: Planning unusual dual-boot setup

#7 2017-11-28 14:43:12

Re: Planning unusual dual-boot setup

#8 2017-11-28 18:39:13

Re: Planning unusual dual-boot setup

#9 2017-11-29 01:37:01

Re: Planning unusual dual-boot setup

#10 2017-11-29 03:06:09

Re: Planning unusual dual-boot setup

#11 2017-11-29 09:20:33

Re: Planning unusual dual-boot setup

#12 2017-11-29 10:00:12

Re: Planning unusual dual-boot setup

#13 2017-11-29 19:06:27

Re: Planning unusual dual-boot setup

#14 2017-11-29 19:13:20

Re: Planning unusual dual-boot setup

#15 2017-11-30 00:48:21

Re: Planning unusual dual-boot setup

#16 2017-11-30 08:59:26

Re: Planning unusual dual-boot setup

#17 2017-11-30 16:14:14

Re: Planning unusual dual-boot setup

#18 2017-11-30 17:32:02

Re: Planning unusual dual-boot setup

#19 2017-11-30 20:41:54

Re: Planning unusual dual-boot setup

#20 2017-11-30 23:29:09

Re: Planning unusual dual-boot setup

#21 2017-12-01 11:35:15

Re: Planning unusual dual-boot setup

Board footer