Le 05/12/2017 à 06:55, David Christensen a écrit :
I wiped the SSD, ran d-i, and chose "Partitioning method" -> "Guided -
use entire disk and set up encrypted LVM", which produced:
LVM VG debian-vg, LV home - 3.5 GB Linux device-mapper (linear)
#1 3.5 GB f ext4 /home
LVM VG debian-vg, LV root - 2.0 GB Linux device-mapper (linear)
#1 2.0 GB f ext4 /
LVM VG debian-vg, LV swap_1 - 8.5 GB Linux device-mapper (linear)
#1 8.5 GB f swap swap
LVM VG debian-vg, LV tmp - 255.9 MB Linux device-mapper (linear)
#1 255.9 MB f ext4 /tmp
LVM VG debian-vg, LV tmp - 998.2 MB Linux device-mapper (linear)
#1 998.2 MB f ext4 /var
Encrypted volume (sda3_crypt) - 15.2 GB Linux device-mapper (crypt)
#1 15.2 GB K lvm
SCSI3 (0,0,0) (sda) - 16.0 GB ATA SAMSUNG SSD UM41
1.0 MB FREE SPACE
#1 536.9 MB B F ESP
#2 255.9 MB F ext2 /boot
#3 15.2 GB K crypto (sda3_crypt)
73.2 kB FREE SPACE
(...)
d-i completed without errors. :-)
ESP means that you ran the installer in EFI mode. If you did that with
the initial partitioning (BIOS boot partition), the installation of GRUB
could not work because there was no ESP partition.
As for "how does it boot with UEFI, GPT, and GRUB?", my vague guess is:
1. There is no 16-bit 8086 first stage boot loader code in sector 0 of
the SSD -- see 'gpart -d -vvv /dev/sda' output, below. The motherboard
firmware doesn't use this in UEFI mode.
Correct.
2. There is a "protective MBR" in sector 0 of the SSD -- see 'fdisk -t
mbr -l /dev/sda' output, below. I don't know if UEFI firmware looks at
this.
It may, in order to check that it contains a valid protective MBR.
3. The firmware finds and reads the GPT partition table on the SSD.
Correct.
4. The firmware finds the first GPT partition and file system, which
look "right" for EFI boot images.
No.
5. The firmware reads this file system and finds only one file, which
it loads and runs (starting GRUB):
/EFI/debian/grubx64.efi
No.
(If there were more than one choice, my guess is that I'd have to
pre-select one in the CMOS setup, or perhaps have to select one from a
menu at the end of POST?)
No.
First, a compliant UEFI firmware should look up its EFI boot variables
and try each boot entry Boot* in the order defined in the BootOrder
variable. The text description associated to theses entries is usually
displayed in the EFI boot menu. If no entry is defined or works, then
the firmware should look for a partition with the "EFI system partition"
type GUID and look for an /EFI/Boot/bootx64.efi file (default path used
on removable devices).
GRUB can be installed in such a path with
grub-install --removable
6. GRUB finds the second GPT partition and file system, which looks
"right" for GRUB, reads the file system, locates the appropriate files
(notably /boot/grub/grub.cfg), and boots the system.
When /boot/grub is in a plain partition on the same drive as GRUB's core
image (grubx64.efi here), the partition number is hardcoded in the core
image.
Again -- are there any other commands I should run that readers might
find interesting?
You can print the EFI boot variables with
efibootmgr -v
