The officially official Devuan Forum!

You are not logged in.

#1 2020-06-18 19:28:29

rolfie
Member
Registered: 2017-11-25
Posts: 1,047  

EFI trouble

This is about an ASUS Prime 470 Pro with latest Bios which behaves strange regarding EFI variables. I have got the board for nearly two years now, running ASCII from a small NVME and Windows7 on a separate SSD. Some weeks ago when starting to prepare for a parallel installation of Beowulf since I had enough free space on the NVME, I discovered:

# efibootmgr -v
No BootOrder is set; firmware will attempt recovery

and based on some research in the internet:

# efibootmgr -v -v
Could not read variable 'BootNext': No such file or directory
error trace:
 vars.c:318 vars_get_variable(): open(/sys/firmware/efi/vars/BootNext-8be4df61-93ca-11d2-aa0d-00e098032b8c/raw_var, O_RDONLY) failed: No such file or directory
 lib.c:145 efi_get_variable(): ops->get_variable failed: No such file or directory
Could not read variable 'BootCurrent': No such file or directory
error trace:
 vars.c:318 vars_get_variable(): open(/sys/firmware/efi/vars/BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c/raw_var, O_RDONLY) failed: No such file or directory
 lib.c:145 efi_get_variable(): ops->get_variable failed: No such file or directory
Could not read variable 'Timeout': No such file or directory
error trace:
 vars.c:318 vars_get_variable(): open(/sys/firmware/efi/vars/Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c/raw_var, O_RDONLY) failed: No such file or directory
 lib.c:145 efi_get_variable(): ops->get_variable failed: No such file or directory
Could not read variable 'BootOrder': No such file or directory
error trace:
 vars.c:318 vars_get_variable(): open(/sys/firmware/efi/vars/BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c/raw_var, O_RDONLY) failed: No such file or directory
 lib.c:145 efi_get_variable(): ops->get_variable failed: No such file or directory
 efibootmgr.c:363 read_order(): efi_get_variable failed: No such file or directory
No BootOrder is set; firmware will attempt recovery
Could not read variable 'MirrorCurrent': No such file or directory
error trace:
 vars.c:318 vars_get_variable(): open(/sys/firmware/efi/vars/MirrorCurrent-7b9be2e0-e28a-4197-ad3e-32f062f9462c/raw_var, O_RDONLY) failed: No such file or directory
 lib.c:145 efi_get_variable(): ops->get_variable failed: No such file or directory
Could not read variable 'MirrorRequest': No such file or directory
error trace:
 vars.c:318 vars_get_variable(): open(/sys/firmware/efi/vars/MirrorRequest-7b9be2e0-e28a-4197-ad3e-32f062f9462c/raw_var, O_RDONLY) failed: No such file or directory
 lib.c:145 efi_get_variable(): ops->get_variable failed: No such file or directory

Since then I have been through a lot of fiddling around: Overwrite the Bios, set option defaults, check/remove battery, reset CMOS, reconfigure the RX570 I have on board since 9 months (as a replacement for a passive graphics card) to the performance bios instead of the compute bios, disable CSM that was still on, fast boot off, talk to ASUS hotline, try EASYUefi on Win7, clean out unused stuff from the /boot/efi directory. Still the same.

efibootmgr and other tools are useless, they do not work.

Strangely enough grub-install seems to work once and sets a Bootorder, but that does not survice the next reboot. Some days ago I installed Beowulf in the new partition. The install worked fine except that grub-install did overwrite the ASCII efi entry. Meanwhile I have rescued both installations by doing a grub-install --bootloader-id=id. My original ASCII is working again, but now I have lost Beowulf when trying to use boot override.

Are there any suggestions how I could reset the EFI memory stuff, something I haven't found?

rolfie

Last edited by rolfie (2020-06-18 20:15:56)

Offline

#2 2020-06-18 19:48:39

larsH
Member
Registered: 2020-05-05
Posts: 184  

Re: EFI trouble

Hi

How are your disks partitioned ?? Bios set up: CSM, Legacy boot, secure boot. Beowulf does install with these on. Searching  Google tells me that there are successful installs on the same machine

Have  a nice day
Lars H

Offline

#3 2020-06-18 19:59:28

rolfie
Member
Registered: 2017-11-25
Posts: 1,047  

Re: EFI trouble

The efi trouble is not due to Beowulf and the install. Somehow the efi memory of the mainboard is bugged, and I see now way to clean out and reset the stuff. The usual tricks to save a not booting system do not help.

BTW: pure EFI install, CSM off, Secure boot off, all keys deleted, all disks GPT. I have read enough to get this right.

I am posting from my original ASCII now, the Beowulf entry still is present on /boot/efi/.., but no more shown in the Bios. Only ASCII and Win7 present (that is crashed also after disabling CSM despite being an UEFI installation, for the moment that isn't important).

Again, is there anybody around who knows the real dirty tricks?

rolfie

Offline

#4 2020-06-18 20:13:37

larsH
Member
Registered: 2020-05-05
Posts: 184  

Re: EFI trouble

Hi again

If you did know everything well enough then you would not have a problem ;-)) So please don't be rude. Many other people have this board running well with linux. Again: How is your partioning. How is your fstab. Try with bios fail-safe settings. Beowulf does mostly install well on secureboot only machines. This is one af the main features of Debian Buster. If you are doing all sorts of tricks, chances are you are screwing things up. And if you want help please provide the necessary information. We do all make simple mistakes from time to time.

Have a nice day

Offline

#5 2020-06-18 20:26:04

Head_on_a_Stick
Member
From: London
Registered: 2019-03-24
Posts: 3,125  
Website

Re: EFI trouble

Copy grubx64.efi to /EFI/BOOT/BOOTX64.EFI (on the EFI system partition), that will be booted even without an NVRAM entry.

It will probably be located at /EFI/devuan/grubx64.efi, use the find command to locate it.

Alternatively, use the grub-install command with the --removable option, which copies the bootloader to that location automatically.

You might be able to get efibootmgr working by mounting efivarfs manually:

mount -t efivarfs efivarfs /sys/firmware/efi/efivars

It is also possible to manually delete the NVRAM entries from /sys/firmware/efi/efivars/ but it might brick your box.


Brianna Ghey — Rest In Power

Offline

#6 2020-06-18 21:18:25

rolfie
Member
Registered: 2017-11-25
Posts: 1,047  

Re: EFI trouble

larsH wrote:

If you did know everything well enough then you would not have a problem ;-)) So please don't be rude.

I am sorry, I know that I am no more than a talented amateur and a private user. But I have got my experience with Linux, with Devuan and Beowulf installations and I have sorted one of the other problem and so on. Don't want to be rude, but concentrate on the issue as I see it. Please convince me that I am wrong.   

larsH wrote:

Many other people have this board running well with linux.

Refer to post #1: I have this board and a Ryzen 7 2700X working with ASCII for about 2 years now, backports kernel. HOAS did not believe me that this is possible, I have proven him wrong. Sorry for that. 

larsH wrote:

Again: How is your partioning. How is your fstab.

# blkid
/dev/nvme0n1: PTUUID="6dfae043-b76f-47ba-8c8c-dade8f545e70" PTTYPE="gpt"
/dev/nvme0n1p1: UUID="26AA-7EAE" TYPE="vfat" PARTUUID="e5604745-edac-4815-bc08-bbf2747deed4"
/dev/nvme0n1p2: LABEL="boot" UUID="6b1a5449-77ac-487b-b9e6-737ec8b8c677" TYPE="ext4" PARTLABEL="nvme_boot" PARTUUID="3a9d4e90-bbb7-4cbd-a54d-df62d98925f6"
/dev/nvme0n1p3: UUID="d1231306-6a42-4e5c-b609-60909d8e210b" TYPE="crypto_LUKS" PARTUUID="03f2a4dc-073f-485f-bce4-7368356daff4"
/dev/nvme0n1p4: LABEL="BeoBoot" UUID="4980605c-6b41-4d4b-81ec-f66c0eb45a8e" TYPE="ext4" PARTLABEL="DevBoot" PARTUUID="5be64e0b-1275-480b-aea9-74483d979008"
/dev/nvme0n1p5: UUID="0f8ed665-79ed-4a19-83ba-6671827567c6" TYPE="crypto_LUKS" PARTLABEL="DevRoot" PARTUUID="c2fa81d3-7e4e-40b1-bee2-bbdeca365611"
/dev/sda1: LABEL="1905E1E68X8" UUID="AEB3-D480" TYPE="vfat" PARTLABEL="ssdefi" PARTUUID="2a66036e-a832-4654-b12f-773f42bc027a"
/dev/sda2: LABEL="Win7Ult" UUID="6CD3FFAC25F17123" TYPE="ntfs" PTTYPE="dos" PARTLABEL="W7Ultimate" PARTUUID="8f878125-d8e2-4e24-ba40-6b884f77f78b"
/dev/sda3: LABEL="SSDData" UUID="5B83C3811BAE211B" TYPE="ntfs" PTTYPE="dos" PARTLABEL="W7Data" PARTUUID="cbfd11d2-df24-4f51-a8c6-952704d130bc"
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/vgsys-1_root /               ext4    discard,relatime,errors=remount-ro 0       1

# /boot was on /dev/nvme0n1p2 during installation
UUID=6b1a5449-77ac-487b-b9e6-737ec8b8c677 /boot           ext4    defaults        0       2

# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=26AA-7EAE  /boot/efi       vfat    umask=0077      0       1

/dev/mapper/vgsys-2_swap none            swap    sw              0       0

/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

I removed a bit of info for the other devices. The NVME is GPT partitioned, p1 is the efi partition, p2 the ASCII boot, p3 an encrypted LVM for root and swap. p4 was added a few days ago as boot for Beowulf, p5 is an encrypted LVM for root and swap for Beowulf. sda holds a Windows7 installation that is detected and listed in the grub menu. 

larsH wrote:

Try with bios fail-safe settings.

What is this?

larsH wrote:

Beowulf does mostly install well on secreboot only machines. This is one af the main features of Debian Buster.

I don't care about secure boot, its disabled and all keys are deleted in the bios. I am using pure efi without secure boot.

larsH wrote:

If you are doing all sorts of tricks, chances are you are screwing things up. And if you want help please provide the necessary information. We do all make simple mistakes from time to time.

I am pretty sure that I haven't made a generic error on the Beowulf install. The efi problem did exist before the install. My mistake and an important learning was that ASCII and Beowulf will install the efi bootloader in the same directory /boot/efi/EFI/debian. I solved this now by booting the Beowulf and ASCII install media in resue mode and doing a grub-install --bootloader-id=beowulf re --bootloader-id=ascii.
Current entries left on the efi partition are:

# cd /boot/efi/efi
root@....:/boot/efi/efi# ls -la
insgesamt 2
drwx------ 4 root root 512 Jun 18 21:23 .
drwx------ 4 root root 512 Jan  1  1970 ..
drwx------ 2 root root 512 Jun 18 09:45 ascii
drwx------ 2 root root 512 Jun 15 08:15 beowulf

Is there something I have overlooked? I am posting from ASCII now, Beowulf is no more present in the boot override menu. If I want to boot it again I need to reboot from the Beowulf install USB stick, use rescue mode, install grub again into the beowulf directory, then I can use Beowulf and have lost the ascii entry as side effect.

On the weekend I may try HOAS hint to create the /EFI/BOOT/ entry as a copy of the beowulf efi entry. Lets see if that allows me to select either ascii or beowulf.

The efi variables problem remains:

# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
root@.....:/# efibootmgr -v
No BootOrder is set; firmware will attempt recovery
# cd /sys/firmware/efi/efivars
root@.....:/sys/firmware/efi/efivars# ls -la
insgesamt 0
drwxr-xr-x 2 root root    0 Jun 18 23:09 .
drwxr-xr-x 6 root root    0 Jun 18 23:09 ..
-rw-r--r-- 1 root root   38 Jun 18 23:09 ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   40 Jun 18 23:09 ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    5 Jun 18 23:09 CurrentPolicy-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    5 Jun 18 23:09 DeploymentModeNv-97e8965f-c761-4f48-b6e4-9ffa9cb2a2d6
-rw-r--r-- 1 root root    8 Jun 18 23:09 Kernel_ATPSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8 Jun 18 23:09 Kernel_EntRevokeSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8 Jun 18 23:09 Kernel_RvkSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8 Jun 18 23:09 Kernel_SiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8 Jun 18 23:09 Kernel_SkuSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8 Jun 18 23:09 Kernel_WinSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root   11 Jun 18 23:09 SecureBootSetup-7b59104a-c00d-4158-87ff-f04d6396a915
-rw-r--r-- 1 root root 5804 Jun 18 23:09 StdDefaults-4599d26f-1a11-49b8-b91f-858745cff824

Useful hints are welcome. I am considering to replace the mainboard. But: the X470 is swept from the market, at least in Germany, and an replacement could be a X570 board, but that does no more have Win7 drivers that I still require for one or the other task (I will never upgrade on Win10, do not suggest something like that).

rolfie

Last edited by rolfie (2020-06-18 21:20:51)

Offline

#7 2020-06-19 07:05:28

larsH
Member
Registered: 2020-05-05
Posts: 184  

Re: EFI trouble

Hi

You cant boot Windows 7 without CSM. Then enable csm. You said your bios is broken. In what way. I hvve looked into asus support and if you decide to upgrade/downgrade your bios I would choose ver. 5216 They tell it is fixed for some linux related problems. If efi install does not work, then make the install using legacy (csm). You do not need to change your partitioning from gpt. But be sure to make 2mb free in the start of the disk so grub can install in legacy mode.

Have a nice day
Lars H

Offline

#8 2020-06-19 10:44:45

Head_on_a_Stick
Member
From: London
Registered: 2019-03-24
Posts: 3,125  
Website

Re: EFI trouble

Sorry but I am failing to understand the exact nature of the problem here.

rolfie wrote:

On the weekend I may try HOAS hint to create the /EFI/BOOT/ entry as a copy of the beowulf efi entry. Lets see if that allows me to select either ascii or beowulf.

But surely you can already select either ASCII or beowulf from the GRUB menu, why do you want separate NVRAM entries?

rolfie wrote:

I am considering to replace the mainboard

Good luck finding one that doesn't have a buggy UEFI firmware implementation. Based on my experiences on various forums the vast majority of motherboards have barely functional UEFI firmware, the manufacturers are clearly farming out their solutions to the lowest bidders.


Brianna Ghey — Rest In Power

Offline

#9 2020-06-20 20:36:17

rolfie
Member
Registered: 2017-11-25
Posts: 1,047  

Re: EFI trouble

Follow up: maybe I am stubborn, but I have changed the setup of my X470 main board to pure EFI and I simply expect it to work, because every "expert" advertises EFI as the future and CSM as being outdated. I wanna use it. I am not trying to use it outside specs, or misuse it in some strange way. When I write an EFI entry I expect this procedure to work as described and that the entry still is present and selectable past the next bootup. And that I can select other entries I have written before, that they are not getting destroyed.

=> the BIOS/EFI of my X470 main board is bad and broken. If you carefully read what I have descibed in this thread I think you have to come to the same conclusion. Additionally it looks like there is no regular way to reset the EFI part to defaults.

@HOAS: Since I am on PURE EFI without CSM, there is no boot entry for Beowulf in my ASCII grub menu. os-prober does only find the Win7 boot manager on the Win7-SSD. The same on a different mainboard with X570 chipset. Arch and Beowulf are present on the same NVME, I only can start the second OS via the boot override. I have just seen that an Ubuntu wiki claims that os-prober should be able to find another OS on the PC - here in my environment it does not work in two instances.
   
I have searched the internet for ways to add a custom configuration other than Windows. Again I found something in the Ubuntu wiki, but I am not sure if that skript will avoid starting another grub from the ASCII grub. The procedure must be safe by not mingling the two distros together so that I can run updates safely. Haven't tried it yet. I might raise another thread about this topic.

I have done a compare of the X470 and the X570 EFI setting. Here is the result. X470 on the top, X570 on the bottom.

# efibootmgr -v
No BootOrder is set; firmware will attempt recovery

# efibootmgr -v -v
Could not read variable 'BootNext': No such file or directory
error trace:
 vars.c:318 vars_get_variable(): open(/sys/firmware/efi/vars/BootNext-8be4df61-93ca-11d2-aa0d-00e098032b8c/raw_var, O_RDONLY) failed: No such file or directory
 lib.c:145 efi_get_variable(): ops->get_variable failed: No such file or directory
Could not read variable 'BootCurrent': No such file or directory
error trace:
 vars.c:318 vars_get_variable(): open(/sys/firmware/efi/vars/BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c/raw_var, O_RDONLY) failed: No such file or directory
 lib.c:145 efi_get_variable(): ops->get_variable failed: No such file or directory
Could not read variable 'Timeout': No such file or directory
error trace:
 vars.c:318 vars_get_variable(): open(/sys/firmware/efi/vars/Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c/raw_var, O_RDONLY) failed: No such file or directory
 lib.c:145 efi_get_variable(): ops->get_variable failed: No such file or directory
Could not read variable 'BootOrder': No such file or directory
error trace:
 vars.c:318 vars_get_variable(): open(/sys/firmware/efi/vars/BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c/raw_var, O_RDONLY) failed: No such file or directory
 lib.c:145 efi_get_variable(): ops->get_variable failed: No such file or directory
 efibootmgr.c:363 read_order(): efi_get_variable failed: No such file or directory
No BootOrder is set; firmware will attempt recovery
Could not read variable 'MirrorCurrent': No such file or directory
error trace:
 vars.c:318 vars_get_variable(): open(/sys/firmware/efi/vars/MirrorCurrent-7b9be2e0-e28a-4197-ad3e-32f062f9462c/raw_var, O_RDONLY) failed: No such file or directory
 lib.c:145 efi_get_variable(): ops->get_variable failed: No such file or directory
Could not read variable 'MirrorRequest': No such file or directory
error trace:
 vars.c:318 vars_get_variable(): open(/sys/firmware/efi/vars/MirrorRequest-7b9be2e0-e28a-4197-ad3e-32f062f9462c/raw_var, O_RDONLY) failed: No such file or directory
 lib.c:145 efi_get_variable(): ops->get_variable failed: No such file or directory

# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
# cd /sys/firmware/efi/efivars
/sys/firmware/efi/efivars# ls -la
insgesamt 0
drwxr-xr-x 2 root root    0 Jun 20 21:24 .
drwxr-xr-x 6 root root    0 Jun 20 21:23 ..
-rw-r--r-- 1 root root   38 Jun 20 21:24 ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   40 Jun 20 21:24 ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    5 Jun 20 21:24 CurrentPolicy-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    5 Jun 20 21:24 DeploymentModeNv-97e8965f-c761-4f48-b6e4-9ffa9cb2a2d6
-rw-r--r-- 1 root root    8 Jun 20 21:24 Kernel_ATPSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8 Jun 20 21:24 Kernel_EntRevokeSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8 Jun 20 21:24 Kernel_RvkSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8 Jun 20 21:24 Kernel_SiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8 Jun 20 21:24 Kernel_SkuSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8 Jun 20 21:24 Kernel_WinSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root   11 Jun 20 21:24 SecureBootSetup-7b59104a-c00d-4158-87ff-f04d6396a915
-rw-r--r-- 1 root root 5804 Jun 20 21:24 StdDefaults-4599d26f-1a11-49b8-b91f-858745cff824
# efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,000E,000F
Boot0000* devuan	HD(1,GPT,47fa57a7-5161-4d26-8b98-90abee299b5f,0x800,0x400000)/File(\EFI\DEVUAN\GRUBX64.EFI)
Boot0001* Arch	HD(1,GPT,47fa57a7-5161-4d26-8b98-90abee299b5f,0x800,0x400000)/File(\EFI\ARCH\GRUBX64.EFI)
Boot000E* debian	HD(1,GPT,47fa57a7-5161-4d26-8b98-90abee299b5f,0x800,0x400000)/File(\EFI\DEBIAN\GRUBX64.EFI)..BO
Boot000F* UEFI: SanDisk, Partition 1	PciRoot(0x0)/Pci(0x8,0x1)/Pci(0x0,0x3)/USB(1,0)/HD(1,MBR,0x97df71f4,0x800,0x1ca3800)..BO

# efibootmgr -v -v
Could not read variable 'BootNext': No such file or directory
error trace:
 vars.c:332 vars_get_variable(): open(/sys/firmware/efi/vars/BootNext-8be4df61-93ca-11d2-aa0d-00e098032b8c/raw_var, O_RDONLY) failed: No such file or directory
 lib.c:139 efi_get_variable(): ops->get_variable failed: No such file or directory
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,000E,000F
Boot0000* devuan	HD(1,GPT,47fa57a7-5161-4d26-8b98-90abee299b5f,0x800,0x400000)/File(\EFI\DEVUAN\GRUBX64.EFI)
Boot0001* Arch	HD(1,GPT,47fa57a7-5161-4d26-8b98-90abee299b5f,0x800,0x400000)/File(\EFI\ARCH\GRUBX64.EFI)
Boot000E* debian	HD(1,GPT,47fa57a7-5161-4d26-8b98-90abee299b5f,0x800,0x400000)/File(\EFI\DEBIAN\GRUBX64.EFI)..BO
Boot000F* UEFI: SanDisk, Partition 1	PciRoot(0x0)/Pci(0x8,0x1)/Pci(0x0,0x3)/USB(1,0)/HD(1,MBR,0x97df71f4,0x800,0x1ca3800)..BO
Could not read variable 'MirrorCurrent': No such file or directory
error trace:
 vars.c:332 vars_get_variable(): open(/sys/firmware/efi/vars/MirrorCurrent-7b9be2e0-e28a-4197-ad3e-32f062f9462c/raw_var, O_RDONLY) failed: No such file or directory
 lib.c:139 efi_get_variable(): ops->get_variable failed: No such file or directory
Could not read variable 'MirrorRequest': No such file or directory
error trace:
 vars.c:332 vars_get_variable(): open(/sys/firmware/efi/vars/MirrorRequest-7b9be2e0-e28a-4197-ad3e-32f062f9462c/raw_var, O_RDONLY) failed: No such file or directory
 lib.c:139 efi_get_variable(): ops->get_variable failed: No such file or directory

/boot/efi/efi# ls -la
insgesamt 20
drwx------ 5 root root 4096 Jun 11 16:58 .
drwx------ 5 root root 4096 Jan  1  1970 ..
drwx------ 2 root root 4096 Jun 10 17:41 Arch
drwx------ 2 root root 4096 Apr 22 17:29 debian
drwx------ 2 root root 4096 Apr 25 22:09 devuan

# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
# cd /sys/firmware/efi/efivars
/sys/firmware/efi/efivars# ls -la
insgesamt 0
drwxr-xr-x 2 root root    0 Jun 19 18:00 .
drwxr-xr-x 6 root root    0 Jun 19 17:15 ..
-rw-r--r-- 1 root root   14 Jun 19 18:00 AmdAcpiVar-79941ecd-ed36-49d0-8124-e4c31ac75cd4
-rw-r--r-- 1 root root  132 Jun 19 18:00 AMD_PBS_SETUP-a339d746-f678-49b3-9fc7-54ce0f9df226
-rw-r--r-- 1 root root   12 Jun 19 18:00 AMD_RAID-fe26a894-d199-47d4-8afa-070e3d54ba86
-rw-r--r-- 1 root root 1557 Jun 19 18:00 AmdSetup-3a997502-647a-4c82-998e-52ef9486a247
-rw-r--r-- 1 root root    8 Jun 19 18:00 AmiHardwareSignatureSetupUpdateCountVar-81c76078-bfde-4368-9790-570914c01a65
-rw-r--r-- 1 root root   28 Jun 19 18:00 AMITCGPPIVAR-a8a2093b-fefa-43c1-8e62-ce526847265e
-rw-r--r-- 1 root root  437 Jun 19 18:00 AOD_SETUP-5ed15dc0-edef-4161-9151-6014c4cc630c
-rw-r--r-- 1 root root    8 Jun 19 18:00 ApSyncFlagNv-ad3f6761-f0a3-46c8-a4cb-19b70ffdb305
-rw-r--r-- 1 root root    5 Jun 19 18:00 asusbkpsmmflag-3eb0ceb0-5890-4853-9a13-0942ec712222
-rw-r--r-- 1 root root   20 Jun 19 18:00 AsusRomLayout-2e0585e9-2b5e-4f1e-bbeb-e632c5ef44b8
-rw-r--r-- 1 root root   40 Jun 19 18:00 AutoDetectData-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
-rw-r--r-- 1 root root  134 Jun 19 18:00 BiosEventLog-4034591c-48ea-4cdc-864f-e7cb61cfd0f2
-rw-r--r-- 1 root root   80 Jun 19 18:00 BiosSettingMappingTable-b57086d5-c2e5-4654-9e3a-0b55830fbb32
-rw-r--r-- 1 root root  122 Jun 19 18:00 Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root  114 Jun 19 18:00 Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root  126 Jun 19 18:00 Boot000E-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root  210 Jun 19 18:00 Boot000F-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    6 Jun 19 18:00 BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    5 Jun 19 18:00 BootFromUSB-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
-rw-r--r-- 1 root root    8 Jun 19 18:00 BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   12 Jun 19 18:00 BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    6 Jun 19 18:00 CMOSfailflag-c89dc9c7-5105-472c-a743-b1621e142b41
-rw-r--r-- 1 root root   38 Jun 19 18:00 ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   38 Jun 19 18:00 ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   52 Jun 19 18:00 ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   52 Jun 19 18:00 ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    5 Jun 19 18:00 CurrentPolicy-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root 6326 Jun 19 18:00 db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
-rw-r--r-- 1 root root 6326 Jun 19 18:00 dbDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 3728 Jun 19 18:00 dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f
-rw-r--r-- 1 root root 3728 Jun 19 18:00 dbxDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   12 Jun 19 18:00 DefaultBootOrder-45cf35f6-0d6e-4d04-856a-0370a5b16f53
-rw-r--r-- 1 root root    5 Jun 19 18:00 DeploymentModeNv-97e8965f-c761-4f48-b6e4-9ffa9cb2a2d6
-rw-r--r-- 1 root root    5 Jun 19 18:00 DownCoreStatus-29749bad-401b-4f6d-b124-cece8c590c48
-rw-r--r-- 1 root root    5 Jun 19 18:00 EntBootMode-d047ab6d-49eb-4a1f-a0bf-ac949bbea113
-rw-r--r-- 1 root root   68 Jun 19 18:00 EnWpData-cbab171f-f356-4009-baaa-6628353a0a29
-rw-r--r-- 1 root root   52 Jun 19 18:00 ErrOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   52 Jun 19 18:00 ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    5 Jun 19 18:00 EXTFanCard-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
-rw-r--r-- 1 root root    5 Jun 19 18:00 FirstBootFlag-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
-rw-r--r-- 1 root root    8 Jun 19 18:00 FPDT_Volatile-01368881-c4ad-4b1d-b631-d57a8ec8db6b
-rw-r--r-- 1 root root   14 Jun 19 18:00 FPLayoutOrder-4db88a62-6721-47a0-9082-280b00323594
-rw-r--r-- 1 root root    5 Jun 19 18:00 FTMActiveFlag-4034591c-48ea-4cdc-864f-e7cb61cfd0f2
-rw-r--r-- 1 root root   26 Jun 19 18:00 FTMEventLog-701d2531-684f-40d1-a1d5-e1466fb38321
-rw-r--r-- 1 root root   12 Jun 19 18:00 HiiDB-1b838190-4625-4ead-abc9-cd5e6af18fe0
-rw-r--r-- 1 root root   12 Jun 19 18:00 HW_Change_Warning-0025a1bf-fdc6-420a-8fc6-6cd9e4736a3b
-rw-r--r-- 1 root root 3577 Jun 19 18:00 KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 3577 Jun 19 18:00 KEKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    8 Jun 19 18:00 Kernel_ATPSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8 Jun 19 18:00 Kernel_DriverSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8 Jun 19 18:00 Kernel_RvkSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8 Jun 19 18:00 Kernel_SiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8 Jun 19 18:00 Kernel_SkuSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root    8 Jun 19 18:00 Kernel_WinSiStatus-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root   12 Jun 19 18:00 LegacyDevicesBuffer-5fc52485-15dd-434a-8c89-c2658a41dec1
-rw-r--r-- 1 root root   12 Jun 19 18:00 LegacyGroupMappingBuffer-f2af59e7-86c4-4f6e-8fbf-4d9ae6cb7fcf
-rw-r--r-- 1 root root    6 Jun 19 18:00 MaximumTableSize-4b3082a3-80c6-4d7e-9cd0-583917265df1
-rw-r--r-- 1 root root    5 Jun 19 18:00 MemoryOverwriteRequestControl-e20939be-32d4-41be-a150-897f85d49829
-rw-r--r-- 1 root root    5 Jun 19 18:00 MemoryOverwriteRequestControlLock-bb983ccf-151d-40e1-a07b-4a17be168292
-rw-r--r-- 1 root root    8 Jun 19 18:00 MonotonicCounter-01368881-c4ad-4b1d-b631-d57a8ec8db6b
-rw-r--r-- 1 root root   76 Jun 19 18:00 MyFav-4034591c-48ea-4cdc-864f-e7cb61cfd0f2
-rw-r--r-- 1 root root    6 Jun 19 18:00 NVRAM_Verify-15a9dd61-e4f8-4a99-80db-353b13d76490
-rw-r--r-- 1 root root   12 Jun 19 18:00 OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   12 Jun 19 18:00 OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    7 Jun 19 18:00 PasswordMode-2b2a9752-feaa-4f86-a313-4d4c7117cee8
-rw-r--r-- 1 root root  890 Jun 19 18:00 PK-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root  890 Jun 19 18:00 PKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   10 Jun 19 18:00 PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   60 Jun 19 18:00 PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    8 Jun 19 18:00 PreVgaInfo-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
-rw-r--r-- 1 root root   12 Jun 19 18:00 RsdpAddr-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
-rw-r--r-- 1 root root    5 Jun 19 18:00 SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    6 Jun 19 18:00 SetupAPMFeatures-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
-rw-r--r-- 1 root root   19 Jun 19 18:00 SetupHWMFeatures-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
-rw-r--r-- 1 root root    5 Jun 19 18:00 SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root  148 Jun 19 18:00 SignatureSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   12 Jun 19 18:00 SmbiosEntryPointTable-4b3082a3-80c6-4d7e-9cd0-583917265df1
-rw-r--r-- 1 root root   12 Jun 19 18:00 SmbiosEntryPointTableF000-4b3082a3-80c6-4d7e-9cd0-583917265df1
-rw-r--r-- 1 root root   12 Jun 19 18:00 SmbiosScratchBuffer-4b3082a3-80c6-4d7e-9cd0-583917265df1
-rw-r--r-- 1 root root   12 Jun 19 18:00 SmbiosV3EntryPointTable-4b3082a3-80c6-4d7e-9cd0-583917265df1
-rw-r--r-- 1 root root    6 Jun 19 18:00 Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    5 Jun 19 18:00 TotalNumberOfRootBridges-fb5703f5-f8a7-f401-18b4-3f108deb2612
-rw-r--r-- 1 root root   10 Jun 19 18:00 TPMPERBIOSFLAGS-7d3dceee-cbce-4ea7-8709-6e552f1edbde
-rw-r--r-- 1 root root   12 Jun 19 18:00 TpmServFlags-7d3dceee-cbce-4ea7-8709-6e552f1edbde
-rw-r--r-- 1 root root    5 Jun 19 18:00 VendorKeys-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    8 Jun 19 18:00 WpBufAddr-cba83c4a-a5fc-48a8-b3a6-d33636166544
-rw-r--r-- 1 root root   68 Jun 19 18:00 WriteOnceStatus-4b3082a3-80c6-4d7e-9cd0-583917265df1

The X470 entries show the problem, and the efivars displayed are much less than the ones from the new board.

During my research I stumbled across an older article in the internet that talked about that a linux developer bricked a Samsung laptop by writing debug info into the EFI variables, all according to the official specs. My gut feeling tells me that I am in a similar situation. This is the second board where I have some trouble with regarding EFI. When you dig a bit into my posts here you may find a thread about a M5A99X Evo R2 having EFI trouble. And now the X470. Maybe something is happening in the background from the linux kernels side or somethhing else I don't know yet. I want to find out to be able to address the problem with the mainboard supplier.

@larsH: maybe your suggestion to enable CSM again is the way out for a while. Nevertheless, I wanna understand why the EFI is half way bricked. And I do not believe CSM fixes the problems forever. I think the BIOS and EFI programmers need to fix their issues. I have found an issue.

Happy reading, have a nice weekend. And thank you for your input.

rolfie

Last edited by rolfie (2020-06-20 20:37:04)

Offline

#10 2020-06-20 20:58:17

Head_on_a_Stick
Member
From: London
Registered: 2019-03-24
Posts: 3,125  
Website

Re: EFI trouble

rolfie wrote:

@HOAS: Since I am on PURE EFI without CSM, there is no boot entry for Beowulf in my ASCII grub menu. os-prober does only find the Win7 boot manager on the Win7-SSD. The same on a different mainboard with X570 chipset. Arch and Beowulf are present on the same NVME, I only can start the second OS via the boot override. I have just seen that an Ubuntu wiki claims that os-prober should be able to find another OS on the PC - here in my environment it does not work in two instances.

The UEFI GRUB version will only provide a menu entry for another system if it is also installed in UEFI mode. The non-UEFI GRUB version will only provide a menu entry for another system if it is also installed in non-UEFI mode.

So are all of your systems installed in UEFI mode? Check for /sys/firmware/efi, that will only exist if the system is booted in UEFI mode.


Brianna Ghey — Rest In Power

Offline

#11 2020-06-20 21:02:53

rolfie
Member
Registered: 2017-11-25
Posts: 1,047  

Re: EFI trouble

On my X470 from ASCII:

# cd /boot/efi/efi
/boot/efi/efi# ls -la
insgesamt 2
drwx------ 4 root root 512 Jun 18 21:23 .
drwx------ 4 root root 512 Jan  1  1970 ..
drwx------ 2 root root 512 Jun 18 09:45 ascii
drwx------ 2 root root 512 Jun 15 08:15 beowulf
/boot/efi/efi# cd /sys/firmware/efi
/sys/firmware/efi# ls -la
insgesamt 0
drwxr-xr-x  6 root root    0 Jun 20 21:25 .
drwxr-xr-x  6 root root    0 Jun 20 10:33 ..
-r--r--r--  1 root root 4096 Jun 20 22:59 config_table
drwxr-xr-x  2 root root    0 Jun 20 21:24 efivars
drwxr-xr-x  3 root root    0 Jun 20 22:59 esrt
-r--r--r--  1 root root 4096 Jun 20 22:59 fw_platform_size
-r--r--r--  1 root root 4096 Jun 20 22:59 fw_vendor
-r--r--r--  1 root root 4096 Jun 20 22:59 runtime
drwxr-xr-x 20 root root    0 Jun 20 22:59 runtime-map
-r--------  1 root root 4096 Jun 20 22:59 systab
drwxr-xr-x 14 root root    0 Jun 20 21:23 vars
root@rh050:/sys/firmware/efi# os-prober
/dev/sda1@/efi/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi

Beowulf was installed in efi mode. 100% sure. Also tried the suggestion from post #5:

# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
mount: efivarfs is already mounted or /sys/firmware/efi/efivars busy
       efivarfs is already mounted on /sys/firmware/efi/efivars
# efibootmgr -v
No BootOrder is set; firmware will attempt recovery

rolfie

Last edited by rolfie (2020-06-20 21:07:51)

Offline

#12 2020-06-20 21:14:46

Head_on_a_Stick
Member
From: London
Registered: 2019-03-24
Posts: 3,125  
Website

Re: EFI trouble

Try adding a file to /boot/grub/custom.cfg in your ASCII system with this content:

menuentry 'Devuan beowulf' {
   uuid=beowulf_uuid
   search --fs-uuid $uuid --set=root
   linux /vmlinuz root=UUID=$uuid ro quiet
   initrd /initrd.img
}

^ Replace beowulf_uuid with the actual UUID of the beowulf root partition.

Last edited by Head_on_a_Stick (2020-06-20 21:15:08)


Brianna Ghey — Rest In Power

Offline

#13 2020-06-20 21:17:58

rolfie
Member
Registered: 2017-11-25
Posts: 1,047  

Re: EFI trouble

Another update to post #5:
Added EFI/BOOT/ to the efi partition and copied grubx64.efi from Beowulf into there. Rebooted and tried F8 = Boot override: no sign of a /BOOT entry. Just got Win7, ascii and a memory stick that on presented.

rolfie

Offline

#14 2020-06-20 21:23:27

Head_on_a_Stick
Member
From: London
Registered: 2019-03-24
Posts: 3,125  
Website

Re: EFI trouble

rolfie wrote:

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

Last edited by Head_on_a_Stick (2020-06-20 21:24:47)


Brianna Ghey — Rest In Power

Offline

#15 2020-06-20 21:35:39

rolfie
Member
Registered: 2017-11-25
Posts: 1,047  

Re: EFI trouble

You got me, just copied grubx64.efi over. Will rename it and give it another try.

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

Offline

#16 2020-06-20 21:50:52

rolfie
Member
Registered: 2017-11-25
Posts: 1,047  

Re: EFI trouble

Hurrah, after renaming grubx64.efi an additional strange entry is displayed on F8, and it actually boots Beowulf. Thanks for the slab.

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

Offline

#17 2020-06-20 21:53:33

Head_on_a_Stick
Member
From: London
Registered: 2019-03-24
Posts: 3,125  
Website

Re: EFI trouble

rolfie wrote:

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


Brianna Ghey — Rest In Power

Offline

#18 2020-06-21 13:46:49

rolfie
Member
Registered: 2017-11-25
Posts: 1,047  

Re: EFI trouble

Again hurrah, finally got it sorted, its working now. I can boot into Beowulf from the grub in my ASCII installation, despite my bad EFI. 

@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).

Last edited by rolfie (2020-06-21 14:22:13)

Offline

#19 2020-07-01 19:08:00

rolfie
Member
Registered: 2017-11-25
Posts: 1,047  

Re: EFI trouble

Followup on bad EFI memory:

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

Offline

#20 2020-07-01 19:28:23

Head_on_a_Stick
Member
From: London
Registered: 2019-03-24
Posts: 3,125  
Website

Re: EFI trouble

rolfie wrote:

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

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

rolfie wrote:

Is there any safe way to clear the EFI variables?

No, I don't think so.

rolfie wrote:

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?

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

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

Brianna Ghey — Rest In Power

Offline

#21 2020-07-02 02:49:53

Tatwi
Member
From: Canada
Registered: 2018-10-24
Posts: 71  
Website

Re: EFI trouble

I am not sure what you mean by "EFI variables", I'm still living in BIOS land, stumbling through EFI on my laptop... but if you are referring to the entries made in the boot options list, those can be removed using Windows command prompt. This was not obvious to me when the BIOS of my Levovo 100e laptop refused to delete them...

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.

Offline

#22 2020-07-02 07:28:54

Head_on_a_Stick
Member
From: London
Registered: 2019-03-24
Posts: 3,125  
Website

Re: EFI trouble

Tatwi wrote:

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.


Brianna Ghey — Rest In Power

Offline

#23 2020-08-14 15:59:53

Geoff 42
Member
Registered: 2016-12-15
Posts: 461  

Re: EFI trouble

I have also been having some fun with EFI.

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.

Offline

#24 2020-08-16 19:20:15

rolfie
Member
Registered: 2017-11-25
Posts: 1,047  

Re: EFI trouble

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

Geoff 42 wrote:

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.

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

Geoff 42 wrote:

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

Is the directory mounted?

Geoff 42 wrote:

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.

Geoff 42 wrote:

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.

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

Offline

#25 2020-08-16 19:25:34

Head_on_a_Stick
Member
From: London
Registered: 2019-03-24
Posts: 3,125  
Website

Re: EFI trouble

rolfie wrote:
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.


Brianna Ghey — Rest In Power

Offline

Board footer