Web lists-archives.com

Re: BIOS Can Not Find Disk




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