Re: "Bug" in Debian Installer?
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.
Reply to: