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 1 of 2  [1] 2  Next page →

#235995 — debian installation issue

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

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

[toc] | [next] | [standalone]

#235997

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?

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

#235999

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

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 <rowlett@cloud85.net>, 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?
>
>
>
>

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

#236000

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.

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

#236004

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

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

#236304

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.

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

#236394

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

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

#236616

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.

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

#236622

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

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

#236857

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.

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

#236883

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

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

#236007

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

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 <greg@wooledge.org>, 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.
>
>

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

#236008

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
<https://superuser.com/questions/739153/uefi-with-mbr-partition-table>
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.

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

#236091

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

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

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

#236093

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

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

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

#236095 — [Off topic thoughts] Re: debian installation issue

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

tomas@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

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

#236096 — Re: [Off topic thoughts] Re: debian installation issue

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

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."
> 
> tomas@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

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

#236100 — Re: [Off topic thoughts] Re: debian installation issue

On Mon, 14 Jun 2021 11:41:37 +0200
<tomas@tuxteam.de> wrote:


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

-- 
Joe

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

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

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

On Mon, Jun 14, 2021 at 4:45 AM Thomas Schmitt <scdbackup@gmx.net> 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."
>
> tomas@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

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

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

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.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web