mirror of
https://git.proxmox.com/git/fwupd
synced 2025-05-11 21:09:23 +00:00
5d7fb6ad88
Some systems remove the BootXXXX entry we add (so we can run fwupdx64.efi) and thus the firmware update does not run. Most commonly this failure is seen with Lenovo systems that call the helpful option 'Boot Order Lock'. Hopefully when we depend on the new kernel bios interface sysfs API in we can check in ->prepare(), not after reboot, but until that we can mark the update failure as transient as the user can actually fix the problem themselves. Fixes https://github.com/fwupd/fwupd/issues/2801
28 lines
673 B
C
28 lines
673 B
C
/*
|
|
* Copyright (C) 2018 Richard Hughes <richard@hughsie.com>
|
|
* Copyright (C) 2015 Peter Jones <pjones@redhat.com>
|
|
*
|
|
* SPDX-License-Identifier: LGPL-2.1+
|
|
*/
|
|
|
|
#pragma once
|
|
|
|
#include <glib.h>
|
|
#include <efivar.h>
|
|
|
|
#include "fu-device.h"
|
|
|
|
typedef enum {
|
|
FU_UEFI_BOOTMGR_FLAG_NONE = 0,
|
|
FU_UEFI_BOOTMGR_FLAG_USE_SHIM_FOR_SB = 1 << 0,
|
|
FU_UEFI_BOOTMGR_FLAG_USE_SHIM_UNIQUE = 1 << 1,
|
|
FU_UEFI_BOOTMGR_FLAG_LAST
|
|
} FuUefiBootmgrFlags;
|
|
|
|
gboolean fu_uefi_bootmgr_verify_fwupd (GError **error);
|
|
gboolean fu_uefi_bootmgr_bootnext (FuDevice *device,
|
|
const gchar *esp_path,
|
|
const gchar *description,
|
|
FuUefiBootmgrFlags flags,
|
|
GError **error);
|