Re: debian installation issue

[Felix Miata]

David Wright composed on 2021-07-04 10:29 (UTC-0500):

> On Tue 29 Jun 2021 at 13:26:04 (-0400), Felix Miata wrote:

>> David Wright composed on 2021-06-29 11:16 (UTC-0500):
...
>>> I don't understand the attraction of messing about with boot flags
>>> in order to choose which primary partition to boot from. It seems
>>> inelegant to write to the drive just for that.
...
>> 2-The system was invented over 4 decades ago, before the PC compatible HD
>> partitioning system was upgraded to allow for more than 4 partitions per HD.

> Sorry, what system?


My fallible memory may have mislead. I believe the 66 byte, 4 primary entry
partition table "standard" MBR (system) was pioneered by the IBM PC/AT, which
debuted with DOS 3.0, a good bit less than 4 decades ago. The reference book I 
had
that spelled such things out never came back from a lend, and it's not proven
worth my time to dig that bit of trivia out of the WWW. I did look on Wikipedia,
but didn't spot a clear answer. The extended type adaptation with logical
partitions arrived with DOS 3.2, which I skipped over to get 3.3 for 3.5" floppy
and Bernoulli Box support.

>> 3-I have yet to intentionally install Grub2 on an MBR system. I use mostly
>> openSUSE's Grub Legacy, which supports ext4 (as long as 64bit is not 
>> enabled), on
>> all MBR systems,

> I'm not sure of the relevance of the Grub version, but I assume, from
> your previous post, that Grub is installed in individual partitions,
> not in the MBR/"on the disk".


Grub Legacy maintenance doesn't require much effort or education. I can clone a
partition, then run tune2fs to change UUID and LABEL, and setup Grub Legacy on 
the
clone, from the same shell session in less than a minute, without need for any
script, .conf file or partition mounting. It needs only a device.map and the 
Grub
binary. Except when IBM BM is the primary bootloader on a system, I always have
Grub Legacy on a primary partition. Historically, each / partition has it as 
well,
but with the increasing absence of its availability, many of my installations 
have
been going without having a bootloader installed by the host OS.
-- 
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

Re: debian installation issue

[David Wright]

On Tue 29 Jun 2021 at 13:26:04 (-0400), Felix Miata wrote:
> David Wright composed on 2021-06-29 11:16 (UTC-0500):
> > On Thu 24 Jun 2021 at 00:07:56 (-0400), Felix Miata wrote:
> >> David Wright composed on 2021-06-22 10:50 (UTC-0500):
> 
> >> I'm not sure there is "a" definition. One could be any code that a Windows
> >> installation would not replace. Another could be based on what it does:
> 
> >> 1-locate a legal boot flag
> >> 2-load an appropriate sector pointed to by a legal flag
> >> 3-announce error if the above conditions are not met
> 
> >> A legal flag is any flag on a primary partition on a disk on which no 
> >> other boot
> >> flags are present in the MBR table.
> 
> > I don't understand the attraction of messing about with boot flags
> > in order to choose which primary partition to boot from. It seems
> > inelegant to write to the drive just for that.
> 
> 1-It's Windows compatible. With it, Windows 7/10 won't refuse to complete 
> updates
> when it doesn't find something it expects in the partition table. "Refuse" in 
> this
> case means install a big heap of updates, then decide it can't finish, and 
> wastes
> more time uninstalling those it just installed, followed by announcing there 
> are a
> heap of updates to install, repeat ad nauseum.

I haven't met that problem. I've run W10 on UEFI with stretch and
buster on BIOS-MBR using Grub, and the two OSes were effectively
unaware of each other. (I can't speak to W7, as that had been upgraded
by the time I started using the machine.

> 2-The system was invented over 4 decades ago, before the PC compatible HD
> partitioning system was upgraded to allow for more than 4 partitions per HD.

Sorry, what system?

> 3-I have yet to intentionally install Grub2 on an MBR system. I use mostly
> openSUSE's Grub Legacy, which supports ext4 (as long as 64bit is not 
> enabled), on
> all MBR systems,

I'm not sure of the relevance of the Grub version, but I assume, from
your previous post, that Grub is installed in individual partitions,
not in the MBR/"on the disk".

OK, yes, I can see that you have a reason, apparently, to keep Grub
away from the MBR on the systems where there's a sensitive Windows
installation, but for someone like the OP, coming to a linux system
afresh, I can't see any reason for them to add complexity by not
installing Grub on the MBR (assuming BIOS booting is in force).

> and Grub2-efi on UEFI systems, including Intel Mac.
> 
> >> > Are there OSes that would install it themselves to a new blank disk?
>   
> >> One version would be code a Windows installation would put there.
> 
> >> Another would be the result of FDISK /MBR from a MS or PC DOS boot, or 
> >> FDISK
> >> /NEWMBR or LVM /NEWMBR from an OS/2, eCS or ArcaOS boot.
> 
> >> I would expect the FreeDOS version of FDISK or its installer to do the 
> >> same.
> 
> >> I normally use code derived from OS/2, installed by DFSee when I first 
> >> partition a
> >> disk.
> 
> > Obtaining DFSee might be alright for someone invested in MBR booting,
> > but for most people, MBR is obsolescent. Putting Grub on the MBR can
> > give a user interface more similar to current machines that use Grub
> > on UEFI, which seems an advantage.
>   
> UEFI is an incontrovertible improvement over MBR, but MBR will be around 
> quite a
> while yet for machines that don't include UEFI.
> 
> DFSee isn't a mere partitioner, and is not for MBR systems only. Among other
> features, it's also a copier/cloner, a binary editor of files and raw 
> sectors, can
> be scripted, and it logs in plain text. Its logs are an indispensable part of 
> my
> environment, facilitating inventorying several hundred partitions and 
> operating
> systems spread across tens of uniquely partitioned and OS-equipped multiboot
> machines. It includes free personal support from its author, as well as a 
> helpful
> support mailing list. It's interface is identical whether run from DOS, Linux,
> Mac, OS/2 or Windows.

Yes, you've posted inventories listed with that tool in the past
(I have one here, for ST HP GB0500…) and that's what I meant by being
"invested in". But again, it's just extra complexity for most people.
Don't misunderstand me, I'm not criticising your individual approach,
but I can't find any more religion in Greg's (qualified) remark than
in your views expressed about Grub/Grub2 and MBRs. I see them both
as strong preferences, held for good reasons.

Cheers,
David.

Re: debian installation issue

[Felix Miata]

David Wright composed on 2021-06-29 11:16 (UTC-0500):

> On Thu 24 Jun 2021 at 00:07:56 (-0400), Felix Miata wrote:

>> David Wright composed on 2021-06-22 10:50 (UTC-0500):

>> I'm not sure there is "a" definition. One could be any code that a Windows
>> installation would not replace. Another could be based on what it does:

>> 1-locate a legal boot flag
>> 2-load an appropriate sector pointed to by a legal flag
>> 3-announce error if the above conditions are not met

>> A legal flag is any flag on a primary partition on a disk on which no other 
>> boot
>> flags are present in the MBR table.

> I don't understand the attraction of messing about with boot flags
> in order to choose which primary partition to boot from. It seems
> inelegant to write to the drive just for that.

1-It's Windows compatible. With it, Windows 7/10 won't refuse to complete 
updates
when it doesn't find something it expects in the partition table. "Refuse" in 
this
case means install a big heap of updates, then decide it can't finish, and 
wastes
more time uninstalling those it just installed, followed by announcing there 
are a
heap of updates to install, repeat ad nauseum.

2-The system was invented over 4 decades ago, before the PC compatible HD
partitioning system was upgraded to allow for more than 4 partitions per HD.

3-I have yet to intentionally install Grub2 on an MBR system. I use mostly
openSUSE's Grub Legacy, which supports ext4 (as long as 64bit is not enabled), 
on
all MBR systems, and Grub2-efi on UEFI systems, including Intel Mac.

>> > Are there OSes that would install it themselves to a new blank disk?

>> One version would be code a Windows installation would put there.

>> Another would be the result of FDISK /MBR from a MS or PC DOS boot, or FDISK
>> /NEWMBR or LVM /NEWMBR from an OS/2, eCS or ArcaOS boot.

>> I would expect the FreeDOS version of FDISK or its installer to do the same.

>> I normally use code derived from OS/2, installed by DFSee when I first 
>> partition a
>> disk.

> Obtaining DFSee might be alright for someone invested in MBR booting,
> but for most people, MBR is obsolescent. Putting Grub on the MBR can
> give a user interface more similar to current machines that use Grub
> on UEFI, which seems an advantage.


UEFI is an incontrovertible improvement over MBR, but MBR will be around quite a
while yet for machines that don't include UEFI.

DFSee isn't a mere partitioner, and is not for MBR systems only. Among other
features, it's also a copier/cloner, a binary editor of files and raw sectors, 
can
be scripted, and it logs in plain text. Its logs are an indispensable part of my
environment, facilitating inventorying several hundred partitions and operating
systems spread across tens of uniquely partitioned and OS-equipped multiboot
machines. It includes free personal support from its author, as well as a 
helpful
support mailing list. It's interface is identical whether run from DOS, Linux,
Mac, OS/2 or Windows.
-- 
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

Re: debian installation issue

[David Wright]

On Thu 24 Jun 2021 at 00:07:56 (-0400), Felix Miata wrote:
> David Wright composed on 2021-06-22 10:50 (UTC-0500):
> > On Fri 11 Jun 2021 at 16:57:35 (-0400), Felix Miata wrote:
> 
> >> OTOH, putting a bootloader on the MBR of a disk on a PC designed for 
> >> Windows is a
> >> relative newcomer to the world of booting such a PC. I've been installing
> >> operating systems on IBM-compatible PCs for more than 3 decades. Not once 
> >> have I
> >> intentionally installed Grub on an MBR. In the dearth of instances where 
> >> it did
> >> happen I wiped whatever caused it, and started over with
> >> DOS/OS2/Windows/Linux-compatible MBR code on the MBR. IOW, Grub can live 
> >> elsewhere
> >> than on the MBR.
> 
> > Can you elaborate on what your "DOS/OS2/Windows/Linux-compatible MBR
> > code" is, what functionality you get, and where you obtain it.
>   
> I'm not sure there is "a" definition. One could be any code that a Windows
> installation would not replace. Another could be based on what it does:
> 
> 1-locate a legal boot flag
> 2-load an appropriate sector pointed to by a legal flag
> 3-announce error if the above conditions are not met
> 
> A legal flag is any flag on a primary partition on a disk on which no other 
> boot
> flags are present in the MBR table.

I don't understand the attraction of messing about with boot flags
in order to choose which primary partition to boot from. It seems
inelegant to write to the drive just for that.

With the mbr package from Debian, you can choose at a boot-time prompt.
With Grub, you can also choose for the next boot, any time the system
is running.

> > Are there OSes that would install it themselves to a new blank disk?
>   
> One version would be code a Windows installation would put there.
> 
> Another would be the result of FDISK /MBR from a MS or PC DOS boot, or FDISK
> /NEWMBR or LVM /NEWMBR from an OS/2, eCS or ArcaOS boot.
> 
> I would expect the FreeDOS version of FDISK or its installer to do the same.
> 
> I normally use code derived from OS/2, installed by DFSee when I first 
> partition a
> disk.

Obtaining DFSee might be alright for someone invested in MBR booting,
but for most people, MBR is obsolescent. Putting Grub on the MBR can
give a user interface more similar to current machines that use Grub
on UEFI, which seems an advantage.

Cheers,
David.

Re: debian installation issue

[Felix Miata]

David Wright composed on 2021-06-22 10:50 (UTC-0500):

> On Fri 11 Jun 2021 at 16:57:35 (-0400), Felix Miata wrote:

>> OTOH, putting a bootloader on the MBR of a disk on a PC designed for Windows 
>> is a
>> relative newcomer to the world of booting such a PC. I've been installing
>> operating systems on IBM-compatible PCs for more than 3 decades. Not once 
>> have I
>> intentionally installed Grub on an MBR. In the dearth of instances where it 
>> did
>> happen I wiped whatever caused it, and started over with
>> DOS/OS2/Windows/Linux-compatible MBR code on the MBR. IOW, Grub can live 
>> elsewhere
>> than on the MBR.

> Can you elaborate on what your "DOS/OS2/Windows/Linux-compatible MBR
> code" is, what functionality you get, and where you obtain it.


I'm not sure there is "a" definition. One could be any code that a Windows
installation would not replace. Another could be based on what it does:

1-locate a legal boot flag
2-load an appropriate sector pointed to by a legal flag
3-announce error if the above conditions are not met

A legal flag is any flag on a primary partition on a disk on which no other boot
flags are present in the MBR table.

> Are there OSes that would install it themselves to a new blank disk?


One version would be code a Windows installation would put there.

Another would be the result of FDISK /MBR from a MS or PC DOS boot, or FDISK
/NEWMBR or LVM /NEWMBR from an OS/2, eCS or ArcaOS boot.

I would expect the FreeDOS version of FDISK or its installer to do the same.

I normally use code derived from OS/2, installed by DFSee when I first 
partition a
disk.

>> With a UEFI "BIOS", the boot process begins rather differently than on an 
>> MBR-only
>> system. On a UEFI system's ESP (Extensible Firmware Interface System 
>> Partition; a
>> quasi-"boot" partition), there are no files containing the string "grub" in 
>> their
>> name.

I have no idea what I was thinking when I wrote that last sentence. I was 
probably
looking at an installation that had been installed without any bootloader, which
is not where I should have been focused.

>> Thus it seems to be a debatable issue whether "bootloader" is actually an
>> appropriate name for Grub 2, as its primary purpose seems to be presenting a 
>> menu
>> from which to select what kernel, initrd (if any), and kernel command line
>> parameters (if any) to load into RAM to /continue/ the boot process 
>> initiated by
>> the UEFI firmware.

> I'm not quite following your point. Are you saying that the ~250 Grub
> modules are just a waste of space, and that the while boot process is
> carried out by the EFI firmware?


The process is initiated by the EFI firmware, begun by probing a panoply of
available media for ESP partition files that fulfill requirements for proceeding
with a boot process defined by the Multiboot Specification. Usually, it's more 
or
less the start of a chain loading process finished by an installed "bootloader".
OTOH, the UEFI firmware might start a PC completely (of sorts) by loading a 
single
file on the ESP originally named mt83x64.efi (memtest86 v8.3).

All the Grub modules aren't required or employed on any given installation. A 
more
sophisticated Grub installer could conceivably install there only those 
components
required for the hardware present during installation.
-- 
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

Re: debian installation issue

[Andrei POPESCU]

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


signature.asc
Description: PGP signature

Re: debian installation issue

[Richard Hector]

On 22/06/21 12:54 am, Steve McIntyre wrote:

[ Apologies, missed this last week... ]

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

Re: debian installation issue

[David Wright]

On Fri 11 Jun 2021 at 16:57:35 (-0400), Felix Miata wrote:
> Greg Wooledge composed on 2021-06-11 15:07 (UTC-0400):
> > On Fri, Jun 11, 2021 at 09:38:37PM +0300, Semih Ozlem wrote:
> 
> >> How to check where grub is installed? And what is a friendly guide to
> >> learning about grub?
> 
> > GRUB should be installed on the *disk* (not on a partition) that you
> > intend to boot. 
> Not to detract from the wisdom of the rest of Greg's excellent reply, but TBC,
> this statement is religion at one extreme, opinion at the other, not fact. 
> Note he
> wisely did not say "must", but "should". For most traditional (BIOS/MBR; 
> designed
> for "Windows" PCs) configurations, it's probably prudent to put the 
> bootloader on
> the "disk". For pure Debian installations, as opposed to multiboot, whether 
> or not
> to install it on the "disk" really doesn't matter.
> 
> OTOH, putting a bootloader on the MBR of a disk on a PC designed for Windows 
> is a
> relative newcomer to the world of booting such a PC. I've been installing
> operating systems on IBM-compatible PCs for more than 3 decades. Not once 
> have I
> intentionally installed Grub on an MBR. In the dearth of instances where it 
> did
> happen I wiped whatever caused it, and started over with
> DOS/OS2/Windows/Linux-compatible MBR code on the MBR. IOW, Grub can live 
> elsewhere
> than on the MBR.

Can you elaborate on what your "DOS/OS2/Windows/Linux-compatible MBR
code" is, what functionality you get, and where you obtain it.
Are there OSes that would install it themselves to a new blank disk?

> A less innocuous error is not clearly qualifying the quoted statement to apply
> only to non-UEFI boot environments, which usually means an MBR-partitioned 
> boot
> disk. On a UEFI installation, which requires GPT partitioning, the first 
> sector
> normally contains nothing until near its end, where a disk identifier and the
> start of the disk's multi-sector partition table begin. No executable code is
> required on this sector.
> 
> With a UEFI "BIOS", the boot process begins rather differently than on an 
> MBR-only
> system. On a UEFI system's ESP (Extensible Firmware Interface System 
> Partition; a
> quasi-"boot" partition), there are no files containing the string "grub" in 
> their
> name.

# ls -GlgR /boot/efi/
/boot/efi/:
total 4
drwx-- 4 4096 Apr  3  2020 EFI

/boot/efi/EFI:
total 8
drwx-- 2 4096 Apr  3  2020 BOOT
drwx-- 2 4096 Apr  3  2020 debian

/boot/efi/EFI/BOOT:
total 3988
-rwx-- 1 1322936 Mar  2 16:23 BOOTX64.EFI
-rwx-- 1 1206824 Mar  2 16:23 fbx64.efi
-rwx-- 1 1549696 Mar  2 16:23 grubx64.efi

/boot/efi/EFI/debian:
total 5228
-rwx-- 1 108 Mar  2 16:23 BOOTX64.CSV
-rwx-- 1 1206824 Mar  2 16:23 fbx64.efi
-rwx-- 1 126 Mar  2 16:23 grub.cfg
-rwx-- 1 1549696 Mar  2 16:23 grubx64.efi
-rwx-- 1 1261192 Mar  2 16:23 mmx64.efi
-rwx-- 1 1322936 Mar  2 16:23 shimx64.efi
# 

Whatever grubx64.efi is, it's copied from grub-efi-amd64-signed, aka
grub-efi-amd64-signed_1+2.02+dfsg1+20+deb10u4_amd64.deb currently.

> Thus it seems to be a debatable issue whether "bootloader" is actually an
> appropriate name for Grub 2, as its primary purpose seems to be presenting a 
> menu
> from which to select what kernel, initrd (if any), and kernel command line
> parameters (if any) to load into RAM to /continue/ the boot process initiated 
> by
> the UEFI firmware.

I'm not quite following your point. Are you saying that the ~250 Grub
modules are just a waste of space, and that the while boot process is
carried out by the EFI firmware?

Cheers,
David.

Re: debian installation issue

[tomas]

On Mon, Jun 21, 2021 at 12:54:31PM +, 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


signature.asc
Description: Digital signature

Re: debian installation issue

[Steve McIntyre]

[ Apologies, missed this last week... ]

to...@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.st...@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

Re: Secure Boot in QEMU (was Re: debian installation issue)

[Andrew M.A. Cater]

On Mon, Jun 14, 2021 at 06:07:50AM -0400, Kenneth Parker wrote:
> Okay.  I am running Debian Bullseye (selected earlier, during its testing
> phase, because I needed its level of QEMU to import a VM from Mint 20's
> QEMU:  Buster's QEMU refused).  My computer is an HP EliteDesk 705 G1-SFF.
> 
> I have a special requirement to run a Licenced version of Windows 10 Pro as
> a QEMU/KVM Guest.  I have already set up QEMU GCOW2 files as gpt and
> partitioned them with UEFI environments, but only with Linux guests so far,
> as well as (in one instance) Refind.
> 
> Does QEMU/KVM support setting up Secure Boot, in a way that passes
> Microsoft Muster?
> 
> Okay, I may be finding my own answers, via a Super User web page on this,
> using Manjaro and ovmf:
> 
> https://superuser.com/questions/1389103/windows-10-uefi-physical-to-kvm-libvirt-virtual
> 
> And now I see that Bullseye has ovmf available as a package.
> 
> So this will be my next Project.  I guess I am asking if anyone on this
> list has been successful with a virtualized Secure Boot that Microsoft
> likes?
> 
> Have a nice day :)
> >
> > Thomas
> >
> 
> Many thanks!
> 
> Kenneth Parker

Hi Kenneth,

Install OVMF. I tend to use Virtual Machine Manager just because it's
easier for me. Essentially, you do get the choice to use Secure Boot and
there are two options - one for Microsoft and one generic, I think.

Andy C.

Re: [Off topic thoughts] Re: debian installation issue

[Joe]

On Mon, 14 Jun 2021 11:41:37 +0200
 wrote:


>  "Any sufficiently advanced malice is indistinguishable from
> stupidity"
> 
> (some call that "plausible deniability").
> 
>
"People would rather appear stupid than evil".

-- 
Joe

Secure Boot in QEMU (was Re: debian installation issue)

[Kenneth Parker]

On Mon, Jun 14, 2021 at 4:45 AM Thomas Schmitt  wrote:

> Hi,
>
> Greg Wooledge wrote:
> > > > Secure Boot (Microsoft's attempt to stop you from using Linux)
>
> Andrei POPESCU wrote:
> > > While I'm not a fan of Microsoft:
> > > https://wiki.debian.org/SecureBoot#What_is_UEFI_Secure_Boot_NOT.3
> > > "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."
>
> to...@tuxteam.de wrote:
> >  - do you know any other alternative CA besides Microsoft
> >  - is there any internationally legal binding of Microsoft
>
> Actually it is the mainboard producers and possibly the CPU producers who
> decide who is in charge as CA.
> Further they decide whether the firmware offers the possibility to disable
> Secure Boot or to become your own CA.
>
>
> https://www.linuxjournal.com/content/take-control-your-pc-uefi-secure-boot
> shows how it should be in an ideal world. Of course this is still expert's
> work.
>
> I myself would see few reason not to disable Secure Boot on my own machines
> if necessary. But currently it does not even hamper kernel experiments.
> (Dunno whether this is intended by Debian and kernel source code or
> whether my test machine is just not as secure as its EFI pretends to be.
> My experiments happen in kernel modules like sr, cdrom, isofs. Maybe a
> change in the kernel's core would meet more distrust.)
>
> I agree with Andrei POPESCU that Secure Boot is not really for the purpose
> of hampering free operating systems, although it causes extra workload on
> those who intend to support this boot procedure.
> Secure Boot is rather the modern attempt to make systems safe against
> simple hardware manipulations. The old way was to seal the USB ports by a
> hot glue gun and to use security screws at the side plates of the box.
>
> It is unfortunate that Intel and Microsoft could not bring themselves to
> create an independent institution which authorizes the legitimate
> boot programs which are acceptable by default.
>
> 
> As we are already off topic:
>
> I agree to Greg Wooledge's overview of x86 boot firmware, as far as
> Debian installation is concerned.
>
> I have some nitpicking on technical details, though, which i did not post
> because it would not be relevant to the initial topic.
>
> Greg Wooledge wrote:
> > UEFI booting requires a GPT disk label (partition table type),
>
> No. UEFI specifies the formats of both, MBR partition table and GPT.
> In both partition table types it specifies an identifier for the EFI
> partition. (Type 0xEF for MBR partition table,
> Type GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B for GPT.)
>
> There exist some few UEFI firmware implementations which do not obey
> the specs and ignore MBR partition tables.
>
>
> > and one of the partitions on the disk must be an EFI partition.
>
> Actually there is no UEFI implementation known which would not peek into
> any recognized partition with a FAT filesystem, whether there is \EFI\BOOT
> with the matching BOOT*.EFI file.
> This seems to be a quirk which is protected by Microsoft Inc.
>
> Whether a partition is used automatically for booting or whether it is
> offered at all as bootable, is a matter of UEFI implementation and
> settings.
>

Okay.  I am running Debian Bullseye (selected earlier, during its testing
phase, because I needed its level of QEMU to import a VM from Mint 20's
QEMU:  Buster's QEMU refused).  My computer is an HP EliteDesk 705 G1-SFF.

I have a special requirement to run a Licenced version of Windows 10 Pro as
a QEMU/KVM Guest.  I have already set up QEMU GCOW2 files as gpt and
partitioned them with UEFI environments, but only with Linux guests so far,
as well as (in one instance) Refind.

Does QEMU/KVM support setting up Secure Boot, in a way that passes
Microsoft Muster?

Okay, I may be finding my own answers, via a Super User web page on this,
using Manjaro and ovmf:

https://superuser.com/questions/1389103/windows-10-uefi-physical-to-kvm-libvirt-virtual

And now I see that Bullseye has ovmf available as a package.

So this will be my next Project.  I guess I am asking if anyone on this
list has been successful with a virtualized Secure Boot that Microsoft
likes?

Have a nice day :)
>
> Thomas
>

Many thanks!

Kenneth Parker

Re: [Off topic thoughts] Re: debian installation issue

[tomas]

On Mon, Jun 14, 2021 at 10:46:34AM +0200, Thomas Schmitt wrote:
> Hi,
> 
> Greg Wooledge wrote:
> > > > Secure Boot (Microsoft's attempt to stop you from using Linux)
> 
> Andrei POPESCU wrote:
> > > While I'm not a fan of Microsoft:
> > > https://wiki.debian.org/SecureBoot#What_is_UEFI_Secure_Boot_NOT.3
> > > "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."
> 
> to...@tuxteam.de wrote:
> >  - do you know any other alternative CA besides Microsoft
> >  - is there any internationally legal binding of Microsoft
> 
> Actually it is the mainboard producers and possibly the CPU producers who
> decide who is in charge as CA.

:-)

Yes, I know how it (should) work. I was pointing out what the actual
effect is.

> create an independent institution which authorizes the legitimate
> boot programs which are acceptable by default.

You know I'm a fan of some bastard of Clarke's Third Law and Hanlon's
Razor. In this case, it applies nicely:

 "Any sufficiently advanced malice is indistinguishable from stupidity"

(some call that "plausible deniability").

Now it doesn't help to whine around that "THEY" are cementing their
monopoly (again"). Well, duh. It's what they do, and I do commend
all the hacker's efforts to understand the new machinery some aliens
have dumped on our yards.

I was just toning down our nerdy "Oh, shiny, no more evil maid attacks"
enthusiasm and just refusing to let Microsoft off that hook, although
they are behaving in a halfway civilised way (the monopoly probes
might have some relation to that, who knows).

Cheers
 - t


signature.asc
Description: Digital signature

[Off topic thoughts] Re: debian installation issue

[Thomas Schmitt]

Hi,

Greg Wooledge wrote:
> > > Secure Boot (Microsoft's attempt to stop you from using Linux)

Andrei POPESCU wrote:
> > While I'm not a fan of Microsoft:
> > https://wiki.debian.org/SecureBoot#What_is_UEFI_Secure_Boot_NOT.3
> > "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."

to...@tuxteam.de wrote:
>  - do you know any other alternative CA besides Microsoft
>  - is there any internationally legal binding of Microsoft

Actually it is the mainboard producers and possibly the CPU producers who
decide who is in charge as CA.
Further they decide whether the firmware offers the possibility to disable
Secure Boot or to become your own CA.

  https://www.linuxjournal.com/content/take-control-your-pc-uefi-secure-boot
shows how it should be in an ideal world. Of course this is still expert's
work.

I myself would see few reason not to disable Secure Boot on my own machines
if necessary. But currently it does not even hamper kernel experiments.
(Dunno whether this is intended by Debian and kernel source code or
whether my test machine is just not as secure as its EFI pretends to be.
My experiments happen in kernel modules like sr, cdrom, isofs. Maybe a
change in the kernel's core would meet more distrust.)

I agree with Andrei POPESCU that Secure Boot is not really for the purpose
of hampering free operating systems, although it causes extra workload on
those who intend to support this boot procedure.
Secure Boot is rather the modern attempt to make systems safe against
simple hardware manipulations. The old way was to seal the USB ports by a
hot glue gun and to use security screws at the side plates of the box.

It is unfortunate that Intel and Microsoft could not bring themselves to
create an independent institution which authorizes the legitimate
boot programs which are acceptable by default.


As we are already off topic:

I agree to Greg Wooledge's overview of x86 boot firmware, as far as
Debian installation is concerned.

I have some nitpicking on technical details, though, which i did not post
because it would not be relevant to the initial topic.

Greg Wooledge wrote:
> UEFI booting requires a GPT disk label (partition table type),

No. UEFI specifies the formats of both, MBR partition table and GPT.
In both partition table types it specifies an identifier for the EFI
partition. (Type 0xEF for MBR partition table,
Type GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B for GPT.)

There exist some few UEFI firmware implementations which do not obey
the specs and ignore MBR partition tables.


> and one of the partitions on the disk must be an EFI partition.

Actually there is no UEFI implementation known which would not peek into
any recognized partition with a FAT filesystem, whether there is \EFI\BOOT
with the matching BOOT*.EFI file.
This seems to be a quirk which is protected by Microsoft Inc.

Whether a partition is used automatically for booting or whether it is
offered at all as bootable, is a matter of UEFI implementation and settings.


Have a nice day :)

Thomas

Re: debian installation issue

[tomas]

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?

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

I'd be surprised if the answer to /any/ of those questions were "yes".

We do have a dependency on Microsoft's "good will" here. Whether we like
it or not.

Cheers
 - t


signature.asc
Description: Digital signature

Re: debian installation issue

[Andrei POPESCU]

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


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


signature.asc
Description: PGP signature

Re: debian installation issue

[Felix Miata]

(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  if I change it.

There's no need for the Debian entry to be . 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

Re: debian installation issue

[Steve McIntyre]

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

Re: debian installation issue

[songbird]

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

Re: debian installation issue

[Joe]

On Sat, 12 Jun 2021 11:47:16 +
"Andrew M.A. Cater"  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  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,,0006,0007,0005
> > 
> > 
> > # efibootmgr -o 0,1,5,6,7
> > BootCurrent: 0001
> > Timeout: 1 seconds
> > BootOrder: ,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

Re: debian installation issue

[Joe]

On Sat, 12 Jun 2021 07:09:29 -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  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,,0006,0007,0005
> 
> 
> # efibootmgr -o 0,1,5,6,7
> BootCurrent: 0001
> Timeout: 1 seconds
> BootOrder: ,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

Re: debian installation issue

[Andrew M.A. Cater]

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  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,,0006,0007,0005
> 
> 
> # efibootmgr -o 0,1,5,6,7
> BootCurrent: 0001
> Timeout: 1 seconds
> BootOrder: ,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.

Re: debian installation issue

[songbird]

Joe wrote:
...
> It doesn't help that the BIOS is broken, that it does not honour the
> EFI DefaultBoot, and always rewrites entry  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,,0006,0007,0005


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


  songbird

Re: debian installation issue

[Joe]

On Fri, 11 Jun 2021 18:24:43 -0400
Felix Miata  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  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

Re: debian installation issue

[Felix Miata]

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

Re: debian installation issue

[Greg Wooledge]

On Sat, Jun 12, 2021 at 12:52:47AM +0300, Semih Ozlem wrote:
> Yes I am running in UEFI mode, but the partitioning is MBR and not GPT. Is
> this a problem? Which is preferred when?

Really, GPT is the future.  The "MBR" disk label is another product of
the 1980s.  It doesn't even support disks over 2 TB, which are fairly
common now.

I wouldn't use MBR partitioning with UEFI, but apparently it's "allowed".
Google gave me

which discusses it.

> Why would legacy boot be preferred?

It's... not?  It's simpler, though, and maybe more familiar to a lot of
the older users, so some people might choose it for one of those two
reasons.

For me -- and this is strictly opinion -- there are two scenarios that
would dictate how I proceed when installing Debian.

1) Does the system already have a disk with an operating sytem on it that
   I want to keep?  Most typically this would be Windows.

   If I'm going to make a dual-boot system from an existing Windows disk,
   then I'll keep whatever disk label (partitioning type) and booting
   strategy Windows is using.  If it's Legacy boot, then I'll install
   Debian to use Legacy boot.  This will maximize the chances of everything
   continuing to work.

2) Am I starting from a blank disk, either because it's literally blank, or
   because I'm wiping whatever OS was on the disk to begin with?

   In these cases, I'd go with GPT and UEFI, as those are the newer
   standards.

   GPT is actually required if the disk is large enough.

Of course these scenarios also assume that the machines in question offer
both types of booting.  If the machine only has UEFI or only has Legacy,
then that makes the decision for me.

Re: debian installation issue

[Semih Ozlem]

Dear Greg, and everyone else thanks for the detailed responses.

By UEFI versus Legacy Boot you mean things that are determined in BIOS
settings correct?

Yes I am running in UEFI mode, but the partitioning is MBR and not GPT. Is
this a problem? Which is preferred when? Why would legacy boot be preferred?

Greg Wooledge , 11 Haz 2021 Cum, 22:07 tarihinde şunu
yazdı:

> On Fri, Jun 11, 2021 at 09:38:37PM +0300, Semih Ozlem wrote:
> > I reinstalled the system, including an efi partition (500MiB) and the
> > problem was fixed.
>
> This suggests that you booted the installer in UEFI mode, rather than in
> Legacy mode.  If you boot the installer in UEFI mode, you are expected
> to install a system that will boot in UEFI mode, which means it needs an
> EFI partition (and GPT disk label).
>
> If you wanted to create an install that would boot in Legacy mode, you
> need to boot the installer in Legacy mode first.
>
> (Or maybe there's something you can do in Expert mode to work around it;
> I don't know.  At a bare minimum, you'd need to switch which of the
> GRUB packages gets installed -- grub-pc vs. grub-efi.)
>
> > How to check where grub is installed? And what is a friendly guide to
> > learning about grub?
>
> GRUB should be installed on the *disk* (not on a partition) that you
> intend to boot.
>
> There are two different GRUB packages: grub-efi for UEFI booting, and
> grub-pc for Legacy (BIOS) booting.  The mode in which you booted the
> installer determines which of these gets installed at the end of the
> installation.
>
> Legacy (BIOS) booting is the old quasi-standard.  It's been around since
> the 1980s.  In this paradigm, the boot loader code is installed to
> something called the "master boot record" (MBR) which is really just the
> first few hundred bytes of the disk.  Some space is left unpartitioned at
> the start of the disk to make room for this.  Much hand-waving is involved.
>
> UEFI booting is the new standard.  It's been around for several years
> now, so it's fairly widespread, but not quite ubiquitous.  UEFI booting
> requires a GPT disk label (partition table type), and one of the partitions
> on the disk must be an EFI partition.  This is a FAT-type file system which
> contains programs used by the boot loader.
>
> A lot of machine (probably most machines made today) can boot in either of
> these two modes, because not everyone has moved over to the new standard
> yet.  Older machines will only support Legacy booting.  A few newer
> machines
> may only support UEFI booting.
>
> 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.
>
> Of course, this is not everything there is to know about UEFI and Legacy
> booting, but it might be enough for most purposes, especially if you just
> want to install and run Debian, and don't particularly care about the
> inner workings.
>
> Next, the care and feeding of GRUB on an installed Debian system:
>
> In the /boot/grub directory there's a file named grub.cfg.  This is the
> menu that GRUB reads from disk when you boot.  It's generated
> automatically every time you do certain things (like installing a new
> kernel package).  If at any time you'd like to regenerate this menu
> (because you changed something yourself), you run this command:
>
> update-grub
>
> You should not edit grub.cfg directly, because your changes will be
> overwritten eventually.
>
> If you'd like to change how the menu operates, there are a few pieces
> you need to know about.
>
> The first is /etc/default/grub which is a file containing lines of shell
> code.  It's only supposed to contain variable definitions, and these
> variables affect the overall menu, or they affect every menu entry.
> You can change these variables (e.g. if you'd like the menu timeout to
> be a bit longer because your monitor takes several seconds to switch
> modes, or if you'd like to remove the "quiet" flag so that you can see
> more details of what's happening).
>
> Individual menu entries are generated by shell code fragments in the
> /etc/grub.d/ directory.  If you'd like to add a menu entry of your own,
> you can create a new file in this directory.  You'll need some expertise
> for this.  If you'd like to customize the generated segments of the GRUB
> menu, you might consider editing one of the existing files in this
> directory, but make sure you have a backup, and a means of booting in
> rescue mode, first.  This is not something you want to break, especially
> if it's a remote system.
>
>

Re: debian installation issue

[Felix Miata]

Greg Wooledge composed on 2021-06-11 15:07 (UTC-0400):

> On Fri, Jun 11, 2021 at 09:38:37PM +0300, Semih Ozlem wrote:

>> How to check where grub is installed? And what is a friendly guide to
>> learning about grub?

> GRUB should be installed on the *disk* (not on a partition) that you
> intend to boot.   
> 
Not to detract from the wisdom of the rest of Greg's excellent reply, but TBC,
this statement is religion at one extreme, opinion at the other, not fact. Note 
he
wisely did not say "must", but "should". For most traditional (BIOS/MBR; 
designed
for "Windows" PCs) configurations, it's probably prudent to put the bootloader 
on
the "disk". For pure Debian installations, as opposed to multiboot, whether or 
not
to install it on the "disk" really doesn't matter.

OTOH, putting a bootloader on the MBR of a disk on a PC designed for Windows is 
a
relative newcomer to the world of booting such a PC. I've been installing
operating systems on IBM-compatible PCs for more than 3 decades. Not once have I
intentionally installed Grub on an MBR. In the dearth of instances where it did
happen I wiped whatever caused it, and started over with
DOS/OS2/Windows/Linux-compatible MBR code on the MBR. IOW, Grub can live 
elsewhere
than on the MBR.

A less innocuous error is not clearly qualifying the quoted statement to apply
only to non-UEFI boot environments, which usually means an MBR-partitioned boot
disk. On a UEFI installation, which requires GPT partitioning, the first sector
normally contains nothing until near its end, where a disk identifier and the
start of the disk's multi-sector partition table begin. No executable code is
required on this sector.

With a UEFI "BIOS", the boot process begins rather differently than on an 
MBR-only
system. On a UEFI system's ESP (Extensible Firmware Interface System Partition; 
a
quasi-"boot" partition), there are no files containing the string "grub" in 
their
name. Thus it seems to be a debatable issue whether "bootloader" is actually an
appropriate name for Grub 2, as its primary purpose seems to be presenting a 
menu
from which to select what kernel, initrd (if any), and kernel command line
parameters (if any) to load into RAM to /continue/ the boot process initiated by
the UEFI firmware.
-- 
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

Re: debian installation issue

[Joe]

On Fri, 11 Jun 2021 21:38:37 +0300
Semih Ozlem  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

Re: debian installation issue

[Greg Wooledge]

On Fri, Jun 11, 2021 at 09:38:37PM +0300, Semih Ozlem wrote:
> I reinstalled the system, including an efi partition (500MiB) and the
> problem was fixed.

This suggests that you booted the installer in UEFI mode, rather than in
Legacy mode.  If you boot the installer in UEFI mode, you are expected
to install a system that will boot in UEFI mode, which means it needs an
EFI partition (and GPT disk label).

If you wanted to create an install that would boot in Legacy mode, you
need to boot the installer in Legacy mode first.

(Or maybe there's something you can do in Expert mode to work around it;
I don't know.  At a bare minimum, you'd need to switch which of the
GRUB packages gets installed -- grub-pc vs. grub-efi.)

> How to check where grub is installed? And what is a friendly guide to
> learning about grub?

GRUB should be installed on the *disk* (not on a partition) that you
intend to boot.

There are two different GRUB packages: grub-efi for UEFI booting, and
grub-pc for Legacy (BIOS) booting.  The mode in which you booted the
installer determines which of these gets installed at the end of the
installation.

Legacy (BIOS) booting is the old quasi-standard.  It's been around since
the 1980s.  In this paradigm, the boot loader code is installed to
something called the "master boot record" (MBR) which is really just the
first few hundred bytes of the disk.  Some space is left unpartitioned at
the start of the disk to make room for this.  Much hand-waving is involved.

UEFI booting is the new standard.  It's been around for several years
now, so it's fairly widespread, but not quite ubiquitous.  UEFI booting
requires a GPT disk label (partition table type), and one of the partitions
on the disk must be an EFI partition.  This is a FAT-type file system which
contains programs used by the boot loader.

A lot of machine (probably most machines made today) can boot in either of
these two modes, because not everyone has moved over to the new standard
yet.  Older machines will only support Legacy booting.  A few newer machines
may only support UEFI booting.

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.

Of course, this is not everything there is to know about UEFI and Legacy
booting, but it might be enough for most purposes, especially if you just
want to install and run Debian, and don't particularly care about the
inner workings.

Next, the care and feeding of GRUB on an installed Debian system:

In the /boot/grub directory there's a file named grub.cfg.  This is the
menu that GRUB reads from disk when you boot.  It's generated
automatically every time you do certain things (like installing a new
kernel package).  If at any time you'd like to regenerate this menu
(because you changed something yourself), you run this command:

update-grub

You should not edit grub.cfg directly, because your changes will be
overwritten eventually.

If you'd like to change how the menu operates, there are a few pieces
you need to know about.

The first is /etc/default/grub which is a file containing lines of shell
code.  It's only supposed to contain variable definitions, and these
variables affect the overall menu, or they affect every menu entry.
You can change these variables (e.g. if you'd like the menu timeout to
be a bit longer because your monitor takes several seconds to switch
modes, or if you'd like to remove the "quiet" flag so that you can see
more details of what's happening).

Individual menu entries are generated by shell code fragments in the
/etc/grub.d/ directory.  If you'd like to add a menu entry of your own,
you can create a new file in this directory.  You'll need some expertise
for this.  If you'd like to customize the generated segments of the GRUB
menu, you might consider editing one of the existing files in this
directory, but make sure you have a backup, and a means of booting in
rescue mode, first.  This is not something you want to break, especially
if it's a remote system.

Re: debian installation issue

[Semih Ozlem]

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?

Richard Owlett , 11 Haz 2021 Cum, 20:17 tarihinde şunu
yazdı:

> On 06/11/2021 11:31 AM, Semih Ozlem wrote:
> > Hi everyone,
> >
> > I am using 64bit with 4GiB system memory Intel COre i3-7100U @ 2.40 GHZ
> > machine. I installed debian on a usb (sandisk cruzer blade 2.0 32 GB). I
> > created a single partition.
> >
> > At the moment the system does not boot. From the installation media grub
> > menu shows up.
> >
> > Is there a way without reinstalling to make the system boot from the usb?
> > Should I have used a different partition system?
> >
> > Thanks
> >
>
> Did grub get installed to the flash drive?
>
>
>
>

Re: debian installation issue

[Richard Owlett]

On 06/11/2021 11:31 AM, Semih Ozlem wrote:

Hi everyone,

I am using 64bit with 4GiB system memory Intel COre i3-7100U @ 2.40 GHZ
machine. I installed debian on a usb (sandisk cruzer blade 2.0 32 GB). I
created a single partition.

At the moment the system does not boot. From the installation media grub
menu shows up.

Is there a way without reinstalling to make the system boot from the usb?
Should I have used a different partition system?

Thanks



Did grub get installed to the flash drive?

Re: Debian installation issue

[Andreas Janssen]

Hello

Kent West (<[EMAIL PROTECTED]>) wrote:

> Sreelal Chandrasenan wrote:

>> [...]
>> Even Debian could not detect the ethernetcard on the P4 board,
>> though it was detected by Redhat 9.X and Windows 2K. It is an Intel 
>> Pro 100 based card.  I tried different Debain CDs, still I am getting
>> the same problem.
> 
> I suspect you're installing from the first CD in a 7-CD set, which
> means you're using a 2.2 kernel. You probably need to use one of the
> other CDs (fourth?) in order to get a 2.4 kernel which will probably
> recognize the eepro100 card.

It is the fifth CD, but the 2.4 Kernel is also on the first CD, you only
have to tell the installer that you want to use it.

best regards
Andreas Janssen

-- 
Andreas Janssen
[EMAIL PROTECTED]
PGP-Key-ID: 0xDC801674
Registered Linux User #267976


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian installation issue

[Andreas Janssen]

Hello

Sreelal Chandrasenan (<[EMAIL PROTECTED]>) wrote:

> One of the Pentium 4 box, when I instaled the Debian linux, I got
> nano_1.0.6_2_i386.deb corrupt error and I am unable to proceed further
> with installation. I tried multiple times and I could not succeed. I
> could install debian on other Pentium3 systems using the same CD
> without any problem.

Maybe making a copy of the CD on another computer and using the copy
will work. Or you exchange the drive. Or you make an image of the
Debian installation from another system and copy it to the Pentium 4.
Or you put the stuff you need for installing the base system somewhere
on the hard disk of another computer or maybe on some partition on the
same computer and use that dir to install the base system from, locally
or via nfs. There are probably plenty other possibilities.

> Even Debian could not detect the ethernetcard on the P4 board, though
> it was detected by Redhat 9.X and Windows 2K. It is an Intel Pro 100 
> based card.

Debian doesn't try to "autodetect" any hardware. You have to load the
driver. You are asked for it during the installation process. I think
you need to select the eepro100 module. Maybe some of the installation
kernels on the first CD has it built in (in that case you don't have to
load the module), at least the 2.4.18-bf2.4 Kernel has it as a module.

best regards
Andreas Janssen

-- 
Andreas Janssen
[EMAIL PROTECTED]
PGP-Key-ID: 0xDC801674
Registered Linux User #267976


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian installation issue

[Kent West]

Sreelal Chandrasenan wrote:
One of the Pentium 4 box, when I instaled the Debian linux, I got nano_1.0.6_2_i386.deb corrupt error and I am unable to proceed further with installation. 
I tried multiple times and I could not succeed. I could install debian on other Pentium3 systems using the same CD without any problem.
This "feels" like a damaged-CD problem. Even though it installed on 
another machine, perhaps the damage/scuff occurred after the first 
install. Of perhaps the P4 box's CD drive is a little less tolerant of 
problems. I think I'd suggest burning a new CD, or at least cleaning 
your current one.

 Even Debian could not detect the ethernetcard on the P4 board, though it was detected 
by Redhat 9.X
and Windows 2K. It is an Intel Pro 100 based card.  I tried different Debain CDs, 
still I am getting the same problem.
 How to proceed ?
I suspect you're installing from the first CD in a 7-CD set, which means 
you're using a 2.2 kernel. You probably need to use one of the other CDs 
(fourth?) in order to get a 2.4 kernel which will probably recognize the 
eepro100 card. (You say you've tried different Debian CDs, but I don't 
know if you mean different burns of the same CD, or different CD from 
different sources, or different CDs of the 7-CD set, or what.) You might 
try running "modprobe eepro100" and see what happens. Or you can 
manually upgrade your kernel if you've already finished installing Debian.

--
Kent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]