Mailing List Archive

On Wed, Sep 13, 2017 at 5:12 PM, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
> Hello list,
>
> I've acquired a copy of Windows 10 home edition (or whatever they call it)
> and I'd like to install it on this box to dual-boot. This is a UEFI box
> though, and I use bootctl from systemd-boot to manage the bootable images.
>
> Is there some guidance out there to help me do this? I haven't found
> anything with Google, and the wiki doesn't help either.
>

Hello,

It should just work if you create space for it. There are admonitions
to install Windows first as people claim it will destroy a disk, but
I'm not sure if it ever did this, and it seems to work well with
whatever you give it.

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

If you don't need to do graphically intensive things I would suggest
looking at QEMU/KVM and possibly libvirtd. If you do need to do
graphically intensive things, GPU passthrough now works fairly well.

Cheers,
R0b0t1

On Wed, Sep 13, 2017 at 11:09:14PM -0500, R0b0t1 wrote:
> It should just work if you create space for it. There are admonitions
> to install Windows first as people claim it will destroy a disk, but
> I'm not sure if it ever did this, and it seems to work well with
> whatever you give it.

It may not destroy any existing partitions, but it will overwrite any
bootloader you had installed (and/or reset boot order) on the install
disk.

--
Sam Jorna (wraeth)
GnuPG Key: D6180C26

On Wed, Sep 13, 2017 at 11:36 PM, Sam Jorna <wraeth@gentoo.org> wrote:
> On Wed, Sep 13, 2017 at 11:09:14PM -0500, R0b0t1 wrote:
>> It should just work if you create space for it. There are admonitions
>> to install Windows first as people claim it will destroy a disk, but
>> I'm not sure if it ever did this, and it seems to work well with
>> whatever you give it.
>
> It may not destroy any existing partitions, but it will overwrite any
> bootloader you had installed (and/or reset boot order) on the install
> disk.
>

If you perform an EFI installation it can't delete your bootloader
(unless you modify the partition it's on).

The second one I didn't think of.

On Wed, Sep 13, 2017 at 11:43:42PM -0500, R0b0t1 wrote:
> On Wed, Sep 13, 2017 at 11:36 PM, Sam Jorna <wraeth@gentoo.org> wrote:
> > On Wed, Sep 13, 2017 at 11:09:14PM -0500, R0b0t1 wrote:
> >> It should just work if you create space for it. There are admonitions
> >> to install Windows first as people claim it will destroy a disk, but
> >> I'm not sure if it ever did this, and it seems to work well with
> >> whatever you give it.
> >
> > It may not destroy any existing partitions, but it will overwrite any
> > bootloader you had installed (and/or reset boot order) on the install
> > disk.
> >
>
> If you perform an EFI installation it can't delete your bootloader
> (unless you modify the partition it's on).
>
> The second one I didn't think of.

Indeed, it won't necessarily destroy the entire ESP, but it will reset
the boot order to point to the Windows booloader, and I suspect it will
overwrite anything at ESP:EFI\Boot.

--
Sam Jorna (wraeth)
GnuPG Key: D6180C26

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.

--
Regards,
Peter.

On Thu, Sep 14, 2017 at 3:20 AM, Peter Humphrey <peter@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.

Install it in a VM!

If your system supports IOMMU for graphics devices here is something
special you can do:

I would instead consider purchasing an additional PCI-e graphics device
and a PCI-e usb card then installing Windows in a VM with IOMMU-GFX,
this way you can have your cake and eat it too.

I play my games in a windows VM on my libre coreboot workstation, it
works great and I highly recommend it
Another reason a VM is much better is that windows doesn't get access to
your bare metal hardware unless you forward a device so it can't send
serial numbers back to MS for their spying/marketing database, such as
your HDD serial number or NIC mac address, and one can avoid a bad virus
as you can simply restore a previous VM snapshot.

[1] (for the VM's keyboard and mouse if you don't have more than one usb
controller onboard)

On Thu, Sep 14, 2017 at 8:16 PM, Taiidan@gmx.com <Taiidan@gmx.com> wrote:
> Install it in a VM!
>

Yes, this is a very good option. I can verify everything "works" but
sometimes you will experience sporadic errors with new hardware. You
won't waste time on this if it does happen; in every case I have seen
it shows up immediately.

Unfortunately you may have to go off the beaten path some and avoid
libvirtd or manually edit the same's configuration files. I can
provide summaries of the manuals and wikis available if you want.

Cheers,
R0b0t1

Hi all,

I am interested in doing something too. Do you talk about GPU
Pass-through? Few months ago I wanted to try it myself but I own a Ryzen
1800x and just one GPU. Is there a way with only one GPU?


Or do I really need 2GPUs and 2 Keyboard/Mouse?


Thanks

-Radi


On 15.09.2017 06:04, R0b0t1 wrote:
> On Thu, Sep 14, 2017 at 8:16 PM, Taiidan@gmx.com <Taiidan@gmx.com> wrote:
>> Install it in a VM!
>>
> Yes, this is a very good option. I can verify everything "works" but
> sometimes you will experience sporadic errors with new hardware. You
> won't waste time on this if it does happen; in every case I have seen
> it shows up immediately.
>
> Unfortunately you may have to go off the beaten path some and avoid
> libvirtd or manually edit the same's configuration files. I can
> provide summaries of the manuals and wikis available if you want.
>
> Cheers,
> R0b0t1
>

On Fri, Sep 15, 2017 at 4:03 AM, Radoje Stojisic
<radoje.stojisic@posteo.de> wrote:
> Hi all,
>
> I am interested in doing something too. Do you talk about GPU Pass-through?
> Few months ago I wanted to try it myself but I own a Ryzen 1800x and just
> one GPU. Is there a way with only one GPU?
>

That depends what you want to do. I'm going to assume what you
actually want is a 3D capable OpenGL provider in your VM.

If you have an Intel GPU, you can use VT-g to share it with virtual
machines. On Linux this is fairly recent development and I personally
have not had time to experiment with it. This functionality has,
surprisingly, been available on Windows for some time. Also available
on Windows is the ability to pool GPUs and allow virtual machines
computation time on them.

However, that doesn't work on Linux (yet), so the only alternative to
VT-g is VGA passthrough which requires another GPU.

> Or do I really need 2GPUs and 2 Keyboard/Mouse?
>

You don't need two keyboards and mice.

However, in the typical setup, when you pass your keyboard and mouse
to the virtual machine, you will be unable to interact with your host
machine. For a lot of users this might be fine. If QEMU crashes the
devices should be released to the host, but if the machine becomes
unresponsive you will have to wait or perform a hard reset.

Another option is to view your machine (Linux or Windows) with remote
desktop software. I personally prefer this one because it doesn't
require you to have a duplicate set of hardware. With Windows, RDP
provides better host/guest integration than anything else.


Taiidan recommended a separate USB controller for the guest. This can
be very helpful but also isn't necessary. You can pass specific USB
ports to a guest. (I have to test this with hotplugging but it looks
like it should work.)

Cheers,
R0b0t1

On 09/15/2017 05:03 AM, Radoje Stojisic wrote:

> Hi all,
>
> I am interested in doing something too. Do you talk about GPU
> Pass-through? Few months ago I wanted to try it myself but I own a
> Ryzen 1800x and just one GPU. Is there a way with only one GPU?
I am always willing to assist with complex technical problems.
> Or do I really need 2GPUs and 2 Keyboard/Mouse?
Yeah you do as it is very difficult to re-map the BAR's of an an in-use
graphics device.
Obviously one can use a single keyboard and mouse with a KVM, but the
multi GPU part is mandatory.

You can buy a video card that doesn't need an additional power
connection for only $30 or so, plus if you only have one USB controller
you would need a USB PCI-e card one for $20 - TOTAL $50 very affordable.

On Thursday, 14 September 2017 19:51:37 BST R0b0t1 wrote:
> On Thu, Sep 14, 2017 at 3:20 AM, Peter Humphrey <peter@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.

2. What will happen to the UEFI kernel entries in /dev/nvme0n1p1?

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.

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.

--
Regards,
Peter.

On Sun, Sep 17, 2017 at 9:12 AM, Peter Humphrey <peter@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 <peter@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

On Monday, 18 September 2017 05:17:34 BST R0b0t1 wrote:
> On Sun, Sep 17, 2017 at 9:12 AM, Peter Humphrey <peter@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 <peter@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.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.

On Monday, 18 September 2017 08:53:01 BST Peter Humphrey wrote:
> 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.

Have you deleted/moved the xxx.efi files and these continue to be shown in
bootctl?

Have you tried using efibootmgr to delete them?

--
Regards,
Mick

On Monday, 18 September 2017 11:52:13 BST Mick wrote:
> On Monday, 18 September 2017 08:53:01 BST Peter Humphrey wrote:
> > 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.
>
> Have you deleted/moved the xxx.efi files and these continue to be shown in
> bootctl?

There's only the one, but yes:

# find /boot -name \*.efi
/boot/EFI/systemd/systemd-bootx64.efi

> Have you tried using efibootmgr to delete them?

Ah! That looks like just what I need. I should have thought of it myself,
but thanks for the nudge.

Now to start poking about where angels fear to tread...

--
Regards,
Peter.

On Monday, 18 September 2017 12:09:54 BST Peter Humphrey wrote:
> On Monday, 18 September 2017 11:52:13 BST Mick wrote:
> > On Monday, 18 September 2017 08:53:01 BST Peter Humphrey wrote:
> > > 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.
> >
> > Have you deleted/moved the xxx.efi files and these continue to be shown in
> > bootctl?
>
> There's only the one, but yes:
>
> # find /boot -name \*.efi
> /boot/EFI/systemd/systemd-bootx64.efi
>
> > Have you tried using efibootmgr to delete them?
>
> Ah! That looks like just what I need. I should have thought of it myself,
> but thanks for the nudge.
>
> Now to start poking about where angels fear to tread...

OK, second hint: you may need to mount your /sys/firmware/efi/efivars as
read-write before you can make any changes to it - bug #627964 refers, as well
as this wiki page:

https://wiki.gentoo.org/index.php?
title=Efibootmgr&type=revision&diff=667826&oldid=667778

--
Regards,
Mick

On Monday, 18 September 2017 12:17:34 BST Mick wrote:

> OK, second hint: you may need to mount your /sys/firmware/efi/efivars as
> read-write before you can make any changes to it - bug #627964 refers, as
> well as this wiki page:
>
> https://wiki.gentoo.org/index.php?
> title=Efibootmgr&type=revision&diff=667826&oldid=667778

Yes, I'd already seen that. :)

--
Regards,
Peter.

On Monday, September 18, 2017, Peter Humphrey <peter@prh.myzen.co.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@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 <
peter@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.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.

On Tuesday, 19 September 2017 05:15:46 BST R0b0t1 wrote:

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

What, efivars being mounted read-only? Quite sure. If I don't remount them
read-write, "bootctl install" refuses to run at all.

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

I wonder. Just possibly this is a motherboard or UEFI BIOS problem (or one
I've caused it). When I first received the machine I couldn't get grub to
install and run, no matter what I tried. That was 18 months ago, since when
it's been running apparently happily using bootctl.

--
Regards,
Peter.

On Tuesday, 25 May 2021 17:43:00 BST antlists wrote:
> On 25/05/2021 16:23, Peter Humphrey wrote:
> > 4. I have the existing ESP mounted on /boot. It belongs to Windows and
> > cannot be enlarged beyond 100MB.
>
> I don't know how this works, but I installed Windows 10 and SUSE
> dual-boot. SUSE installed a second 500MB ESP, and it works. Somehow the
> system must be able to link the two together.

Oo-er! What, on the same drive?

--
Regards,
Peter.

On 25/05/21 20:02, Peter Humphrey wrote:
> On Tuesday, 25 May 2021 17:43:00 BST antlists wrote:
>> On 25/05/2021 16:23, Peter Humphrey wrote:
>>> 4. I have the existing ESP mounted on /boot. It belongs to Windows and
>>> cannot be enlarged beyond 100MB.
>>
>> I don't know how this works, but I installed Windows 10 and SUSE
>> dual-boot. SUSE installed a second 500MB ESP, and it works. Somehow the
>> system must be able to link the two together.
>
> Oo-er! What, on the same drive?
>
There's only one drive ...

Cheers.
Wol

On Tue, May 25, 2021, at 2:02 PM, Peter Humphrey wrote:
> On Tuesday, 25 May 2021 17:43:00 BST antlists wrote:
> > On 25/05/2021 16:23, Peter Humphrey wrote:
> > > 4. I have the existing ESP mounted on /boot. It belongs to Windows and
> > > cannot be enlarged beyond 100MB.
> >
> > I don't know how this works, but I installed Windows 10 and SUSE
> > dual-boot. SUSE installed a second 500MB ESP, and it works. Somehow the
> > system must be able to link the two together.
>
> Oo-er! What, on the same drive?
>

I typically specify --removable for grub-install because it works around
common issues in board firmwares. You can still do everything else, it's
just more likely to work.

You might want to try that and see what the differences on disk are or
check the efibootmgr flags. IIRC there is something relevant.

Still works with fastboot (at least where I tested) if you want your machine
to boot extremely fast. On mine, I have to remove the boot media because
there is no time to hit the setup keys.