Re: [gentoo-user] Dual booting with Windows 10

[Peter Humphrey]

On Monday, 18 September 2017 05:17:34 BST R0b0t1 wrote:
> On Sun, Sep 17, 2017 at 9:12 AM, Peter Humphrey <peter@××××××××××××.uk>
wrote:
> > On Thursday, 14 September 2017 19:51:37 BST R0b0t1 wrote:
> >> On Thu, Sep 14, 2017 at 3:20 AM, Peter Humphrey <peter@××××××××××××.uk>
> >
> > wrote:
> >> > On Thursday, 14 September 2017 05:09:14 BST R0b0t1 wrote:
> >> >> The trickiest part is still the same - going from GRUB or, now, your
> >> >> EFI shell, to Window's bootloader. See here:
> >> >> https://wiki.archlinux.org/index.php/GRUB#Chainloading_Windows.2FLin
> >> >> ux_
> >> >> ins talled_in_UEFI_mode.
> >> >
> >> > That advice, though helpful, is about Grub, which isn't installed on
> >> > this box. I did try at first to get it to work here, but failed, so I
> >> > removed it and went for bootctl. It's a fiddle to keep up to date
> >> > with
> >> > kernel upgrades, but at least it works.
> >>
> >> In that case it seems like systemd-boot will check for the Windows
> >> loader and add it to its menu automatically
> >> (https://wiki.archlinux.org/index.php/systemd-boot#Adding_boot_entries)
> >> .
> >> As above, you may need to reinstall it if the Windows bootloader
> >> installs itself on top of systemd-boot.
> >>
> >> I originally thought you were just booting an EFI stub kernel, in
> >> which case you would have needed some kind of boot manager.
> >
> > I have three questions now:
> >
> > 1.      Will Windows 10 install itself in the unpartitioned space? I've
> > attached a screen shot of gparted to show the current layout.
>
> Yes. It will split the free space into a number of partitions if you
> give the installer no further instruction besides selecting the
> unallocated area.

That's what I was hoping to hear - thanks.

> To force Windows to use one partition delete the ones it creates
> automatically. You will need to select "custom" or "advanced" in every
> place it is offered as an option.
>
> > 2.      What will happen to the UEFI kernel entries in /dev/nvme0n1p1?
>
> When people say "entries" they are usually referring to settings in
> the nonvolatile memory used by a motherboard's EFI firmware. An entry
> associates with an ID a path, priority, and name which is used to
> start the corresponding EFI executable.

I mean the things that "bootctl status" displays. I've already disabled the 
unwanted ones in the UEFI BIOS's list of bootable kernels, but bootctl still 
shows them and won't remove them.

> The actual kernels on /dev/nvme0np1 will remain there because Windows
> won't touch that partition unless you tell it to.
>
> > 3.      Those entries include some left over from experimenting with
> > other distros. How can I manage the entries and purge the ones I don't
> > need? "Bootctl remove" ignores them.
>
> If you are referring to the kernels left in your /boot then simply
> delete them. "Bootctl remove" and other EFI boot managers I have seen
> refuse to touch your disk. They operate on the EFI configuration
> memory.
>
> > Thanks everyone for your help so far.
> >
> > I don't want to install into a VM, because my main reason for installing
> > Win10 is to be able to run an occasional firmware update program, none
> > of
> > which, it seems, run on Linux. Of course, it should also help me get up
> > to speed with the M$ world.
>
> If you pass an entire hard disk to the VM you can then take it out and
> put it in another computer and boot it (or boot it in the same
> computer sans hypervisor).

Maybe that's a use for a couple of spare SSDs I have here.

> With Linux you can pass partitions in individually and use what the
> guest thinks is a raw character device as a disk, so that if you
> wanted to boot that installation from outside of the hypervisor you
> could. This might not be possible with Windows.
>
> If you install into a VM you can pass almost everything to the VM
> directly. I suppose the only thing that may not work extremely well
> would be motherboard firmware updates, but if you look QEMU has
> options to pass almost everything in a computer to a VM. Admittedly
> this isn't a very plug-and-play solution.
>
> Aside from firmware updates (realize though that almost everything -
> barring some low level interfaces like I2C - can be passed to a VM) I
> would invite you to use Windows only in a VM. I find it easier to get
> work done in this way while using Windows programs. Xfreerdp is a good
> way to interact with a Windows guest and can provide better desktop
> integration than QEMU or libvirtd.

I use VirtualBox here, mostly because some BOINC projects require it.

Thanks, R0b0t1.

-- 
Regards,
Peter.