Re: EFISTUB arguments in Dell BIOS

[Jacobo Pantoja <jacobopantoja@gmail.com>]

Sorry for the delay. I accidentally bricked the machine during a BIOS updated.
It is recovered now.

On Mon, 7 Sep 2020 at 19:00, Arvind Sankar <nivedita@alum.mit.edu> wrote:
>
> 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.
Thank you very much

>
> >
> > 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.
>
Yes I'm booting directly from firmware into EFI stub, no
grub2/systemd-boot/refind
involved. My current kernel is 5.8.5.
I'm able to compile kernel with patches, no problem.
As a side note, the exact same kernel with the exact same efibootmgr command
is booting in other machines (different models).

> >
> > 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 is weird; I can see the difference between including initrd arg or not
including, but "cat /proc/cmdline" returns a blank line. Hexdump reveals
that it is really 0x01 0x0a. I'm 100% sure the initramfs is being loaded when
passed as an argument, although the cmdline does not reflect it.

> >
> > 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.
>
Yes, I'm including here my efibootmgr command, and the output after calling
with -v. Line breaks are simply for the email readability.

$ efibootmgr --disk /dev/disk/by-id/ata-(...) --part 1 --create
--label "ArchLinux" \
  --loader /vmlinuz-linux --unicode "root=LABEL=ArchRoot rw quiet \
  initrd=\intel-ucode.img initrd=\initramfs-linux.img intel_iommu=on audit=0"

$ efibootmgr -v
Boot0000* ArchLinux
HD(1,GPT,b0fd4cf1-1566-4c71-b214-c3c0c5924fea,0x800,0xfa000)/File(\vmlinuz-linux)r.o.o.t.=.L.A.B.E.L.=.A.r.c.h.R.o.o.t.
.r.w. .q.u.i.e.t. .i.n.i.t.r.d.=.\.i.n.t.e.l.-.u.c.o.d.e...i.m.g.
.i.n.i.t.r.d.=.\.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g.
.i.n.t.e.l._.i.o.m.m.u.=.o.n. .a.u.d.i.t.=.0.

I've just checked right after a power cycle, with the exact same result:
1) No parameters appended in efibootmgr => black screen
2) Parameters appended in efibootmgr => boots to rescue shell

> > 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