| View previous topic :: View next topic |
| Author |
Message |
Einstok_Fair
n00b
Joined: 12 Aug 2020
Posts: 40
|
 Posted: Fri May 28, 2021 5:19 am Post subject: Questions about the Linux boot process |
 |
|
Is GPT structure necessary, or MBR (EF) partition works?
I have a motherboard with UEFI firmware (something tianocore-based).
Do I need to split the HDD with sfdisk, or I can just create 2 primary partitions with fdisk?
Where this is defined in UEFI specification?
https://unix.stackexchange.com/questions/340764/should-i-use-fdisk-for-partitioning-or-gpt-aware-tools
I didn't understood, is it possible to create GPT with modern fdisk, and how to do that.
sfdisk
fdisk
gdisk
Unified Extensible Firmware Interface (UEFI) Specification, Version 2.8, March 2019
5.2.1 Legacy Master Boot Record (MBR)
| Quote: | 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 using
InstallProtocolInterface(). This allows drivers and applications, including OS loaders, to easily
search for handles that represent UEFI System Partitions.
The following test must be performed to determine if a legacy MBR is valid:
• The Signature must be 0xaa55.
• A Partition Record that contains an OSType value of zero or a SizeInLBA value of zero may
be ignored.
Otherwise:
• The partition defined by each MBR Partition Record must physically reside on the disk (i.e., not
exceed the capacity of the disk).
• Each partition must not overlap with other partitions.
|
5.2.2 OS Types
| Quote: |
Unique types defined by this specification (other values are not defined by this specification):
• 0xEF (i.e., UEFI System Partition) defines a UEFI system partition.
|
Here I don't understand, what is "UEFI System Partition GUID" and where it is added, and what are the consequences.
Should firmware be able to use such legacy MBR or still may ignore it by some reason?
Which command line interface commands should one use, to check that drive in legacy MBR format conforms to reqiurements to be booted by firmware?
Last edited by Einstok_Fair on Sat May 29, 2021 12:02 am; edited 1 time in total |
|
| Back to top |
|
 |
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9824
Location: almost Mile High in the USA
|
| Posted: Fri May 28, 2021 5:56 am Post subject: |
|
|
I don't think you need to worry about it unless you're writing firmware for a motherboard manufacturer.
UEFI can handle MBR partition tables just fine though it was designed for MBR's successor, GPT. In any case it can boot off of ESPs that are MBR partitioned disks just fine as long as they're marked as ESP partitions.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
Einstok_Fair
n00b
Joined: 12 Aug 2020
Posts: 40
|
| Posted: Fri May 28, 2021 6:43 am Post subject: |
|
|
I have 2 goals which I want to achieve:
1) I want to load firmware into QEMU and successfully boot an HDD image prepared by me
2) I want to use the prepared image to perform boot on the actual hardware
Right now I successfully run Debain-based distribution from motherboard manufacturer, but I want to replace it with mine gentoo-based system.
And image prepared by me doesn't boot.
The manufacturer provides an SDK, which contains a build script for compiling firmware.
I also don't know how to write that compiled firmware (newer version from the site) into the existing motherboard. Motherboard users guide doesn't describe that.
I want to use a legacy MBR to create 2 different GRUB loaders for different architectures (arm64 and amd64) on the same partition to be able to use that single image as resque disk (and my old motherboards have BIOS-based firmware). |
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2179
|
| Posted: Fri May 28, 2021 9:48 am Post subject: Re: Is GPT structure necessary, or MBR (EF) partition works? |
|
|
| Einstok_Fair wrote: | ...
I didn't understood, is it possible to create GPT with modern fdisk, and how to do that.
... |
You can manage GPT disks with many tools. "gdisk" is the GPT equivalent of "fdisk"; there's also "cgdisk", which is the curses-version, equivalent to "cfdisk". Lots more.
Rather than read the EFI standard (7,000 pages, as I recall, and pretty tedious), it might be easier to start with the relevant Gentoo wiki article.
_________________
Greybeard |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9824
Location: almost Mile High in the USA
|
| Posted: Fri May 28, 2021 3:09 pm Post subject: |
|
|
If you really want to be confused, the excerpt you wrote is because MBR partitions do not have GUIDs. The firmware spec wants all partitions to have GUIDs so it tells you to write firmware to fake this fact so that to make everything consistent. This is kept track internally in the firmware as you can't write it to the MBR partition where it would make sense to anyone using it.
If you just want to work with disk images, this translation been done for you in Tianocore and InsydeH2O EFI firmwares, etc. The only thing that you do need to worry about is that the MBR partition type ID needs to be marked with 0xEF and formatted FAT, of which the firmware will pick up and notice it should try to locate boot images off it.
Of course secure boot is a different story and can't help you there, this is a whole different problem.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
Einstok_Fair
n00b
Joined: 12 Aug 2020
Posts: 40
|
| Posted: Fri May 28, 2021 5:12 pm Post subject: |
|
|
| eccerr0r wrote: | | The only thing that you do need to worry about is that the MBR partition type ID |
I also need to know the path, where the binary file should reside. Because for example Debian and Gentoo installs them on different paths.
Man and info pages on grub-install don't say anything definite about what it does. The GRUB Manual too - https://www.gnu.org/software/grub/manual/grub/grub.html#Invoking-grub_002dinstall
13.3.1.3 Directory Structure
| Quote: | | there must be only one UEFI-compliant system partition, and that partition must contain an UEFI-defined directory in the root directory. The directory will be named EFI. All OS loaders and applications will be stored in a subdirectory below EFI called BOOT. There must only be one executable EFI image for each supported processor architecture in the BOOT directory. |
|
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9824
Location: almost Mile High in the USA
|
| Posted: Fri May 28, 2021 5:26 pm Post subject: |
|
|
It doesn't say because it's possible to change it... efibootmgr and EFI itself can change image.
There is a default name if the firmware isn't changed, I think it's something like boot<arch>.efi where <arch> is a 4-letter or less architecture name, but I forgot...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5108
Location: Bavaria
|
| Posted: Fri May 28, 2021 6:02 pm Post subject: |
|
|
| Einstok_Fair wrote: | | I also need to know the path, where the binary file should reside. |
With UEFi you can boot as much as different systems as you want (Windows, a Linux Stub-Kernel, a Bootmgr like grub2). For this you need this Wiki article:
https://wiki.gentoo.org/wiki/Efibootmgr
For a Stub-Kernel:
https://wiki.gentoo.org/wiki/EFI_Stub
If you want a Bootmgr to select your linux kernel - like grub2 - you have to tell it in which locations your kernel are.
Here is an example of my system:
| Code: | # efibootmgr -v
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0002,0000
Boot0000* gentoo HD(2,GPT,e6cccc9a-40e0-4b59-b6d2-082596500077,0x1800,0x1fe800)/File(\EFI\gentoo\grubx64.efi)
Boot0001* SECLINUX HD(2,GPT,e6cccc9a-40e0-4b59-b6d2-082596500077,0x1800,0x1fe800)/File(\EFI\Boot\bzImage.efi)
Boot0002* UNLOCKED HD(2,GPT,e6cccc9a-40e0-4b59-b6d2-082596500077,0x1800,0x1fe800)/File(\EFI\unlocked\bzImage.efi) |
The first entry is a grub2 from my initial installation; the other two are signed Linux Stub-Kernels (I do SecureBoot). |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5108
Location: Bavaria
|
| Posted: Fri May 28, 2021 6:08 pm Post subject: |
|
|
| eccerr0r wrote: | | There is a default name if the firmware isn't changed, I think it's something like boot<arch>.efi where <arch> is a 4-letter or less architecture name, but I forgot... |
What you mean is a bootable binary which will be ALWAYS found by UEFi - even without an explicit entry in the UEFI table - this is:
/EFI/BOOT/bootx64.efi
If a binary is named like this you dont need an extra entry in UEFI; so it is possible to put a binary with this name onto an USB stick and you can boot it (of course the partition of the stick must be FAT32 an must have an ESP-flag; this you must have always). |
|
| Back to top |
|
|
Einstok_Fair
n00b
Joined: 12 Aug 2020
Posts: 40
|
| Posted: Fri May 28, 2021 11:10 pm Post subject: |
|
|
| pietinger wrote: | | What you mean is a bootable binary which will be ALWAYS found by UEFi - even without an explicit entry in the UEFI table |
Yes, after your advise I found this place in UEFI specification:
3.5.1.1 Removable Media Boot Behavior
| Quote: |
Table 15. UEFI Image Types
File Name Convention PE Executable Machine Type *
...
x64 BOOTx64.EFI 0x8664
...
AArch64 architecture BOOTAA64.EFI 0xAA64
The PE Executable machine type is contained in the machine field of the COFF file header as defined in the
Microsoft Portable Executable and Common Object File Format Specification, Revision 6.0
|
I wonder, why you all use low case register of letters, if specification always use capital case of letters. Probably that's because FAT32 is case-independent? Or it always store names in the upper register?
They recomend to read
"Microsoft Extensible Firmware Initiative FAT32 File System Specification, Version 1.03”
heading at “Links to UEFI-Related Documents” (http://uefi.org/uefi).
and the link
http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx
doesn't work for me.
«An error (502 Bad Gateway) has occurred in response to this request. »
I googled by name, and got .doc-file (with EULA) on another location at Microsoft's site.
Name Matching In Short & Long Names
| Quote: |
although the case of a name is preserved in a long name, no two names can have the same name although the names on the media actually differ by case.
...
All types of search operations within the file system (i.e. find, open, create, delete, rename) are case-insensitive.
...
The same rules are also true for extended characters that are accented.
...
When a character on the media, whether it is stored in the OEM character set or in UNICODE, cannot be translated into the appropriate character in the OEM or ANSI code page, it is always "translated" to the "_" (underscore) character as it is returned to the user – it is NOT modified on the disk. This character is the same in all OEM code pages and ANSI.
|
So, the filename can be
/EFI/BOOT/BOOTAA64.EFI
(and another second file /EFI/BOOT/BOOTx64.EFI with lowercase "x" for my old machines).
The next thing i want to know is the location of grub.cfg and modules.
https://i.ibb.co/jWZWKz7/probe1.jpg
Why they are necessary at all, if I can build my own core with all modules and config built into it, and how that all works in the case of PXE-boot (to have single binary image of grub core for all use-cases). Do I need to have 2 sets of modules, compiled for different architectures? If I need 2 different kernes for 2 architectures, each one loaded by default, then I should have 2 different grub.cfg files instead of one common? What are the differences in paths between them?
i.e. if modules are prefixed like this (where that is documented?):
/boot/grub/arm64-efi/normal.mod
/boot/grub/i386-pc/normal.mod
then why grub.cfg is not?
Does some variable exist which contain the architecture string?
https://unix.stackexchange.com/questions/252189/how-does-grub2-find-its-configuration-file-in-efi-boot
https://unix.stackexchange.com/questions/265861/how-can-i-manually-define-the-grub-prefix-variable
https://www.gnu.org/software/grub/manual/grub/grub.html#Environment
grub_cpu
- i386 or x86_64 (i386=Legacy mode or 32-bit UEFI, x86_64=UEFI64) (why not x86,x64,x32 ?)
- https://github.com/schierlm/usb-modboot/issues/3
grub_platform (why not "firmware"?)
- "efi"
- "pc" (why not "bios"?)
grub-install --target=i386-pc /dev/sdX
| Quote: | --target=<TARGET>
install GRUB for TARGET platform [default=i386-pc]; available targets: arm-coreboot, arm-efi, arm-uboot, arm64-efi, i386-coreboot, i386-efi, i386-ieee1275, i386-multiboot, i386-pc, i386-qemu, i386-xen, i386-xen_pvh, ia64-efi, mips-arc, mips-qemu_mips, mipsel-arc, mipsel-loongson, mipsel-qemu_mips, powerpc-ieee1275, riscv32-efi, riscv64-efi, sparc64-ieee1275, x86_64-efi, x86_64-xen |
grub-install --efi-directory=/mnt/sdX1 --removable --boot-directory=/mnt/sdX1/boot --target=arm64-efi
| Quote: | --removable
the installation device is removable. This option is only available on EFI. |
Do I need a non-FAT partition for GRUB to save the user's current choice? How that works with PXE? |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1699
Location: South America
|
| Posted: Sat May 29, 2021 4:12 pm Post subject: |
|
|
| Einstok_Fair wrote: | | I want to use a legacy MBR to create 2 different GRUB loaders for different architectures (arm64 and amd64) on the same partition to be able to use that single image as resque disk (and my old motherboards have BIOS-based firmware). |
This confuses me. Two different architectures ==> two different machine instruction sets ==> you need two sets of everything. And then, you also throw BIOS boot in the mix. You want BIOS boot for the Intel / AMD architecture, and UEFI boot for the ARM architecture?
| Einstok_Fair wrote: | | The next thing i want to know is the location of grub.cfg and modules. |
Modules are installed to /$bootdir/grub/$cpu-$platform in the system you used to run grub-install. $bootdir is the value specified with --boot-directory, or boot if you didn't specify that option. Also, other details vary between BIOS (i386-pc) and UEFI (x86_64-efi / arm64-efi). In the first case, GRUB installs intself to the MBR and the space between the MBR and the first partition (in the MS-DOS partition table case), and in the second case, it installs itself to the EFI system partition (ESP) as an EFI executable. \EFI\gentoo\grub<arch>.efi or \EFI\BOOT\BOOT<arch>.efi with grub-install --removable.
With an MS-DOS partition table, the ESP is marked with the EF (hexadecimal) OSType (both fdisk and parted can do this). And the UEFI ímplementation must support booting from a disk with an MS-DOS partition table.
| Einstok_Fair wrote: | | Why they are necessary at all, if I can build my own core with all modules and config built into it |
You can't, GRUB is modular.
| Einstok_Fair wrote: | | Do I need to have 2 sets of modules, compiled for different architectures? |
Yes.
| Einstok_Fair wrote: | | If I need 2 different kernes for 2 architectures, each one loaded by default, then I should have 2 different grub.cfg files instead of one common? |
Maybe. Because of the "loaded by default" part. Or maybe you can get away with one using GRUB's scripting language (that means no grub-mkconfig).
| Einstok_Fair wrote: | | What are the differences in paths between them? |
The configuration file is always /$bootdir/grub/grub.cfg in the system you used to run grub-install. $bootdir is the value specified with --boot-directory, or boot if you didn't specify that option.
| Einstok_Fair wrote: | i.e. if modules are prefixed like this (where that is documented?):
/boot/grub/arm64-efi/normal.mod
/boot/grub/i386-pc/normal.mod
then why grub.cfg is not? |
Probably because grub.cfg is a text file and there is nothing architecture- or platform-dependent about it. Unlike GRUB modules, which contain machine code and are platform-dependent.
| Einstok_Fair wrote: | grub_cpu
- i386 or x86_64 (i386=Legacy mode or 32-bit UEFI, x86_64=UEFI64) (why not x86,x64,x32 ?) |
Because GRUB developers chose to code it that way, and no, i386 = Intel / AMD 32-bit CPU, x86_64 = Intel / AMD 64-bit CPU. And will be arm64 when you boot on ARM.
| Einstok_Fair wrote: | grub_platform (why not "firmware"?)
- "efi"
- "pc" (why not "bios"?) |
Because GRUB developers chose to code it that way.
| Einstok_Fair wrote: | | grub-install --efi-directory=/mnt/sdX1 --removable --boot-directory=/mnt/sdX1/boot --target=arm64-efi |
Probably grub-install --target=arm64-efi --removable --efi-directory=<pathname of the mounted ESP> while running in the ARM machine.
I don't know about PXE, and you haven't mentioned what is its relationship with what you want to do. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo on ARM
