UEFI BIOS + Linux

Vrai

Well-Known Member
Joined
Mar 16, 2019
Messages
1,085
Reaction score
1,050
Credits
4,227
This question is related to another post here on Linux.org.

I'm not very knowledgeable about UEFI as I have only just recently started using it.

My question is: does the Linux kernel interact with the UEFI? I mean other than the BIOS POST handing off the boot process to the kernel or operating system after completing it's function?

It seemed to me that with legacy BIOS the only way to interact with it was through the BIOS settings. I was not aware of any way to change BIOS settings through the operating system. Is the same true for UEFI? Or can the operating system or kernel change the UEFI BIOS?

Just wondering.
 


im still digesting uefi and grub on the basis Mr V will probably introduce grub in the next century, so i want to be ready . One way to understand uefi is to see what it is and what its not. BIOS basic input..blah blah is code embedded on a chip in the motherboard. Hopefully we can agree on that. Then on your PC you hit esc and access a window to chnage things and we also call that "bios" . My PC is uefi so there is uefi hard embedded on my motherboard. I then hit escape or similar and see a windows with settings. What do i call that ? do i say its a Window to uefi , its a hybrid something ..or something else ? @givsoc did quite an extensive post if you can find it. Roderick at https://www.rodsbooks.com has some stuff all about uefi
 
In short, the OS interacts with UEFI in the same way it interacts with BIOS. It's how the OS converses with hardware.
 
UEFI is in fact code embedded on your motherboard thus "fireware"

it starts getting more complicated when you throw in say grub2. I previously installed legacy grub on slackware 14.2 ,it was a piece of cake. I get worried when i see a post within slackware forums about installing grub2 with efi and it consists of about 8 pages and they still haven't figured it out ? Obviously they don't follow the philosophy of gino d'acampo like me ..

What i so far understand with my slackware using elio and uefi firmware is that my PC has a hard drive with gpt partition , it uses uefi firmware and that I can use uefi firmware and have an option to turn the secure boot element off and it still uses uefi firmware ; i have a 100MB(partition) file of type EF00 that holds (not sure)

if i look into
/boot/efi/EFI/Slackware/
i have :
Slackware
├── elilo.conf
├── elilo.efi
├── initrd.gz
├── initrd_old.gz
└── vmlinuz

I found a new toy rEFInd and that I could boot my slackware PC and my wifes Windows 10 both uefi firmware.


in the above tree i think rEFIind was using that elilo.efi , the vmlinuz is my kernel and the initrd.gz the minimum inital boot ram stuff.what i have and can see seems to make sense, but when it goes to grub2 ? well i know .cfg files will go to boot/grub . i've seen things like :

sudo grub-install /dev/sda

and i'm thinking oh not another another parameter. My root partition is /dev/sda3

what the difference betwteen :

sudo grub-install /dev/sda

and

sudo grub-install /dev/sda3


what gets put on the EFI partition when using grub2 ?
 
Last edited:
what gets put on the EFI partition when using grub2 ?
Here's what I get using grub2 in Centos:
Code:
/boot/efi/
└── EFI
    ├── BOOT
    │   ├── BOOTX64.EFI
    │   └── fbx64.efi
    └── centos
        ├── BOOTX64.CSV
        ├── fonts
        ├── grub.cfg
        ├── grubenv
        ├── grubx64.efi
        ├── mmx64.efi
        ├── shimx64-centos.efi
        └── shimx64.efi
Here's what I get when using grub2 in Arch:
Code:
/efi/
└── EFI
    └── grubarch
        └── grubx64.efi

You have to tell grub which directory is your efi partition. So like this:
Code:
grub-install --target=x86_64-efi --efi-directory=esp --bootloader-id=GRUB
 
Last edited:
well cheers @f33dm3bits always interesting to see what other people have and i 've never used centros before probably never will ; arch or freeBSD would be the choice is something happens to Mr Volkerding before his time ;^{ but the tree your showing ,which makes sense is a directory structure located at your root install of the OS .

so the only question left is ... what actually is put onto in my case the 100MB efi partition of file type EF00 located /dev/sda1 ?

the code

Code:
grub-install --target=x86_64-efi --efi-directory=esp --bootloader-id=GRUB

yes its specifying thats a 64bit PC with efi that there is an esp
but i note it doesn't actually specifiy the partition . i'm a control freak so i like to see code that actually says something like <do something> </dev/sda1> or allows manual specification if you see what i mean . Also what actually goes onto the EFI partition .

I used this : sfdisk -d /dev/sda > /home/andrew/Desktop/partitionTable.txt

then i could actually have a look at my partition table. Anybody can a means of doing something similar for the EFI partition then i guess i could take out my magnifying glass and examine the contents of my EFI partition myself
 

Attachments

  • partition.png
    partition.png
    66.8 KB · Views: 500
@captain-sensible

Centos:
Code:
UUID=78D4-3ED4          /boot/efi               vfat    umask=0077,shortname=winnt 0 2
/dev/nvme0n1p1: SEC_TYPE="msdos" UUID="78D4-3ED4" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="16b29127-3c01-42cf-8d66-047e34610516"

Arch:
Code:
UUID=21C7-72CF          /efi          vfat          rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro    0 2
/dev/nvme0n1p1: UUID="21C7-72CF" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="2e3b5e82-6716-474f-9342-c7b8d7efa115"

Under Centos the installer creates a separate partition and then mounts it under /boot/efi and then creates the efi files with grub-install. When installing Arch this is al done manually, but basically you create a partition, mount it under /boot or /boot/efi or wherever your distro allows for you to have an efi partition. Then you run grub-install:
Code:
grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB
If you run grub with the verbose option it will show you what it is actually doing:
Code:
grub-install -v --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB
And then you use grub-mkconfig to generate the rest of your grub configuration:
Code:
grub-mkconfig -o /boot/grub/grub.cfg
Does that makes more sense now?

I use Centos on my vpses and my homeserver system because I don't need bleeding edge for those systems, and I don't want to spend a lot of time maintaining them once they are running. On my laptop I run Arch because for a workstation it is useful to have bleeding edge software, and it also has an advantage to gaming under GNU/Linux to have the most bleeding edge software running. Ever since I have switched over to Arch my gaming experience has gotten so much better.
 
Last edited:
just got in from a BBQ , some lemonade was had so will digets it tomorrow ,but yes

Code:
grub-mkconfig -o /boot/grub/grub.cfg
thats what i ran last time with legacy; also i think basically grub-update is a wrapper for variation on that grub-mkconfig command. on my slackware i manually created the 100mb EFI using cgdisk i think
 
just got in from a BBQ , some lemonade was had so will digets it tomorrow ,but yes

Code:
grub-mkconfig -o /boot/grub/grub.cfg
thats what i ran last time with legacy; also i think basically grub-update is a wrapper for variation on that grub-mkconfig command. on my slackware i manually created the 100mb EFI using cgdisk i think
BBQ's are always fun! Good food and fun people. :cool:

grub-mkconfig is not wrapper script for grub-update, it's just a bash script but grub-update is not mentioned in it.
 
Last edited:
This question is related to another post here on Linux.org.

I'm not very knowledgeable about UEFI as I have only just recently started using it.

My question is: does the Linux kernel interact with the UEFI? I mean other than the BIOS POST handing off the boot process to the kernel or operating system after completing it's function?

It seemed to me that with legacy BIOS the only way to interact with it was through the BIOS settings. I was not aware of any way to change BIOS settings through the operating system. Is the same true for UEFI? Or can the operating system or kernel change the UEFI BIOS?

Just wondering.
To answer your question yes(source):
"A boot loader is a piece of software started by the firmware (BIOS or UEFI). It is responsible for loading the kernel with the wanted kernel parameters, and initial RAM disk based on configuration files. In the case of UEFI, the kernel itself can be directly launched by the UEFI using the EFI boot stub. A separate boot loader or boot manager can still be used for the purpose of editing kernel parameters before booting."
 
you know i'm always surprised the stuff that comes default with slackware:

bash-5.0# efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0004,0001,9999
Boot0000* Slackware HD(1,GPT,192a9aa1-9848-4329-8171-9253ffc0f920,0x800,0x32000)/File(\EFI\Slackware\elilo.efi)
Boot0001* Windows Boot Manager HD(1,GPT,14e3012e-310b-42fd-961b-19272d6995fb,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WIND

mm thats strange my PC came with Windows 10, i wiped by mistake in haste the original EFI partition and created it manually using cgdisk but still have remnants of .. some might say contamination of Windows
 
BBQ's are always fun! Good food and fun people. :cool:

grub-mkconfig is not wrapper script for grub-update, it's just a bash script but grub-update is not mentioned in it.
i was with my wife visiting one of her friends a Ghanaian ; so i was de-coding TWI (their language) and then back here to de-code...mmm
 
To answer your question yes(source):
"A boot loader is a piece of software started by the firmware (BIOS or UEFI). It is responsible for loading the kernel with the wanted kernel parameters, and initial RAM disk based on configuration files. In the case of UEFI, the kernel itself can be directly launched by the UEFI using the EFI boot stub. A separate boot loader or boot manager can still be used for the purpose of editing kernel parameters before booting."
I'm not sure which question is answered! :/
That's my fault for not asking the question more clearly and succinctly.
I was kinda formulating my thoughts as I typed, trying to figure out just what I was trying to ask.

I think what I am trying to figure out is:
Can the kernel or operating system write to the UEFI firmware?

I've been doing some reading and research into the matter and have found a couple good sources so far (just getting started).

and

Thanks for your input! :)
 
Not immediately (trying to) answering any other points, - just to clarify #8 by Andy and #9 by @f33dm3bits :

1. It's update-grub, not grub-update
2. Update-grub is a stub for the grub-mkconfig command, not the other way around, "wrapper" is close, but technical is stub.

update-grub can be used in Debian-based Distros from Debian itself through to Ubuntu, Mint and the like.

It can also be used in Manjaro only, of the Arch-based Distros.

I am unaware of it being used anywhere else, but my experience only goes up to about 140 to 150 Distros of over 400 plus. So I never say never.

In Debian-based Distros, the full command for updating grub is

(sudo or as root) grub-mkconfig -o /boot/grub/grub.cfg

Likewise with all Arch-based that I am familiar with, not just Manjaro.

In openSUSE, it is

grub2-mkconfig -o /boot/grub2/grub.cfg

Fedora (and perhaps others) can differ between UEFI and non-UEFI versions. It also diverges from its RPM-based cousin, openSUSE, in this regard:

Fedora uses

grub2-mkconfig -o /boot/grub2/grub.cfg

ONLY for BIOS-based systems (I'll bet you were wondering how I would work this back to BIOS-UEFI?)

For UEFI systems, the command is

grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

... so a different hierarchical structure

So when helping others update their grubs, we might all need a cheat sheet :)

More when I get a chance.

Nice Thread, @Vrai

Cheers

Wiz
 
just got in from a BBQ , some lemonade was had so will digets it tomorrow ,but yes

Code:
grub-mkconfig -o /boot/grub/grub.cfg
thats what i ran last time with legacy; also i think basically grub-update is a wrapper for variation on that grub-mkconfig command. on my slackware i manually created the 100mb EFI using cgdisk i think
Grub mkconfig writes to the hard drive does it not?
And there is a small bit of Grub (it's been a while so I am forgetting the exact nomenclature) which is written to the MBR (or wherever with UEFI) which is read by the BIOS or UEFI?
And isn't there an "EFI" 'partition' (?) with a file it it which is read by the UEFI and contains useful information for the UEFI firmware? A file which I think is written by the UEFI firmware.

So far I haven't seen anything which indicates that the Linux kernel or any operating system actually writes to the UEFI firmware or to the EFI file (partition). Grub seems to be writing to the hard drive and dropping stuff for the UEFI or BIOS to find and continue the boot process.

I forsee some reading in my future! ;)
 
And there is a small bit of Grub (it's been a while so I am forgetting the exact nomenclature) which is written to the MBR (or wherever with UEFI) which is read by the BIOS or UEFI?

It would seem so. That is called Protective MBR, and it is a Legacy of MBR maintained under UEFI

IX0LgkU.gif

OK, I could have helped that.

Seriously, though, I do not know a fraction of what there is to know here, I only learn a fair bit by my experience with many, many Linux, and working between BIOS-MBR and UEFI-GPT environments in my home.

Reading sounds good.

Works for me.

Cheers

Wiz
 
Not immediately (trying to) answering any other points, - just to clarify #8 by Andy and #9 by @f33dm3bits :

1. It's update-grub, not grub-update
2. Update-grub is a stub for the grub-mkconfig command, not the other way around, "wrapper" is close, but technical is stub.

update-grub can be used in Debian-based Distros from Debian itself through to Ubuntu, Mint and the like.

It can also be used in Manjaro only, of the Arch-based Distros.

I am unaware of it being used anywhere else, but my experience only goes up to about 140 to 150 Distros of over 400 plus. So I never say never.

In Debian-based Distros, the full command for updating grub is

(sudo or as root) grub-mkconfig -o /boot/grub/grub.cfg

Likewise with all Arch-based that I am familiar with, not just Manjaro.

In openSUSE, it is

grub2-mkconfig -o /boot/grub2/grub.cfg

Fedora (and perhaps others) can differ between UEFI and non-UEFI versions. It also diverges from its RPM-based cousin, openSUSE, in this regard:

Fedora uses

grub2-mkconfig -o /boot/grub2/grub.cfg

ONLY for BIOS-based systems (I'll bet you were wondering how I would work this back to BIOS-UEFI?)

For UEFI systems, the command is

grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

... so a different hierarchical structure

So when helping others update their grubs, we might all need a cheat sheet :)

More when I get a chance.

Nice Thread, @Vrai

Cheers

Wiz
Since English isn't my first language I had to google what the word stub meant, now it makes sense because it means short for. But yes grub-update is a stub for grub-mkconfig, when I checked it myself on one of my Ubuntu based virtual machines. Actually never knew that since the few times I have needed to update my grub I have always used grub-mkconfig.

After I read this @wizardfromoz I just had to try it out myself. Under rpm based distros you are correct:
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg. I even saw this on my Centos Installation, however on Arch it is different. I tried it with the same setup and resulted in an unbootable system. When using grub-install on Arch it also creates /boot/grub/x86_64-efi, so with the different ways of distros doing it can be confusing. And we are quite spoiled because usually grub gets updated automatically when installing a new kernel.
 
Last edited:
On the first language, I know that, but the others don't, lol - it's deceptive because your English is so good.

Maybe I should have said

1. Don't try it without the

-o

in the command unless you are prepared, and

2. Do keep your Timeshift snapshots up-to-date, when you monkey with grub commands :p

I for one love by being both spoiled, challenged, and entertained all at the same time, by Linux. It is so refreshing a change from the alternatives.

Later folks, stay safe

Wizard
 


Top