# [SOLVED] efibootmgr and kernel commandline options

## Holysword

How does one pass commandline options to the kernel, when one uses efibootmgr (without rEfind or the such)?

I basically need to workaround this bug

https://github.com/Bumblebee-Project/bbswitch/issues/140

which people do by setting pcie_port_pm=off.

----------

## Jaglover

The command line can be built into kernel.

----------

## charles17

 *Holysword wrote:*   

> How does one pass commandline options to the kernel, when one uses efibootmgr (without rEfind or the such)?

 

You are aware of gentoo wiki?

----------

## Holysword

 *Jaglover wrote:*   

> The command line can be built into kernel.

 

What I meant was without building it into the kernel (or else I'd have to keep copies of the same kernel with varying commandline).

Is it possible to pass commandline options without hardsetting them?

----------

## charles17

What is the background this topic?

efibotmgr does nothing but make efi applications (such like grub.efi or refind.efi or bzImage.efi) known to the (u)efi firmware.

(u)efi firmware then loads the selected efi (e.g. bzImage.efi or bootmanager) application.

In case the selected efi application is not an EFI stub kernel and not a bootmanager, how then did you intend to load a kernel??????

----------

## Holysword

 *charles17 wrote:*   

> What is the background this topic?
> 
> efibotmgr does nothing but make efi applications (such like grub.efi or refind.efi or bzImage.efi) known to the (u)efi firmware.
> 
> (u)efi firmware then loads the selected efi (e.g. bzImage.efi or bootmanager) application.
> ...

 

The background of this topic is stated at the first post. Workarounding a bug, but without hardsetting options into the kernel.

If it is not possible, an answer such as "Sorry, it is not possible" is much more informative than a rethorical question asking how to achieve the impossible followed by 6 interrogation marks.

Currently I am loading a kernel directly without any efi application. I know that the bios currently does not give me the option to "pass arguments" to the kernel being loaded, what I am wondering is if efibootmgr (or other tools) are able to provide this functionality.

----------

## charles17

 *Holysword wrote:*   

> Currently I am loading a kernel directly without any efi application. 

 

AFAIK that is only possible with EFI stub kernel.  Is this what you are doing, or am I missing something?

 *Holysword wrote:*   

> I know that the bios currently does not give me the option to "pass arguments" to the kernel being loaded, what I am wondering is if efibootmgr (or other tools) are able to provide this functionality.

 

As I understand, efibootmgr is not at all involved in loading / booting.  External resources say to add parameters to the efi firmware.

----------

## dmpogo

If you are using EFI stub kernel without bootloader (as I do as well),   the only way to pass the parameters is to build them into the kernel.

----------

## Holysword

 *charles17 wrote:*   

> AFAIK that is only possible with EFI stub kernel. Is this what you are doing, or am I missing something? 

 

That's correct. I'm booting directly from EFI stub kernel. No bootloader.

 *dmpogo wrote:*   

> If you are using EFI stub kernel without bootloader (as I do as well),   the only way to pass the parameters is to build them into the kernel.

 

Thank you, that's what I wanted to know. Quite inconvenient though.

----------

## dmpogo

 *Holysword wrote:*   

>  *charles17 wrote:*   AFAIK that is only possible with EFI stub kernel. Is this what you are doing, or am I missing something?  
> 
> That's correct. I'm booting directly from EFI stub kernel. No bootloader.
> 
>  *dmpogo wrote:*   If you are using EFI stub kernel without bootloader (as I do as well),   the only way to pass the parameters is to build them into the kernel. 
> ...

 

well, this is a limitation of direct boot,   and (in my opinion, almost the only) reason for additional bootloaders to exist.

Another limitations is that all firmware needed at boot has to be compiled into the kernel as well,  or the path to the root device

On the bright side,  changing kernel parameters in   make menuconfig  does not lead to any recompilation,  so almost as fast as editing bootloader config  :Smile: 

(just not forget to copy the bzImage into its place on /boot/EFI)

----------

## charles17

 *dmpogo wrote:*   

> On the bright side,  changing kernel parameters in   make menuconfig  does not lead to any recompilation,  so almost as fast as editing bootloader config 
> 
> 

 

Are you saying changes done in make menuconfig were going directly into bzImage without recompilation?

----------

## grumblebear

This thread is going to be a little confusing. With efibootmgr you pass the kernel command line parameters with the -u option when creating a new boot entry (-c).

Only when booting the standard UEFI OS, that is the kernel you put under bootx64.efi, you have to compile the parameters into the kernel.

----------

## s4e8

"efibootmgr -u" would add load option/kernel parameters to firmware.

----------

## charles17

 *grumblebear wrote:*   

> Only when booting the standard UEFI OS, that is the kernel you put under bootx64.efi, you have to compile the parameters into the kernel.

 

aka EFI stub kernel

----------

## grumblebear

Yes of course. Since the first entry in this thread we all know, that Holysword is using an EFI stub kernel. And yes, the -u option is storing the command line parameters in the EFI firmware. But from my understanding, this is what Holysword wants. If you want to pass different parameters on every single boot, you have to use the EFI shell.

----------

## Holysword

 *s4e8 wrote:*   

> "efibootmgr -u" would add load option/kernel parameters to firmware.

 

@s4e8 and @grumblebear

I'm sorry, I am indeed a bit confused:

```
   -u | --unicode | --UCS-2

              Handle extra command line arguments as UCS-2 (default is ASCII)
```

That seems to only change the encoding of the arguments, but not to take the arguments themselves. Am I misunderstanding something?

----------

## grumblebear

 *Quote:*   

> I'm sorry, I am indeed a bit confused: 
> 
> ```
> 
>    -u | --unicode | --UCS-2 
> ...

 

Admitted, that description is not very clear. It simply means the command line string does not have to be pure ASCII. So just put your arguments behind the -u.

For example:

```
efibootmgr -c -L MyGentoo -l '\EFI\BOOT\MyKernel.efi' -u "root=/dev/sda2 ro quiet"
```

----------

## Holysword

 *grumblebear wrote:*   

>  *Quote:*   I'm sorry, I am indeed a bit confused: 
> 
> ```
> 
>    -u | --unicode | --UCS-2 
> ...

 

Indeed! Works like a charm, thanks!

----------

