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
