[gentoo-user] Dual booting with Windows 10

[R0b0t1]

On Monday, September 18, 2017, Peter Humphrey <peter@××××××××××××.uk> wrote:
>
> 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.
>

Having checked bootctl's documentation it should be changing EFI variables
(it may manage kernels also, I am not entirely sure). Are you sure this
isn't related to the bug Mick mentioned? If it is then I am unsure why
efibootmgr works.

Now it's fixed (by using something else) and I can't expect you to care,
but I am left perplexed.

> > 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.
>

Fair enough.