Kernel panic when booting with EFISTUB

julienfalque · 2017-11-25 22:23:58

Hi.

I'm trying to boot Arch Linux on my Dell XPS 15 (9550) using EFISTUB directly but I get a kernel panic:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Here is the command I use to create the boot entry:

efibootmgr -c -d /dev/nvme0n1 -p 1 -L "Arch Linux" -l "\EFI\arch\vmlinuz-linux" -u "root=UUID=74a6604d-ca6e-43f6-88d0-58075addbd9a rw initrd=\EFI\arch\initramfs-linux.img resume=UUID=74a6604d-ca6e-43f6-88d0-58075addbd9a resume_offset=323584 fbcon=scrollback:1024k"

and the created boot entry:

Boot0001* Arch Linux	HD(1,GPT,e3d6ce83-d6a1-4d33-bf06-3196fc01290d,0x800,0xfa000)/File(\EFI\arch\vmlinuz-linux)r.o.o.t.=.U.U.I.D.=.7.4.a.6.6.0.4.d.-.c.a.6.e.-.4.3.f.6.-.8.8.d.0.-.5.8.0.7.5.a.d.d.b.d.9.a. .r.w. .i.n.i.t.r.d.=.\.E.F.I.\.a.r.c.h.\.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g. .r.e.s.u.m.e.=.U.U.I.D.=.7.4.a.6.6.0.4.d.-.c.a.6.e.-.4.3.f.6.-.8.8.d.0.-.5.8.0.7.5.a.d.d.b.d.9.a. .r.e.s.u.m.e._.o.f.f.s.e.t.=.3.2.3.5.8.4. .f.b.c.o.n.=.s.c.r.o.l.l.b.a.c.k.:.1.0.2.4.k.

I have another boot entry that uses rEFInd:

menuentry "Arch Linux" {
    icon   /EFI/refind/icons/os_arch.png
    loader /EFI/arch/vmlinuz-linux
    initrd /EFI/arch/initramfs-linux.img
    options "root=UUID=74a6604d-ca6e-43f6-88d0-58075addbd9a rw resume=UUID=74a6604d-ca6e-43f6-88d0-58075addbd9a resume_offset=323584 fbcon=scrollback:1024k"
}

When I use this boot entry, Arch boots just fine. Any idea why using EFISTUB directly fails?

Head_on_a_Stick · 2017-11-26 12:50:13

OK, I'll bite...

julienfalque wrote:

efibootmgr -c -d /dev/nvme0n1 -p 1 -L "Arch Linux" -l "\EFI\arch\vmlinuz-linux" -u "root=UUID=74a6604d-ca6e-43f6-88d0-58075addbd9a rw initrd=\EFI\arch\initramfs-linux.img resume=UUID=74a6604d-ca6e-43f6-88d0-58075addbd9a resume_offset=323584 fbcon=scrollback:1024k"

Why is your kernel in such a strange place?

Does EFI_STUB booting work if you have /boot mounted to the EFI system partition and the kernel image and initramfs in the normal location?

The fact that rEFInd works but EFI_STUB does not would suggest that the kernel & initramfs are not on the ESP itself.

cfr · 2017-11-27 03:57:25

Try removing the resume stuff for now, to see if you can get the simpler case working first.

julienfalque · 2017-11-28 07:17:51

Head_on_a_Stick wrote:

Why is your kernel in such a strange place?
Does EFI_STUB booting work if you have /boot mounted to the EFI system partition and the kernel image and initramfs in the normal location?

When I installed the system, I did as suggested on the EFI System Partition page of the Wiki (link found in the Installation Guide).

Not sure what you mean by "normal location". The files are on the ESP partition (mounted to /part/esp):

 $ ll /part/esp/EFI/arch/
total 40436
drwxr-xr-x 2 root root     4096 20 nov.  19:21 .
drwxr-xr-x 7 root root     4096 24 nov.  22:58 ..
-rwxr-xr-x 1 root root 25841343 15 nov.  19:14 initramfs-linux-fallback.img
-rwxr-xr-x 1 root root  8461442 15 nov.  19:14 initramfs-linux.img
-rwxr-xr-x 1 root root  1586688 18 nov.  20:44 intel-ucode.img
-rwxr-xr-x 1 root root  5502736  8 nov.  11:55 vmlinuz-linux

This directory is also bind mounted to /boot:

 $ ll /boot
total 40436
drwxr-xr-x  2 root root     4096 20 nov.  19:21 .
drwxr-xr-x 18 root root     4096  1 avril  2017 ..
-rwxr-xr-x  1 root root 25841343 15 nov.  19:14 initramfs-linux-fallback.img
-rwxr-xr-x  1 root root  8461442 15 nov.  19:14 initramfs-linux.img
-rwxr-xr-x  1 root root  1586688 18 nov.  20:44 intel-ucode.img
-rwxr-xr-x  1 root root  5502736  8 nov.  11:55 vmlinuz-linux

Is there something wrong with this setup?

cfr wrote:

Try removing the resume stuff for now, to see if you can get the simpler case working first.

Sadly I already tried that without success. I also tried replacing UUID with PARTUUID or /dev/nvme0n1p1 and still got the same error.

Head_on_a_Stick · 2017-11-28 21:39:51

julienfalque wrote:

Not sure what you mean by "normal location"

From your own link:

ArchWiki wrote:

For sake of simplicity, you can also use the ESP as the /boot partition itself instead of a separate /boot partition, for EFISTUB booting. In other words, after creating and formatting the EFI System Partition as instructed above, simply mount it at /boot.

So why not try that first?

You can mess around with bind mounts (why?) after you have got the basic configuration working.

julienfalque · 2017-11-29 19:02:32

I did this because I don't want the Arch boot files to be at the root of the ESP partition but in a subdirectory of it. If those files are accessible in /boot anyway, it should be fine, right?

Reading the wiki again, I tried adding initrd=\EFI\arch\intel-ucode.img but that failed too, though the error seemed slightly different.

law · 2017-12-02 10:53:57

I'm having the exact same problem on my Dell XPS 15 (9550), although I'm using /boot as the EFI system partition.

This is the command I used to create the boot entry:

efibootmgr -c -d /dev/nvme0n1 --part 1 -L "Arch Linux" -l /vmlinuz-linux -u "root=UUID=b5eeba69-b2bd-45b8-9760-12b8b08303d9 rw initrd=/initramfs-linux.img initrd=/intel-ucode.img"

Last edited by law (2017-12-02 10:54:59)

Head_on_a_Stick · 2017-12-02 17:50:30

Have you (both) tried "root=/dev/nvme0n1p{whatever}" instead of the UUID?

law · 2017-12-02 20:48:46

I did, and it still fails with the same error.

I wonder if it may have anything to do with the root partition being f2fs?

Head_on_a_Stick · 2017-12-02 23:01:15

Do you also experience the error if the LTS kernel is used?

julienfalque · 2017-12-03 08:47:46

Just tried root=/dev/nvme0n1p5, same error. Using LTS kernel doesn't help either.

My root partition is ext4 so I don't think this is related to file system.

Head_on_a_Stick · 2017-12-03 13:24:04

julienfalque wrote:

Just tried root=/dev/nvme0n1p5, same error. Using LTS kernel doesn't help either.

Have you tried mounting the ESP to /boot and removing the bind mounts?

I don't have any nVME devices & EFI_STUB has always worked for me so perhaps this is a bug.

julienfalque · 2017-12-04 21:14:41

I just tried that, still failing

Could it be some missing module or configuration in the kernel?

Head_on_a_Stick · 2017-12-04 22:41:17

It occurs that we haven't checked the actual NVRAM entries, which is an oversight:

# efibootmgr -v

julienfalque · 2017-12-04 22:45:01

 $ efibootmgr -v
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0000,0001,0002,000A,000B,000C,000D,000E
Boot0000* Windows Boot Manager	HD(1,GPT,e3d6ce83-d6a1-4d33-bf06-3196fc01290d,0x800,0xfa000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot0001* Arch Linux	HD(1,GPT,e3d6ce83-d6a1-4d33-bf06-3196fc01290d,0x800,0xfa000)/File(\EFI\arch\vmlinuz-linux)r.o.o.t.=.U.U.I.D.=.7.4.a.6.6.0.4.d.-.c.a.6.e.-.4.3.f.6.-.8.8.d.0.-.5.8.0.7.5.a.d.d.b.d.9.a. .r.w. .i.n.i.t.r.d.=.\.E.F.I.\.a.r.c.h.\.i.n.t.e.l.-.u.c.o.d.e...i.m.g. .i.n.i.t.r.d.=.\.E.F.I.\.a.r.c.h.\.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g. .r.e.s.u.m.e.=.U.U.I.D.=.7.4.a.6.6.0.4.d.-.c.a.6.e.-.4.3.f.6.-.8.8.d.0.-.5.8.0.7.5.a.d.d.b.d.9.a. .r.e.s.u.m.e._.o.f.f.s.e.t.=.3.2.3.5.8.4. .f.b.c.o.n.=.s.c.r.o.l.l.b.a.c.k.:.1.0.2.4.k.
Boot0002* Arch Linux (rEFInd)	PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-25-38-4C-F1-B0-FD-07)/HD(1,GPT,e3d6ce83-d6a1-4d33-bf06-3196fc01290d,0x800,0xfa000)/File(\EFI\refind\refind_x64.efi)
Boot000A* UEFI: PM951 NVMe SAMSUNG 1024GB, Partition 1	HD(1,GPT,e3d6ce83-d6a1-4d33-bf06-3196fc01290d,0x800,0xfa000)/File(EFI\Microsoft\Boot\bootmgfw.efi)..BO
Boot000B* Diskette Drive	BBS(Floppy,Diskette Drive,0x0)..BO
Boot000C* M.2 PCIe SSD	BBS(HD,PM951 NVMe SAMSUNG 1024GB ,0x0)..BO
Boot000D* CD/DVD/CD-RW Drive	BBS(CDROM,CD/DVD/CD-RW Drive,0x0)..BO
Boot000E* USB Storage Device	BBS(USB,USB Storage Device,0x0)..BO

Head_on_a_Stick · 2017-12-04 22:53:41

julienfalque wrote:

Boot0002* Arch Linux (rEFInd)	PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-25-38-4C-F1-B0-FD-07)/HD(1,GPT,e3d6ce83-d6a1-4d33-bf06-3196fc01290d,0x800,0xfa000)/File(\EFI\refind\refind_x64.efi)

Perhaps rEFInd is working because it's not using EFI_STUB, does GRUB boot your drive also?

By contrast, systemd-boot needs EFI_STUB to work so you should probably try that as well.

Your configuration looks fine to me, unless I've missed something.

Omar007 · 2017-12-05 00:05:02

I'm afraid you may not be able to get this working at all unless Dell brings out an update to the UEFI firmware (or you try to go a coreboot route maybe?).
The UEFI implementation of the Dell XPS models is basically broken; any arguments you set on a bootentry (efibootmgr's -u/--unicode) will be ignored. As a result you will have a boot entry for it but no data will ever be passed to the loader so it will never know your initrd or any other settings.

This is why most bootloaders work fine; they are just programs run without any arguments that chainload the appropriate item using their own configuration method (thus bypassing the broken UEFI implementation).

EDIT: Sadly there is no general Dell XPS page containing this information. It's currently only mentioned on the wiki under certain models (e.g. https://wiki.archlinux.org/index.php/De … _not_boot) while, as far as I'm aware, every model so far is affected by this.

Last edited by Omar007 (2017-12-05 00:17:55)

julienfalque · 2017-12-05 08:39:11

I see, maybe I should report this to Dell somehow then. Thanks for the information!

Is there any alternative way to pass kernel parameters, e.g. some config file or whatever?

Omar007 · 2017-12-05 10:37:17

julienfalque wrote:

Is there any alternative way to pass kernel parameters, e.g. some config file or whatever?

Only if you use a bootloader in-between (e.g. systemd-boot, rEFInd, grub).
https://wiki.archlinux.org/index.php/Ca … ot_loaders

Last edited by Omar007 (2017-12-05 10:37:45)

julienfalque · 2017-12-05 10:51:09

I currently use rEFInd which still needs to pass kernel parameters itself. But is it possible to compile a kernel with "built-in" parameters so that passing them isn't required anymore? Would that work with EFISTUB?

I reported the issue on Dell Community Support Forums, hope I'll get some answers.

Omar007 · 2017-12-05 11:50:12

You could compile the kernel with hard-coded parameters (though at that point it's not so much configurable anymore..), however I don't personally know how exactly.
I do know this is mentioned on the Wiki; https://wiki.archlinux.org/index.php/kernel_parameters

Blasphemist · 2017-12-05 18:40:32

That wiki entry doesn't fully explain this to me and I'm hoping you can help. What flavor of UEFI do these systems use? Do the systems that ship with Ubuntu not use EFISTUB? The entry above this issue on that wiki page discusses updating the UEFI firmware. Is there no version now that has resolved this? Can I assume that efibootmgr doesn't even show the boot params part of the boot entry prior to reboot?

Head_on_a_Stick · 2017-12-05 20:56:56

Blasphemist wrote:

Do the systems that ship with Ubuntu not use EFISTUB?

Ubuntu uses GRUB to boot and this does not require any arguments to the NVRAM entry so the bug does not apply to them.

cfr · 2017-12-06 01:27:05

julienfalque wrote:

 $ efibootmgr -v
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0000,0001,0002,000A,000B,000C,000D,000E
Boot0000* Windows Boot Manager	HD(1,GPT,e3d6ce83-d6a1-4d33-bf06-3196fc01290d,0x800,0xfa000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot0001* Arch Linux	HD(1,GPT,e3d6ce83-d6a1-4d33-bf06-3196fc01290d,0x800,0xfa000)/File(\EFI\arch\vmlinuz-linux)r.o.o.t.=.U.U.I.D.=.7.4.a.6.6.0.4.d.-.c.a.6.e.-.4.3.f.6.-.8.8.d.0.-.5.8.0.7.5.a.d.d.b.d.9.a. .r.w. .i.n.i.t.r.d.=.\.E.F.I.\.a.r.c.h.\.i.n.t.e.l.-.u.c.o.d.e...i.m.g. .i.n.i.t.r.d.=.\.E.F.I.\.a.r.c.h.\.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g. .r.e.s.u.m.e.=.U.U.I.D.=.7.4.a.6.6.0.4.d.-.c.a.6.e.-.4.3.f.6.-.8.8.d.0.-.5.8.0.7.5.a.d.d.b.d.9.a. .r.e.s.u.m.e._.o.f.f.s.e.t.=.3.2.3.5.8.4. .f.b.c.o.n.=.s.c.r.o.l.l.b.a.c.k.:.1.0.2.4.k.
Boot0002* Arch Linux (rEFInd)	PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-25-38-4C-F1-B0-FD-07)/HD(1,GPT,e3d6ce83-d6a1-4d33-bf06-3196fc01290d,0x800,0xfa000)/File(\EFI\refind\refind_x64.efi)
Boot000A* UEFI: PM951 NVMe SAMSUNG 1024GB, Partition 1	HD(1,GPT,e3d6ce83-d6a1-4d33-bf06-3196fc01290d,0x800,0xfa000)/File(EFI\Microsoft\Boot\bootmgfw.efi)..BO
Boot000B* Diskette Drive	BBS(Floppy,Diskette Drive,0x0)..BO
Boot000C* M.2 PCIe SSD	BBS(HD,PM951 NVMe SAMSUNG 1024GB ,0x0)..BO
Boot000D* CD/DVD/CD-RW Drive	BBS(CDROM,CD/DVD/CD-RW Drive,0x0)..BO
Boot000E* USB Storage Device	BBS(USB,USB Storage Device,0x0)..BO

So how are you trying to boot Arch? Using your EFI's boot manager? That is, default loads Windows and you use a firmware menu to switch to refind or whatever? Usually, if you use refind, you would use it as default and then use it to select the option you want - Windows, Arch or whatever. And this doesn't require the firmware to pass any options to the executable.

cfr · 2017-12-06 01:30:28

Blasphemist wrote:

That wiki entry doesn't fully explain this to me and I'm hoping you can help. What flavor of UEFI do these systems use? Do the systems that ship with Ubuntu not use EFISTUB? The entry above this issue on that wiki page discusses updating the UEFI firmware. Is there no version now that has resolved this? Can I assume that efibootmgr doesn't even show the boot params part of the boot entry prior to reboot?

Plenty of UEFI implementations don't have this bug. It is a question of what is available for your hardware. My previous machine had several UEFI updates, but it never booted EFISTUB - not even using refind (which is described as a workaround above).

Arch Linux

#1 2017-11-25 22:23:58

Kernel panic when booting with EFISTUB

#2 2017-11-26 12:50:13

Re: Kernel panic when booting with EFISTUB

#3 2017-11-27 03:57:25

Re: Kernel panic when booting with EFISTUB

#4 2017-11-28 07:17:51

Re: Kernel panic when booting with EFISTUB

#5 2017-11-28 21:39:51

Re: Kernel panic when booting with EFISTUB

#6 2017-11-29 19:02:32

Re: Kernel panic when booting with EFISTUB

#7 2017-12-02 10:53:57

Re: Kernel panic when booting with EFISTUB

#8 2017-12-02 17:50:30

Re: Kernel panic when booting with EFISTUB

#9 2017-12-02 20:48:46

Re: Kernel panic when booting with EFISTUB

#10 2017-12-02 23:01:15

Re: Kernel panic when booting with EFISTUB

#11 2017-12-03 08:47:46

Re: Kernel panic when booting with EFISTUB

#12 2017-12-03 13:24:04

Re: Kernel panic when booting with EFISTUB

#13 2017-12-04 21:14:41

Re: Kernel panic when booting with EFISTUB

#14 2017-12-04 22:41:17

Re: Kernel panic when booting with EFISTUB

#15 2017-12-04 22:45:01

Re: Kernel panic when booting with EFISTUB

#16 2017-12-04 22:53:41

Re: Kernel panic when booting with EFISTUB

#17 2017-12-05 00:05:02

Re: Kernel panic when booting with EFISTUB

#18 2017-12-05 08:39:11

Re: Kernel panic when booting with EFISTUB

#19 2017-12-05 10:37:17

Re: Kernel panic when booting with EFISTUB

#20 2017-12-05 10:51:09

Re: Kernel panic when booting with EFISTUB

#21 2017-12-05 11:50:12

Re: Kernel panic when booting with EFISTUB

#22 2017-12-05 18:40:32

Re: Kernel panic when booting with EFISTUB

#23 2017-12-05 20:56:56

Re: Kernel panic when booting with EFISTUB

#24 2017-12-06 01:27:05

Re: Kernel panic when booting with EFISTUB

#25 2017-12-06 01:30:28

Re: Kernel panic when booting with EFISTUB

Board footer