Bug#789798: Bug#792547 / Bug#789798: grub-installer / grub2: add option to _not_ install to UEFI boot order

[Holger Wansing]

> Ian Jackson writes ("Bug#792547: grub-installer: add option to _not_ install 
> to UEFI boot order"):
> > I see that Ian C updated this patch (in July 2015) and reported
> > testing it successfully.  Is it now OK ?
> 
> every Debian release I update our workaround to apply to the current
> release.  FTR, I am just updating our workaround to apply to buster.
> (I see the grub2 package is RFH.)
> 
> Ian.

What's the status here?
Should we push that in for Bullseye?

Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#789798: Bug#792547: grub-installer: add option to _not_ install to UEFI boot order

[Ian Jackson]

Ian Jackson writes ("Bug#792547: grub-installer: add option to _not_ install to 
UEFI boot order"):
> I see that Ian C updated this patch (in July 2015) and reported
> testing it successfully.  Is it now OK ?

every Debian release I update our workaround to apply to the current
release.  FTR, I am just updating our workaround to apply to buster.
(I see the grub2 package is RFH.)

Ian.

Processed: Re: Bug#931917: grub-installer: call efibootmgr (if available) to keep track of boot order/options

[Debian Bug Tracking System]

Processing control commands:

> tag -1 patch
Bug #931917 [grub-installer] grub-installer: call efibootmgr (if available) to 
keep track of boot order/options
Added tag(s) patch.

-- 
931917: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931917
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#931917: grub-installer: call efibootmgr (if available) to keep track of boot order/options

[Cyril Brulebois]

Control: tag -1 patch

Cyril Brulebois  (2019-07-12):
> With stretch, we were getting efibootmgr's output in the installer's
> syslog, which could help track down issues related to the boot sequence.
> 
> With buster, due to grub2's switch to using libefi* (since both the
> 2.02+dfsg1-14 and 2.02+dfsg1-15 uploads), efibootmgr is no longer used;
> it's kept in Recommends (since 2.02+dfsg1-17) though.
> 
> It would be great to check whether efibootmgr is present and to call it
> to get its output back into the installer's syslog.
> 
> This would have been helpful for the #931910 installation report, for
> example.
> 
> 
> Once it's implemented and tested in unstable/testing, I'll consider
> backporting this for a buster point release.

Untested commit pushed in the pu/efibootmgr-for-debugging-931917 branch.

Review/tests welcome!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#931917: grub-installer: call efibootmgr (if available) to keep track of boot order/options

[Cyril Brulebois]

Package: grub-installer
Version: 1.165
Severity: important

With stretch, we were getting efibootmgr's output in the installer's
syslog, which could help track down issues related to the boot sequence.

With buster, due to grub2's switch to using libefi* (since both the
2.02+dfsg1-14 and 2.02+dfsg1-15 uploads), efibootmgr is no longer used;
it's kept in Recommends (since 2.02+dfsg1-17) though.

It would be great to check whether efibootmgr is present and to call it
to get its output back into the installer's syslog.

This would have been helpful for the #931910 installation report, for
example.


Once it's implemented and tested in unstable/testing, I'll consider
backporting this for a buster point release.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

Re: Boot Order

[Dan Norton]

On Wed, 28 Feb 2018 11:41:30 -0500
lsore...@csclub.uwaterloo.ca (Lennart Sorensen) wrote:

> On Tue, Feb 27, 2018 at 09:01:18PM -0500, Dan Norton wrote:
> > Why insert itself anywhere in the first place? The machine booted
> > before the installation. To start installing, the installation
> > medium is placed in a CD drive or USB port and the machine is
> > rebooted. During installation, other OSs are detected by the
> > installer. The installer forms the grub menu with the latest
> > install first and the other OSs following. Installer finishes by
> > reminding the admin to remove the installation medium and it
> > reboots the machine. The latest install boots unless the admin
> > intervenes. Where in this process is a requirement to tinker with
> > the UEFI menu?  
> 
> How are you supposed to get grub to run at all if you don't add a boot
> entry for it?  The grub is installed by this installer after.
> 
> There is nothing that makes the latest install boot unless you add it
> to the boot order.  On legacy bios it was different because there you
> just put what you wanted into the MBR boot sector and the BIOS was
> typically configured to boot from the harddisk.  UEFI does not work
> that way.  UEFI uses an explicit entry specifying which filename to
> boot from which harddisk.  So an entry is created specifying to boot
> the grub_x64.efi file from the FAT partition containing the
> bootloaders.
> 
> Now there are some default filenames that UEFI will look for if not
> explicitly told, but they are not always supported and most installers
> don't use those filenames because it isn't reliable, and the explicit
> entry is the official way to do it.
> 
> The installer has no way to tell what else was on your system already
> and how it booted.
> 

OK, I think I see. Installer is not replacing something with grub, it
is adding grub to the ESP, leaving anything else that might be there
alone. Therefore it must make the UEFI menu point to grub. If there is
something from windows, etc. there it is ignored(?). In contrast, with
the primary/logical partitioning scheme it could just rewrite the mbr
and let the user pick alternative systems, if any, from the grub menu.

That leaves the issue of boot order, but with all the possible
configurations and names for entries in the UEFI menu, putting the
latest first instead of trying to parse all that stuff makes sense.

Taking a look at what efibootmgr reports...

# efibootmgr
BootCurrent: 
Timeout: 9 seconds
BootOrder: 0003,0001,0002,,0004,0005,0006
Boot* debian
Boot0001* USB Floppy/CD
Boot0002* USB Hard Drive
Boot0003* ATAPI CD-ROM Drive
Boot0004* Unknown Device
Boot0005* USB Floppy/CD
Boot0006* Hard Drive

...but, if you go into the setup menu on my PC (POST -> Esc) you
see some 'UEFI Boot Sources' and some 'Legacy Boot Sources' with common
items. However, 'debian' is exclusively in the UEFI list and 'Hard
Drive' is exclusively in the Legacy list. One cannot be moved to the
other. If 6 were put first in the boot order or made current, it might
try to legacy boot windows, but windows is long gone. This disk was
cleaned off and several debian distros installed with the GPT and LVM
schemes. 

Thanks very much everybody.

 - Dan

Re: Boot Order

[Lennart Sorensen]

On Tue, Feb 27, 2018 at 09:01:18PM -0500, Dan Norton wrote:
> Why insert itself anywhere in the first place? The machine booted
> before the installation. To start installing, the installation medium
> is placed in a CD drive or USB port and the machine is rebooted. During
> installation, other OSs are detected by the installer. The installer
> forms the grub menu with the latest install first and the other OSs
> following. Installer finishes by reminding the admin to remove the
> installation medium and it reboots the machine. The latest install
> boots unless the admin intervenes. Where in this process is a
> requirement to tinker with the UEFI menu?

How are you supposed to get grub to run at all if you don't add a boot
entry for it?  The grub is installed by this installer after.

There is nothing that makes the latest install boot unless you add it
to the boot order.  On legacy bios it was different because there you
just put what you wanted into the MBR boot sector and the BIOS was
typically configured to boot from the harddisk.  UEFI does not work
that way.  UEFI uses an explicit entry specifying which filename to boot
from which harddisk.  So an entry is created specifying to boot the
grub_x64.efi file from the FAT partition containing the bootloaders.

Now there are some default filenames that UEFI will look for if not
explicitly told, but they are not always supported and most installers
don't use those filenames because it isn't reliable, and the explicit
entry is the official way to do it.

The installer has no way to tell what else was on your system already
and how it booted.

-- 
Len Sorensen

Re: Boot Order

[Ian Campbell]

On Wed, 2018-02-28 at 02:16 +, Steve McIntyre wrote:
> On Tue, Feb 27, 2018 at 09:01:18PM -0500, Dan Norton wrote:
> > On Mon, 26 Feb 2018 10:40:20 -0500
> > lsore...@csclub.uwaterloo.ca (Lennart Sorensen) wrote:
> > > 
> > > With UEFI, adding an entry to the boot meny is what you do when
> > > you
> > > install an OS you want to be able to boot.  UEFI does not rely on
> > > the
> > > boot sector anymore the way legacy BIOS did.
> > > 
> > > Adding it first makes sense since why install it if you don't
> > > want to
> > > use it?  Advanced users can always rearrange the order if they
> > > want
> > > something else.  No way an installer could guess where in an
> > > existing
> > > list to insert itself.  First is the only sane default option.
> > > 
> > 
> > Why insert itself anywhere in the first place? The machine booted
> > before the installation. To start installing, the installation
> > medium
> > is placed in a CD drive or USB port and the machine is rebooted.
> > During
> > installation, other OSs are detected by the installer. The
> > installer
> > forms the grub menu with the latest install first and the other OSs
> > following. Installer finishes by reminding the admin to remove the
> > installation medium and it reboots the machine. The latest install
> > boots unless the admin intervenes. Where in this process is a
> > requirement to tinker with the UEFI menu?
> 
> As Lennart said: "adding an entry to the boot meny is what you do when
> you install an OS you want to be able to boot". Adding an entry in the
> UEFI boot variables *is how UEFI is meant to work*. If you don't add
> an entry there, a correctly-working UEFI won't know how to find the OS
> you just installed.

The entry which Debian is adding to the UEFI boot menu is really a
pointer to the Grub (so a more technically correct title for the entry
would be "Debian's Grub bootloader"[0], but that would be terrible from
a UI perspective).

If Debian didn't install Grub into the UEFI boot menu then nothing else
in the system would know how to read and interpret the Grub menu. So
installing Grub is needed for:

> > The installer forms the grub menu

to have any meaning/use.

The system probably has a Windows bootloader preinstalled (probably
labelled "Hard Drive" in the UEFI menu) but that is not as flexible as
Grub and Debian does/will not mess around with its configuration files.

Ian.

[0] In the same way I suggested earlier that "Hard Drive" was just what
MS (or the system builder or whoever) has decided to call the entry
which points to the Windows bootloader. That's a reasonable choice for
an ecosystem where some large majority of users do not install an
alternative (either replacement or dual boot) OS. In Debian's case a
more specificly named entry makes sense.

Re: Boot Order

[Steve McIntyre]

On Tue, Feb 27, 2018 at 09:01:18PM -0500, Dan Norton wrote:
>On Mon, 26 Feb 2018 10:40:20 -0500
>lsore...@csclub.uwaterloo.ca (Lennart Sorensen) wrote:
>> 
>> With UEFI, adding an entry to the boot meny is what you do when you
>> install an OS you want to be able to boot.  UEFI does not rely on the
>> boot sector anymore the way legacy BIOS did.
>> 
>> Adding it first makes sense since why install it if you don't want to
>> use it?  Advanced users can always rearrange the order if they want
>> something else.  No way an installer could guess where in an existing
>> list to insert itself.  First is the only sane default option.
>> 
>Why insert itself anywhere in the first place? The machine booted
>before the installation. To start installing, the installation medium
>is placed in a CD drive or USB port and the machine is rebooted. During
>installation, other OSs are detected by the installer. The installer
>forms the grub menu with the latest install first and the other OSs
>following. Installer finishes by reminding the admin to remove the
>installation medium and it reboots the machine. The latest install
>boots unless the admin intervenes. Where in this process is a
>requirement to tinker with the UEFI menu?

As Lennart said: "adding an entry to the boot meny is what you do when
you install an OS you want to be able to boot". Adding an entry in the
UEFI boot variables *is how UEFI is meant to work*. If you don't add
an entry there, a correctly-working UEFI won't know how to find the OS
you just installed.

There's more information about Debian and UEFI in https://wiki.debian.org/UEFI

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver." -- Daniel Pead

Re: Boot Order

[Dan Norton]

On Mon, 26 Feb 2018 10:40:20 -0500
lsore...@csclub.uwaterloo.ca (Lennart Sorensen) wrote:

> On Fri, Feb 23, 2018 at 10:18:00PM -0500, Dan Norton wrote:
> > Installing either stretch or buster via netinst results in changes
> > to the bios menu. Under "UEFI Boot Sources" the term "Hard Drive" is
> > replaced with "debian" and this entry is put first in the boot
> > order.
> > 
> > The PC is:
> > Hewlett-Packard HP Pro 3400 Series MT/2ABF, BIOS 7.16 03/23/2012
> > 
> > Please tell me the justification for putting "debian" in the menu
> > and having it boot first, ahead of CD/DVD/USB. Thanks.  
> 
> With UEFI, adding an entry to the boot meny is what you do when you
> install an OS you want to be able to boot.  UEFI does not rely on the
> boot sector anymore the way legacy BIOS did.
> 
> Adding it first makes sense since why install it if you don't want to
> use it?  Advanced users can always rearrange the order if they want
> something else.  No way an installer could guess where in an existing
> list to insert itself.  First is the only sane default option.
> 

Why insert itself anywhere in the first place? The machine booted
before the installation. To start installing, the installation medium
is placed in a CD drive or USB port and the machine is rebooted. During
installation, other OSs are detected by the installer. The installer
forms the grub menu with the latest install first and the other OSs
following. Installer finishes by reminding the admin to remove the
installation medium and it reboots the machine. The latest install
boots unless the admin intervenes. Where in this process is a
requirement to tinker with the UEFI menu?

Re: Boot Order

[Lennart Sorensen]

On Mon, Feb 26, 2018 at 05:42:36PM -0500, Dan Norton wrote:
> I would hate to have to do something because windows does it :-)
> 
> No one's yet mentioned secure boot as a justification. AIUI some
> manufacturers are making it so that you can't even disable secure boot.
> How will you multi-boot linux and windows, or replace windows entirely
> with such a machine?

Secureboot has nothing to do with it.  All secureboot means is that it
won't boot something that isn't signed by a trusted key.  So if enabled
you wouldn't be able to even boot the installer if it wasn't signed.

I have not yet seen a machine where you can't disable secureboot.
For Windows 8 it was a requirement to allow disabling it (but to have
it enabled by default) to get a Windows 8 Lego on the box.  I think
Windows 10 has the same requirement.  Now on some machines you have to
set a UEFI admin password before you get the option to disable secureboot
for some reason.

-- 
Len Sorensen

Re: Boot Order

[Geert Stappers]

On Mon, Feb 26, 2018 at 05:42:36PM -0500, Dan Norton wrote:
> No one's yet mentioned secure boot as a justification. AIUI some
> manufacturers are making it so that you can't even disable secure boot.
> How will you multi-boot linux and windows, or replace windows entirely
> with such a machine?

That problem is solved by wallet voting.


Groeten
Geert Stappers
-- 
Leven en laten leven

Re: Boot Order

[Dan Norton]

On Mon, 26 Feb 2018 10:40:20 -0500
lsore...@csclub.uwaterloo.ca (Lennart Sorensen) wrote:

> On Fri, Feb 23, 2018 at 10:18:00PM -0500, Dan Norton wrote:
> > Installing either stretch or buster via netinst results in changes
> > to the bios menu. Under "UEFI Boot Sources" the term "Hard Drive" is
> > replaced with "debian" and this entry is put first in the boot
> > order.
> > 
> > The PC is:
> > Hewlett-Packard HP Pro 3400 Series MT/2ABF, BIOS 7.16 03/23/2012
> > 
> > Please tell me the justification for putting "debian" in the menu
> > and having it boot first, ahead of CD/DVD/USB. Thanks.  
> 
> With UEFI, adding an entry to the boot meny is what you do when you
> install an OS you want to be able to boot.  UEFI does not rely on the
> boot sector anymore the way legacy BIOS did.
> 
> Adding it first makes sense since why install it if you don't want to
> use it?  Advanced users can always rearrange the order if they want
> something else.  No way an installer could guess where in an existing
> list to insert itself.  First is the only sane default option.
> 
> Having a system default to booting from USB or CD makes no sense and
> is rather unsafe too.
> 
> Installing windows does the same thing, as it should.
> 

I would hate to have to do something because windows does it :-)

No one's yet mentioned secure boot as a justification. AIUI some
manufacturers are making it so that you can't even disable secure boot.
How will you multi-boot linux and windows, or replace windows entirely
with such a machine?

Re: Boot Order

[Dan Norton]

On Mon, 26 Feb 2018 16:54:22 +
Steve McIntyre  wrote:

> It seems Dan Norton has decided to selfishly make *his* spam problem
> into everybody else's spam problem, and I've just had a bounce message
> in response to my mail below, saying I have to ask to be added to his
> list of allowed senders. I refuse to pander to this - I guess he will
> have to do without any help...
> 

Your previous post came through on the list. I guess the problem you're
alluding to came because you also cc'd me directly, which was
unnecessary.

I appreciate your response. Sorry for any inconvenience.

> On Mon, Feb 26, 2018 at 04:46:16PM +, Steve McIntyre wrote:
> >On Sat, Feb 24, 2018 at 02:59:44PM -0500, Dan Norton wrote:  
> >>
> >>After installing stretch, it changed to:
> >>
> >>UEFI Boot Sources
> >>  debian
> >>  ATAPI CD/DVD Drive
> >>  USB Floppy/CD
> >>  USB Hard Drive
> >>Legacy Boot Sources
> >>  [...]
> >>
> >>If done by firmware, wouldn't grub or the installer have to tell
> >>the firmware to put "debian" in the bios menu and make it first? In
> >>its past life, this PC ran Windows 7 but in order to boot from
> >>mountable media there was no need for the user to change the boot
> >>order.  
> >
> >You've been bitten by an unexpected change due to your PC's vendor
> >doing crap setup, I'm afraid. For your setup to have worked, that
> >means that you had a Windows setup using BIOS boot, but the BIOS set
> >to boot UEFI first then BIOS second. If you want sensible dual boot
> >with a BIOS-booting Windows, the best way to achieve that is to turn
> >UEFI boot *off* in the BIOS setup so you have consistency between the
> >two OSes. The installer even has code to check for this setup and
> >offer you a chance to *not* install in UEFI mode if it detects traces
> >of BIOS-booting OSes on your system.
> >
> >-- 
> >Steve McIntyre, Cambridge, UK.
> >st...@einval.com
> >  Getting a SCSI chain working is perfectly simple if you remember
> > that there must be exactly three terminations: one on one end of
> > the cable, one on the far end, and the goat, terminated over the
> > SCSI chain with a silver-handled knife whilst burning *black*
> > candles. --- Anthony DeBoer  

Re: Boot Order

[Ian Campbell]

On Mon, 2018-02-26 at 16:54 +, Steve McIntyre wrote:
> It seems Dan Norton has decided to selfishly make *his* spam problem
> into everybody else's spam problem, and I've just had a bounce
> message
> in response to my mail below, saying I have to ask to be added to his
> list of allowed senders. I refuse to pander to this - I guess he will
> have to do without any help...

He's been following our usual (for Debian) no-cc rule[0] when replying
to list posts and others have been doing so as well in this thread
(e.g. I got no bounce because I didn't cc him). I expect he will see
(and is expecting) the list copy.

Ian.

[0] it does seem to be getting less common around here generally
though...

Re: Boot Order

[Steve McIntyre]

It seems Dan Norton has decided to selfishly make *his* spam problem
into everybody else's spam problem, and I've just had a bounce message
in response to my mail below, saying I have to ask to be added to his
list of allowed senders. I refuse to pander to this - I guess he will
have to do without any help...

On Mon, Feb 26, 2018 at 04:46:16PM +, Steve McIntyre wrote:
>On Sat, Feb 24, 2018 at 02:59:44PM -0500, Dan Norton wrote:
>>
>>After installing stretch, it changed to:
>>
>>UEFI Boot Sources
>>  debian
>>  ATAPI CD/DVD Drive
>>  USB Floppy/CD
>>  USB Hard Drive
>>Legacy Boot Sources
>>  [...]
>>
>>If done by firmware, wouldn't grub or the installer have to tell
>>the firmware to put "debian" in the bios menu and make it first? In its
>>past life, this PC ran Windows 7 but in order to boot from mountable
>>media there was no need for the user to change the boot order.
>
>You've been bitten by an unexpected change due to your PC's vendor
>doing crap setup, I'm afraid. For your setup to have worked, that
>means that you had a Windows setup using BIOS boot, but the BIOS set
>to boot UEFI first then BIOS second. If you want sensible dual boot
>with a BIOS-booting Windows, the best way to achieve that is to turn
>UEFI boot *off* in the BIOS setup so you have consistency between the
>two OSes. The installer even has code to check for this setup and
>offer you a chance to *not* install in UEFI mode if it detects traces
>of BIOS-booting OSes on your system.
>
>-- 
>Steve McIntyre, Cambridge, UK.st...@einval.com
>  Getting a SCSI chain working is perfectly simple if you remember that there
>  must be exactly three terminations: one on one end of the cable, one on the
>  far end, and the goat, terminated over the SCSI chain with a silver-handled
>  knife whilst burning *black* candles. --- Anthony DeBoer
-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Re: Boot Order

[Steve McIntyre]

On Sat, Feb 24, 2018 at 02:59:44PM -0500, Dan Norton wrote:
>
>After installing stretch, it changed to:
>
>UEFI Boot Sources
>  debian
>  ATAPI CD/DVD Drive
>  USB Floppy/CD
>  USB Hard Drive
>Legacy Boot Sources
>  [...]
>
>If done by firmware, wouldn't grub or the installer have to tell
>the firmware to put "debian" in the bios menu and make it first? In its
>past life, this PC ran Windows 7 but in order to boot from mountable
>media there was no need for the user to change the boot order.

You've been bitten by an unexpected change due to your PC's vendor
doing crap setup, I'm afraid. For your setup to have worked, that
means that you had a Windows setup using BIOS boot, but the BIOS set
to boot UEFI first then BIOS second. If you want sensible dual boot
with a BIOS-booting Windows, the best way to achieve that is to turn
UEFI boot *off* in the BIOS setup so you have consistency between the
two OSes. The installer even has code to check for this setup and
offer you a chance to *not* install in UEFI mode if it detects traces
of BIOS-booting OSes on your system.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Getting a SCSI chain working is perfectly simple if you remember that there
  must be exactly three terminations: one on one end of the cable, one on the
  far end, and the goat, terminated over the SCSI chain with a silver-handled
  knife whilst burning *black* candles. --- Anthony DeBoer

Re: Boot Order

[Steve McIntyre]

On Mon, Feb 26, 2018 at 10:40:20AM -0500, Lennart Sorensen wrote:
>On Fri, Feb 23, 2018 at 10:18:00PM -0500, Dan Norton wrote:
>> Installing either stretch or buster via netinst results in changes to
>> the bios menu. Under "UEFI Boot Sources" the term "Hard Drive" is
>> replaced with "debian" and this entry is put first in the boot order.
>> 
>> The PC is:
>> Hewlett-Packard HP Pro 3400 Series MT/2ABF, BIOS 7.16 03/23/2012
>> 
>> Please tell me the justification for putting "debian" in the menu and
>> having it boot first, ahead of CD/DVD/USB. Thanks.
>
>With UEFI, adding an entry to the boot meny is what you do when you
>install an OS you want to be able to boot.  UEFI does not rely on the
>boot sector anymore the way legacy BIOS did.
>
>Adding it first makes sense since why install it if you don't want to
>use it?  Advanced users can always rearrange the order if they want
>something else.  No way an installer could guess where in an existing
>list to insert itself.  First is the only sane default option.
>
>Having a system default to booting from USB or CD makes no sense and is
>rather unsafe too.
>
>Installing windows does the same thing, as it should.

You beat me to it Lennart - this is exactly what I was just about to
write. :-)

Dan: this is the standard way that things are meant to work with UEFI;
it's rather more sophisticated than older BIOS setups...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess

Re: Boot Order

[Lennart Sorensen]

On Fri, Feb 23, 2018 at 10:18:00PM -0500, Dan Norton wrote:
> Installing either stretch or buster via netinst results in changes to
> the bios menu. Under "UEFI Boot Sources" the term "Hard Drive" is
> replaced with "debian" and this entry is put first in the boot order.
> 
> The PC is:
> Hewlett-Packard HP Pro 3400 Series MT/2ABF, BIOS 7.16 03/23/2012
> 
> Please tell me the justification for putting "debian" in the menu and
> having it boot first, ahead of CD/DVD/USB. Thanks.

With UEFI, adding an entry to the boot meny is what you do when you
install an OS you want to be able to boot.  UEFI does not rely on the
boot sector anymore the way legacy BIOS did.

Adding it first makes sense since why install it if you don't want to
use it?  Advanced users can always rearrange the order if they want
something else.  No way an installer could guess where in an existing
list to insert itself.  First is the only sane default option.

Having a system default to booting from USB or CD makes no sense and is
rather unsafe too.

Installing windows does the same thing, as it should.

-- 
Len Sorensen

Re: Boot Order

[Ian Campbell]

On Sun, 2018-02-25 at 17:03 -0500, Dan Norton wrote:
> On Sat, 24 Feb 2018 14:59:44 -0500
> Dan Norton  wrote:
> 
> > On Sat, 24 Feb 2018 18:37:02 +0100
> > Ben Hutchings  wrote:
> > 
> > > On Fri, 2018-02-23 at 22:18 -0500, Dan Norton wrote:  
> > > > Installing either stretch or buster via netinst results in changes
> > > > to the bios menu. Under "UEFI Boot Sources" the term "Hard Drive"
> > > > is replaced with "debian" and this entry is put first in the boot
> > > > order.
> > > > 
> > > > The PC is:
> > > > Hewlett-Packard HP Pro 3400 Series MT/2ABF, BIOS 7.16 03/23/2012
> > > > 
> > > > Please tell me the justification for putting "debian" in the menu
> > > > and having it boot first, ahead of CD/DVD/USB. Thanks.
> > > 
> > > If there are multiple bootable operating systems on local hard
> > > drives, I think the installer sets Debian to be higher priority
> > > than the other operating systems.
> > >   
> > 
> > In my case, there are multiple debian installations and the installer
> > positions the last installation at the top of the *grub* menu. This
> > makes sense. But why change the *bios* menu? With the variability in
> > manufacturers bios code, changing the bios menu seems like a risky,
> > tricky, and tedious undertaking. AFAICT it's instigated by the
> > installer and presumably a necessary thing. I've searched for the
> > rationale, but have missed it, if it's out there. Can you refer me to
> > something?
> > 
> > > But as far as I am aware, the relative priority of boot entries on
> > > removable vs hard drives is solely controlled by the BIOS/UEFI
> > > firmware.
> > >   
> > 
> > That just doesn't seem logical. There was a perfectly good priority,
> > before installs of Debian, I think it went:
> > 
> > UEFI Boot Sources
> >   ATAPI CD/DVD Drive
> >   USB Floppy/CD
> >   Hard Drive
> >   USB Hard Drive
> > Legacy Boot Sources
> >   ATAPI CD/DVD Drive
> >   USB Floppy/CD
> >   Hard Drive
> > SATA0
> > 
> > After installing stretch, it changed to:
> > 
> > UEFI Boot Sources
> >   debian
> >   ATAPI CD/DVD Drive
> >   USB Floppy/CD
> >   USB Hard Drive
> > Legacy Boot Sources
> >   [...]
> > 
> > If done by firmware, wouldn't grub or the installer have to tell
> > the firmware to put "debian" in the bios menu and make it first? In
> > its past life, this PC ran Windows 7 but in order to boot from
> > mountable media there was no need for the user to change the boot
> > order.
> > 
> 
> There is a description of sorts for UEFI and bios booting in [1] and in
> the section on "The UEFI boot manager" it says "Linux distributions
> contain a tool called efibootmgr which is used to manipulate the
> configuration of the UEFI boot manager"
> 
> $ man efibootmgr
> 
> DESCRIPTION
>...This application can create and destroy boot entries, change
>the boot order, ... and more.
> OPTIONS
>[...]
>-c | --create
>   Create new variable bootnum and add to bootorder
>[...]
>-L | --label LABEL
>   Boot manager display label (defaults to "Linux")
> 
> Debian Code Search for "efibootmgr" shows that grub2 code calls it and
> uses the -c and -L options, among others.
> 
> I was not able to figure out how "Linux" is replaced by "debian"

I think it is usually `grub-install` which calls `efibootmgr` and it
seems to pass `"-L", efi_distributor` where `efi_distributor` would be
"debian" in the case of grub packaged for Debian.

>  but it
> looks like this is what is changing the boot order but I still don't
> know *why* - any hints?

I suspect there may be a general assumption (I don't mean within Debian
or Grub but in the world at large) that if you install something new
then it is what you want to boot in the future. The vast majority of
systems only boot a single operation system and I could see system
manufacturers and/or consumer OS producers with a lot of clout deciding
that booting from a CD by default is more likely to confuse the average
user than be what they actually wanted and be happy to require
documentation to "Press F?? and choose CD" for the uncommon case.

`efibootmgr` doesn't appear to have any options to control the
placement of the new option within the boot order when using `-c`, only

Re: Boot Order

[Dan Norton]

On Sat, 24 Feb 2018 14:59:44 -0500
Dan Norton  wrote:

> On Sat, 24 Feb 2018 18:37:02 +0100
> Ben Hutchings  wrote:
> 
> > On Fri, 2018-02-23 at 22:18 -0500, Dan Norton wrote:  
> > > Installing either stretch or buster via netinst results in changes
> > > to the bios menu. Under "UEFI Boot Sources" the term "Hard Drive"
> > > is replaced with "debian" and this entry is put first in the boot
> > > order.
> > > 
> > > The PC is:
> > > Hewlett-Packard HP Pro 3400 Series MT/2ABF, BIOS 7.16 03/23/2012
> > > 
> > > Please tell me the justification for putting "debian" in the menu
> > > and having it boot first, ahead of CD/DVD/USB. Thanks.
> > 
> > If there are multiple bootable operating systems on local hard
> > drives, I think the installer sets Debian to be higher priority
> > than the other operating systems.
> >   
> 
> In my case, there are multiple debian installations and the installer
> positions the last installation at the top of the *grub* menu. This
> makes sense. But why change the *bios* menu? With the variability in
> manufacturers bios code, changing the bios menu seems like a risky,
> tricky, and tedious undertaking. AFAICT it's instigated by the
> installer and presumably a necessary thing. I've searched for the
> rationale, but have missed it, if it's out there. Can you refer me to
> something?
> 
> > But as far as I am aware, the relative priority of boot entries on
> > removable vs hard drives is solely controlled by the BIOS/UEFI
> > firmware.
> >   
> 
> That just doesn't seem logical. There was a perfectly good priority,
> before installs of Debian, I think it went:
> 
> UEFI Boot Sources
>   ATAPI CD/DVD Drive
>   USB Floppy/CD
>   Hard Drive
>   USB Hard Drive
> Legacy Boot Sources
>   ATAPI CD/DVD Drive
>   USB Floppy/CD
>   Hard Drive
> SATA0
> 
> After installing stretch, it changed to:
> 
> UEFI Boot Sources
>   debian
>   ATAPI CD/DVD Drive
>   USB Floppy/CD
>   USB Hard Drive
> Legacy Boot Sources
>   [...]
> 
> If done by firmware, wouldn't grub or the installer have to tell
> the firmware to put "debian" in the bios menu and make it first? In
> its past life, this PC ran Windows 7 but in order to boot from
> mountable media there was no need for the user to change the boot
> order.
> 

There is a description of sorts for UEFI and bios booting in [1] and in
the section on "The UEFI boot manager" it says "Linux distributions
contain a tool called efibootmgr which is used to manipulate the
configuration of the UEFI boot manager"

$ man efibootmgr

DESCRIPTION
   ...This application can create and destroy boot entries, change
   the boot order, ... and more.
OPTIONS
   [...]
   -c | --create
  Create new variable bootnum and add to bootorder
   [...]
   -L | --label LABEL
  Boot manager display label (defaults to "Linux")

Debian Code Search for "efibootmgr" shows that grub2 code calls it and
uses the -c and -L options, among others.

I was not able to figure out how "Linux" is replaced by "debian" but it
looks like this is what is changing the boot order but I still don't
know *why* - any hints?

[1]
https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/

Re: Boot Order

[Richard Owlett]

On 02/25/2018 02:35 AM, Ian Campbell wrote:

On Sat, 2018-02-24 at 14:18 -0600, Richard Owlett wrote:

On 02/24/2018 01:59 PM, Dan Norton wrote:

[snip]

In my case, there are multiple debian installations and the

installer

positions the last installation at the top of the *grub* menu. This
makes sense.


Not always. I'm continually doing installs, tweaking them in one way or
another. The last install is the one most likely to "crash and burn". I
solve the problem by having grub installed ONLY on first partition of my
ONLY hard disk. I'd love to see an os-prober which created menu entries
in partition number order.


Why not send a patch which adds this as a (perhaps only preseedable or
certainly very low priority) option then?


Because I don't have the skill set. That's why I took the brute force 
approach.




You could also (I think) have grub installed by the installer to the
individual partitions and then have your primary grub installed in the
MBR configured to chain load to those.


I've seen chain loading mentioned, but never had need to understand it. 
Time for some reading. Thank you.

Re: Boot Order

[Ian Campbell]

On Sat, 2018-02-24 at 14:18 -0600, Richard Owlett wrote:
> On 02/24/2018 01:59 PM, Dan Norton wrote:
> > [snip]
> > 
> > In my case, there are multiple debian installations and the
> installer
> > positions the last installation at the top of the *grub* menu. This
> > makes sense.
> 
> Not always. I'm continually doing installs, tweaking them in one way or 
> another. The last install is the one most likely to "crash and burn". I 
> solve the problem by having grub installed ONLY on first partition of my 
> ONLY hard disk. I'd love to see an os-prober which created menu entries 
> in partition number order.

Why not send a patch which adds this as a (perhaps only preseedable or
certainly very low priority) option then?

You could also (I think) have grub installed by the installer to the
individual partitions and then have your primary grub installed in the
MBR configured to chain load to those.

Ian.

Re: Boot Order

[Richard Owlett]

On 02/24/2018 06:49 PM, Dan Norton wrote:

On Sat, 24 Feb 2018 14:18:13 -0600
Richard Owlett  wrote:


On 02/24/2018 01:59 PM, Dan Norton wrote:

[snip]

In my case, there are multiple debian installations and the
installer positions the last installation at the top of the *grub*
menu. This makes sense.


Not always. I'm continually doing installs, tweaking them in one way
or another. The last install is the one most likely to "crash and
burn". I solve the problem by having grub installed ONLY on first
partition of my ONLY hard disk. I'd love to see an os-prober which
created menu entries in partition number order.



With your many installs, have you needed to edit the bios menu so that
you could boot something mountable? IOW is debian first in the boot
order?
  


I have older machines. I only encounter a so-called legacy bios.
E.G. I type this on a Lenovo T510.

IOW I never deal with a "UEFI" bios, only a "Legacy" bios.

But independent of that, Debian annoyingly presumes that most recent 
install is Nirvana.


*NOT* true.


I.E. During a "Cold Boot" it prompts me to press the "Blue Thinkvantage" 
button to bring up a choice of boot devices.
My Lenovo desktop asks me to press "Enter/Return" at a similar point in 
the boot sequence.


I was explicitly referring to how Grub2 handles searching for boot-able 
OS since Squeeze.

Re: Boot Order

[Dan Norton]

On Sat, 24 Feb 2018 14:18:13 -0600
Richard Owlett  wrote:

> On 02/24/2018 01:59 PM, Dan Norton wrote:
> > [snip]
> > 
> > In my case, there are multiple debian installations and the
> > installer positions the last installation at the top of the *grub*
> > menu. This makes sense.  
> 
> Not always. I'm continually doing installs, tweaking them in one way
> or another. The last install is the one most likely to "crash and
> burn". I solve the problem by having grub installed ONLY on first
> partition of my ONLY hard disk. I'd love to see an os-prober which
> created menu entries in partition number order.
>

With your many installs, have you needed to edit the bios menu so that
you could boot something mountable? IOW is debian first in the boot
order?
 
> 
> 
> > But why change the *bios* menu? With the variability in
> > manufacturers bios code, changing the bios menu seems like a risky,
> > tricky, and tedious undertaking. AFAICT it's instigated by the
> > installer and presumably a necessary thing. I've searched for the
> > rationale, but have missed it, if it's out there. Can you refer me
> > to something?
> >   
> >> But as far as I am aware, the relative priority of boot entries on
> >> removable vs hard drives is solely controlled by the BIOS/UEFI
> >> firmware.
> >>  
> > 
> > That just doesn't seem logical. There was a perfectly good priority,
> > before installs of Debian, I think it went:
> > 
> > UEFI Boot Sources
> >ATAPI CD/DVD Drive
> >USB Floppy/CD
> >Hard Drive
> >USB Hard Drive
> > Legacy Boot Sources
> >ATAPI CD/DVD Drive
> >USB Floppy/CD
> >Hard Drive
> >  SATA0
> > 
> > After installing stretch, it changed to:
> > 
> > UEFI Boot Sources
> >debian
> >ATAPI CD/DVD Drive
> >USB Floppy/CD
> >USB Hard Drive
> > Legacy Boot Sources
> >[...]
> > 
> > If done by firmware, wouldn't grub or the installer have to tell
> > the firmware to put "debian" in the bios menu and make it first? In
> > its past life, this PC ran Windows 7 but in order to boot from
> > mountable media there was no need for the user to change the boot
> > order.
> > 
> >   - Dan
> > 
> >   
> 
> 

Re: Boot Order

[Richard Owlett]

On 02/24/2018 01:59 PM, Dan Norton wrote:

[snip]

In my case, there are multiple debian installations and the installer
positions the last installation at the top of the *grub* menu. This
makes sense.


Not always. I'm continually doing installs, tweaking them in one way or 
another. The last install is the one most likely to "crash and burn". I 
solve the problem by having grub installed ONLY on first partition of my 
ONLY hard disk. I'd love to see an os-prober which created menu entries 
in partition number order.





But why change the *bios* menu? With the variability in
manufacturers bios code, changing the bios menu seems like a risky,
tricky, and tedious undertaking. AFAICT it's instigated by the
installer and presumably a necessary thing. I've searched for the
rationale, but have missed it, if it's out there. Can you refer me to
something?


But as far as I am aware, the relative priority of boot entries on
removable vs hard drives is solely controlled by the BIOS/UEFI
firmware.



That just doesn't seem logical. There was a perfectly good priority,
before installs of Debian, I think it went:

UEFI Boot Sources
   ATAPI CD/DVD Drive
   USB Floppy/CD
   Hard Drive
   USB Hard Drive
Legacy Boot Sources
   ATAPI CD/DVD Drive
   USB Floppy/CD
   Hard Drive
 SATA0

After installing stretch, it changed to:

UEFI Boot Sources
   debian
   ATAPI CD/DVD Drive
   USB Floppy/CD
   USB Hard Drive
Legacy Boot Sources
   [...]

If done by firmware, wouldn't grub or the installer have to tell
the firmware to put "debian" in the bios menu and make it first? In its
past life, this PC ran Windows 7 but in order to boot from mountable
media there was no need for the user to change the boot order.

  - Dan

Re: Boot Order

[Dan Norton]

On Sat, 24 Feb 2018 18:37:02 +0100
Ben Hutchings  wrote:

> On Fri, 2018-02-23 at 22:18 -0500, Dan Norton wrote:
> > Installing either stretch or buster via netinst results in changes
> > to the bios menu. Under "UEFI Boot Sources" the term "Hard Drive" is
> > replaced with "debian" and this entry is put first in the boot
> > order.
> > 
> > The PC is:
> > Hewlett-Packard HP Pro 3400 Series MT/2ABF, BIOS 7.16 03/23/2012
> > 
> > Please tell me the justification for putting "debian" in the menu
> > and having it boot first, ahead of CD/DVD/USB. Thanks.  
> 
> If there are multiple bootable operating systems on local hard drives,
> I think the installer sets Debian to be higher priority than the other
> operating systems.
> 

In my case, there are multiple debian installations and the installer
positions the last installation at the top of the *grub* menu. This
makes sense. But why change the *bios* menu? With the variability in
manufacturers bios code, changing the bios menu seems like a risky,
tricky, and tedious undertaking. AFAICT it's instigated by the
installer and presumably a necessary thing. I've searched for the
rationale, but have missed it, if it's out there. Can you refer me to
something?

> But as far as I am aware, the relative priority of boot entries on
> removable vs hard drives is solely controlled by the BIOS/UEFI
> firmware.
> 

That just doesn't seem logical. There was a perfectly good priority,
before installs of Debian, I think it went:

UEFI Boot Sources
  ATAPI CD/DVD Drive
  USB Floppy/CD
  Hard Drive
  USB Hard Drive
Legacy Boot Sources
  ATAPI CD/DVD Drive
  USB Floppy/CD
  Hard Drive
SATA0

After installing stretch, it changed to:

UEFI Boot Sources
  debian
  ATAPI CD/DVD Drive
  USB Floppy/CD
  USB Hard Drive
Legacy Boot Sources
  [...]

If done by firmware, wouldn't grub or the installer have to tell
the firmware to put "debian" in the bios menu and make it first? In its
past life, this PC ran Windows 7 but in order to boot from mountable
media there was no need for the user to change the boot order.

 - Dan

Re: Boot Order

[Ben Hutchings]

On Fri, 2018-02-23 at 22:18 -0500, Dan Norton wrote:
> Installing either stretch or buster via netinst results in changes to
> the bios menu. Under "UEFI Boot Sources" the term "Hard Drive" is
> replaced with "debian" and this entry is put first in the boot order.
> 
> The PC is:
> Hewlett-Packard HP Pro 3400 Series MT/2ABF, BIOS 7.16 03/23/2012
> 
> Please tell me the justification for putting "debian" in the menu and
> having it boot first, ahead of CD/DVD/USB. Thanks.

If there are multiple bootable operating systems on local hard drives,
I think the installer sets Debian to be higher priority than the other
operating systems.

But as far as I am aware, the relative priority of boot entries on
removable vs hard drives is solely controlled by the BIOS/UEFI
firmware.

Ben.

-- 
Ben Hutchings
Life is what happens to you while you're busy making other plans.
  - John Lennon



signature.asc
Description: This is a digitally signed message part

Re: Boot Order

[Geert Stappers]

On Fri, Feb 23, 2018 at 10:18:00PM -0500, Dan Norton wrote:
> Installing either stretch or buster via netinst results in changes to
> the bios menu. Under "UEFI Boot Sources" the term "Hard Drive" is
> replaced with "debian" and this entry is put first in the boot order.
> 
> The PC is:
> Hewlett-Packard HP Pro 3400 Series MT/2ABF, BIOS 7.16 03/23/2012
> 
> Please tell me the justification for putting "debian" in the menu and
> having it boot first, ahead of CD/DVD/USB. Thanks.

Preamble: this mailinglist is about software development of the installer


The idea of an install is to get the computer working with that installation.

What I understand from the "Please tell me" request, is that goal accomplished.

But I also recieve a "It is not optimal for original poster".
My advice to OP: Take some time to write down your optimum.


See also http://catb.org/esr/faqs/smart-questions.html

Groeten
Geert Stappers
-- 
Leven en laten leven

Boot Order

[Dan Norton]

Installing either stretch or buster via netinst results in changes to
the bios menu. Under "UEFI Boot Sources" the term "Hard Drive" is
replaced with "debian" and this entry is put first in the boot order.

The PC is:
Hewlett-Packard HP Pro 3400 Series MT/2ABF, BIOS 7.16 03/23/2012

Please tell me the justification for putting "debian" in the menu and
having it boot first, ahead of CD/DVD/USB. Thanks.

 - Dan

Bug#789798: Bug#792547: Bug#789798: grub-installer: add option to _not_ install to UEFI boot order

[Ian Campbell]

On Thu, 2015-07-16 at 08:34 +0100, Ian Campbell wrote:
> Control: block 789798 by 792547
> 
> I've tested both of these patches (grub-installer [0] and grub2 [1]
> together but the grub-installer one doesn't do much without the grub2
> one, since it appears that the installation of the grub-* packages also
> ends up running grub-install during installation.

To clarify, I rebuilt the Jessie d-i version with this modified
grub-installer included in the initrd and did two tests:

A normal x86/UEFI install, from mini.iso, which showed no change in
behaviour (i.e. Debian was added to the boot order as expected). In the
installed system I then installed the updated version of grub2 and
manually confirmed that /var/cache/debconf/config.dat had the new option
set to true and that having deleted Debian from the boot order
dpkg-reconfigure grub-efi-amd64 put it back and that dpkg-reconfigure
-plow grub-efi-amd64 asked me the question and it behaved as expected
(i.e. didn't add the entry if I deselected the new option).

I then reinstalled using my patched d-i but with
grub-installer/install-to-nvram=false added tothe kernel command line. I
ran through the install and observed in syslog that grub-installer had
passed --no-nvram but that Debian was added to the boot order by the
existing grub2 packages from the archive (not my patched version) as
they were installed. Then in the installed system I confirmed
that /var/cache/debconf/config.dat had the new question in it set to
false. Deleting the boot order and then installing my patched grub2
packages then correctly obeyed that setting, leading me to conclude that
if it had been present in the archive during install then the right
thing would have happened.

Ian.

> 
> Ian.
> 
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789798#65
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792547#5
> 
> ___
> Pkg-grub-devel mailing list
> pkg-grub-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grub-devel
> 


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1437037142.32371.141.ca...@debian.org

Processed: Bug#789798: grub-installer: add option to _not_ install to UEFI boot order

[Debian Bug Tracking System]

Processing control commands:

> block 789798 by 792547
Bug #789798 [grub-installer] grub-installer: add option to _not_ install to 
UEFI boot order
789798 was blocked by: 792547
789798 was not blocking any bugs.
Ignoring request to alter blocking bugs of bug #789798 to the same blocks 
previously set

-- 
789798: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789798
792547: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792547
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.b792547.143703206822296.transcr...@bugs.debian.org

Processed: Bug#789798: grub-installer: add option to _not_ install to UEFI boot order

[Debian Bug Tracking System]

Processing control commands:

> block 789798 by 792547
Bug #789798 [grub-installer] grub-installer: add option to _not_ install to 
UEFI boot order
789798 was not blocked by any bugs.
789798 was not blocking any bugs.
Added blocking bug(s) of 789798: 792547

-- 
789798: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789798
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.b789798.143703206822287.transcr...@bugs.debian.org

Bug#789798: grub-installer: add option to _not_ install to UEFI boot order

[Ian Campbell]

Control: block 789798 by 792547

I've tested both of these patches (grub-installer [0] and grub2 [1]
together but the grub-installer one doesn't do much without the grub2
one, since it appears that the installation of the grub-* packages also
ends up running grub-install during installation.

Ian.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789798#65
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792547#5


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1437032065.7019.160.ca...@debian.org

Bug#789798: Updated patch to "add option to _not_ install to UEFI boot order"

[Ian Campbell]

Attached new patch inverts the sense of the option after review of the
wording by debian-l10n-english and fixes the propagation of the setting
to the installed grub2 package.

Ian.
From 4e038e33ea681dde7cccb05ba5a1a6b1e3ae8d6f Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Fri, 19 Jun 2015 15:17:40 +0100
Subject: [PATCH] Allow avoiding installation to NVRAM on EFI or IEEE1275
 systems

On systems which demand greater control over the boot order (e.g. ones which
PXE boot) it is useful to avoid messing with this during installation.

(Closes: #789798)
---
 debian/changelog|  2 ++
 debian/grub-installer.templates | 12 
 grub-installer  | 12 
 3 files changed, 26 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 24873db..87f4d17 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,8 @@ grub-installer (1.125) UNRELEASED; urgency=medium
   [ Ian Campbell ]
   * Correctly propagate grub-installer/force-efi-extra-removable to installed
 system. (Closes: #792247).
+  * Add preseedable option to allow avoiding installation to NVRAM.
+(Closes: #789798)
 
  -- Ian Campbell   Mon, 13 Jul 2015 09:01:46 +0100
 
diff --git a/debian/grub-installer.templates b/debian/grub-installer.templates
index e294afb..73cbff0 100644
--- a/debian/grub-installer.templates
+++ b/debian/grub-installer.templates
@@ -285,3 +285,15 @@ _Description: Force GRUB installation to the EFI removable media path?
  installing GRUB there will make that operating system temporarily
  unbootable. GRUB can be manually configured later to boot it if
  necessary.
+
+Template: grub-installer/install-to-nvram
+Type: boolean
+Default: true
+# :sl4:
+_Description: Add GRUB to firmware NVRAM configuration?
+ By default, GRUB will be registered into NVRAM on platforms where this is
+ required, such as UEFI Boot Manager or OpenFirmware boot devices.
+ .
+ Occasionally this is not desired (for instance on systems that PXE boot
+ and then chainload). If you reject this option, the NVRAM will be left
+ untouched.
diff --git a/grub-installer b/grub-installer
index c407cd1..296419e 100755
--- a/grub-installer
+++ b/grub-installer
@@ -813,6 +813,18 @@ $grub_package grub2/force_efi_extra_removable boolean true
 EOF
 		fi
 
+		# Should we avoid installing/registering GRUB in NVRAM?
+		db_input low grub-installer/install-to-nvram || [ $? -eq 30 ]
+		db_go || exit 10
+		db_get grub-installer/install-to-nvram
+		if [ "$RET" = false ]; then
+			grub_install_params="$grub_install_params --no-nvram"
+			# Make sure this happens on upgrades too
+			$chroot $ROOT 'debconf-set-selections' <

Bug#789798: grub-installer: add option to _not_ install to UEFI boot order

[Ian Campbell]

On Wed, 2015-06-24 at 16:02 +0100, Ian Campbell wrote:
> +# Should we avoid installing/registering GRUB in NVRAM?
> +   db_input low grub-installer/no-nvram || [ $? -eq 30 ]
> +   db_go || exit 10
> +   db_get grub-installer/no-nvram
> +   if [ "$RET" = true ]; then
> +   grub_install_params="$grub_install_params --no-nvram"
> +   # Make sure this happens on upgrades too
> +   $chroot $ROOT 'debconf-set-selections' < +grub-installer/no-nvram boolean true
> +EOF
> +   fi

Reminder to self:

As it stands this last bit is bogus. I need to arrange for there to be a
similar grub2/no-nvram question in grub itself and set that here not the
grub-installer one.

Ian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1435736974.17598.108.ca...@debian.org

Bug#789798: grub-installer: add option to _not_ install to UEFI boot order

[Ian Campbell]

On Mon, 2015-06-29 at 14:12 +0100, Steve McIntyre wrote:
> >diff --git a/debian/grub-installer.templates 
> >b/debian/grub-installer.templates
> >index e294afb..e5d090b 100644
> >--- a/debian/grub-installer.templates
> >+++ b/debian/grub-installer.templates
> >@@ -285,3 +285,15 @@ _Description: Force GRUB installation to the EFI 
> >removable media path?
> >  installing GRUB there will make that operating system temporarily
> >  unbootable. GRUB can be manually configured later to boot it if
> >  necessary.
> >+
> >+Template: grub-installer/no-nvram
> >+Type: boolean
> >+Default: false
> >+# :sl4:
> >+_Description: Avoid adding GRUB to Firmmware NVRAM configuration?
> >+ By default GRUB will be registered into NVRAM on platforms where this is
> >+ required. e.g. UEFI Boot Manager or OpenFirmware boot device.
> >+ .
> >+ This is sometimes not desirable, e.g. for systems which PXE boot and 
> >chainload
> >+ instead and do not want the firmware configuration adjusted. Answering no 
> >here
> >+ will avoid make such adjustments.
> 
> s/make such/making such/ ?

Yes, that is much better, thanks.

I suppose I ought to run this by the English i18n list too.

Ian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1435649774.17598.102.ca...@debian.org

Bug#789798: grub-installer: add option to _not_ install to UEFI boot order

[Steve McIntyre]

On Wed, Jun 24, 2015 at 04:02:28PM +0100, Ian Campbell wrote:
>Package: grub-installer
>Version: 1.124
>Severity: wishlist
>Tags: patch
>
>I have a need to repeatedly install Debian from PXE on systems which are UEFI
>only (arm64 as it happens but I think all of the below applies to x86 UEFI
>too). When we want to actually boot the installed OS we chainload from the PXE
>grub.efi to the one on the ESP (using grub-installer/force-efi-extra-removable
>for simplicity, but that's by the by, I think).
>
>This is for automated testing which does a fresh install before most tests.
>
>The problem is that during install Debian inserts itself into the UEFI boot
>order _before_ the PXE entry, this happens via grub-installer.udeb ->
>grub-install (from the main grub deb) -> efibootmgr -c.
>
>This means that when we come to want to regroove the box it won't boot from 
>PXE.
>
>grub-install offers an option to avoid this (--no-nvram) which is passed by
>grub-installer under some very specific circumstances (known broken hardware)
>but it would be very useful if this was a pre-seedable option so it could be
>used in circumstances such as the above as well.
>
>The attached patch adds a preseedable grub-installer/no-nvram (heavily inspired
>by the grub-installer/force-efi-extra-removable option) which forces the
>--no-nvram option to be used. I've tested this by rebuilding the Jessie
>installer with a patched version of grub-installer. The English text could
>probably do with some review on the appropriate list.

Mostly looks good to me, just one minor wording tweak that I'd
suggest...

>commit 3f74e51b6a10253d4fe598a1bf83a3d21783b0be
>Author: Ian Campbell 
>Date:   Fri Jun 19 15:17:40 2015 +0100
>
>Add preseedable option to allow avoiding installation to NVRAM. (Closes: 
> #xx)
>
>diff --git a/debian/changelog b/debian/changelog
>index cf6fda2..47a679c 100644
>--- a/debian/changelog
>+++ b/debian/changelog
>@@ -1,3 +1,10 @@
>+grub-installer (1.124) UNRELEASED; urgency=medium
>+
>+  * Add preseedable option to allow avoiding installation to NVRAM.
>+(Closes: #xx)
>+
>+ -- Ian Campbell   Fri, 19 Jun 2015 15:16:47 +0100
>+
> grub-installer (1.123) unstable; urgency=medium
> 
>   [ Updated translations ]
>diff --git a/debian/grub-installer.templates b/debian/grub-installer.templates
>index e294afb..e5d090b 100644
>--- a/debian/grub-installer.templates
>+++ b/debian/grub-installer.templates
>@@ -285,3 +285,15 @@ _Description: Force GRUB installation to the EFI 
>removable media path?
>  installing GRUB there will make that operating system temporarily
>  unbootable. GRUB can be manually configured later to boot it if
>  necessary.
>+
>+Template: grub-installer/no-nvram
>+Type: boolean
>+Default: false
>+# :sl4:
>+_Description: Avoid adding GRUB to Firmmware NVRAM configuration?
>+ By default GRUB will be registered into NVRAM on platforms where this is
>+ required. e.g. UEFI Boot Manager or OpenFirmware boot device.
>+ .
>+ This is sometimes not desirable, e.g. for systems which PXE boot and 
>chainload
>+ instead and do not want the firmware configuration adjusted. Answering no 
>here
>+ will avoid make such adjustments.

s/make such/making such/ ?

>diff --git a/grub-installer b/grub-installer
>index 777b3b2..ee186d2 100755
>--- a/grub-installer
>+++ b/grub-installer
>@@ -813,6 +813,18 @@ grub2/force_efi_extra_removable boolean true
> EOF
>   fi
> 
>+# Should we avoid installing/registering GRUB in NVRAM?
>+  db_input low grub-installer/no-nvram || [ $? -eq 30 ]
>+  db_go || exit 10
>+  db_get grub-installer/no-nvram
>+  if [ "$RET" = true ]; then
>+  grub_install_params="$grub_install_params --no-nvram"
>+  # Make sure this happens on upgrades too
>+  $chroot $ROOT 'debconf-set-selections' <+grub-installer/no-nvram boolean true
>+EOF
>+  fi
>+
>   if [ "$ARCH" = "powerpc/chrp_pegasos" ] ; then
>   # nvram is broken here
>   grub_install_params="$grub_install_params --no-nvram"

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Managing a volunteer open source project is a lot like herding
 kittens, except the kittens randomly appear and disappear because they
 have day jobs." -- Matt Mackall


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150629131218.gd11...@einval.com

Bug#789798: grub-installer: add option to _not_ install to UEFI boot order

[Ian Campbell]

Package: grub-installer
Version: 1.124
Severity: wishlist
Tags: patch

I have a need to repeatedly install Debian from PXE on systems which are UEFI
only (arm64 as it happens but I think all of the below applies to x86 UEFI
too). When we want to actually boot the installed OS we chainload from the PXE
grub.efi to the one on the ESP (using grub-installer/force-efi-extra-removable
for simplicity, but that's by the by, I think).

This is for automated testing which does a fresh install before most tests.

The problem is that during install Debian inserts itself into the UEFI boot
order _before_ the PXE entry, this happens via grub-installer.udeb ->
grub-install (from the main grub deb) -> efibootmgr -c.

This means that when we come to want to regroove the box it won't boot from PXE.

grub-install offers an option to avoid this (--no-nvram) which is passed by
grub-installer under some very specific circumstances (known broken hardware)
but it would be very useful if this was a pre-seedable option so it could be
used in circumstances such as the above as well.

The attached patch adds a preseedable grub-installer/no-nvram (heavily inspired
by the grub-installer/force-efi-extra-removable option) which forces the
--no-nvram option to be used. I've tested this by rebuilding the Jessie
installer with a patched version of grub-installer. The English text could
probably do with some review on the appropriate list.

Thanks,
Ian.

-- System Information:
Debian Release: 8.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
commit 3f74e51b6a10253d4fe598a1bf83a3d21783b0be
Author: Ian Campbell 
Date:   Fri Jun 19 15:17:40 2015 +0100

Add preseedable option to allow avoiding installation to NVRAM. (Closes: #xx)

diff --git a/debian/changelog b/debian/changelog
index cf6fda2..47a679c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+grub-installer (1.124) UNRELEASED; urgency=medium
+
+  * Add preseedable option to allow avoiding installation to NVRAM.
+(Closes: #xx)
+
+ -- Ian Campbell   Fri, 19 Jun 2015 15:16:47 +0100
+
 grub-installer (1.123) unstable; urgency=medium
 
   [ Updated translations ]
diff --git a/debian/grub-installer.templates b/debian/grub-installer.templates
index e294afb..e5d090b 100644
--- a/debian/grub-installer.templates
+++ b/debian/grub-installer.templates
@@ -285,3 +285,15 @@ _Description: Force GRUB installation to the EFI removable media path?
  installing GRUB there will make that operating system temporarily
  unbootable. GRUB can be manually configured later to boot it if
  necessary.
+
+Template: grub-installer/no-nvram
+Type: boolean
+Default: false
+# :sl4:
+_Description: Avoid adding GRUB to Firmmware NVRAM configuration?
+ By default GRUB will be registered into NVRAM on platforms where this is
+ required. e.g. UEFI Boot Manager or OpenFirmware boot device.
+ .
+ This is sometimes not desirable, e.g. for systems which PXE boot and chainload
+ instead and do not want the firmware configuration adjusted. Answering no here
+ will avoid make such adjustments.
diff --git a/grub-installer b/grub-installer
index 777b3b2..ee186d2 100755
--- a/grub-installer
+++ b/grub-installer
@@ -813,6 +813,18 @@ grub2/force_efi_extra_removable boolean true
 EOF
 		fi
 
+# Should we avoid installing/registering GRUB in NVRAM?
+		db_input low grub-installer/no-nvram || [ $? -eq 30 ]
+		db_go || exit 10
+		db_get grub-installer/no-nvram
+		if [ "$RET" = true ]; then
+			grub_install_params="$grub_install_params --no-nvram"
+			# Make sure this happens on upgrades too
+			$chroot $ROOT 'debconf-set-selections' <