Greetings Bhupesh, > Sent: Friday, August 31, 2018 at 8:47 AM > From: "Bhupesh Sharma" <[email protected]> > To: daggs <[email protected]> > Cc: [email protected] > Subject: Re: question regarding partition detection on efi boot > > On Fri, Aug 31, 2018 at 12:51 AM, daggs <[email protected]> wrote: > > Greetings Bhupesh, > > > >> Sent: Thursday, August 30, 2018 at 6:24 PM > >> From: "Bhupesh Sharma" <[email protected]> > >> To: daggs <[email protected]> > >> Cc: [email protected] > >> Subject: Re: question regarding partition detection on efi boot > >> > >> Hi, > >> > >> On Thu, Aug 30, 2018 at 7:54 PM, daggs <[email protected]> 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 >
I think I have all the answers I need, thanks alot for your help. Dagg.
