From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id F04411396D0 for ; Tue, 19 Sep 2017 04:15:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 530811FC0A5; Tue, 19 Sep 2017 04:15:49 +0000 (UTC) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E6AF41FC009 for ; Tue, 19 Sep 2017 04:15:48 +0000 (UTC) Received: by mail-yw0-x22e.google.com with SMTP id q80so1717115ywg.2 for ; Mon, 18 Sep 2017 21:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=wGPx8mdjzyXifstm4C9sVVKBxIz4swv3MoanKJrSWoM=; b=jW6YF9xclkeLJQrrgz+RFLX+HolpD6EFyrAtkKkGJ/cxTq3lImzh2Te2jHgCFzPrBj MD70+xy96Jzk+E37IWn2HZZK96gC63JukLMuYbOE8Je8tG53HnqEny21zCqP/1E9OnpR s5UqxCIslQjgcOxI2RzGaIrftgf9aY2hb0xZ2ioVGYlqDv7PefQAbvcHP1crIB5UAVfq GFRtHGyAAQPaj8fNvAX3t73Y6U2aYYSs11qF1rlTgA4QAGFUVlbRtPGIsydd/oPAB2CT ByO/y5zI2nTn4MiiV7wJvUNkjXWRnB07SQSTQ310qRNhtXDqTvtcCPBi1D/KEKS3hjLB UnBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=wGPx8mdjzyXifstm4C9sVVKBxIz4swv3MoanKJrSWoM=; b=SRMmkKIs+xgg+a5pivm9ZsMK2ZHA3X2Djya4QUBWva68px6W0ew/3ZpVc6tiRNjz3H 10269PyGdXK5SKIHkKhJtyxjT5/a7w/mNfyX7VOg3d5Yds5gVLfv13IJFgv9+LMmIEMx Gl2jUFjwWQYll78igo/t1l9rr6i2sslna5S4G7yZuoROy2NAl9OLcbCk6IKqnfqhD+1q xUbSMqTO+LE+uQHbSh75q5K6FHyf3AqHZtIXdZ8R7DGf0307cd4a+Ekv01F9JPrJlr+k dRizx4UY/QkbDIdeWYl0zLwA4Q+GY7kXq2+j3uLZUqhGlppwcEummwephtTVJj1E9yTJ vMyg== X-Gm-Message-State: AHPjjUhmR82H6NL998ju95WhItjFrL/qczgvE+ZCGJhefR+lhb3MvVzC K6FqbwiihcGXr9qa3CvC+5DBQyFSlN3L7ldTgNA= X-Google-Smtp-Source: AOwi7QDkAXSfzGsOZm3YXnG5Q8gkHqK8pZDiJQrRYlc8bJbAbI9fflDanUBObkWtJ19b1EJD3x9d/sYUO40rPJsfcFg= X-Received: by 10.129.83.195 with SMTP id h186mr59546ywb.164.1505794547563; Mon, 18 Sep 2017 21:15:47 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.129.131.138 with HTTP; Mon, 18 Sep 2017 21:15:46 -0700 (PDT) In-Reply-To: <9974947.hHFfXzH0oW@peak> References: <4214538.FFuQGbLWd5@peak> <18364961.EDvUJmtLd7@peak> <9974947.hHFfXzH0oW@peak> From: R0b0t1 Date: Mon, 18 Sep 2017 23:15:46 -0500 Message-ID: Subject: [gentoo-user] Dual booting with Windows 10 To: "gentoo-user@lists.gentoo.org" Content-Type: multipart/alternative; boundary="001a114d72921cc1300559831d9b" X-Archives-Salt: 94fcc3a3-ffe7-4557-866d-e8de271d8800 X-Archives-Hash: 5cb514e7cffa5080b461112dba045f53 --001a114d72921cc1300559831d9b Content-Type: text/plain; charset="UTF-8" On Monday, September 18, 2017, Peter Humphrey wrote: > > On Monday, 18 September 2017 05:17:34 BST R0b0t1 wrote: > > On Sun, Sep 17, 2017 at 9:12 AM, Peter Humphrey > 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. --001a114d72921cc1300559831d9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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.m= yzen.co.uk>
> wrote:
> > > On Thursday, 14 Septemb= er 2017 19:51:37 BST R0b0t1 wrote:
> > >> On Thu, Sep 14, 20= 17 at 3:20 AM, Peter Humphrey <peter@prh.myzen.co.uk>
> > >
> &= gt; > wrote:
> > >> > On Thursday, 14 September 2017 0= 5:09:14 BST R0b0t1 wrote:
> > >> >> The trickiest part= is still the same - going from GRUB or, now, your
> > >> &g= t;> EFI shell, to Window's bootloader. See here:
> > >&g= t; >> https://wiki.archlinux.org/index.p= hp/GRUB#Chainloading_Windows.2FLin
> > >> >> = ux_
> > >> >> ins talled_in_UEFI_mode.
> > &g= t;> >
> > >> > That advice, though helpful, is abou= t 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 upg= rades, but at least it works.
> > >>
> > >> I= n that case it seems like systemd-boot will check for the Windows
> &= gt; >> loader and add it to its menu automatically
> > >&= gt; (https://wiki.archlinux.org/index.php/sys= temd-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 need= ed some kind of boot manager.
> > >
> > > I have th= ree questions now:
> > >
> > > 1.=C2=A0 =C2=A0 =C2= =A0 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 instructio= n besides selecting the
> > unallocated area.
>
> That= 's what I was hoping to hear - thanks.
>
> > To force Wi= ndows to use one partition delete the ones it creates
> > automati= cally. You will need to select "custom" or "advanced" i= n every
> > place it is offered as an option.
> >
>= > > 2.=C2=A0 =C2=A0 =C2=A0 What will happen to the UEFI kernel entri= es in /dev/nvme0n1p1?
> >
> > When people say "entri= es" they are usually referring to settings in
> > the nonvola= tile 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 thi= ngs 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 varia= bles (it may manage kernels also, I am not entirely sure). Are you sure thi= s isn't related to the bug Mick mentioned? If it is then I am unsure wh= y efibootmgr works.

Now it's fixed (by usi= ng something else) and I can't expect you to care, but I am left perple= xed.

> > The actual kernels on /dev/nvme= 0np1 will remain there because Windows
> > won't touch that pa= rtition unless you tell it to.
> >
> > > 3.=C2=A0 =C2= =A0 =C2=A0 Those entries include some left over from experimenting with
= > > > other distros. How can I manage the entries and purge the on= es I don't
> > > need? "Bootctl remove" ignores t= hem.
> >
> > 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.
> &g= t;
> > > 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 occas= ional 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
> &g= t; put it in another computer and boot it (or boot it in the same
> &= gt; 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
> > coul= d. This might not be possible with Windows.
> >
> > If yo= u install into a VM you can pass almost everything to the VM
> > d= irectly. 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<= br>> > this isn't a very plug-and-play solution.
> >
= > > Aside from firmware updates (realize though that almost everythin= g -
> > 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 fi= nd it easier to get
> > work done in this way while using Windows = programs. Xfreerdp is a good
> > way to interact with a Windows gu= est and can provide better desktop
> > integration than QEMU or li= bvirtd.
>
> I use VirtualBox here, mostly because some BOINC pr= ojects require it.
>

Fair enough.
--001a114d72921cc1300559831d9b--