On Fri, Aug 31, 2018 at 12:51 AM, daggs <daggs@xxxxxxx> wrote: > Greetings Bhupesh, > >> Sent: Thursday, August 30, 2018 at 6:24 PM >> From: "Bhupesh Sharma" <bhsharma@xxxxxxxxxx> >> To: daggs <daggs@xxxxxxx> >> Cc: linux-efi@xxxxxxxxxxxxxxx >> Subject: Re: question regarding partition detection on efi boot >> >> Hi, >> >> On Thu, Aug 30, 2018 at 7:54 PM, daggs <daggs@xxxxxxx> wrote: >> > Greetings, >> > >> > I apologize if this isn't the right location to ask. as you guys wrote efi support for linux I've thought you might be able to help me fill the gaps on this issue. >> > >> > we have a production server with sles12 sp3 installed on it. >> > the partition table on the machine is this: >> > # fdisk -l /dev/sda >> > Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors >> > Units: sectors of 1 * 512 = 512 bytes >> > Sector size (logical/physical): 512 bytes / 4096 bytes >> > I/O size (minimum/optimal): 4096 bytes / 4096 bytes >> > Disklabel type: dos >> >> See the Disklabel type: dos. If it shows dos, AFAICR it means it is >> MBR schema (and not a GPT schema) >> >> > Disk identifier: 0xf9a6b446 >> > >> > Device Boot Start End Sectors Size Id Type >> > /dev/sda1 * 2048 4192255 4190208 2G 83 Linux >> > /dev/sda2 4192256 468860927 464668672 221.6G 83 Linux >> > >> > mount output is as follows: >> > s2600wf-0:~ # mount | grep boot >> > /dev/sda2 on /boot/grub2/i386-pc type btrfs (rw,relatime,ssd,space_cache,subvolid=260,subvol=/@/boot/grub2/i386-pc) >> > /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0002,dmask=0002,allow_utime=0020,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro) >> > /dev/sda2 on /boot/grub2/x86_64-efi type btrfs (rw,relatime,ssd,space_cache,subvolid=261,subvol=/@/boot/grub2/x86_64-efi) >> >> May be you should try 'gdisk' instead to list the GPT partitions in >> addition to the MBR ones. Following is an output from my Fedora28 EFI >> machine: >> >> $ sudo gdisk -l /dev/sda >> GPT fdisk (gdisk) version 1.0.4 >> >> Partition table scan: >> MBR: protective >> BSD: not present >> APM: not present >> GPT: present >> >> Found valid GPT with protective MBR; using GPT. >> Disk /dev/sda: 1953525168 sectors, 931.5 GiB >> Model: TOSHIBA DT01ACA1 >> Sector size (logical/physical): 512/4096 bytes >> Disk identifier (GUID): E01AB4D7-2DA7-4300-9CE8-FD573801C1DC >> Partition table holds up to 128 entries >> Main partition table begins at sector 2 and ends at sector 33 >> First usable sector is 34, last usable sector is 1953525134 >> Partitions will be aligned on 2048-sector boundaries >> Total free space is 3437 sectors (1.7 MiB) >> >> Number Start (sector) End (sector) Size Code Name >> 1 2048 411647 200.0 MiB EF00 EFI System Partition >> 2 411648 2508799 1024.0 MiB 8300 >> 3 2508800 1953523711 930.3 GiB 8E00 >> >> Looking at the output you can make out the 'EFI System Partition' entry. >> Also if you see something like: >> >> *************************************************************** >> Found invalid GPT and valid MBR; converting MBR to GPT format >> in memory. >> *************************************************************** >> >> then you have a MBR style disk.. >> > the partition table isn't gpt, it is mbr. Since you did not share the details of the underlying hardware (on which you are trying EFI boot) and also whether you have legacy BIOS or newer UEFI available on the same, my comments would assume that we have newer UEFI firmware available on your hardware. Since you have a MBR style layout on the disk, it would mean that you are running the UEFI-MBR boot case, which although supported by UEFI specifications (see Section 5.1 - GPT and MBR disk layout comparison of UEFI specifications 2.7 here <http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf>), is normally a corner case (as compare to UEFI-GPT boot). If you really want, you can also try converting your MBR disk to GPT layout (<http://www.rodsbooks.com/gdisk/mbr2gpt.html>), but that I guess is a separate discussion topic. >> > and here is the content of /sys/firmware/efi/: >> > s2600wf-0:~ # ll /sys/firmware/efi/ >> > total 0 >> > -r--r--r-- 1 root root 4096 Aug 29 03:19 config_table >> > drwxr-xr-x 2 root root 0 Aug 29 03:17 efivars >> > -r--r--r-- 1 root root 4096 Aug 29 03:19 fw_platform_size >> > -r--r--r-- 1 root root 4096 Aug 29 03:19 fw_vendor >> > -r--r--r-- 1 root root 4096 Aug 29 03:19 runtime >> > drwxr-xr-x 11 root root 0 Aug 29 03:19 runtime-map >> > -r-------- 1 root root 4096 Aug 29 03:17 systab >> > drwxr-xr-x 140 root root 0 Aug 29 03:19 vars >> > >> > afaik, if the partition table is mbr, then for efi to boot, the boot partition must be of type EF. in this case it isn't so I was wondering how the system boots in efi? how does the bios detects it? >> > am I missing something? >> >> It depends on the BIOS on your machine. Please see >> <https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#UEFI_booting> >> for details. > Interesting, so according to the link, if <vfat>/EFi/BOOT/boot<arch>.efi exists, the bios will try to boot it as efi (assuming that the bios supports it). > I wonder if this can be found in the spec, will have to take a look. this is true fir gto partition tables too? Normally if the legacy MBR is located at the first logical block of the disk, the UEFI firmware will not execute the boot code on the MBR. If an MBR partition has an OSType field of 0xEF (i.e., UEFI System Partition), then the firmware must add the UEFI System Partition GUID to the handle for the MBR partition. This allows drivers and applications, including OS loaders (like grub/grub2), to easily search for handles that represent UEFI System Partitions and load OS from them. You can have a look at Secton 5.1 of UEFI-2.7 specifications for more details, but in brief the UEFI firmware tries to find a OS loader/bootloader (default:grub2 for most modern day distributions) and the function of grub2 is to boot Kernel - so we have a chain loading flow happening during the boot process on such UEFI systems. Hope this helps. Thanks, Bhupesh
