Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #235995 > unrolled thread

debian installation issue

Back to article view | Back to linux.debian.user

Contents

  debian installation issue Semih Ozlem <semihozlemlinuxuser@gmail.com> - 2021-06-11 18:40 +0200
    Re: debian installation issue Richard Owlett <rowlett@cloud85.net> - 2021-06-11 19:20 +0200
      Re: debian installation issue Semih Ozlem <semihozlemlinuxuser@gmail.com> - 2021-06-11 20:40 +0200
        Re: debian installation issue Greg Wooledge <greg@wooledge.org> - 2021-06-11 21:10 +0200
          Re: debian installation issue Felix Miata <mrmazda@earthlink.net> - 2021-06-11 23:20 +0200
            Re: debian installation issue David Wright <deblis@lionunicorn.co.uk> - 2021-06-22 18:00 +0200
              Re: debian installation issue Felix Miata <mrmazda@earthlink.net> - 2021-06-24 06:30 +0200
                Re: debian installation issue David Wright <deblis@lionunicorn.co.uk> - 2021-06-29 18:20 +0200
                  Re: debian installation issue Felix Miata <mrmazda@earthlink.net> - 2021-06-29 19:30 +0200
                    Re: debian installation issue David Wright <deblis@lionunicorn.co.uk> - 2021-07-04 17:30 +0200
                      Re: debian installation issue Felix Miata <mrmazda@earthlink.net> - 2021-07-05 05:40 +0200
          Re: debian installation issue Semih Ozlem <semihozlemlinuxuser@gmail.com> - 2021-06-12 00:00 +0200
            Re: debian installation issue Greg Wooledge <greg@wooledge.org> - 2021-06-12 00:10 +0200
          Re: debian installation issue Andrei POPESCU <andreimpopescu@gmail.com> - 2021-06-14 08:30 +0200
            Re: debian installation issue <tomas@tuxteam.de> - 2021-06-14 09:50 +0200
              [Off topic thoughts] Re: debian installation issue "Thomas Schmitt" <scdbackup@gmx.net> - 2021-06-14 10:50 +0200
                Re: [Off topic thoughts] Re: debian installation issue <tomas@tuxteam.de> - 2021-06-14 11:50 +0200
                  Re: [Off topic thoughts] Re: debian installation issue Joe <joe@jretrading.com> - 2021-06-14 13:20 +0200
                Secure Boot in QEMU (was Re: debian installation issue) Kenneth Parker <sea7kenp@gmail.com> - 2021-06-14 12:10 +0200
                  Re: Secure Boot in QEMU (was Re: debian installation issue) "Andrew M.A. Cater" <amacater@einval.com> - 2021-06-14 13:40 +0200
              Re: debian installation issue Steve McIntyre <steve@einval.com> - 2021-06-21 15:00 +0200
                Re: debian installation issue tomas@tuxteam.de - 2021-06-21 16:40 +0200
                Re: debian installation issue Richard Hector <richard@walnut.gen.nz> - 2021-06-23 09:50 +0200
                  Re: debian installation issue Andrei POPESCU <andreimpopescu@gmail.com> - 2021-06-23 14:30 +0200
        Re: debian installation issue Joe <joe@jretrading.com> - 2021-06-11 21:20 +0200
          Re: debian installation issue Felix Miata <mrmazda@earthlink.net> - 2021-06-12 00:30 +0200
            Re: debian installation issue Joe <joe@jretrading.com> - 2021-06-12 09:00 +0200
              Re: debian installation issue songbird <songbird@anthive.com> - 2021-06-12 13:50 +0200
                Re: debian installation issue "Andrew M.A. Cater" <amacater@einval.com> - 2021-06-12 13:50 +0200
                  Re: debian installation issue Joe <joe@jretrading.com> - 2021-06-12 14:20 +0200
                  Re: debian installation issue songbird <songbird@anthive.com> - 2021-06-12 15:10 +0200
                Re: debian installation issue Joe <joe@jretrading.com> - 2021-06-12 14:10 +0200
              Re: debian installation issue Felix Miata <mrmazda@earthlink.net> - 2021-06-12 23:00 +0200
          Re: debian installation issue Steve McIntyre <steve@einval.com> - 2021-06-12 17:30 +0200

Page 2 of 2 — ← Prev page 1 [2]

#236239

[ Apologies, missed this last week... ]

tomas@tuxteam.de wrote:
>
>On Mon, Jun 14, 2021 at 09:20:52AM +0300, Andrei POPESCU wrote:
>> On Vi, 11 iun 21, 15:07:11, Greg Wooledge wrote:
>> > 
>> > Secure Boot (Microsoft's attempt to stop you from using Linux) relies on
>> > UEFI booting, and therefore this was one of the driving forces behind it,
>> > but not the *only* driving force.  If your machine doesn't use Secure Boot,
>> > don't worry about it.  It won't affect you.
>> 
>> While I'm not a fan of Microsoft:
>> 
>> https://wiki.debian.org/SecureBoot#What_is_UEFI_Secure_Boot_NOT.3F
>
>Quoting from there:
>
>  "Microsoft act as a Certification Authority (CA) for SB, and they will
>   sign programs on behalf of other trusted organisations so that their
>   programs will also run."
>
>Now two questions:
>
> - do you know any other alternative CA besides Microsoft who is
>   capable of effectively doing this? In a way that it'd "work"
>   with most PC vendors?

I've been in a number of discussions about this over the last few
years, particularly when talking about adding arm64 Secure Boot and
*maybe* finding somebody else to act as CA for that. There's a few
important (but probably not well-understood) aspect ofs the CA role
here:

 * the entity providing the CA needs to be stable (changing things is
   expensive and hard)
 * they need to be trustworthy - having an existing long-term business
   relationship with the OEMs is a major feature here
 * they need to be *large* - if there is a major mistake that might
   cause a problem on a lot of machines in production, the potential
   cost liability (and lawsuits) from OEMs is *huge*

There are not many companies who would fit here. Intel and AMD are
both very interested in enhancing trust and security at this kind of
level, but have competing products and ideas, for example.

> - is there any internationally legal binding of Microsoft for
>   them to provide that service in the future, in a fair and non
>   discriminatory way?

That is a question I *can't* answer as I've not seen anything
personally. But I would be shocked if agreements like that have not
been made with various vendors.

Having worked with Microsoft and a number of representatives from the
Linux distros, I *can* confirm that Microsoft care about Linux and SB
working well. Hell, they're even using SB (shim, etc.) themselves for
their own small Linux distro. That's not a *guarantee* of future
goodwill, but they're not about to break things here on a whim.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

[toc] | [prev] | [next] | [standalone]

#236240

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jun 21, 2021 at 12:54:31PM +0000, Steve McIntyre wrote:
> [ Apologies, missed this last week... ]

No need to apologise: I appreciate the detailed answer.

> > - do you know any other alternative CA besides Microsoft [...]

> I've been in a number of discussions about this over the last few
> years, particularly when talking about adding arm64 Secure Boot and
> *maybe* finding somebody else to act as CA for that. There's a few
> important (but probably not well-understood) aspect ofs the CA role
> here:
> 
>  * the entity providing the CA needs to be stable (changing things is
>    expensive and hard)
>  * they need to be trustworthy - having an existing long-term business
>    relationship with the OEMs is a major feature here
>  * they need to be *large* - if there is a major mistake that might
>    cause a problem on a lot of machines in production, the potential
>    cost liability (and lawsuits) from OEMs is *huge*

This makes sense. It still feels... weird to have one company do
it who has a bone to pick in the market.

Watching Oracle/Java doesn't give me good feelings about that.
It is even much more fundamental, because it's more or less all
of the "general purpose computing devices" we are talking about
here.

> There are not many companies who would fit here. Intel and AMD are
> both very interested in enhancing trust and security at this kind of
> level, but have competing products and ideas, for example.

That's why I think this shouldn't be done by "a company", but by
a non-profit industry consortium, of which there are enough examples
around.

> > - is there any internationally legal binding of Microsoft for
> >   them to provide that service in the future, in a fair and non
> >   discriminatory way?
> 
> That is a question I *can't* answer as I've not seen anything
> personally. But I would be shocked if agreements like that have not
> been made with various vendors.

This can cut both ways. Vendors have interests (and be it that other
competing vendors be kept out of the market). If things don't happen
transparently...

> Having worked with Microsoft and a number of representatives from the
> Linux distros, I *can* confirm that Microsoft care about Linux and SB
> working well. Hell, they're even using SB (shim, etc.) themselves for
> their own small Linux distro. That's not a *guarantee* of future
> goodwill, but they're not about to break things here on a whim.

Winds change. The above example of Oracle/Java (as that horrible SCO
saga, remember?) should teach people some care...

Colour me... sceptical.

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#236336

On 22/06/21 12:54 am, Steve McIntyre wrote:
> [ Apologies, missed this last week... ]
> 
> tomas@tuxteam.de wrote:
>>
>>On Mon, Jun 14, 2021 at 09:20:52AM +0300, Andrei POPESCU wrote:
>>> On Vi, 11 iun 21, 15:07:11, Greg Wooledge wrote:
>>> > 
>>> > Secure Boot (Microsoft's attempt to stop you from using Linux) relies on
>>> > UEFI booting, and therefore this was one of the driving forces behind it,
>>> > but not the *only* driving force.  If your machine doesn't use Secure Boot,
>>> > don't worry about it.  It won't affect you.
>>> 
>>> While I'm not a fan of Microsoft:
>>> 
>>> https://wiki.debian.org/SecureBoot#What_is_UEFI_Secure_Boot_NOT.3F
>>
>>Quoting from there:
>>
>>  "Microsoft act as a Certification Authority (CA) for SB, and they will
>>   sign programs on behalf of other trusted organisations so that their
>>   programs will also run."
>>
>>Now two questions:
>>
>> - do you know any other alternative CA besides Microsoft who is
>>   capable of effectively doing this? In a way that it'd "work"
>>   with most PC vendors?
> 
> I've been in a number of discussions about this over the last few
> years, particularly when talking about adding arm64 Secure Boot and
> *maybe* finding somebody else to act as CA for that. There's a few
> important (but probably not well-understood) aspect ofs the CA role
> here:
> 
>   * the entity providing the CA needs to be stable (changing things is
>     expensive and hard)
>   * they need to be trustworthy - having an existing long-term business
>     relationship with the OEMs is a major feature here
>   * they need to be *large* - if there is a major mistake that might
>     cause a problem on a lot of machines in production, the potential
>     cost liability (and lawsuits) from OEMs is *huge*
> 
> There are not many companies who would fit here. Intel and AMD are
> both very interested in enhancing trust and security at this kind of
> level, but have competing products and ideas, for example.

Is that something that needs to be done by one company? Perhaps because 
of how SecureBoot is implemented?

I'd prefer to be able to add Debian's key either in addition to or 
instead of Microsoft's, which could also be happily installed alongside 
those of Intel, AMD, your favourite government security agency or 
whoever. And Debian can get theirs signed by whichever of those they 
might think is appropriate. But I want to be able to reduce that list to 
just Debian's, or just the EFF's, or mine. Whatever combination I choose.

I think that should all work ok? Changing things, rather than being 
expensive and hard, should just be a matter of either getting a new 
organisation to sign Debian's key, and/or having them revoke one. As one 
of those on the list.

As an aside, I'd like to see this with web certificates too - I want to 
be able to get my cert signed by LetsEncrypt _and_ whatever commercial 
CA or CAs I choose, so if one of them does something stupid and needs to 
be removed from the list of approved CAs, it doesn't break the internet, 
because any significant site will have its certs signed by others as well.

Richard

[toc] | [prev] | [next] | [standalone]

#236355

[Multipart message — attachments visible in raw view] — view raw

On Mi, 23 iun 21, 19:43:14, Richard Hector wrote:
> 
> Is that something that needs to be done by one company? Perhaps because of
> how SecureBoot is implemented?
 
For a logistic point of view, at least for x86, Microsoft appears to be 
the natural choice: many mainboard manufacturers, but most hardware will 
end up running Windows anyway[1].

> I'd prefer to be able to add Debian's key either in addition to or instead
> of Microsoft's, which could also be happily installed alongside those of
> Intel, AMD, your favourite government security agency or whoever. And Debian
> can get theirs signed by whichever of those they might think is appropriate.
> But I want to be able to reduce that list to just Debian's, or just the
> EFF's, or mine. Whatever combination I choose.

In my limited understanding and experience with Secure Boot it's mostly 
up to the mainboard manufacturer.

As far as I can tell for the ASRock board here it's possible to provide 
a machine owner key, possibly also to revoke all other keys. Even if it 
does work, I'm pretty sure 99% of home users don't actually care about 
any of this.

[1] Yes, I'm aware there are lots of x86 Chromebooks, but those are 
special purpose hardware, and even there it might make sense to include 
Microsoft's key, just in case someone wants to attempt installing 
Windows on the limited storage available :D

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#236001

On Fri, 11 Jun 2021 21:38:37 +0300
Semih Ozlem <semihozlemlinuxuser@gmail.com> wrote:

> I reinstalled the system, including an efi partition (500MiB) and the
> problem was fixed.
> 
> How to check where grub is installed? And what is a friendly guide to
> learning about grub?

I don't like quoting specific sources, as they go out of date so
quickly, but here's the official starting point:
https://www.gnu.org/software/grub/

There is a lot of other information on the Net, some of it more
user-friendly, but much of it is out of date. Search using the version
number of grub, which you see on the boot menu screen, and use 'grub2'
which is the current package name.

Grub lives in more than one place: most of it is in /boot/grub, but
there is a first-stage bootloader which calls this. To be honest,
I don't know for sure where that lives on a GPT disk, on the old
DOS-type partition it would live at the start of either the whole hard
drive or the start of a particular partition, chosen during
installation. I'm guessing it's the same for GPT partitioning.

With an EFI system there is more to it that, you've already found the
need for an /efi partition/folder, but there's also an EFI boot table
on the drive, and something else which tells the computer where to look
for entries. I have a netbook which booted fine into grub on stretch,
but an upgrade to buster killed that, and to boot into buster I have to
use a rescue medium and use efibootmgr to set NextBoot to the right
entry. Nobody here seems able to help, and I gave Google a good kicking
to no avail. Clearly you don't have this problem. 

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#236009

Joe composed on 2021-06-11 20:14 (UTC+0100):

> I have a netbook which booted fine into grub on stretch,
> but an upgrade to buster killed that, and to boot into buster I have to
> use a rescue medium and use efibootmgr to set NextBoot to the right
> entry. Nobody here seems able to help, and I gave Google a good kicking
> to no avail. 
										
Almost certainly the culprits live within /etc/default/grub/, this line:
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
likely coupled with this line:
GRUB_DISABLE_OS_PROBER=true

The presence of the second line cements the problem with the first, which is that
the result of any Debian installation creates /EFI/debian on the ESP filesystem.
This is fine when there is no other installed operating system. The second
prevents the presentation of another operating system to boot from in Grub's boot
menu. The first causes replacement of the original /EFI/debian, which in effect
makes the Stretch installation invisible at boot time except via a rescue boot, or
to a user knowledgeable in use of the Grub shell.

The solution most obvious to me is to make the content of GRUB_DISTRIBUTOR= a
unique string, such as stretch or debian9 or buster or debian10, followed by
running grub-mkconfig, and verifying that the UEFI BIOS contains these unique
entries for each Debian installation.

Whether or not to set GRUB_DISABLE_OS_PROBER= false or true depends on personal
preference. If true, the Grub menu selected by the last Grub-updated installation
will exclude all other OS installations. To boot any other OS then requires the
services of the UEFI BIOS to select booting any other, or booting rescue media.
When instead false is configured (in both/all), either's/any's Grub menu can be
used to boot another.

A much less obvious solution is to utilize the services of /etc/grub.d/ to present
a custom grub menu configured by a system administrator knowledgeable in manual
construction of a Grub menu.
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[toc] | [prev] | [next] | [standalone]

#236017

On Fri, 11 Jun 2021 18:24:43 -0400
Felix Miata <mrmazda@earthlink.net> wrote:

> Joe composed on 2021-06-11 20:14 (UTC+0100):
> 
> > I have a netbook which booted fine into grub on stretch,
> > but an upgrade to buster killed that, and to boot into buster I
> > have to use a rescue medium and use efibootmgr to set NextBoot to
> > the right entry. Nobody here seems able to help, and I gave Google
> > a good kicking to no avail.   
> 										
> Almost certainly the culprits live within /etc/default/grub/, this
> line: GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
> likely coupled with this line:
> GRUB_DISABLE_OS_PROBER=true
> 
> The presence of the second line cements the problem with the first,
> which is that the result of any Debian installation creates
> /EFI/debian on the ESP filesystem. This is fine when there is no
> other installed operating system. The second prevents the
> presentation of another operating system to boot from in Grub's boot
> menu. The first causes replacement of the original /EFI/debian, which
> in effect makes the Stretch installation invisible at boot time
> except via a rescue boot, or to a user knowledgeable in use of the
> Grub shell.
> 
> The solution most obvious to me is to make the content of
> GRUB_DISTRIBUTOR= a unique string, such as stretch or debian9 or
> buster or debian10, followed by running grub-mkconfig, and verifying
> that the UEFI BIOS contains these unique entries for each Debian
> installation.
> 
> Whether or not to set GRUB_DISABLE_OS_PROBER= false or true depends
> on personal preference. If true, the Grub menu selected by the last
> Grub-updated installation will exclude all other OS installations. To
> boot any other OS then requires the services of the UEFI BIOS to
> select booting any other, or booting rescue media. When instead false
> is configured (in both/all), either's/any's Grub menu can be used to
> boot another.
> 
> A much less obvious solution is to utilize the services of
> /etc/grub.d/ to present a custom grub menu configured by a system
> administrator knowledgeable in manual construction of a Grub menu.

Things aren't getting that far. If I turn on the computer, it shows me
its logo and then a brief flash of text at the top of the page. It
waits ten seconds or so, then repeats, and does this indefinitely.

The brief text says that it can't find a Debian file, and I later
discovered that every cycle of this process adds another Debian entry
to the EFI boot table. At the top of this table, and the BIOS recreates
it if I change it, is the hard drive, with a Windows entry lower.

I've been through all the copying, moving and renaming of things in /efi
suggested by Google, and none of it helps. The fact remains that adding
stretch to a Win10 installation worked fine, and upgrading to buster
stopped it booting at all without manual intervention. I later did a
clean reinstall of buster, and it didn't help. Before the text flash
appears, I can hit the F12 key and select the Windows Boot Manager, or
stick in a rescue USB and select that. This BIOS boot manager never
shows me a Debian entry, though the EFI boot table always has at least
one.

It doesn't help that the BIOS is broken, that it does not honour the
EFI DefaultBoot, and always rewrites entry 0000 if I change it.
Fortunately, it does honour NextBoot, or I'd never be able to get it
booted into buster. But it worked with stretch. I could try installing
stretch again and take a disc image, but it's a fair bit of work when I
have no guarantee that whatever is missing will get replaced, and I do
have a workaround which works.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#236022

Joe wrote:
...
> It doesn't help that the BIOS is broken, that it does not honour the
> EFI DefaultBoot, and always rewrites entry 0000 if I change it.
> Fortunately, it does honour NextBoot, or I'd never be able to get it
> booted into buster. But it worked with stretch. I could try installing
> stretch again and take a disc image, but it's a fair bit of work when I
> have no guarantee that whatever is missing will get replaced, and I do
> have a workaround which works.

  after grub has updates i have to run a script which 
resets the boot order in uefi.


#
# efibootmgr

BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0000,0006,0007,0005


# efibootmgr -o 0,1,5,6,7
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0000,0001,0005,0006,0007


  songbird

[toc] | [prev] | [next] | [standalone]

#236023

On Sat, Jun 12, 2021 at 07:09:29AM -0400, songbird wrote:
> Joe wrote:
> ...
> > It doesn't help that the BIOS is broken, that it does not honour the
> > EFI DefaultBoot, and always rewrites entry 0000 if I change it.
> > Fortunately, it does honour NextBoot, or I'd never be able to get it
> > booted into buster. But it worked with stretch. I could try installing
> > stretch again and take a disc image, but it's a fair bit of work when I
> > have no guarantee that whatever is missing will get replaced, and I do
> > have a workaround which works.
> 
>   after grub has updates i have to run a script which 
> resets the boot order in uefi.
> 
> 
> #
> # efibootmgr
> 
> BootCurrent: 0001
> Timeout: 1 seconds
> BootOrder: 0001,0000,0006,0007,0005
> 
> 
> # efibootmgr -o 0,1,5,6,7
> BootCurrent: 0001
> Timeout: 1 seconds
> BootOrder: 0000,0001,0005,0006,0007
> 
> 
>   songbird
> 

These sound like either: broken versions of UEFI / broken installations or,
exceptionally, a broken manufacturer somewhere.

It may be worth revisiting installations when Bulleseye comes out to 
get something that works and is supportable for the next few years.

Andy C.

[toc] | [prev] | [next] | [standalone]

#236025

On Sat, 12 Jun 2021 11:47:16 +0000
"Andrew M.A. Cater" <amacater@einval.com> wrote:

> On Sat, Jun 12, 2021 at 07:09:29AM -0400, songbird wrote:
> > Joe wrote:
> > ...  
> > > It doesn't help that the BIOS is broken, that it does not honour
> > > the EFI DefaultBoot, and always rewrites entry 0000 if I change
> > > it. Fortunately, it does honour NextBoot, or I'd never be able to
> > > get it booted into buster. But it worked with stretch. I could
> > > try installing stretch again and take a disc image, but it's a
> > > fair bit of work when I have no guarantee that whatever is
> > > missing will get replaced, and I do have a workaround which
> > > works.  
> > 
> >   after grub has updates i have to run a script which 
> > resets the boot order in uefi.
> > 
> > 
> > #
> > # efibootmgr
> > 
> > BootCurrent: 0001
> > Timeout: 1 seconds
> > BootOrder: 0001,0000,0006,0007,0005
> > 
> > 
> > # efibootmgr -o 0,1,5,6,7
> > BootCurrent: 0001
> > Timeout: 1 seconds
> > BootOrder: 0000,0001,0005,0006,0007
> > 
> > 
> >   songbird
> >   
> 
> These sound like either: broken versions of UEFI / broken
> installations or, exceptionally, a broken manufacturer somewhere.

Yes, no question about that. Failing to honour DefaultBoot is
definitely a no-no, along with the rewriting of the boot order. The
thing is, the stretch installer took a Win10 installation and an empty
second drive, and made a fully-working dual boot system with grub in
charge. Stretch knows something about EFI booting that buster doesn't.
> 
> It may be worth revisiting installations when Bulleseye comes out to 
> get something that works and is supportable for the next few years.
> 
Yes. But at the moment, I need to use suspend rather than shutdown, and
I only just about trust stable to do suspend properly. Even stable
occasionally freaks out and goes dead, and I have to do the four second
power button thing.

It would be bearable if there was a trivial way to get Win10 to set
NextBoot, but that involves booting it into Safe Mode and some Registry
editing, which is more trouble than using a rescue USB and efibootmgr
in chroot. I suppose I could try running efibootmgr under Win10, but
I've never had any luck doing really low-level system stuff under
emulation.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#236026

Andrew M.A. Cater wrote:
...
> These sound like either: broken versions of UEFI / broken installations or,
> exceptionally, a broken manufacturer somewhere.
>
> It may be worth revisiting installations when Bulleseye comes out to 
> get something that works and is supportable for the next few years.

  in my case it is that grub and refind don't do well together.  i
prefer booting via refind, but keep grub around just in case.  i
have also now put a menu entry for grub to chainload refind.


in /etc/grub.d/40_custom i have:

=====
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
#
menuentry "Refind Menu" {
    insmod part_gpt
    insmod fat
    insmod chain
    root=hd0,1
    chainloader /EFI/BOOT/BOOTX64.EFI
    }
=====

but i also have this documented in another place just in case
grub deletes my 40_custom file.


  songbird

[toc] | [prev] | [next] | [standalone]

#236024

On Sat, 12 Jun 2021 07:09:29 -0400
songbird <songbird@anthive.com> wrote:

> Joe wrote:
> ...
> > It doesn't help that the BIOS is broken, that it does not honour the
> > EFI DefaultBoot, and always rewrites entry 0000 if I change it.
> > Fortunately, it does honour NextBoot, or I'd never be able to get it
> > booted into buster. But it worked with stretch. I could try
> > installing stretch again and take a disc image, but it's a fair bit
> > of work when I have no guarantee that whatever is missing will get
> > replaced, and I do have a workaround which works.  
> 
>   after grub has updates i have to run a script which 
> resets the boot order in uefi.
> 
> 
> #
> # efibootmgr
> 
> BootCurrent: 0001
> Timeout: 1 seconds
> BootOrder: 0001,0000,0006,0007,0005
> 
> 
> # efibootmgr -o 0,1,5,6,7
> BootCurrent: 0001
> Timeout: 1 seconds
> BootOrder: 0000,0001,0005,0006,0007
> 

Yes, I can do that, but the BIOS rewrites it. It always puts the SATA
SSD drive (it also has a hardwired SSD) first in the list, and it
always fails to find something bootable on it. EFI booting is working
OK, as if I use efibootmgr to set NextBoot, that is honoured, and it
boots the correct entry.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#236044

(I wrote this over 12 hours ago, before I went to bed, and forgot to send first.)

Joe composed on 2021-06-12 07:59 (UTC+0100):

> It doesn't help that the BIOS is broken, that it does not honour the
> EFI DefaultBoot, and always rewrites entry 0000 if I change it.
										
There's no need for the Debian entry to be 0000. One normally can change the boot
priority order with either efibootmgr or BIOS setup. If the BIOS is broken and an
upgrade isn't available, a CMOS reset should provide a workable solution. Pull the
plug, take the CMOS battery out, and leave it out as long as it takes for
everything to be forgotten. Removing all bootable devices might be required to
make forgetfulness stick. If that doesn't work, put a wiped drive in for reset
purposes.
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[toc] | [prev] | [next] | [standalone]

#236029

Joe wrote:
>
>Grub lives in more than one place: most of it is in /boot/grub, but
>there is a first-stage bootloader which calls this. To be honest,
>I don't know for sure where that lives on a GPT disk, on the old
>DOS-type partition it would live at the start of either the whole hard
>drive or the start of a particular partition, chosen during
>installation. I'm guessing it's the same for GPT partitioning.

It's ... complicated. :-)

See

  https://wiki.debian.org/Grub2#UEFI_vs_BIOS_boot

for documentation I've written comparing how GRUB works in BIOS mode
vs. UEFI mode.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web