[SOLVED] Struggling with weird EFI behaviour

wombat23 · 2014-11-25 21:27:39

I'm trying to set up Linux on an Acer aspire ES1-111M. It apparently has an EFI called "insydeh20". I disabled "Secure Boot".
Following the wiki article on "EFISTUB", I first tried the following:

efibootmgr -d /dev/mmcblk0 -p 1 -c -L "Arch Linux" -l /vmlinuz-linux -u "root=/dev/mmcblk0p2 rootwait initrd=/initramfs-linux.img"

but when I rebooted the EFI would ignore this entry if it was set in BootOrder, and it would not show up in the firmware "boot order" menu. I managed to "trick it" into successfully loading it by setting it as BootNext. But, of course, after each reboot, it has to be set again. I suppose this is a firmware bug (maybe intentional?)

anyway I was not happy with this, so I made another approach by examining the firmware setup menu. I noticed that if I enable "Secure Boot", I can choose "trusted" boot loaders, so I copied vmlinuz-linux to bootx64.efi (else the firmware apparently does not see the file probably because it has no file extension), and chose it. Now, a new entry shows up in the boot menu and I can choose it. Problem is now, i cannot set kernel parameters in the firmware setup, so it will boot right into a kernel panic. Is there a way (with efiboomgr or EFI shell etc) to change the start parameters of an EFI boot entry?

any insights? this is all way more frustrating than I expected it to be

Last edited by wombat23 (2014-11-26 17:16:03)

wombat23 · 2014-11-25 22:30:21

Btw, I noticed in the output of

efivar -l

that the boot entry created by efibootmgr has GUID which consists of only zeros, while the other Boot entries have certain GUID. maybe that is the reason why the EFI firmware does not see it. i'll continue my investigations...

UPDATE: it was only one entry (i have no idea why). the other entries have the correct GUID. also it seems that the boot entries created by the firmware setup have ACPI and PCI values. the ones created by efibootmgr do not. maybe that is why the firmware does not recognise them...

Last edited by wombat23 (2014-11-26 00:16:09)

Head_on_a_Stick · 2014-11-25 22:34:57

wombat23 wrote:

efibootmgr -d /dev/mmcblk0 -p 1 -c -L "Arch Linux" -l /vmlinuz-linux -u "root=/dev/mmcblk0p2 rootwait initrd=/initramfs-linux.img"

This will make an NVRAM entry that will boot up a memory card in your card reader (mmcblk0) -- is this what you want?

FWIW, I suggest trying gummiboot -- my firmware is as buggy as hell & gummiboot seems to work. I have to re-install it every time I try a distro in non-EFI mode, mind you...

wombat23 · 2014-11-25 22:50:32

Head_on_a_Stick wrote:

wombat23 wrote:
efibootmgr -d /dev/mmcblk0 -p 1 -c -L "Arch Linux" -l /vmlinuz-linux -u "root=/dev/mmcblk0p2 rootwait initrd=/initramfs-linux.img"
This will make an NVRAM entry that will boot up a memory card in your card reader (mmcblk0) -- is this what you want?

yes, should have mentioned, the machine has no traditional disk, but an integrated eMMC flash storage. it works with the BootNext entry, so i think the kernel parameters are fine. the problem seems to be getting the EFI to pass them to the kernel.

i thought i could do it without a bootloader, but if I can't find another solution soon, I'll do what you suggested.

wombat23 · 2014-11-26 17:15:14

OK, I installed gummiboot, and added the gummiboot loader via the EFI firmware setup menu to the start entries. now it works! thanks for the suggestion

TheSaint · 2014-11-26 20:26:16

I doubt that a removable media will remain in the NVRAM. Once is removed at the next boot BIOS will clear the entry.

Arch Linux

#1 2014-11-25 21:27:39

[SOLVED] Struggling with weird EFI behaviour

#2 2014-11-25 22:30:21

Re: [SOLVED] Struggling with weird EFI behaviour

#3 2014-11-25 22:34:57

Re: [SOLVED] Struggling with weird EFI behaviour

#4 2014-11-25 22:50:32

Re: [SOLVED] Struggling with weird EFI behaviour

#5 2014-11-26 17:15:14

Re: [SOLVED] Struggling with weird EFI behaviour

#6 2014-11-26 20:26:16

Re: [SOLVED] Struggling with weird EFI behaviour

Board footer