rhboot / fwupdate Goto Github PK
View Code? Open in Web Editor NEWSystem firmware update support for UEFI machines
System firmware update support for UEFI machines
Another review happened in Ubuntu recently (https://bugs.launchpad.net/ubuntu/+source/fwupdate/+bug/1508926/comments/7) and one question was put forward that should be double checked:
fwup_set_up_update() lots of work between final fputc() and fclose() --
does this need fflush(fout); fsync(outfd); before the work?
The remaining items from the review that were applicable are submitted in a pull request here: https://github.com/rhinstaller/fwupdate/pull/45/commits
9669ab0 mentions a bump to version 10, but it was never tagged. Can you add a tag?
This isn't the full security audit we need - and in fact doesn't include the most important efi/ bits at all - but here's a list of stuff from https://bugs.launchpad.net/ubuntu/+source/fwupdate/+bug/1508926/comments/1 that should get addressed:
Hello,
My ESP is mounted as /boot:
max@host % tree /boot
/boot
├── EFI
│ ├── Boot
│ │ └── …
│ ├── Dell
│ │ └── …
│ ├── fwupdate
│ │ ├── fw
│ │ │ └── fwupdate-30cdyM.cap
│ │ └── fwupx64.efi
│ └── systemd
│ └── …
├── initramfs-linux-fallback.img
├── initramfs-linux.img
├── loader
│ ├── entries
│ │ ├── arch.conf
│ │ ├── arch-fallback.conf
│ │ └── arch-save.conf
│ └── loader.conf
└── vmlinuz-linux
EFIDIR is set to "fwupdate" (as show on the tree above).
To make fwupdate work I had to apply the following patch since the ESP mount point is currently hardcoded (see #(58)) :
max@mde-oxalide % diff -Naur fwupdate-8/linux/libfwup.c aaa/linux/libfwup.c
--- fwupdate-8/linux/libfwup.c 2016-08-19 17:03:59.000000000 +0200
+++ aaa/linux/libfwup.c 2017-02-19 15:28:29.726339752 +0100
@@ -688,8 +688,8 @@
{
int ret = -1;
- char shim_fs_path_tmpl[] = "/boot/efi/EFI/"FWUP_EFI_DIR_NAME"/shim";
- char fwup_fs_path_tmpl[] = "/boot/efi/EFI/"FWUP_EFI_DIR_NAME"/fwup";
+ char shim_fs_path_tmpl[] = "/boot/EFI/"FWUP_EFI_DIR_NAME"/shim";
+ char fwup_fs_path_tmpl[] = "/boot/EFI/"FWUP_EFI_DIR_NAME"/fwup";
uint8_t fwup_esp_path_tmpl[] = "\\fwup";
char *shim_fs_path_tmp = NULL;
@@ -1059,7 +1059,7 @@
untilt_slashes(relpath);
/* build a complete path */
- rc = asprintf(&fullpath, "/boot/efi%s", relpath);
+ rc = asprintf(&fullpath, "/boot%s", relpath);
if (rc < 0)
fullpath = NULL;
@@ -1097,7 +1097,7 @@
} else {
/* fall back to creating a new file from scratch */
rc = asprintf(&fullpath,
- "/boot/efi/EFI/%s/fw/fwupdate-XXXXXX.cap",
+ "/boot/EFI/%s/fw/fwupdate-XXXXXX.cap",
FWUP_EFI_DIR_NAME);
if (rc < 0) {
efi_error("asprintf failed");
But it wasn't sufficient, I also had to bypass the get_existing_media_path function as the one which fwupdate try to use wasn't the /boot/EFI/fwupdate/…
.
Can you add an option to make it more easy to bypass get_existing_media_path ?
Regards
Due to this change in fwupd:
https://github.com/hughsie/fwupd/commit/a941c3a9e919cd2ec45067ce14359bdd7404cce2
MINOR_VERSION will need to be incremented to at least 5 to let fwupd still continue to compile.
Jared pulled in 8f8dcbc into the last upload to Debian that synced to Ubuntu. Under Ubuntu, this has failed to build on arm64 and armhf with the following errors:
arm64(https://launchpadlibrarian.net/211678696/buildlog_ubuntu-wily-arm64.fwupdate_0.4-3_BUILDING.txt.gz)
make[3]: Entering directory '/«PKGBUILDDIR»/efi'
gcc -O0 -g3 -fpic -Wall -fshort-wchar -fno-strict-aliasing -fno-merge-constants -ffreestanding -fno-stack-protector -fno-stack-check --std=c11 -DCONFIG_aarch64 -D__KERNEL__ -I/usr/include/efi/ -I/usr/include/efi/aarch64/ -iquote/«PKGBUILDDIR»/include "-DDEBUGDIR=L\"/\"" -ffreestanding -I/usr/lib/gcc/aarch64-linux-gnu/4.9/include -c -o fakeesrt2.o fakeesrt2.c
ld -nostdlib --warn-common --no-undefined --fatal-warnings -shared -Bsymbolic -L/usr/lib -L/usr/lib --build-id=sha1 /usr/lib/crt0-efi-aarch64.o --defsym=EFI_SUBSYSTEM=0xa -o fakeesrt2.so fakeesrt2.o -lefi -lgnuefi \
/usr/lib/gcc/aarch64-linux-gnu/4.9/libgcc.a \
-T elf_aarch64_efi.lds
ld: section .note.gnu.build-id loaded at [0000000000000000,0000000000000023] overlaps section .text loaded at [0000000000000000,000000000000668f]
Makefile:74: recipe for target 'fakeesrt2.so' failed
make[3]: *** [fakeesrt2.so] Error 1
rm fakeesrt2.o
armhf (https://launchpadlibrarian.net/211678705/buildlog_ubuntu-wily-armhf.fwupdate_0.4-3_BUILDING.txt.gz)
make[3]: Entering directory '/«PKGBUILDDIR»/efi'
gcc -O0 -g3 -fpic -Wall -fshort-wchar -fno-strict-aliasing -fno-merge-constants -ffreestanding -fno-stack-protector -fno-stack-check --std=c11 -DCONFIG_arm -D__KERNEL__ -I/usr/include/efi/ -I/usr/include/efi/arm/ -iquote/«PKGBUILDDIR»/include "-DDEBUGDIR=L\"/\"" -ffreestanding -I/usr/lib/gcc/arm-linux-gnueabihf/4.9/include -c -o fakeesrt2.o fakeesrt2.c
ld -nostdlib --warn-common --no-undefined --fatal-warnings -shared -Bsymbolic -L/usr/lib -L/usr/lib --build-id=sha1 /usr/lib/crt0-efi-arm.o --defsym=EFI_SUBSYSTEM=0xa -o fakeesrt2.so fakeesrt2.o -lefi -lgnuefi \
/usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a \
-T elf_arm_efi.lds
ld: section .note.gnu.build-id loaded at [00000000,00000023] overlaps section .text loaded at [00000000,0000647f]
make[3]: *** [fakeesrt2.so] Error 1
Makefile:74: recipe for target 'fakeesrt2.so' failed
rm fakeesrt2.o
It built fine on amd64 and i386.
commit c3429b2 changed the version of efivar that was required to 28, but this doesn't currently exist (even master for efivar is at 27: rhboot/efivar@1429d89)
I recently purchased a Dell XPS 15 9560 and the BIOS version is 0.1.3.4 instead of the current 0.1.4.0 version. I have been trying to run fwupdate/ fwupdmgr to update the BIOS but running it does not seem to do anything
OS: Arch Linux
Kernel: 4.12.12-1-ARCH
fwupdmgr: 0.9.7
efivars: 31-1
efibootmgr: version 15
$ sudo efibootmgr
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001
Boot0000 Windows Boot Manager
Boot0001* Grub
Boot0002* grub
Boot0008 WindowsIns
This does not change upon calling fwupdate or fwupdmgr (no entry for Linux-Firmware-Updater is created)
When running the update commands it will download the correct package and does not seem to exit with any error however nothing happens, upon calling the commands again after it will say that the device already has an update scheduled
Output:
$ sudo fwupdmgr update -v
Downloading 0.1.4.0 for XPS 15 9560 System Firmware...
(fwupdmgr:10145): Fu-DEBUG: creating path /root/.cache/fwupdmgr
(fwupdmgr:10145): Fu-DEBUG: skpping download as file already exists
Updating 0.1.4.0 on XPS 15 9560 System Firmware...
(fwupdmgr:10145): Fwupd-DEBUG: Emitting ::status-changed() [decompressing]
Decompressing… [- ]
Decompressing… [ - ]
Decompressing… [ - ]
(fwupdmgr:10145): Fwupd-DEBUG: Emitting ::status-changed() [idle]
(fwupdmgr:10145): Fwupd-DEBUG: Emitting ::status-changed() [scheduling]
Scheduling… [ - ]
Retrying as an offline update...
(fwupdmgr:10145): Fwupd-DEBUG: Emitting ::status-changed() [decompressing]
Decompressing… [ - ]
Decompressing… [ \ ]
Decompressing… [ \ ]
(fwupdmgr:10145): Fwupd-DEBUG: Emitting ::status-changed() [idle]
(fwupdmgr:10145): Fwupd-DEBUG: Emitting ::status-changed() [scheduling]
Scheduling… [ \ ]
(fwupdmgr:10145): Fwupd-DEBUG: Emitting ::status-changed() [idle]
(fwupdmgr:10145): Fwupd-DEBUG: Emitting ::device-changed((null))
(fwupdmgr:10145): Fwupd-DEBUG: Emitting ::changed()
Note: This did not print correctly on my terminal, I had to pipe it to a file and delete H^ strings in vim
Output fwupdmgr get-devices:
$ sudo fwupdmgr get-devices
Intel AMT (unprovisioned)
DeviceID: /dev/mei
Guid: 2800f812-b7b4-2d4b-aca8-46e0ff65814c
Plugin: amt
Flags: internal|registered
Version: 11.6.29
VersionBootloader: 11.6.29
Created: 2017-09-14
XPS 15 9560 TPM 2.0
DeviceID: DELL-bc891321-25aa-54f6-86e7-633d065b8d5dlu
Guid: bc891321-25aa-54f6-86e7-633d065b8d5d
Plugin: dell
Flags: internal|updatable|require-ac|supported|registered|needs-reboot
Version: 1.3.1.0
Created: 2017-09-14
XPS 15 9560 TPM 1.2
DeviceID: DELL-c5e6d7ef-4270-54bf-af0f-8b8ef2a561e6lu
Guid: c5e6d7ef-4270-54bf-af0f-8b8ef2a561e6
Plugin: dell
Flags: internal|require-ac|locked|registered
Created: 2017-09-14
XPS 15 9560 System Firmware
DeviceID: UEFI-34578c72-11dc-4378-bc7f-b643866f598c-dev0
Guid: 34578c72-11dc-4378-bc7f-b643866f598c
Description: <p>Updating the system firmware improves performance.</p>
Plugin: uefi
Flags: internal|updatable|require-ac|supported|registered|needs-reboot
Version: 0.1.3.4
VersionLowest: 0.1.3.4
Created: 2017-09-14
Integrated Webcam HD
DeviceID: usb:00:0c
Guid: 4c03e6af-b94c-5c18-8689-e77ceadbe524
Guid: fb0df457-b15e-5d4a-b73a-8491dca96a07
Plugin: usb
Flags: registered
DeviceVendorId: USB:0x0C45
Version: 86.5
Created: 2017-09-14
GP107M [GeForce GTX 1050 Mobile]
DeviceID: ro__sys_devices_pci0000_00_0000_00_01_0_0000_01_00_0
Guid: 37921484-dff0-57a0-b7dd-4cd6a82b54a1
Plugin: udev
Flags: internal|registered
DeviceVendor: NVIDIA Corporation
DeviceVendorId: PCI:0x10DE
Created: 2017-09-14
Unknown Device
DeviceID: ro__sys_devices_pci0000_00_0000_00_02_0
Guid: 3ab5fe9e-bef7-5421-920a-ef7301884933
Plugin: udev
Flags: internal|registered
DeviceVendor: Intel Corporation
DeviceVendorId: PCI:0x8086
Created: 2017-09-14
The XPS 15 9560 System Firmware with GUID: 34578c72-11dc-4378-bc7f-b643866f598c is the device which requires updating
And applying it manually through fwupdate outputs this:
$ sudo fwupdate -a 34578c72-11dc-4378-bc7f-b643866f598c ~/.cache/fwupdmgr/5b8e9cbc79dd4f37df0f792196f246d9b7da1e0d-firmware_XPS_9560_1_4_0.wu.cab -v
Could not set up firmware update: No such file or directory
error trace:
efivarfs.c:230 efivarfs_get_variable(): open(/sys/firmware/efi/efivars/fwupdate-34578c72-11dc-4378-bc7f-b643866f598c-0-0abba7dc-e516-4167-bbf5-4d9d1c739416): No such file or directory
lib.c:152 efi_get_variable(): ops->get_variable failed: No such file or directory
efivarfs.c:230 efivarfs_get_variable(): open(/sys/firmware/efi/efivars/fwupdate-34578c72-11dc-4378-bc7f-b643866f598c-0-0abba7dc-e516-4167-bbf5-4d9d1c739416): No such file or directory
lib.c:152 efi_get_variable(): ops->get_variable failed: No such file or directory
libfwup.c:1194 get_fd_and_media_path(): failed to make /boot/efi/EFI/arch/fw: No such file or directory
If I have missed any important information please let me know and I will provide the details
I had a failure installing firmware update 0.2.2.1:
https://bugzilla.redhat.com/show_bug.cgi?id=1506609
Now there is a 0.2.3.1 update available, but it tries to use the old checksum for it:
XPS 13 9360 System Firmware has firmware updates:
ID: com.dell.uefi5ffdbc0d.firmware
GUID: 5ffdbc0d-f340-441c-a803-8439c8c0ae10
Update Version: 0.2.3.1
Update Remote ID: lvfs
Update Checksum: SHA1(52b875e4eab8bf4c384861b9cd878c62e8fc899f)
Update Checksum: SHA1(18d9501fc82e8c39acb57693e2c6ad60a2712f9a)
Update Location: https://fwupd.org/downloads/6fd391badc79a4d9a2c9916073f6941f885a22fd-firmware_XPS_9360_2_3_1.cab
In order to support updating multiple PCI-style peripheral cards of the same model independently, and really to support PCI cards at all, we need to be able to express which FMP entry should be updated in the fwupdate EFI variables, and fwupdate.efi needs to know to use FMP with those updates.
This is on Ubuntu 16.04 with it's current default compile flags and master. -O2
is used instead of -O0
gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -fpic -Werror -Wall -Wextra -fshort-wchar -fno-merge-constants -ffreestanding -fno-stack-protector -fno-stack-check --std=gnu11 -DCONFIG_x86_64 -I/usr/include/efi/ -I/usr/include/efi/x86_64/ -iquote/home/test/fwupdate/include "-DDEBUGDIR=L\"/\"" -mno-mmx -mno-sse -mno-red-zone -nostdinc -maccumulate-outgoing-args -DEFI_FUNCTION_WRAPPER -DGNU_EFI_USE_MS_ABI -I/usr/lib/gcc/x86_64-linux-gnu/5/include -c -o fwupdate.o fwupdate.c
fwupdate.c: In function ‘open_file’:
fwupdate.c:584:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
UINTN sz = *(UINT16 *)file_dp->Length - 4;
^
cc1: all warnings being treated as errors
Makefile:90: recipe for target 'fwupdate.o' failed
These were masked previously but 84dae17 added -Werror
so this causes a failure now.
We need to be able to tell if for some reason fwupdate did not get run, and IEIT will tell us that.
We probably want to do something like:
enable_esrt() -> fwup_esrt_enable()
esrt_disabled() -> fwup_esrt_is_disabled()
Otherwise it's quite confusing where these symbols are coming from...
It would be really useful to have something like this in fwup.h: https://github.com/hughsie/fwupd/blob/master/libfwupd/fwupd-version.h.in -- this way I can #ifdef the new things without having to rely on configure.ac checks.
the path to fwupdate.efi needs to be arch specific, and we need to determine the correct arch at /runtime/ for things like baytrail.
So that fwupd can use it (per a discussion somewhere in https://github.com/hughsie/fwupd/pull/226)
This issue is in similar vain to rhboot/efivar#20.
I've noticed that the fwupdate build process isn't explicitly linking to libraries containing functions necessary for use. This causes problems when building on Ubuntu.
gcc -g -O0 -Wall -Wno-unused-result -Wno-unused-function -Wsign-compare -Werror=sign-compare -fshort-wchar --std=c11 -DLOCALEDIR=\"/usr/share//locale/\" -D_GNU_SOURCE -DFWUP_EFI_DIR_NAME=\"Ubuntu\" -I/home/supermario/src/efi-fw-packages/fwupdate/linux/include -iquote/home/supermario/src/efi-fw-packages/fwupdate/include/ -I/usr/include/efivar -I/usr/include/efivar -lpopt -lpthread -ldl -lefivar -ldl -lefivar -lefiboot -pie -fPIE -Wl,-z,relro,-z,now -L. -o fwupdate fwupdate.o -lfwup
fwupdate.o: In function `efi_guid_is_zero':
/usr/include/efivar/efivar.h:141: undefined reference to `efi_guid_zero'
fwupdate.o: In function `print_system_resources':
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:96: undefined reference to `efi_guid_to_id_guid'
fwupdate.o: In function `main':
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:132: undefined reference to `poptAliasOptions'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:132: undefined reference to `poptHelpOptions'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:151: undefined reference to `poptGetContext'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:154: undefined reference to `poptReadDefaultConfig'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:156: undefined reference to `poptStrerror'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:156: undefined reference to `poptBadOption'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:159: undefined reference to `poptGetNextOpt'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:164: undefined reference to `poptGetArg'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:167: undefined reference to `poptPrintUsage'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:170: undefined reference to `efi_str_to_guid'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:174: undefined reference to `poptGetArg'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:178: undefined reference to `poptPrintUsage'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:185: undefined reference to `poptStrerror'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:185: undefined reference to `poptBadOption'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:188: undefined reference to `poptPeekArg'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:189: undefined reference to `poptPeekArg'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:194: undefined reference to `poptPrintUsage'
/home/supermario/src/efi-fw-packages/fwupdate/linux/fwupdate.c:197: undefined reference to `poptFreeContext'
./libfwup.so: undefined reference to `efi_loadopt_is_valid'
./libfwup.so: undefined reference to `efidp_make_generic'
./libfwup.so: undefined reference to `efi_generate_file_device_path'
./libfwup.so: undefined reference to `efi_guid_global'
./libfwup.so: undefined reference to `efi_loadopt_create'
./libfwup.so: undefined reference to `efi_loadopt_path'
./libfwup.so: undefined reference to `efi_get_next_variable_name'
./libfwup.so: undefined reference to `efi_set_variable'
./libfwup.so: undefined reference to `efi_loadopt_pathlen'
./libfwup.so: undefined reference to `efi_get_variable'
./libfwup.so: undefined reference to `efi_loadopt_attr_set'
./libfwup.so: undefined reference to `efi_guid_to_str'
collect2: error: ld returned 1 exit status
make[3]: *** [fwupdate] Error 1
There's a few errors here.
fwupdate 0.5 was working properly on this system.
I bisected:
git bisect start
# bad: [c5fabccbea56e8c9f99efafe5c985c854e110513] fwupdate: Use libsmbios_c.pc instead of manually writing our command line.
git bisect bad c5fabccbea56e8c9f99efafe5c985c854e110513
# good: [03178919675d277178dc50c7c8941a9fd91e98ef] Release 0.5
git bisect good 03178919675d277178dc50c7c8941a9fd91e98ef
# good: [03178919675d277178dc50c7c8941a9fd91e98ef] Release 0.5
git bisect good 03178919675d277178dc50c7c8941a9fd91e98ef
# bad: [742ebb4ef1676467a36b846b9cd54b0a3b6d9756] Make our CFLAGS even meaner.
git bisect bad 742ebb4ef1676467a36b846b9cd54b0a3b6d9756
# good: [827a9dc84c4f1f866982b38b1c0a77abb2265754] fwupdate: support showing the info of fwupdate status variable
git bisect good 827a9dc84c4f1f866982b38b1c0a77abb2265754
# bad: [3674fec025e5be54e91ff14c26c67f5c1293da9f] efi: document our use of UINTN vs INTN comparison in get_info()
git bisect bad 3674fec025e5be54e91ff14c26c67f5c1293da9f
# bad: [47f65e83dda4ea558b13d6bd3eb0fab7e5005a93] efi: check for size overflow in read_file()
git bisect bad 47f65e83dda4ea558b13d6bd3eb0fab7e5005a93
# good: [172f8b3d5d3a2b103b5dc9bd502ade6296e3294d] efi: Get rid of -fno-strict-aliasing
git bisect good 172f8b3d5d3a2b103b5dc9bd502ade6296e3294d
# first bad commit: [47f65e83dda4ea558b13d6bd3eb0fab7e5005a93] efi: check for size overflow in read_file()
The results yielded two commits causing problems
1st: 47f65e8
2nd: a49f4ff
With both commits applied, this is the error received:
fwupdate.c:find_updates();290: would overflow size
fwupdate: Couldnot find updates: Out of Resources
With a49f4ff reverted, this is the error received:
Found update fwupdate-*
Update "fwupdate-*" has an invalid file path
update info size 172 dp size: 120 size for dp: 52
Could not get update info for "fwupdate-*", aborting
fwupdate: Could not find updates: Invalid Paramater
Reverting both isn't enough to resolve the problem, so bc3f523
probably needs to be removed too and there is definitely systemic about this overflow detection
wrong on this system. FWIW running the same fwupx64.efi binary in Virtualbox through EFI shell
reproduces the issues too.
I've originally reported this over at https://github.com/hughsie/fwupd/issues/152 and with continued research think this is a better place for it.
I've applied two firmware updates using gnome software centre, but now the laptop is unbootable. How can I fix this?
It's got #define LIBFWUP_VERSION (@FWUP_VERSION@)
as in, it installs it into /usr/include without replacing the @FWUP_VERSION@
string with the actual version.
I triggered the update with Gnome Software on Ubuntu 17.10. Gnome Software asked me to restart, I click restart. During boot, the update starts correctly, and succeeds. After it succeeds, the laptop boots back into fwupd, which fails with the following error:
found update fwupdate-49w03513-7afe-49a-9d03-89e5ba1da865-0
fwupdate: No updates to process. Called in error?
start_image() returned Invalid Parameter
After a few seconds, it shows another screen:
No bootable devices found.
Press F1 key to retry boot.
Press F2 key to reboot into setup.
Press F5 key to run onboard diagnostics.
I was able to workaround the issue by going into setup
, general > Boot Sequence
, and adding grub64.efi
back as primary boot option.
Picture walkthrough:
When you see this message, press F2 to enter the UEFI/BIOS setup.
Once in the setup, go to general > Boot Sequence
.
Click Add boot option
.
Call the boot option "Ubuntu" and click the three dots behind "filename".
Choose the "grubx64.efi" file, click OK and add the boot option.
Now use the arrows to put the "Ubuntu" boot option to the top.
Save and exit, reboot and Ubuntu boots as normal!
It's been brought to my attention that some UEFI implementations will potentially overwrite any Boot#### variables that are not present in BootOrder during bootup.
Because of this, we've seen some scenarios that entries are overwritten by built-in entries as the UEFI boot manager would reshuffle them on boot-up. Putting the entries into BootOrder will prevent this from happening.
So I'd to propose that fwupdate does the following:
In the Linux application
In the EFI application
The net result should be that whenever a FW update is staged the entry will be created and placed in the BootOrder. This should allow it to also show up in the one time boot menu.
When the update has ran (successfully or not) the entry would be cleaned up and not show in one time boot menu.
A future capsule update would perform the same steps again.
Commit e3b443d introduces a regression if existing variables are around from a previous fwupdate run.
$ ls /sys/firmware/efi/efivars/fwupdate-e0f614ed-fb82-467a-a34e-71172cc07e4d-0-0abba7dc-e516-4167-bbf5-4d9d1c739416
/sys/firmware/efi/efivars/fwupdate-e0f614ed-fb82-467a-a34e-71172cc07e4d-0-0abba7dc-e516-4167-bbf5-4d9d1c739416
$ fwupdate -a `cat /sys/firmware/efi/esrt/entries/entry0/fw_class` firmware_0.3.1.cap // cause a segment fault
$ rm /sys/firmware/efi/efivars/fwupdate-e0f614ed-fb82-467a-a34e-71172cc07e4d-0-0abba7dc-e516-4167-bbf5-4d9d1c739416
$ fwupdate -a `cat /sys/firmware/efi/esrt/entries/entry0/fw_class` firmware_0.3.1.cap // successful
@vathpela added these strict compile flags recently, but they actually cause the build to fail, on Fedora Rawhide at least. Here's a build of current git master on Fedora Rawhide:
https://kojipkgs.fedoraproject.org//work/tasks/2875/15232875/build.log
gcc -O0 -g3 -fpic -Werror -Wall -Wextra -fshort-wchar -fno-merge-constants -ffreestanding -fno-stack-protector -fno-stack-check --std=gnu11 -DCONFIG_ia32 -I/usr/include/efi/ -I/usr/include/efi/ia32/ -iquote/builddir/build/BUILD/fwupdate-0.5/include "-DDEBUGDIR=L\"/\"" -mno-mmx -mno-sse -mno-red-zone -nostdinc -maccumulate-outgoing-args -m32 -I/usr/lib/gcc/i686-redhat-linux/6.1.1/include -c -o fwupdate.o fwupdate.c
fakeesrt.c: In function 'efi_main':
fakeesrt.c:50:14: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
VOID *ptr = (VOID *)mem;
^
fwupdate.c: In function 'allocate':
fwupdate.c:74:10: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
*addr = (void *)pageaddr;
^
In file included from /usr/include/efi/efi.h:35:0,
from fwupdate.c:11:
fwupdate.c: In function 'free':
fwupdate.c:87:43: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
rc = uefi_call_wrapper(BS->FreePages, 2, (EFI_PHYSICAL_ADDRESS)addr,
^
/usr/include/efi/ia32/efibind.h:283:51: note: in definition of macro 'uefi_call_wrapper'
#define uefi_call_wrapper(func, va_num, ...) func(__VA_ARGS__)
^~~~~~~~~~~
fwupdate.c: In function 'apply_capsules':
fwupdate.c:753:11: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
(EFI_PHYSICAL_ADDRESS)(VOID *)cbd);
^
/usr/include/efi/ia32/efibind.h:283:51: note: in definition of macro 'uefi_call_wrapper'
#define uefi_call_wrapper(func, va_num, ...) func(__VA_ARGS__)
^~~~~~~~~~~
cc1: all warnings being treated as errors
Makefile:92: recipe for target 'fakeesrt.o' failed
Before the commit to add -Werror -Wextra
, the same warnings are present but they do only act as warnings and the compile succeeds.
During make
on ArchLinux:
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -DFWUPDATE_HAVE_LIBSMBIOS__ -Wall -Wextra -Werror -Wno-error=cpp -Wno-unused-result -Wno-unused-function -Wsign-compare -Werror=sign-compare -fshort-wchar --std=gnu11 -DLOCALEDIR=\"/usr/share/locale\" -D_GNU_SOURCE -DFWUP_EFI_DIR_NAME=\"arch\" -DFWUP_ESP_MOUNTPOINT=\""/boot/efi"\" -I include -I /build/fwupdate/src/fwupdate-10/linux/include/ -iquote /build/fwupdate/src/fwupdate-10/include/ -I/usr/include/efivar -I/usr/include/efivar -fPIC -c -o libfwup.o libfwup.c
xgettext -a --package-name=libfwup --package-version=10 -o libfwup.po libfwup.c
libfwup.c: In function ‘make_ux_capsule_entry’:
libfwup.c:733:30: error: ‘efi_guid_ux_capsule’ undeclared (first use in this function); did you mean ‘efi_guid_ux_capsule_guid’?
fwup_ux_capsule.esre.guid = efi_guid_ux_capsule;
^~~~~~~~~~~~~~~~~~~
efi_guid_ux_capsule_guid
libfwup.c:733:30: note: each undeclared identifier is reported only once for each function it appears in
libfwup.c: In function ‘write_ux_capsule_header’:
libfwup.c:1648:11: error: ‘efi_guid_ux_capsule’ undeclared (first use in this function); did you mean ‘efi_guid_ux_capsule_guid’?
.guid = efi_guid_ux_capsule,
^~~~~~~~~~~~~~~~~~~
efi_guid_ux_capsule_guid
libfwup.c: In function ‘fwup_set_up_update’:
libfwup.c:1795:37: error: ‘efi_guid_ux_capsule’ undeclared (first use in this function); did you mean ‘efi_guid_ux_capsule_guid’?
if (!efi_guid_cmp(&re->esre.guid, &efi_guid_ux_capsule)) {
^~~~~~~~~~~~~~~~~~~
efi_guid_ux_capsule_guid
libfwup.c: In function ‘fwup_set_up_update_with_buf’:
libfwup.c:1899:37: error: ‘efi_guid_ux_capsule’ undeclared (first use in this function); did you mean ‘efi_guid_ux_capsule_guid’?
if (!efi_guid_cmp(&re->esre.guid, &efi_guid_ux_capsule)) {
^~~~~~~~~~~~~~~~~~~
efi_guid_ux_capsule_guid
make[1]: *** [/build/fwupdate/src/fwupdate-10/linux/Makefile:90: libfwup.o] Error 1
make[1]: *** Waiting for unfinished jobs....
Hi,
I'm testing this on a future platform. I'm noticing that the boot entry isn't getting created even if the tool successfully exits 0 on Linux. It doesn't show up in efibootmgr output or in the F12 boot menu on the system.
It does stage efi$distro\fw\fwupdate-x0XphZ.cap on the disk though.
Ignoring that first problem (can be solved later unless it's related I guess), I tried to launch fwupdate from EFI shell.
Here's the output I got:
fs0:\ > fwupdate.efi
Found update fwupdate-6180aaaa-5529-4bb4-b4fd-65b4f788de5b-0
Could not locate device handle: Not Found.
fwupdate: Could not build update list: Not Found
Hi I'm currently struggling to use fwupdate due to the location of my efi partition. I have it mounted to /esp as FAT32 and /boot is a bind mount to /esp/EFI/arch. Due to it being fat32 I can't do a symlink to support fwupdate's expected folder structure. The exact process for bind mounts is shown here: https://wiki.archlinux.org/index.php/EFI_System_Partition#Using_bind_mount
and isn't too uncommon in the arch community. Would you please look at supporting alternative mount pounts.
Thanks! :)
efi/Makefile tries to prepare .so files by linking using $(LD), which breaks here.
Some distributions may set LDFLAGS with -Wl parameters intended for linking through $(CC).
For instance, in Ubuntu we set -Wl,-Bsymbolic-functions, which breaks linking because $(LD) will refuse to parse those directly -- it should be just -Bsymbolic-functions.
This should work properly if linking via $(CC), passing the -shared parameter like so:
rather than:
Thanks!
Is there any public documentation on how to update a Lenovo (Thinkpad) UEFI with fwupdate?
The vendorlist show it as supported.
Also my Firmware update release notes mention fixes in the WUFU compatability.
Furthermore the update package from Lenovo itself contains strings that indicate that some sort of support should exist:
Found fwupdate variable, set as Linux WUFU (fwupd) triggered capsule update.
Delete fwupdate variable successfully.
However I could not find any public documentation about this.
Sorry if this was the wrong place to ask.
I have code here: https://github.com/rhboot/fwupdate/tree/ux-capsule
It looks (to me) like it should work, but when I apply an update that includes the UX capsule in the list, the machine just reboots without applying any updates.
@superm1 , can I get a bit of help here?
I think the open() at line 820 in libfwup.c is missing a 0 (or some other mode) as third parameter.
make[3]: Leaving directory '/home/mtrudel/workspace/ubuntu/build-area/fwupdate-0.4+git20151015.081427/efi'
make[3]: Entering directory '/home/mtrudel/workspace/ubuntu/build-area/fwupdate-0.4+git20151015.081427/linux'
gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-unused-result -Wno-unused-function -Wsign-compare -Werror=sign-compare -fshort-wchar --std=c11 -DLOCALEDIR="/usr/share//locale/" -D_GNU_SOURCE -DFWUP_EFI_DIR_NAME="ubuntu" -I/home/mtrudel/workspace/ubuntu/build-area/fwupdate-0.4+git20151015.081427/linux/include -iquote/home/mtrudel/workspace/ubuntu/build-area/fwupdate-0.4+git20151015.081427/include/ -I/usr/include/efivar -I/usr/include/efivar -fPIC -c -o libfwup.o libfwup.c
In file included from /usr/include/fcntl.h:279:0,
from util.h:14,
from libfwup.c:27:
In function ‘open’,
inlined from ‘get_fd_and_media_path’ at libfwup.c:820:6:
/usr/include/x86_64-linux-gnu/bits/fcntl2.h:50:4: error: call to ‘__open_missing_mode’ declared with attribute error: open with O_CREAT in second argument needs 3 arguments
__open_missing_mode ();
^
libfwup.c: In function ‘fwup_set_up_update’:
libfwup.c:1007:2: warning: ‘offset’ may be used uninitialized in this function [-Wmaybe-uninitialized]
lseek(infd, offset, SEEK_SET);
^
Makefile:59: recipe for target 'libfwup.o' failed
linux/libfwup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/linux/libfwup.c
+++ b/linux/libfwup.c
@@ -817,7 +817,7 @@ get_fd_and_media_path (update_info *info
* littering the filesystem with old updates */
fullpath = fwup_get_existing_media_path (info);
if (fullpath) {
fd = open(fullpath, O_CREAT|O_TRUNC|O_CLOEXEC|O_RDWR);
fd = open(fullpath, O_CREAT|O_TRUNC|O_CLOEXEC|O_RDWR, 0);
if (fd < 0) {
warn("open of %s failed", fullpath);
goto out;
Trying to use fwupdate on a machine running RHEL, I got:
# fwupdate -a 34578c72-11dc-4378-bc7f-b643866f598c firmware.cap
Could not set up firmware update: No such file or directory
Using strace to find out which path caused the error:
open("/boot/efi/EFI/fedora/fw/fwupdate-yML5Cm.cap", O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0600) = -1 ENOENT (No such file or directory)
write(2, "Could not set up firmware update", 32Could not set up firmware update) = 32
The "/boot/efi/EFI/fedora" path doesn't make much sense since the machine is running RHEL.
There is this fwupdate variable which may be causing the bug since it contains a "fedora" path, likely from an earlier attempt to use fwupdate on this machine.
# hexdump -C /sys/firmware/efi/efivars/fwupdate-34578c72-11dc-4378-bc7f-b643866f598c-0-0abba7dc-e516-4167-bbf5-4d9d1c739416
00000000 07 00 00 00 07 00 00 00 72 8c 57 34 dc 11 78 43 |........r.W4..xC|
00000010 bc 7f b6 43 86 6f 59 8c 00 00 02 00 00 00 00 00 |...C.oY.........|
00000020 00 00 00 00 e1 07 04 0c 11 01 1e 00 00 00 00 00 |................|
00000030 ff 07 00 00 02 00 00 00 04 01 2a 00 01 00 00 00 |..........*.....|
00000040 00 08 00 00 00 00 00 00 00 a0 0f 00 00 00 00 00 |................|
00000050 92 a4 82 63 f4 d9 af 42 a7 9d 9a ed 2b 49 4b 8b |...c...B....+IK.|
00000060 02 02 04 04 4a 00 5c 00 45 00 46 00 49 00 5c 00 |....J.\.E.F.I.\.|
00000070 66 00 65 00 64 00 6f 00 72 00 61 00 5c 00 66 00 |f.e.d.o.r.a.\.f.|
00000080 77 00 5c 00 66 00 77 00 75 00 70 00 64 00 61 00 |w.\.f.w.u.p.d.a.|
00000090 74 00 65 00 2d 00 79 00 4d 00 4c 00 35 00 43 00 |t.e.-.y.M.L.5.C.|
000000a0 6d 00 2e 00 63 00 61 00 70 00 00 00 7f ff 04 00 |m...c.a.p.......|
000000b0
Removing the variable fixed the error and I was able to run fwupdate.
We need to support HD() abbreviated paths plus any of the networking ones.
This would have stopped #4 from having any effect.
In trying to debug #4, I was walking through the code and found an inconsistency for adding Boot#### variables compared to efibootmgr.
Variables are getting added using the same GUID that corresponds to BootNext rather than the EFI Global GUID.
This patch fixes the behavior (and entries start to show up in efibootmgr):
commit e632b671466df50da60213493fd81aebba7f527b
Author: Mario Limonciello <[email protected]>
Date: Fri Jul 10 13:52:00 2015 -0500
When adding a Boot#### entry it should be the global GUID not the GUID
that was found for the BootNext variable.
diff --git a/linux/libfwup.c b/linux/libfwup.c
index 860505d..0ccd88e 100644
--- a/linux/libfwup.c
+++ b/linux/libfwup.c
@@ -694,7 +694,7 @@ do_next:
goto out;
sprintf(boot_next_name, "Boot%04X", boot_next);
- rc = efi_set_variable(*guid, boot_next_name, opt, opt_size,
+ rc = efi_set_variable(efi_guid_global, boot_next_name, opt, opt_size,
EFI_VARIABLE_NON_VOLATILE |
EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS);
I think an unconditional 5 second delay before rebooting would be a really good thing to have. It's not like updating the firmware is in the fast path, and it would be reassuring to see (and read) any success or failure messages on the console.
Following up on Richard's request to bring the G+ discussion to the tracker.
I would like to start a discussion around the packaging of assets in /boot
, as well as dynamic discovery of where /boot
really is.
Specifically, in Solus packaging, it is illegal for any package to ship files in /boot
. For UEFI systems we automatically mount the ESP to /boot
using the freedesktop bootloader specification (as we use systemd-boot), perform any updates, sync, and unmount again. With that said we'll automatically discover if /boot
is actually mounted (i.e. getmntent
) and leave it mounted if this is how the users system is configured.
In an ideal world, fwupdate would automatically discover the ESP, and as appropriate push the blobs (safely + sanely) into the ESP, respecting the various plagues of issues known to FAT on Linux (case ignorance, atomic writes, dangers of overwriting, requirement to sync) to facilitate integration with standard update procedures.
For an example of interacting with the freedesktop bootloader specification, please see the clr-boot-manager work. Note even in clr-boot-manager we still looked to see if the ESP was mounted at /boot
(simple example) to locate a valid boot mount before falling back to var probing (because as we all know, firmware can and will suck.)
So in short, if approved, I'd like to implement:
Before I go gung-ho on writing code, I'd like to see a conversation around this so its either rejected/approved, but either way, everyone would at least be on the same page. Cheers!
The generated fwupdate status variable contains an invalid device path on my DELL SLA board. On this board, an USB key (/dev/sdb) and SSD(/dev/sda) are attached. Two drives all uses the first partition as ESP (MBR scheme not GPT). See the infos below.
# fdisk -l /dev/sda
Disk /dev/sda: 29.8 GiB, 32017047552 bytes, 62533296 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5078fe0f
Device Boot Start End Blocks Id System
/dev/sda1 63 273104 136521 e W95 FAT16 (LBA)
# fdisk -l /dev/sdb
Disk /dev/sdb: 7.5 GiB, 8004304896 bytes, 15633408 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x59c88c89
Device Boot Start End Blocks Id System
/dev/sdb1 2048 264191 131072 c W95 FAT32 (LBA)
/dev/sdb2 264192 6555647 3145728 83 Linux
/dev/sdb3 6555648 12847103 3145728 83 Linux
/dev/sdb4 12847104 15633407 1393152 83 Linux
# mount | grep sd
/dev/sdb2 on / type ext3 (rw,relatime,errors=continue,user_xattr,barrier=1,data=ordered)
/dev/sdb4 on /media/sdb4 type ext3 (rw,relatime,sync,errors=continue,user_xattr,barrier=1,data=ordered)
/dev/sdb3 on /media/sdb3 type ext3 (rw,relatime,sync,errors=continue,user_xattr,barrier=1,data=ordered)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/sdb1 on /mnt type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
# rm -f /sys/firmware/efi/efivars/BootNext* /sys/firmware/efi/efivars/fwupdate* /sys/firmware/efi/efivars/Boot0000*
# hexdump -C fwupdate-e0f614ed-fb82-467a-a34e-71172cc07e4d-0-0abba7dc-e516-4167-bbf5-4d9d1c739416
00000000 07 00 00 00 07 00 00 00 ed 14 f6 e0 82 fb 7a 46 |..............zF|
00000010 a3 4e 71 17 2c c0 7e 4d 00 00 00 00 00 00 00 00 |.Nq.,.~M........|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 01 00 00 00 02 01 0c 00 d0 41 03 0a |.............A..|
00000040 00 00 00 00 01 01 06 00 00 13 03 12 0a 00 00 00 |................|
00000050 ff ff 00 00 04 01 2a 00 01 00 00 00 00 20 00 00 |......*...... ..|
00000060 00 00 00 00 00 20 00 00 00 00 00 00 6a a5 3a ce |..... ......j.:.|
00000070 5b 51 37 49 a1 f2 b5 a1 a8 e6 f4 74 02 02 04 04 |[Q7I.......t....|
00000080 46 00 5c 00 45 00 46 00 49 00 5c 00 64 00 65 00 |F.\.E.F.I.\.d.e.|
00000090 6c 00 6c 00 5c 00 66 00 77 00 5c 00 66 00 77 00 |l.l.\.f.w.\.f.w.|
000000a0 75 00 70 00 64 00 61 00 74 00 65 00 2d 00 64 00 |u.p.d.a.t.e.-.d.|
000000b0 38 00 42 00 34 00 5a 00 63 00 2e 00 63 00 61 00 |8.B.4.Z.c...c.a.|
000000c0 70 00 00 00 7f ff 04 00 |p.......|
000000c8
# # hexdump -C BootNext*
00000000 07 00 00 00 00 00 |......|
00000006
# hexdump -C Boot0000*
00000000 07 00 00 00 01 00 00 00 60 00 4c 00 69 00 6e 00 |........`.L.i.n.|
00000010 75 00 78 00 20 00 46 00 69 00 72 00 6d 00 77 00 |u.x. .F.i.r.m.w.|
00000020 61 00 72 00 65 00 20 00 55 00 70 00 64 00 61 00 |a.r.e. .U.p.d.a.|
00000030 74 00 65 00 72 00 00 00 04 01 2a 00 01 00 00 00 |t.e.r.....*.....|
00000040 00 20 00 00 00 00 00 00 00 20 00 00 00 00 00 00 |. ....... ......|
00000050 6a a5 3a ce 5b 51 37 49 a1 f2 b5 a1 a8 e6 f4 74 |j.:.[Q7I.......t|
00000060 02 02 04 04 32 00 5c 00 45 00 46 00 49 00 5c 00 |....2.\.E.F.I.\.|
00000070 64 00 65 00 6c 00 6c 00 5c 00 66 00 77 00 75 00 |d.e.l.l.\.f.w.u.|
00000080 70 00 64 00 61 00 74 00 65 00 2e 00 65 00 66 00 |p.d.a.t.e...e.f.|
00000090 69 00 00 00 7f ff 04 00 |i.......|
00000098
# ls /dev/disk/by-uuid/ -l
total 0
lrwxrwxrwx 1 root root 10 Oct 15 02:55 1f66bb01-dfcb-4e84-abff-d873016bde4e -> ../../sdb4
lrwxrwxrwx 1 root root 10 Oct 15 02:55 2ef3b596-392d-43e2-9ca3-00fd747c14a3 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Oct 15 02:56 561D-FFCC -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 15 02:55 AE67-7F11 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Oct 15 02:55 f16d9979-60e3-48a6-abf5-d9505faf8fa1 -> ../../sdb3
# ls /dev/disk/
by-id by-path by-uuid
# ls -l /sys/dev/block/
total 0
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:0 -> ../../devices/virtual/block/ram0
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:1 -> ../../devices/virtual/block/ram1
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:10 -> ../../devices/virtual/block/ram10
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:11 -> ../../devices/virtual/block/ram11
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:12 -> ../../devices/virtual/block/ram12
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:13 -> ../../devices/virtual/block/ram13
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:14 -> ../../devices/virtual/block/ram14
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:15 -> ../../devices/virtual/block/ram15
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:2 -> ../../devices/virtual/block/ram2
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:3 -> ../../devices/virtual/block/ram3
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:4 -> ../../devices/virtual/block/ram4
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:5 -> ../../devices/virtual/block/ram5
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:6 -> ../../devices/virtual/block/ram6
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:7 -> ../../devices/virtual/block/ram7
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:8 -> ../../devices/virtual/block/ram8
lrwxrwxrwx 1 root root 0 Oct 15 02:55 1:9 -> ../../devices/virtual/block/ram9
lrwxrwxrwx 1 root root 0 Oct 15 02:55 7:0 -> ../../devices/virtual/block/loop0
lrwxrwxrwx 1 root root 0 Oct 15 02:55 7:1 -> ../../devices/virtual/block/loop1
lrwxrwxrwx 1 root root 0 Oct 15 02:55 7:2 -> ../../devices/virtual/block/loop2
lrwxrwxrwx 1 root root 0 Oct 15 02:55 7:3 -> ../../devices/virtual/block/loop3
lrwxrwxrwx 1 root root 0 Oct 15 02:55 7:4 -> ../../devices/virtual/block/loop4
lrwxrwxrwx 1 root root 0 Oct 15 02:55 7:5 -> ../../devices/virtual/block/loop5
lrwxrwxrwx 1 root root 0 Oct 15 02:55 7:6 -> ../../devices/virtual/block/loop6
lrwxrwxrwx 1 root root 0 Oct 15 02:55 7:7 -> ../../devices/virtual/block/loop7
lrwxrwxrwx 1 root root 0 Oct 15 02:55 8:0 -> ../../devices/pci0000:00/0000:00:13.0/ata1/host0/target0:0:0/0:0:0:0/block/sda
lrwxrwxrwx 1 root root 0 Oct 15 02:55 8:1 -> ../../devices/pci0000:00/0000:00:13.0/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1
lrwxrwxrwx 1 root root 0 Oct 15 02:55 8:16 -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb
lrwxrwxrwx 1 root root 0 Oct 15 02:55 8:17 -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb/sdb1
lrwxrwxrwx 1 root root 0 Oct 15 02:55 8:18 -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb/sdb2
lrwxrwxrwx 1 root root 0 Oct 15 02:55 8:19 -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb/sdb3
lrwxrwxrwx 1 root root 0 Oct 15 02:55 8:20 -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb/sdb4
# echo -e -n "\x07\x00\x00\x00\x01" > /sys/firmware/efi/efivars/SHIM_DEBUG-605dab50-e046-4300-abb6-3dd810dd8b23
After reboot, the fwupdate.efi is not launched at all. To work around this issue, I made such a patch and it works well:
static EFI_STATUS
+search_file(EFI_DEVICE_PATH **file_dp, EFI_FILE_HANDLE *fh)
+{
+ EFI_DEVICE_PATH *dp, *parent_dp;
+ EFI_GUID sfsp = SIMPLE_FILE_SYSTEM_PROTOCOL;
+ EFI_GUID dpp = DEVICE_PATH_PROTOCOL;
+ EFI_HANDLE *devices;
+ UINTN i, n_handles, count;
+ EFI_STATUS rc;
+
+ rc = uefi_call_wrapper(BS->LocateHandleBuffer, 5, ByProtocol, &sfsp, NULL,
+ &n_handles, &devices);
+ if (EFI_ERROR(rc)) {
+ Print(L"Could not find handles.\n");
+ return rc;
+ }
+
+ dp = *file_dp;
+
+ if (debugging)
+ Print(L"Searching Device Path: %s ...\n", DevicePathToStr(dp));
+
+ parent_dp = DuplicateDevicePath(dp);
+ if (!parent_dp) {
+ rc = EFI_INVALID_PARAMETER;
+ goto out;
+ }
+
+ dp = parent_dp;
+ count = 0;
+ while (1) {
+ if (IsDevicePathEnd(dp)) {
+ rc = EFI_INVALID_PARAMETER;
+ goto out;
+ }
+
+ if (DevicePathType(dp) == MEDIA_DEVICE_PATH && DevicePathSubType(dp) == MEDIA_FILEPATH_DP)
+ break;
+
+ dp = NextDevicePathNode(dp);
+ ++count;
+ }
+
+ SetDevicePathEndNode(dp);
+
+ if (debugging)
+ Print(L"Device Path prepared: %s\n", DevicePathToStr(parent_dp));
+
+ for (i = 0; i < n_handles; i++) {
+ EFI_DEVICE_PATH *path;
+
+ for (i = 0; i < n_handles; i++) {
+ EFI_DEVICE_PATH *path;
+
+ rc = uefi_call_wrapper(BS->HandleProtocol, 3, devices[i], &dpp,
+ (void **)&path);
+ if (EFI_ERROR(rc))
+ continue;
+
+ if (debugging)
+ Print(L"Device supporting SFSP: %s\n", DevicePathToStr(path));
+
+ rc = EFI_UNSUPPORTED;
+ while (!IsDevicePathEnd(path)) {
+ if (debugging)
+ Print(L"Comparing: %s and %s\n", DevicePathToStr(parent_dp), DevicePathToStr(path));
+
+ if (LibMatchDevicePaths(path, parent_dp) == TRUE) {
+ *fh = devices[i];
+ for (i = 0; i < count; i++)
+ *file_dp = NextDevicePathNode(*file_dp);
+ rc = EFI_SUCCESS;
+
+ if (debugging)
+ Print(L"Match up! Returning %s\n", DevicePathToStr(*file_dp));
+
+ goto out;
+ }
+
+ path = NextDevicePathNode(path);
+ }
+ }
+
+out:
+ if (!EFI_ERROR(rc))
+ Print(L"File %s searched\n", DevicePathToStr(*file_dp));
+
+ uefi_call_wrapper(BS->FreePool, 1, devices);
+ return rc;
+}
+
+static EFI_STATUS
open_file(EFI_DEVICE_PATH *dp, EFI_FILE_HANDLE *fh)
{
EFI_DEVICE_PATH *file_dp = dp;
@@ -373,9 +461,12 @@ open_file(EFI_DEVICE_PATH *dp, EFI_FILE_HANDLE *fh)
rc = uefi_call_wrapper(BS->LocateDevicePath, 3, &sfsp, &file_dp,
&device);
if (EFI_ERROR(rc)) {
- Print(L"%a:%a():%d: Could not locate device handle: %r\n",
- __FILE__, __func__, __LINE__, rc);
- return rc;
+ rc = search_file(&file_dp, &device);
+ if (EFI_ERROR(rc)) {
+ Print(L"%a:%a():%d: Could not locate device handle: %r\n",
+ __FILE__, __func__, __LINE__, rc);
+ return rc;
+ }
}
if (DevicePathType(file_dp) != MEDIA_DEVICE_PATH ||
@@ -752,6 +753,11 @@ efi_main(EFI_HANDLE image, EFI_SYSTEM_TABLE *systab)
return rc;
}
+ if (debugging) {
+ Print(L"Applying the capsules ...\n");
+ uefi_call_wrapper(BS->Stall, 1, 10000000);
+ }
+
/*
* Step 4: apply the capsules.
*/
If fwupdate employs USB key to execute capsule update, the generated device path is valid. However, the fwupdate.efi will report open_file() fails. With the patch above, USB key also works well.
Here are the dumps for USB key as ESP
# hexdump -C fwupdate-e0f614ed-fb82-467a-a34e-71172cc07e4d-0-0abba7dc-e516-4167-bbf5-4d9d1c739416
00000000 07 00 00 00 07 00 00 00 ed 14 f6 e0 82 fb 7a 46 |..............zF|
00000010 a3 4e 71 17 2c c0 7e 4d 00 00 00 00 00 00 00 00 |.Nq.,.~M........|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 01 00 00 00 04 01 2a 00 01 00 00 00 |..........*.....|
00000040 00 08 00 00 00 00 00 00 00 00 04 00 00 00 00 00 |................|
00000050 89 8c c8 59 00 00 00 00 00 00 00 00 00 00 00 00 |...Y............|
00000060 01 01 04 04 46 00 5c 00 45 00 46 00 49 00 5c 00 |....F.\.E.F.I.\.|
00000070 64 00 65 00 6c 00 6c 00 5c 00 66 00 77 00 5c 00 |d.e.l.l.\.f.w.\.|
00000080 66 00 77 00 75 00 70 00 64 00 61 00 74 00 65 00 |f.w.u.p.d.a.t.e.|
00000090 2d 00 37 00 45 00 42 00 36 00 6c 00 31 00 2e 00 |-.7.E.B.6.l.1...|
000000a0 63 00 61 00 70 00 00 00 7f ff 04 00 |c.a.p.......|
000000ac
# hexdump -C BootNext-8be4df61-93ca-11d2-aa0d-00e098032b8c
00000000 07 00 00 00 00 00 |......|
00000006
# hexdump -C Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
00000000 07 00 00 00 01 00 00 00 60 00 4c 00 69 00 6e 00 |........`.L.i.n.|
00000010 75 00 78 00 20 00 46 00 69 00 72 00 6d 00 77 00 |u.x. .F.i.r.m.w.|
00000020 61 00 72 00 65 00 20 00 55 00 70 00 64 00 61 00 |a.r.e. .U.p.d.a.|
00000030 74 00 65 00 72 00 00 00 04 01 2a 00 01 00 00 00 |t.e.r.....*.....|
00000040 00 08 00 00 00 00 00 00 00 00 04 00 00 00 00 00 |................|
00000050 89 8c c8 59 00 00 00 00 00 00 00 00 00 00 00 00 |...Y............|
00000060 01 01 04 04 32 00 5c 00 45 00 46 00 49 00 5c 00 |....2.\.E.F.I.\.|
00000070 64 00 65 00 6c 00 6c 00 5c 00 66 00 77 00 75 00 |d.e.l.l.\.f.w.u.|
00000080 70 00 64 00 61 00 74 00 65 00 2e 00 65 00 66 00 |p.d.a.t.e...e.f.|
00000090 69 00 00 00 7f ff 04 00 |i.......|
00000098
The picture attached shows how the patch works (note that the picture is captures recently so it doesn't match the name of capsule file shown in the dumps):
This can be detected via lsb_release
instead, which should make it more flexible to out of the box compiles on other OSes.
commit 971ff735adf93064e47af49a2195ea201bd043ae
Author: Mario Limonciello <[email protected]>
Date: Mon Feb 29 10:32:58 2016 -0600
Use lsb_release to detect EFIDIR instead of hardcoding
diff --git a/Make.defaults b/Make.defaults
index 912a893..59b4379 100644
--- a/Make.defaults
+++ b/Make.defaults
@@ -36,7 +36,7 @@ localedir ?= $(datadir)/locale/
libexecdir ?= $(prefix)libexec/
libdatadir ?= $(prefix)lib/
-EFIDIR ?= redhat
+EFIDIR ?= $(lsb_release -s -i | tr A-Z a-z)
DEBUGINFO ?= $(prefix)lib/debug/
DEBUGSOURCE ?= $(prefix)src/debug/
TARGETDIR ?= /boot/efi/EFI/$(EFIDIR)/
I currently have a HP Pavilion g7 and I was wondering if there was any way to get updated BIOS?
I've noticed I can't run a make clean and have everything cleaned up.
This patch resolves the issue:
From 69162bf038954777b62599602e69d308a63cf3e1 Mon Sep 17 00:00:00 2001
From: Mario Limonciello <[email protected]>
Date: Thu, 4 Jun 2015 18:50:14 -0500
Subject: [PATCH] In clean rule, remove libfwup.so
Github issue: https://github.com/rhinstaller/fwupdate/issues/2
Signed-off-by: Mario Limonciello <[email protected]>
---
linux/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux/Makefile b/linux/Makefile
index ed47fe1..ca4072c 100644
--- a/linux/Makefile
+++ b/linux/Makefile
@@ -68,7 +68,7 @@ test : tester
LD_LIBRARY_PATH=$(shell pwd) ./tester
clean :
- @rm -vf $(BINTARGETS) $(LIBTARGETS) $(PCTARGETS) $(POTARGETS) *.o
+ @rm -vf $(BINTARGETS) $(LIBTARGETS) $(PCTARGETS) $(POTARGETS) *.o libfwup.so
install : all
$(INSTALL) -d -m 755 $(DESTDIR)/$(libdir)
--
1.9.1
Hi,
Gnome-softwate offers me to update my bios to the latest version (0.1.4.10 -> 0.1.4.13)
However, nothing happens when I click "install": the button disappear and comes back a few seconds later. Nothing happens on reboot either.
I'm using a freshly installed fedora 25.
How can I help troubleshooting this issue?
Thanks
Since torvalds/linux@ed8b0de has been made, the fwupdate-* variable can no longer be deleted automatically from https://github.com/rhinstaller/fwupdate/blob/master/linux/cleanup.in
This causes problems on a fresh install with a new kernel that contains this patch but also contains an old fwupdate-* variable that is supposed to be cleaned up.
I suspect that the variable being immutable will also prevent fwupdate from updating the variable too, but haven't confirmed this.
When running with an update to apply, fwupdate.efi prints an error on screen just above it's "Found fwupdate-..." message:
'Could not get variable "SHIM_DEBUG": Not Found'
Ideally there shouldn't be any error message printed on screen before running the update; otherwise users might think there is an issue.
At least encode the last tagged version or git hash it was built with
Not sure if this because fwupdate is not taking pkgconfig corretly or because the patch is hardcoded but make call /usr/lib/gnuefi//crt0-efi-ia32.o wich is different in some distros.
In Arch (yeah, I'm trying to make a MAKEPKG for fwupdate for Arch) the path for crt0-efi-ia32.o in gnu-efi-lib is simply usr/lib/crt0-efi-ia32.o
gnu-efi in arch only have this setup therefor I can build fwupdate (from git) without seed magic, but that is plain wrong, so, some hints help?
fwupdate should provide a rasterized text image capsule, so that the firmware's message can be localized the same as the OS.
We need a couple of things for this:
so diskless systems can work.
Hi,
please merge this patch, as currently global CFLAGS and LDFLAGS are not respected by makefiles
Thanks.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.