On Sun, Sep 17, 2017 at 9:12 AM, Peter Humphrey <pe...@prh.myzen.co.uk> wrote:
> On Thursday, 14 September 2017 19:51:37 BST R0b0t1 wrote:
>> On Thu, Sep 14, 2017 at 3:20 AM, Peter Humphrey <pe...@prh.myzen.co.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.2FLinux_
>> >> 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.
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.
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).
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.
Cheers,
R0b0t1
