linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arvind Sankar <nivedita@alum.mit.edu>
To: Jacobo Pantoja <jacobopantoja@gmail.com>
Cc: ardb@kernel.org, nivedita@alum.mit.edu, linux-efi@vger.kernel.org
Subject: Re: EFISTUB arguments in Dell BIOS
Date: Mon, 7 Sep 2020 13:00:21 -0400	[thread overview]
Message-ID: <20200907170021.GA2284449@rani.riverdale.lan> (raw)
In-Reply-To: <CAO18KQgxfCBFacLxpLZJZ6iDmEA83DUwG2kjfPyJmPZHPQZ5vQ@mail.gmail.com>

On Mon, Sep 07, 2020 at 05:30:39PM +0200, Jacobo Pantoja wrote:
> Hi Arvind and Ard:
> 
> First, I'm sorry to use a direct email communication instead of a mailing
> list, but honestly at this point I cannot guess the correct procedure. If
> this should be managed from a mailing list, please be so kind to indicate
> to me which one would it be. I've seen that you have authored some commits
> regarding EFISTUB, so I guess you can at the very least direct me in the
> right way.

Adding linux-efi to Cc.

> 
> Now the problem, related to EFISTUB and argument passing: I've setup a Dell
> workstation for use with ArchLinux, as the rest of my machines, but I've
> faced a problem when using EFI boot stub: kernel arguments are not passed,
> _apparently_. I've seen in [1], [2], [3] and [4] that it might be a common
> problem to Dell's BIOS implementation, not passing the arguments to the
> kernel at all.

Just to check, are you directly booting from firmware into the EFI stub,
or do you have something (grub2/systemd-boot/refind etc) in between?
Which kernel version are you using, and are you able to compile your own
kernel with patches for testing? If so, we should be able to add in some
debug statements in the EFI stub itself to see what the firmware passed
it as the command line, and if it's getting truncated or something.

> 
> Now the _apparently_ part. I have a simple script to create the bootloader
> entry, and it is properly working in at least 3 different machines.
> * If I simply leave the command line empty (i.e. I pass no arguments, i.e.
> no --unicode "..." section in the efibootmgr command): I can see a blank
> screen.
> * However, if I specify my initramfs via the "initrd=\..." argument (i.e.
> efibootmgr ... -u "initrd=...."), it properly boots up to a rescue console.
> 
> In the rescue console, I can see that /proc/cmdline is empty. As no root
> has been specified, the boot process cannot continue. If I manually mount
> the root fs and exit the console, the boot is completed (with no arguments,
> obviously).

If you boot directly from firmware, the EFI stub is what would load the
initramfs, and at least the initrd= argument should be in /proc/cmdline
after boot.

> 
> That said, I can boot in several different ways, but I'd like to understand
> the problem, and solve it if possible.
> My understanding is that the firmware *is* actually passing somehow the
> arguments (because initramfs is properly mounted), but somehow the
> arguments are being discarded or something. *Is there a way I can properly
> debug this?* I'm a bit lost in the kernel tree, I see a lot of ASM that I
> don't understand so I don't know how to debug.
> 

Does efibootmgr -v show the complete command line (i.e. both initrd and
any rootfs argument), so we're sure the full command line did make it to
NVRAM? Check it after a power cycle so we can cross at least that off
the list.

> Thank you very much in advance,
> JPantoja
> 
> [1]:
> https://www.dell.com/community/Linux-Developer-Systems/Linux-EFISTUB/td-p/4586378
> [2]:
> https://www.dell.com/community/Laptops-General-Read-Only/Dell-UEFI-implementation-does-not-support-Linux-Kernel-EFISTUB/td-p/5185272
> [3]: https://bbs.archlinux.org/viewtopic.php?pid=1753169#p1753169
> [4]: https://github.com/xdever/arch-efiboot

       reply	other threads:[~2020-09-07 17:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAO18KQgxfCBFacLxpLZJZ6iDmEA83DUwG2kjfPyJmPZHPQZ5vQ@mail.gmail.com>
2020-09-07 17:00 ` Arvind Sankar [this message]
2020-09-08 22:12   ` EFISTUB arguments in Dell BIOS Jacobo Pantoja
2020-09-08 22:32     ` Arvind Sankar
2020-09-09 17:34       ` Jacobo Pantoja
2020-09-09 19:00         ` Arvind Sankar
2020-09-09 19:37           ` Jacobo Pantoja
2020-09-09 20:38             ` Arvind Sankar
2020-09-10 10:11               ` Ard Biesheuvel
2020-09-10 20:40                 ` Limonciello, Mario
2020-09-11  0:04                   ` Arvind Sankar
2020-09-11  5:53                     ` Jacobo Pantoja
2020-09-11 15:28                       ` Limonciello, Mario
2020-09-12 17:51                         ` [RFC PATCH 0/2] Quirk to handle " Arvind Sankar
2020-09-12 17:51                           ` [RFC PATCH 1/2] efi/x86: Add a quirk to support command line arguments on Dell EFI firmware Arvind Sankar
2020-09-14 16:56                             ` Limonciello, Mario
2020-09-14 18:30                               ` Ard Biesheuvel
2020-09-14 18:45                                 ` Limonciello, Mario
2020-09-12 17:51                           ` [RFC PATCH 2/2] efi/libstub: Dump command line before/after conversion Arvind Sankar
2020-09-14 15:59                           ` [RFC PATCH 0/2] Quirk to handle Dell BIOS Jacobo Pantoja

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200907170021.GA2284449@rani.riverdale.lan \
    --to=nivedita@alum.mit.edu \
    --cc=ardb@kernel.org \
    --cc=jacobopantoja@gmail.com \
    --cc=linux-efi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).