<F2>  BIOS screen
<delete> BIOS screen
<escape> Boot screen

Geoff

Geoff

What do you mean by "firmware screen"? The bios?

I was just trying to work out what that screen is called if it is using EFI rather than BIOS, but you might want to think of it as the BIOS screen.

It is not always easy to find out which key to hit to get the BIOS screen to appear. My ASUS laptop will give the boot order choice if you hit (or rather keep hitting) one particular key, but if you can find the other magic key then the BIOS screen appears. The keys that may be used include :-

<escape>, <delete>, <F10>, <F12> and there may be others. I have no written documentation to tell me what to use! I will have a look on the web...

Geoff

Geoff 42 wrote:

Once booted up efibootmgr -v reported an error. After fiddling around for a while I ran

grub-install /dev/sda

to try and ensure that it would still boot. This was ok and does still boot via grub as expected.

Wonder why this worked. This is CSM style, not EFI. To my knowledge you have to use something like

# grub-install --bootloader-id=devuan

as I use to generate a devuan entry (no secure boot).

The UEFI version of GRUB will just ignore the device argument and presume that the ESP is mounted under /boot/efi.

Once booted up efibootmgr -v reported an error. After fiddling around for a while I ran

grub-install /dev/sda

to try and ensure that it would still boot. This was ok and does still boot via grub as expected.

Wonder why this worked. This is CSM style, not EFI. To my knowledge you have to use something like

# grub-install --bootloader-id=devuan

as I use to generate a devuan entry (no secure boot).

Doesn't tell me anything, don't use Xen.

Is the directory mounted?

What do you mean by "firmware screen"? The bios? On my 3 latest ASUS board with AMI bios I haven't got any chance to modify any settings but the boot order, if any.

Confused, rolfie

My Asus ZenBook UX305FA is formatted with GPT partitions and boots with EFI.
This has been working fine for a number of years and has been upgraded and is now on Chimaera.

The only thing that I was unable to get to work was running the Xen hypervisor.
I have Xen running on my DOS partitioned desktop, when I want it, but it would not boot on this EFI laptop.
I have had it set up as a boot option via grub, but it would just hang.
I also tried setting it up to boot the Xen hypervisor directly with EFI, but that would just return immediately.

Having a look at getting Xen running, I used efibootmgr under Devuan to look at the EFI settings and also using the firmware screen, from American Megatrends.
In using the firmware screen, trying to see what was set up, I managed to swap round a couple of boot entries and then managed to swap them back!
Once booted up efibootmgr -v reported an error. After fiddling around for a while I ran

grub-install /dev/sda

to try and ensure that it would still boot. This was ok and does still boot via grub as expected.

efibootmgr (with or with "-v") now reports

efibootmgr 
No BootOrder is set; firmware will attempt recovery

However, as a side effect of all this, the grub entry for Xen now works and I am posting this with Chimaera as Dom0 under Xen.

The directory /sys/firmware/efi/efivars/ exists, but is empty.

As everything seems to be working, it is tempting to leave it alone. But where is the fun in that!
It would be nice if efibootmgr agreed with the firmware screen (what is that called, it can't be the BIOS screen, can it?)

In writing this an obvious point becomes clear. If I am running Devuan under Xen, then access to EFI stuff may be impaired. Having booted on the bare metal,

efibootmgr 
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,0004,0002
Boot0000* debian
Boot0002* Hard Drive
Boot0004* zen

efibootmgr -v
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,0004,0002
Boot0000* debianCould not parse device path: Invalid argument

It is interesting that it couldn't parse option 0000 as that is the one that is actually booted.

Also the directory /sys/firmware/efi/efivars/ now contains the expected stuff.

Setting up stuff seems to be easier on the firmware screen than using efibootmgr as selecting the the parts of the path to the boot image is easier when there is a choice of options rather than entering a complex command line. The first part of the path was incomprehensible to me, but there was a choice of one (disk?) and from there the options were obvious.

3. Run BCDEDIT

bcdedit /enum firmware

This provides a list of entries you see in your bios boot list.

4. Remove the entries you don't want using,

bcdedit delete IDENTIFIER_NAME

where IDENTIFIER_NAME is the name of the entry you no longer want.

The efibootmgr(8) command performs the same functions, no need to load up Windows.

1. Boot Windows or a Windows Recovery Mode Image (disk or usb).

2. Open the command prompt as admin.

3. Run BCDEDIT

bcdedit /enum firmware

This provides a list of entries you see in your bios boot list.

4. Remove the entries you don't want using,

bcdedit delete IDENTIFIER_NAME

where IDENTIFIER_NAME is the name of the entry you no longer want.

I would be interested where and how you found the above info

https://wiki.archlinux.org/index.php/Dm … t_loader_3

No, I don't think so.

To stop the machine accessing the EFI variables mount efivarfs read-only:

# /etc/fstab
efivarfs /sys/firmware/efi/efivars efivarfs ro 0 0

Got two boards at home that suffer from strange EFI behaviour. Digged a bit in the internet and came across some threads that talk about that the Linux kernel tries to save some data in EFI variables when the computer crashes. I am pretty sure that happened to my hardware.

Is there any safe way to clear the EFI variables? ASUS denied it and told me to return the board.

Is there a way to prove my theory? To force ASUS to fix the lockup because that should not happen?

These rants also talk about that noefi as kernel parameter would stop the kernel to access the EFI variables. But that would mean the computer has to boot in BIOS mode. Am I right?

rolfie

@HOAS: I owe you a crate of Frankonian beer.

Took me a while to sort everything. The uuids and the kernel were the easy part. I had to add insmod lvm and ext2, the hardest bit was to figure out what to replace "cryptroot" with. There you need to enter the /dev/mapper-name for the decrypted in my case ext4 root device.

Have a nice Sunday, cheers.

rolfie

PS: I would be interested where and how you found the above info. I was searching around with the duck with keywords grub(2) custom.cfg encrypted and found references to Arch and Ubuntu wikis and a lot of rants/posts from various forums, but none was really pointing to the right thing (for me at least).

both my ASCII and Beowulf are encrypted LVMs with unencrypted /boot partitions. I tried the UUID of the encrypted partition. When I select the new entry, it clearly states that vmlinuz isn't found. Don't know yet how to deal with this situation.

Ah, right. Unfortunately I don't know how to deal with encrypted partitions in a GRUB configuration file.

A bit of sleuthing suggests that this might work:

menuentry 'Devuan beowulf' {
   search --fs-uuid boot_uuid --set=root
   linux /vmlinuz-4.19.0-9-amd64 cryptdevice=UUID=beowulf_uuid:cryptroot root=/dev/mapper/cryptroot ro quiet
   initrd /initrd.img-4.19.0-9-amd64
}

^ Again replace beowuld_uuid with the UUID of the (encrypted) root partition and replace boot_uuid with the UUID of the (unencrypted) /boot partition and make sure that the names of the kernel & initramfs images in /boot are corrrect (my last suggestion relied on the symlinks in the root partition that always have the same name).

Lets see if I also can get the custom cfg to work, but that a topic for tomorrow, I am too tired already. Too many typos...

Have a nice evening, rolfie

Well, also prepared a custom.cfg. The menu entry is added, but: both my ASCII and Beowulf are encrypted LVMs with unencrypted /boot partitions. I tried the UUID of the encrypted partition. When I select the new entry, it clearly states that vmlinuz isn't found. Don't know yet how to deal with this situation.

Thanks for your continous input, rolfie

Added EFI/BOOT/ to the efi partition and copied grubx64.efi from Beowulf into there

Did you rename the grubx64.efi file to BOOTX64.EFI?

EDIT: some UEFI firmware implementations are so broken that they will only boot $ESP/EFI/Microsoft/Boot/bootmgfw.efi