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

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

"Bug" in Debian Installer?

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  "Bug" in Debian Installer? Andrew Wood <andrewjameswood@ymail.com> - 2023-04-15 11:40 +0200
    Re: "Bug" in Debian Installer? Geert Stappers <stappers@stappers.nl> - 2023-04-15 15:20 +0200
      Re: "Bug" in Debian Installer? Jude DaShiell <jdashiel@panix.com> - 2023-04-15 17:10 +0200
        Re: "Bug" in Debian Installer? Geert Stappers <stappers@stappers.nl> - 2023-04-15 19:30 +0200
          Re: "Bug" in Debian Installer? Jude DaShiell <jdashiel@panix.com> - 2023-04-15 19:40 +0200
          Re: "Bug" in Debian Installer? Geert Stappers <stappers@stappers.nl> - 2023-04-15 19:50 +0200
          Re: "Bug" in Debian Installer? Greg Wooledge <greg@wooledge.org> - 2023-04-15 21:40 +0200
            Re: "Bug" in Debian Installer? rhkramer@gmail.com - 2023-04-16 01:20 +0200
              Re: "Bug" in Debian Installer?  S.W.A.G. Geert Stappers <stappers@stappers.nl> - 2023-04-16 10:40 +0200
                Re: "Bug" in Debian Installer? S.W.A.G. Jude DaShiell <jdashiel@panix.com> - 2023-04-16 11:30 +0200
    Re: "Bug" in Debian Installer? David Christensen <dpchrist@holgerdanske.com> - 2023-04-16 01:00 +0200
      Re: "Bug" in Debian Installer? David Wright <deblis@lionunicorn.co.uk> - 2023-04-16 05:30 +0200
        Re: "Bug" in Debian Installer? Jude DaShiell <jdashiel@panix.com> - 2023-04-16 09:20 +0200
      Re: "Bug" in Debian Installer? Max Nikulin <manikulin@gmail.com> - 2023-04-16 12:50 +0200
        Re: "Bug" in Debian Installer? David Christensen <dpchrist@holgerdanske.com> - 2023-04-17 04:20 +0200
          Re: "Bug" in Debian Installer? Max Nikulin <manikulin@gmail.com> - 2023-04-17 07:10 +0200
            Re: "Bug" in Debian Installer? David Christensen <dpchrist@holgerdanske.com> - 2023-04-17 10:30 +0200
              Re: "Bug" in Debian Installer? Max Nikulin <manikulin@gmail.com> - 2023-04-17 12:40 +0200
                Re: "Bug" in Debian Installer? David Christensen <dpchrist@holgerdanske.com> - 2023-04-18 00:40 +0200
              Re: "Bug" in Debian Installer? David Wright <deblis@lionunicorn.co.uk> - 2023-04-17 16:50 +0200
                Re: "Bug" in Debian Installer? David Christensen <dpchrist@holgerdanske.com> - 2023-04-18 00:30 +0200
                  Re: "Bug" in Debian Installer? David Wright <deblis@lionunicorn.co.uk> - 2023-04-18 06:50 +0200
                    Re: "Bug" in Debian Installer? David Christensen <dpchrist@holgerdanske.com> - 2023-04-18 11:00 +0200
                      Re: "Bug" in Debian Installer? Max Nikulin <manikulin@gmail.com> - 2023-04-21 04:50 +0200
                        Re: "Bug" in Debian Installer? David Wright <deblis@lionunicorn.co.uk> - 2023-04-21 06:30 +0200
                          Re: "Bug" in Debian Installer? Max Nikulin <manikulin@gmail.com> - 2023-04-21 18:10 +0200
                            Re: "Bug" in Debian Installer? David Wright <deblis@lionunicorn.co.uk> - 2023-04-22 17:30 +0200
                    Re: "Bug" in Debian Installer? "Roy J. Tellason, Sr." <roy@rtellason.com> - 2023-04-18 19:10 +0200
                    Re: "Bug" in Debian Installer? Max Nikulin <manikulin@gmail.com> - 2023-04-20 18:00 +0200

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

#257338

On 4/17/23 07:41, David Wright wrote:
> On Mon 17 Apr 2023 at 01:27:45 (-0700), David Christensen wrote:
>> On 4/16/23 22:08, Max Nikulin wrote:
>>> On 17/04/2023 09:18, David Christensen wrote:
>>>> On 4/16/23 03:41, Max Nikulin wrote:
>>>>> On 16/04/2023 05:51, David Christensen wrote:
>>>>>> When I moved the 2.5" SATA SSD to a homebrew Intel
>>>>>> DQ67SW computer and configured BIOS Setup:
>>>>>>
>>>>>>       "Boot" -> "UEFI Boot" -> "Enable"
>>>>>>
>>>>>> The SSD would not boot.
>>>>>
>>>>> New boot entry usually should be created in such case from
>>>>> EFI Shell,
>>>
>>> I have realized that you may be confused by difference of MBR vs.
>>> UEFI behavior. For MBR it is enough to choose a disk to boot in
>>> BIOS, for UEFI it is necessary to add boot entries through EFI
>>> variables in firmware. Boot entry consists of disk, partition (EFI
>>> System partition) and path of an .efi file on this partition.
>>>
>>> If so, you may suggest an additional subsection to
>>> https://wiki.debian.org/UEFI#Troubleshooting_common_issues
>>
>> Are you saying that d-i modifies the CMOS settings of UEFI computers?
> 
> I think the preferred name is NVRAM, but yes.


So, in addition to modifying disks without notifying me or obtaining my 
permission, d-i modified, or attempted to modify, NVRAM settings without 
notifying me or obtaining my permission.


That is disappointing, but thank you for the information.


> 
>>>>>> I later discovered that the first install created a
>>>>>> directory and put files into the Dell's ESP (!).  I
>>>>>> did not select this, nor do I desire it.  This is a
>>>>>> defect with d-i:
>>>>>
>>>>> Why do you think it is wrong?
>>>>
>>>> Because OS installers should not modify a disk unless the user
>>>> authorizes it.
>>>
>>> I agree if a computer is booted into MBR/BIOS/Compatibility mode
>>> or if expert install is selected. For regular UEFI install it is a
>>> trade-off since multiple OS loaders may coexist without conflicts.
>>> User should be asked if new OS should be booted by default
>>> (BootOrder), adding files to ESP is quite safe.
>>
>> d-i should always ask before writing to disk.
> 
> You will certainly be used to this because of years of BIOS/MBR
> experience. There's always a question of where to install Grub
> because you might make another OS unbootable, or you might want
> Grub placed on a particular partition.
> 
> With UEFI booting, that doesn't typically come into play, so to
> provoke your question, you'd probably need low priority/Expert
> Install, which I don't think you asked for.


I asked for "Install":

On 4/15/23 15:51, David Christensen wrote:
 >      "Debian GNU/Linux UEFI Installer menu" -> "Install"


> 
>>>> Here are my notes from a debian-9.9.0-amd64-xfce-CD-1 install
>>>> on February 2, 2020:
>>>>
>>>>       Install GRUB into master boot record        Yes
>>>>       Device                                      /dev/sda
>>>>
>>>> That was the proper way to do it.
>>>
>>> Am I right that it was not UEFI install? Certainly overwriting of
>>> MBR must be acknowledged by the user.
>>
>> The point is that d-i asked before writing to disk.
> 
> Yes, it's MBR.
> 
>>>>>> The SSD would not boot.
> 
> I asked about the partitioning scheme earlier, but no response.


Here is the current system disk configuration.  It should match the 
failed installation, except that I added the fifth "scratch" partition 
and file system later:

2023-04-17 14:21:39 root@taz ~
# parted /dev/sda u s p free
Model: ATA INTEL SSDSC2CW06 (scsi)
Disk /dev/sda: 117231408s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start       End         Size       File system  Name 
   Flags
         34s         2047s       2014s      Free Space
  1      2048s       1953791s    1951744s   fat32        ESP 
    boot, esp
  2      1953792s    3907583s    1953792s   ext4         taz_boot
  3      3907584s    5861375s    1953792s                taz_swap_crypt
  4      5861376s    29298687s   23437312s               taz_root_crypt
  5      29298688s   117229567s  87930880s               taz_scratch_crypt
         117229568s  117231374s  1807s      Free Space

2023-04-17 14:25:51 root@taz ~
# mount | egrep 'boot|mapper' | sort
/dev/mapper/sda4_crypt on / type ext4 (rw,relatime,errors=remount-ro)
/dev/mapper/sda5_crypt on /scratch type ext4 (rw,relatime)
/dev/sda1 on /boot/efi type vfat 
(rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/sda2 on /boot type ext4 (rw,relatime)

2023-04-17 14:27:06 root@taz ~
# swapon
NAME      TYPE      SIZE USED PRIO
/dev/dm-1 partition 954M   0B   -2


> I'll hazard a guess that the second disk had no ESP on it, so the
> original installer set up a dual boot system for Windows and Debian
> by adding an entry to the original disk's ESP. No need to quiz the
> operator as there would be with a Windows MBR.
> 
> When you took the second disk out, it was unbootable as there was
> no ESP on it. (That's my guess.) 


During the failed installation, d-i put the directory and files onto the 
primary disk:

On 4/15/23 15:51, David Christensen wrote:
 > 2023-04-15 15:10:34 root@taz ~
 > # ls -ld /mnt/nvme0n1p1/EFI/debian
 > drwxr-xr-x 2 root root 4096 Mar 16 22:19 /mnt/nvme0n1p1/EFI/debian
 >
 > 2023-04-15 15:10:36 root@taz ~
 > # ls -l /mnt/nvme0n1p1/EFI/debian
 > total 5892
 > -rwxr-xr-x 1 root root     108 Mar 16 22:19 BOOTX64.CSV
 > -rwxr-xr-x 1 root root   84648 Mar 16 22:19 fbx64.efi
 > -rwxr-xr-x 1 root root     121 Mar 16 22:19 grub.cfg
 > -rwxr-xr-x 1 root root 4150720 Mar 16 22:19 grubx64.efi
 > -rwxr-xr-x 1 root root  845480 Mar 16 22:19 mmx64.efi
 > -rwxr-xr-x 1 root root  934240 Mar 16 22:19 shimx64.efi


Without repeating the failed installation, it is impossible to know 
whether or not d-i also put the above directory and files into the ESP 
of the second disk.  The fact that the disk would not boot in another 
UEFI computer tends to indicates d-i did not, but there are other 
possibilities (UEFI settings, bugs, features, PEBKAC, etc.)


> So you zeroed it and reinstalled.
> 
> My experience, from having a mixed bag of BIOS/UEFI computers with
> GPT disks, has been to always create a BIOS Boot Partition (3MB,
> at the start, giving 4MB alignment for the rest of the drive), and
> always create a potential ESP ½GB immediately following. On a BIOS
> machine, it can make an extra swap as they have less memory anyway,
> but the disk is then suitable for conversion to a UEFI environment.
> With GPT, you don't have to worry about running out of primary
> partitions.


I have never seen a document that completely and accurately explains, in 
computer engineering and science terms, the design and implementation of 
the boot processes for Debian (or FreeBSD, or Windows, or macOS) for all 
the possible combinations of BIOS, UEFI, MBR, and GPT; including 
work-arounds such as "protective MBR", "BIOS Boot Partition", etc..  If 
anyone knows of such, please provide a citation.


> 
> I have one ESP-less laptop, dating from 2004, so I don't think
> I'll be moving its 60GB GPT disk into a different machine when
> it finally dies.
> 
> I did convert one BIOS laptop to UEFI without even reinstalling its
> Debian, with encouragement from Felix. That was back in 2022-02 too.
> 
>  From the UEFI wiki:
> 
>   "Once the normal installation process has been completed, the second
>    major component with UEFI support comes into play: grub-installer.
>    It will install the grub-efi bootloader to the right location in the
>    ESP and will use efibootmgr to register that bootloader with the
>    firmware. On correctly-working systems, this should work without
>    needing any user interaction. This module will automatically find
>    the ESP and install its files in the right place, leaving no space
>    for confusion on where boot files are saved (as can happen with
>    MBR/MS-DOS systems)."
> 
> Cheers,
> David.
> 


I will expand my statement to: d-i should inform the user and obtain 
their permission before making changes to a computer.


David

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

#257342

On Mon 17 Apr 2023 at 15:26:58 (-0700), David Christensen wrote:
> On 4/17/23 07:41, David Wright wrote:
> > On Mon 17 Apr 2023 at 01:27:45 (-0700), David Christensen wrote:
> > > On 4/16/23 22:08, Max Nikulin wrote:
> > > > On 17/04/2023 09:18, David Christensen wrote:
> > > > > On 4/16/23 03:41, Max Nikulin wrote:
> > > > > > On 16/04/2023 05:51, David Christensen wrote:
> > > > > > > When I moved the 2.5" SATA SSD to a homebrew Intel
> > > > > > > DQ67SW computer and configured BIOS Setup:
> > > > > > > 
> > > > > > >       "Boot" -> "UEFI Boot" -> "Enable"
> > > > > > > 
> > > > > > > The SSD would not boot.
> > > > > > 
> > > > > > New boot entry usually should be created in such case from
> > > > > > EFI Shell,
> > > > 
> > > > I have realized that you may be confused by difference of MBR vs.
> > > > UEFI behavior. For MBR it is enough to choose a disk to boot in
> > > > BIOS, for UEFI it is necessary to add boot entries through EFI
> > > > variables in firmware. Boot entry consists of disk, partition (EFI
> > > > System partition) and path of an .efi file on this partition.
> > > > 
> > > > If so, you may suggest an additional subsection to
> > > > https://wiki.debian.org/UEFI#Troubleshooting_common_issues
> > > 
> > > Are you saying that d-i modifies the CMOS settings of UEFI computers?
> > 
> > I think the preferred name is NVRAM, but yes.
> 
> So, in addition to modifying disks without notifying me or obtaining
> my permission, d-i modified, or attempted to modify, NVRAM settings
> without notifying me or obtaining my permission.

When you run the d-i, there are steps that are generally irrevocable.
Examples would be partitioning, writing random data for an encrypted
filesystem, and writing the MBR. (If you boot the d-i from the hard
disk itself, you have no medium with which to boot the machine when
you screw up the MBR.) I don't think adding material to the ESP, or
running efibootmgr are necessarily seen that way.

> That is disappointing, but thank you for the information.
> 
> 
> > 
> > > > > > > I later discovered that the first install created a
> > > > > > > directory and put files into the Dell's ESP (!).  I
> > > > > > > did not select this, nor do I desire it.  This is a
> > > > > > > defect with d-i:
> > > > > > 
> > > > > > Why do you think it is wrong?
> > > > > 
> > > > > Because OS installers should not modify a disk unless the user
> > > > > authorizes it.
> > > > 
> > > > I agree if a computer is booted into MBR/BIOS/Compatibility mode
> > > > or if expert install is selected. For regular UEFI install it is a
> > > > trade-off since multiple OS loaders may coexist without conflicts.
> > > > User should be asked if new OS should be booted by default
> > > > (BootOrder), adding files to ESP is quite safe.
> > > 
> > > d-i should always ask before writing to disk.
> > 
> > You will certainly be used to this because of years of BIOS/MBR
> > experience. There's always a question of where to install Grub
> > because you might make another OS unbootable, or you might want
> > Grub placed on a particular partition.
> > 
> > With UEFI booting, that doesn't typically come into play, so to
> > provoke your question, you'd probably need low priority/Expert
> > Install, which I don't think you asked for.
> 
> 
> I asked for "Install":
> 
> On 4/15/23 15:51, David Christensen wrote:
> >      "Debian GNU/Linux UEFI Installer menu" -> "Install"

AIUI, from the first menu, that gives you Priority=medium.

> > > > > Here are my notes from a debian-9.9.0-amd64-xfce-CD-1 install
> > > > > on February 2, 2020:
> > > > > 
> > > > >       Install GRUB into master boot record        Yes
> > > > >       Device                                      /dev/sda
> > > > > 
> > > > > That was the proper way to do it.
> > > > 
> > > > Am I right that it was not UEFI install? Certainly overwriting of
> > > > MBR must be acknowledged by the user.
> > > 
> > > The point is that d-i asked before writing to disk.
> > 
> > Yes, it's MBR.
> > 
> > > > > > > The SSD would not boot.
> > 
> > I asked about the partitioning scheme earlier, but no response.
> 
> 
> Here is the current system disk configuration.  It should match the
> failed installation, except that I added the fifth "scratch" partition
> and file system later:
> 
> 2023-04-17 14:21:39 root@taz ~
> # parted /dev/sda u s p free
> Model: ATA INTEL SSDSC2CW06 (scsi)
> Disk /dev/sda: 117231408s
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
> Disk Flags:
> 
> Number  Start       End         Size       File system  Name   Flags
>         34s         2047s       2014s      Free Space
>  1      2048s       1953791s    1951744s   fat32        ESP    boot,
> esp
>  2      1953792s    3907583s    1953792s   ext4         taz_boot
>  3      3907584s    5861375s    1953792s                taz_swap_crypt
>  4      5861376s    29298687s   23437312s               taz_root_crypt
>  5      29298688s   117229567s  87930880s               taz_scratch_crypt
>         117229568s  117231374s  1807s      Free Space
> 
> 2023-04-17 14:25:51 root@taz ~
> # mount | egrep 'boot|mapper' | sort
> /dev/mapper/sda4_crypt on / type ext4 (rw,relatime,errors=remount-ro)
> /dev/mapper/sda5_crypt on /scratch type ext4 (rw,relatime)
> /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
> /dev/sda2 on /boot type ext4 (rw,relatime)
> 
> 2023-04-17 14:27:06 root@taz ~
> # swapon
> NAME      TYPE      SIZE USED PRIO
> /dev/dm-1 partition 954M   0B   -2
> 
> 
> > I'll hazard a guess that the second disk had no ESP on it, so the
> > original installer set up a dual boot system for Windows and Debian
> > by adding an entry to the original disk's ESP. No need to quiz the
> > operator as there would be with a Windows MBR.
> > 
> > When you took the second disk out, it was unbootable as there was
> > no ESP on it. (That's my guess.)
> 
> 
> During the failed installation, d-i put the directory and files onto
> the primary disk:
> 
> On 4/15/23 15:51, David Christensen wrote:
> > 2023-04-15 15:10:34 root@taz ~
> > # ls -ld /mnt/nvme0n1p1/EFI/debian
> > drwxr-xr-x 2 root root 4096 Mar 16 22:19 /mnt/nvme0n1p1/EFI/debian
> >
> > 2023-04-15 15:10:36 root@taz ~
> > # ls -l /mnt/nvme0n1p1/EFI/debian
> > total 5892
> > -rwxr-xr-x 1 root root     108 Mar 16 22:19 BOOTX64.CSV
> > -rwxr-xr-x 1 root root   84648 Mar 16 22:19 fbx64.efi
> > -rwxr-xr-x 1 root root     121 Mar 16 22:19 grub.cfg
> > -rwxr-xr-x 1 root root 4150720 Mar 16 22:19 grubx64.efi
> > -rwxr-xr-x 1 root root  845480 Mar 16 22:19 mmx64.efi
> > -rwxr-xr-x 1 root root  934240 Mar 16 22:19 shimx64.efi
> 
> 
> Without repeating the failed installation, it is impossible to know
> whether or not d-i also put the above directory and files into the ESP
> of the second disk.  The fact that the disk would not boot in another
> UEFI computer tends to indicates d-i did not, but there are other
> possibilities (UEFI settings, bugs, features, PEBKAC, etc.)

Yes, I think that if you wanted the installer to populate a second
ESP, you'd have to ask for it, and that would probably require a
Priority lower than medium.

> > So you zeroed it and reinstalled.
> > 
> > My experience, from having a mixed bag of BIOS/UEFI computers with
> > GPT disks, has been to always create a BIOS Boot Partition (3MB,
> > at the start, giving 4MB alignment for the rest of the drive), and
> > always create a potential ESP ½GB immediately following. On a BIOS
> > machine, it can make an extra swap as they have less memory anyway,
> > but the disk is then suitable for conversion to a UEFI environment.
> > With GPT, you don't have to worry about running out of primary
> > partitions.
> 
> 
> I have never seen a document that completely and accurately explains,
> in computer engineering and science terms, the design and
> implementation of the boot processes for Debian (or FreeBSD, or
> Windows, or macOS) for all the possible combinations of BIOS, UEFI,
> MBR, and GPT; including work-arounds such as "protective MBR", "BIOS
> Boot Partition", etc..  If anyone knows of such, please provide a
> citation.

You might start with:

  https://www.rodsbooks.com/gdisk/whatsgpt.html

> > I have one ESP-less laptop, dating from 2004, so I don't think
> > I'll be moving its 60GB GPT disk into a different machine when
> > it finally dies.
> > 
> > I did convert one BIOS laptop to UEFI without even reinstalling its
> > Debian, with encouragement from Felix. That was back in 2022-02 too.
> > 
> >  From the UEFI wiki:
> > 
> >   "Once the normal installation process has been completed, the second
> >    major component with UEFI support comes into play: grub-installer.
> >    It will install the grub-efi bootloader to the right location in the
> >    ESP and will use efibootmgr to register that bootloader with the
> >    firmware. On correctly-working systems, this should work without
> >    needing any user interaction. This module will automatically find
> >    the ESP and install its files in the right place, leaving no space
> >    for confusion on where boot files are saved (as can happen with
> >    MBR/MS-DOS systems)."
> 
> I will expand my statement to: d-i should inform the user and obtain
> their permission before making changes to a computer.

As in "Permission to break an egg, sir"? Did not pressing Enter in
reply to "Install" imply something?

 "If there is a problem, the user will see an error screen, and the
  installer menu may be shown in order to select some alternative
  action. If there are no problems, the user will never see the
  installer menu, but will simply answer questions for each component
  in turn. Serious error notifications are set to priority “critical”
  so the user will always be notified."

You'd have to consult the Installation Guide to see which initial
replies lead to which Priority for the d-i to run at. I've always
run an Expert Install, because I've always installed remotely from
another machine ever since that option's been around. I find it
far more convenient.

Cheers,
David.

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

#257346

On 4/17/23 21:47, David Wright wrote:
> On Mon 17 Apr 2023 at 15:26:58 (-0700), David Christensen wrote:

>> I have never seen a document that completely and accurately explains,
>> in computer engineering and science terms, the design and
>> implementation of the boot processes for Debian (or FreeBSD, or
>> Windows, or macOS) for all the possible combinations of BIOS, UEFI,
>> MBR, and GPT; including work-arounds such as "protective MBR", "BIOS
>> Boot Partition", etc..  If anyone knows of such, please provide a
>> citation.
> 
> You might start with:
> 
>    https://www.rodsbooks.com/gdisk/whatsgpt.html


Thank you for the link.


>> I will expand my statement to: d-i should inform the user and obtain
>> their permission before making changes to a computer.
> 
> As in "Permission to break an egg, sir"? Did not pressing Enter in
> reply to "Install" imply something?


d-i modifying a disk without explicit notification and permission is 
unacceptable.


d-i modifying NVRAM without explicit notification and permission is 
unacceptable.


Do you contribute to d-i?


David

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

#257453

On 4/15/23 15:51, David Christensen wrote:
 >      "Debian GNU/Linux UEFI Installer menu" -> "Install"

On 18/04/2023 15:51, David Christensen wrote:
> On 4/17/23 21:47, David Wright wrote:
>> As in "Permission to break an egg, sir"? Did not pressing Enter in
>> reply to "Install" imply something?
> 
> d-i modifying a disk without explicit notification and permission is 
> unacceptable.
> 
> d-i modifying NVRAM without explicit notification and permission is 
> unacceptable.

These modifications happen at the last installation steps, so they 
hardly could be considered as unintended at least in the case of default 
(not expert) install.

I have tried bookworm RC1 netinst. "Detect disks" + manual partitioning 
detects existing ESP and selects it for ESP. I think, it is reasonable 
default action. I aborted installation, so I can say nothing concerning 
install grub stage.

Perhaps, preparing disk for another machine, you did not expect that you 
have to create another EFI System Partition, to choose it to use as ESP 
and to explicitly tell installer that existing ESP should not be used.

Opt-out variant for ESP sounds reasonable for me. However I am unsure if 
it is possible to complete installation with no ESP at all.

What may be considered as issues from my point of view:
1. From the disks overview screen it is not immediately obvious that 
installer is going to write to ESP partitions.
2. On a laptop having ESP partitions on 2 disks, both ones are marked 
for usage as ESP. I am unsure if it causes installation error later or 
grub is installed on both ones (taking into account single /boot/efi 
mount point).

> Do you contribute to d-i?

No, I do not. You may check if your case has been discussed on the 
installer mailing list or in the bug tracker.

I am not sure that the topic starter faced the same issue as you are 
trying to rise since quite few details have been provided so far.

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

#257454

On Fri 21 Apr 2023 at 09:48:43 (+0700), Max Nikulin wrote:

> Opt-out variant for ESP sounds reasonable for me. However I am unsure
> if it is possible to complete installation with no ESP at all.

If you mean: to install Grub but not write to the ESP, I think you can
do this by saying Yes to:

┌─────────────────┤ [!] Install the GRUB boot loader ├──────────────────┐
│                                                                       │
│ The following other operating systems have been detected on this      │
│ computer: Debian GNU/Linux 11 (bullseye)                              │
│                                                                       │
│ If all of your operating systems are listed above, then it should be  │
│ safe to install the boot loader to your primary drive (UEFI           │
│ partition/boot record). When your computer boots, you will be able to │
│ choose to load one of these operating systems or the newly installed  │
│ Debian system.                                                        │
│                                                                       │
│ Install the GRUB boot loader to your primary drive?                   │

and Go Back to:

┌──────────────────┤ [!] Install the GRUB boot loader ├───────────────┐
│                                                                     │
│ You need to make the newly installed system bootable, by installing │
│ the GRUB boot loader on a bootable device. The usual way to do this │
│ is to install GRUB to your primary drive (UEFI partition/boot       │
│ record). You may instead install GRUB to a different drive (or      │
│ partition), or to removable media.                                  │
│                                                                     │
│           Device for boot loader installation:                      │

If there was already a working Grub on the disk, then it should be
straightforward to boot by editing one of its menu entries.
With anything less than that, it helps to be familiar with the Grub
rescue prompt.

> What may be considered as issues from my point of view:
> 1. From the disks overview screen it is not immediately obvious that
> installer is going to write to ESP partitions.

If, by disks overview, you mean the screen quoted just above, then no,
it is less obvious than ISTR in the past (up to buster), where MBR was
explicitly mentioned on BIOS machines.

Bullseye had a misfeature where it would, even on a BIOS machine,
solicit installing to the fallback location. I don't know whether
it was the presence of a GPT disk that caused this offer (I have no
MBR disks to try out instead), or whether it was a belt and braces
(suspenders) approach for mitigating buggy UEFI implementations.

If you forget which mode you booted with, then sure-fire confirmation
is given by   # ls /sys/firmware/efi   in VC2/VC3, which is present
only for UEFI. (Doesn't count as obvious, though.)

> 2. On a laptop having ESP partitions on 2 disks, both ones are marked
> for usage as ESP. I am unsure if it causes installation error later or
> grub is installed on both ones (taking into account single /boot/efi
> mount point).

I would assume not, as people complain about this as a single point of
failure in UEFI booting. I haven't tried repeating "Install the GRUB
boot loader" from the Main Menu, but I don't see why it shouldn't
work. But I don't think that that would get you two entries in NVRAM
without playing some tricks.

Cheers,
David.

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

#257467

On 21/04/2023 11:26, David Wright wrote:
> On Fri 21 Apr 2023 at 09:48:43 (+0700), Max Nikulin wrote:
> 
>> Opt-out variant for ESP sounds reasonable for me. However I am unsure
>> if it is possible to complete installation with no ESP at all.
> 
> If you mean: to install Grub but not write to the ESP,

No, I did not go so far. I wrote about partitioning screen. It is 
possible to select ESP partition and mark it "Do not use". My 
expectation is that it should prevent installing grub to ESP. However it 
is easy to forget about the "K" flag (partition will be used by installer).

My point is that if a partition is marked for usage as ESP then it is 
not "without explicit notification and permission".

> ┌─────────────────┤ [!] Install the GRUB boot loader ├──────────────────┐

Is it shown in the case of default debconf priority or it is necessary 
to switch to "low"?

Frankly speaking, from this text it is unclear for me if the question is 
related to putting files to EFI/debian or to creation of new BootXXXX 
NVRAM variable with possible modification of BootOrder.

> │ The following other operating systems have been detected on this      │
> │ computer: Debian GNU/Linux 11 (bullseye)                              │
> │                                                                       │
> │ If all of your operating systems are listed above, then it should be  │
> │ safe to install the boot loader to your primary drive (UEFI           │
> │ partition/boot record).

Side note. I do not think it is safe to install *Debian* boot loader 
when another *Debian* is detected. It will overwrite EFI/debian/grub.cfg 
and so will make earlier installed debian not bootable. Either I missed 
something or it is fragile to manage grub configuration shared by 2 
independent debian (or other linux distributions) systems.

> Bullseye had a misfeature where it would, even on a BIOS machine,
> solicit installing to the fallback location.

Do you mean installing grub to EFI/BOOT (layout for removable storage)? 
I have an almost 10 years old HP laptop with buggy firmware. The easiest 
way to make linux bootable is to put grub into EFI/BOOT (and remove 
fbx64.efi fallback binary that attempts to adjust BootXXXX and ignored 
BootOrder on each boot). It is possible to select any boot entry from F9 
menu, but by default it boots from EFI/BOOT/bootx64.efi.

>> 2. On a laptop having ESP partitions on 2 disks, both ones are marked
>> for usage as ESP. I am unsure if it causes installation error later or
>> grub is installed on both ones (taking into account single /boot/efi
>> mount point).
> 
> I would assume not, as people complain about this as a single point of
> failure in UEFI booting. I haven't tried repeating "Install the GRUB
> boot loader" from the Main Menu, but I don't see why it shouldn't
> work. But I don't think that that would get you two entries in NVRAM
> without playing some tricks.

On that HP laptop I manually installed grub to second ESP. The result is 
2 indistinguishable entries in F9 boot menu. The text is taken from 
shim/BOOTX64.CSV, no other hints displayed.

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

#257477

On Fri 21 Apr 2023 at 23:05:53 (+0700), Max Nikulin wrote:
> On 21/04/2023 11:26, David Wright wrote:
> > On Fri 21 Apr 2023 at 09:48:43 (+0700), Max Nikulin wrote:
> > 
> > > Opt-out variant for ESP sounds reasonable for me. However I am unsure
> > > if it is possible to complete installation with no ESP at all.
> > 
> > If you mean: to install Grub but not write to the ESP,
> 
> No, I did not go so far. I wrote about partitioning screen.

Understood; I wasn't sure.

> It is
> possible to select ESP partition and mark it "Do not use". My
> expectation is that it should prevent installing grub to ESP. However
> it is easy to forget about the "K" flag (partition will be used by
> installer).

I haven't tried removing all the flags to see what warning might result,
and whether there would even be any attempt to install grub-* (the
packages called grub-*, not writing grub.cfg or placing Grub code in
NVRAM). It does help to have the grub packages available to make
changes later.

> My point is that if a partition is marked for usage as ESP then it is
> not "without explicit notification and permission".

Agreed: it reinforces/confirms the point that the user asked the d-i
to install a Debian system.

> > ┌─────────────────┤ [!] Install the GRUB boot loader ├──────────────────┐
> 
> Is it shown in the case of default debconf priority or it is necessary
> to switch to "low"?

IDK. As I said, "I think you can …", which I wrote because I think I
did just that. (I was doing something very similar to what the OP was
doing, using a PC with dual-booting Windows/Debian to install Debian
onto a portable drive, without screwing up the dual-boot.

> Frankly speaking, from this text it is unclear for me if the question
> is related to putting files to EFI/debian or to creation of new
> BootXXXX NVRAM variable with possible modification of BootOrder.

Sure. I was hacking, and keeping a close eye on VC4. (Using more is
hard work compared with less.)

> > │ The following other operating systems have been detected on this      │
> > │ computer: Debian GNU/Linux 11 (bullseye)                              │
> > │                                                                       │
> > │ If all of your operating systems are listed above, then it should be  │
> > │ safe to install the boot loader to your primary drive (UEFI           │
> > │ partition/boot record).
> 
> Side note. I do not think it is safe to install *Debian* boot loader
> when another *Debian* is detected. It will overwrite
> EFI/debian/grub.cfg and so will make earlier installed debian not
> bootable. Either I missed something or it is fragile to manage grub
> configuration shared by 2 independent debian (or other linux
> distributions) systems.

That's why I wrote about "playing tricks" below. Felix mentioned
using GRUB_DISTRIBUTOR to avoid having the same name used twice.

> > Bullseye had a misfeature where it would, even on a BIOS machine,
> > solicit installing to the fallback location.
> 
> Do you mean installing grub to EFI/BOOT (layout for removable
> storage)?

Yes. The nomenclature is very confusing IMO.

> I have an almost 10 years old HP laptop with buggy firmware.
> The easiest way to make linux bootable is to put grub into EFI/BOOT
> (and remove fbx64.efi fallback binary that attempts to adjust BootXXXX
> and ignored BootOrder on each boot). It is possible to select any boot
> entry from F9 menu, but by default it boots from EFI/BOOT/bootx64.efi.

But this was a BIOS machine, so there's no UEFI/EFI. The buster d-i
seemed not to realise that, even though it knew it had an MBR:

┌───────────┤ [!] Install the GRUB boot loader on a hard disk ├───────────┐
│                                                                         │
│ You need to make the newly installed system bootable, by installing     │
│ the GRUB boot loader on a bootable device. The usual way to do this     │
│ is to install GRUB on the master boot record of your first hard         │
                            ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
│ drive. If you prefer, you can install GRUB elsewhere on the drive, or   │
│ to another drive, or even to a floppy.                                  │
│                                                                         │
│ Device for boot loader installation:                                    │

 ┌──────────┤ [.] Install the GRUB boot loader on a hard disk ├──────────┐
 │                                                                       │
 │ It seems that this computer is configured to boot via EFI, but maybe  │
                                                ↑↑↑↑↑↑↑↑↑↑↑↑
 │ that configuration will not work for booting from the hard drive.     │
 │ Some EFI firmware implementations do not meet the EFI specification   │
 │ (i.e. they are buggy!) and do not support proper configuration of     │
 │ boot options from system hard drives.                                 │
 │                                                                       │
 │ A workaround for this problem is to install an extra copy of the EFI  │
 │ version of the GRUB boot loader to a fallback location, the           │
┌│ "removable media path". Almost all EFI systems, no matter how buggy,  │
││ will boot GRUB that way.                                              │
││                                                                       │
││ Warning: If the installer failed to detect another operating system   │
││ that is present on your computer that also depends on this fallback,  │
││ installing GRUB there will make that operating system temporarily     │
└│ unbootable. GRUB can be manually configured later to boot it if       │
 │ necessary.                                                            │
 │                                                                       │
 │ Force GRUB installation to the EFI removable media path?              │

> > > 2. On a laptop having ESP partitions on 2 disks, both ones are marked
> > > for usage as ESP. I am unsure if it causes installation error later or
> > > grub is installed on both ones (taking into account single /boot/efi
> > > mount point).
> > 
> > I would assume not, as people complain about this as a single point of
> > failure in UEFI booting. I haven't tried repeating "Install the GRUB
> > boot loader" from the Main Menu, but I don't see why it shouldn't
> > work. But I don't think that that would get you two entries in NVRAM
> > without playing some tricks.
            ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑

> On that HP laptop I manually installed grub to second ESP. The result
> is 2 indistinguishable entries in F9 boot menu. The text is taken from
> shim/BOOTX64.CSV, no other hints displayed.

AIUI the desired outcome from that situation would be that the system
would choose one entry pointing to one ESP, and if that failed to
boot, automatically try the other. Fewer single points of failure.
Obviously, that doesn't happen.

Cheers,
David.

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

#257366

On Tuesday 18 April 2023 12:47:44 am David Wright wrote:
> > I have never seen a document that completely and accurately explains,
> > in computer engineering and science terms, the design and
> > implementation of the boot processes for Debian (or FreeBSD, or
> > Windows, or macOS) for all the possible combinations of BIOS, UEFI,
> > MBR, and GPT; including work-arounds such as "protective MBR", "BIOS
> > Boot Partition", etc..  If anyone knows of such, please provide a
> > citation.
> 
> You might start with:
> 
>   https://www.rodsbooks.com/gdisk/whatsgpt.html
> 

Thanks for that...

It's clarified some things that I've been wondering about.

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

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

#257443

On 18/04/2023 11:47, David Wright wrote:
> On Mon 17 Apr 2023 at 15:26:58 (-0700), David Christensen wrote:
>>
>> I have never seen a document that completely and accurately explains,
>> in computer engineering and science terms, the design and
>> implementation of the boot processes for Debian (or FreeBSD, or
>> Windows, or macOS) for all the possible combinations of BIOS, UEFI,
>> MBR, and GPT; including work-arounds such as "protective MBR", "BIOS
>> Boot Partition", etc..  If anyone knows of such, please provide a
>> citation.
> You might start with:
> 
>    https://www.rodsbooks.com/gdisk/whatsgpt.html

The site by Roderick W. Smith contains a lot of invaluable information 
from "first hands" of a developer of a boot loader and of GPT fdisk. 
Sometimes however I had difficulties however to find details related to 
particular question.

Concerning UEFI I have the following links in my notes:

https://www.happyassassin.net/posts/2014/01/25/uefi-boot-how-does-that-actually-work-then/
Adam Williamson. UEFI boot: how does that actually work, then? 
2014-01-25 21:07

https://en.opensuse.org/openSUSE:UEFI
About UEFI

https://www.rodsbooks.com/linux-uefi/
Roderick W. Smith. Linux on UEFI:
A Quick Installation Guide

I do not think a document that "completely and accurately explains..." 
exists at all.

[toc] | [prev] | [standalone]

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

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

csiph-web