FS#55815 - [fwupdate] Uses wrong efi path during installation

Attached to Project: Community Packages
Opened by Arvid (arvids) - Saturday, 30 September 2017, 13:45 GMT
Last edited by Bruno Pagani (ArchangeGabriel) - Tuesday, 06 March 2018, 22:37 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Bruno Pagani (ArchangeGabriel)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 6
Private No

Details

Description: I recieve the following error when trying to use fwupdate:

% sudo fwupdate -a 34578c72-11dc-4378-bc7f-b643866f598c .cache/fwupdmgr/e69073e5403ee433ddfdd40b53781e91074b07b2-firmware_XPS_9560_1_5_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:1207 get_fd_and_media_path(): mkostemps(/boot/efi/EFI//boot/efi/EFI/arch/fw/fw/fwupdate-9FJxpS.cap) failed: No such file or directory

The problems seems to be the last line where "/boot/efi/EFI/boot//boot/ef/EFI/arch/fw/fw" should be /boot/efi/EFI/arch/fw.

See also: https://github.com/rhboot/fwupdate/issues/80

This task depends upon
 FS#57043 - [efivar] Add an upstream patch 

Closed by  Bruno Pagani (ArchangeGabriel)
Tuesday, 06 March 2018, 22:37 GMT
Reason for closing:  Implemented
Additional comments about closing:  fwupdate 10-1 + fwupd 1.0.5-2
Comment by Thom Wiggers (twiggers) - Wednesday, 18 October 2017, 13:10 GMT Comment by Thom Wiggers (twiggers) - Wednesday, 18 October 2017, 13:15 GMT
I think the culprit is this line of code:

https://git.archlinux.org/svntogit/community.git/tree/trunk/create-fw-directory.patch?h=packages/fwupdate#n47

The string `directory' is inserted into `/boot/efi/EFI` here, but `directory` ALREADY contains `/boot/efi/EFI'.
Comment by Thom Wiggers (twiggers) - Wednesday, 18 October 2017, 13:25 GMT
Changing `create-fw-directory.patch` to the attached patch fixes the problem for me and allowed me to update the firmware through fwupdmgr.
Comment by Bruno Pagani (ArchangeGabriel) - Wednesday, 18 October 2017, 18:43 GMT
Please try fwupdate 9-3 from [community-testing].
Comment by Gonzalo Peci (pecigonzalo) - Tuesday, 09 January 2018, 20:35 GMT
  • Field changed: Percent Complete (100% → 0%)
I believe this is still causing issues and the path gets wrongly sent to the `get_fd_and_media_path` function.

```
❯ sudo fwupdmgr update
No upgrades for device, current is 1.3.1.0: 1.3.1.0=same
Downloading 0.2.5.0 for XPS 13 9360 System Firmware...
Updating 0.2.5.0 on XPS 13 9360 System Firmware...
Decompressing… [***************************************]
Authenticating… [***************************************]
Scheduling… [ - ]UEFI firmware update failed: {error #0} libfwup.c:1178 get_fd_and_media_path(): open of /boot/efi/efi/efi/efi/efi/efi/efi/efi/EFI//boot/efi/EFI/arch/fw/fw/fwupdate-2Lazsa.cap failed: No such file or directory
```

```
❯ tree /boot
/boot
├── EFI
│   ├── BOOT
│   │   └── BOOTX64.EFI
│   ├── Dell
│   │   └── logs
│   │   └── diags_current.xml
│   ├── EFI
│   │   └── arch
│   │   ├── fw
│   │   └── fwupx64.efi
│   └── systemd
│   └── systemd-bootx64.efi
[...]
```

Comment by Gonzalo Peci (pecigonzalo) - Wednesday, 10 January 2018, 17:08 GMT
Some additional information, seems like fwupdate left 2 entries on my EFI vars

```
❯ efivar -l | grep fwupdate
0abba7dc-e516-4167-bbf5-4d9d1c739416-fwupdate-5ffdbc0d-f340-441c-a803-8439c8c0ae10-0
0abba7dc-e516-4167-bbf5-4d9d1c739416-fwupdate-73c2051d-8688-56fb-a93f-d56a9b455e52-0
```

EG content:
```
❯ efivar -p --name 0abba7dc-e516-4167-bbf5-4d9d1c739416-fwupdate-5ffdbc0d-f340-441c-a803-8439c8c0ae10-0
GUID: 0abba7dc-e516-4167-bbf5-4d9d1c739416
Name: "fwupdate-5ffdbc0d-f340-441c-a803-8439c8c0ae10-0"
Attributes:
Non-Volatile
Boot Service Access
Runtime Service Access
Value:
00000000 07 00 00 00 0d bc fd 5f 40 f3 1c 44 a8 03 84 39 |......._@..D...9|
00000010 c8 c0 ae 10 00 00 02 00 00 00 00 00 00 00 00 00 |................|
00000020 e1 07 0b 10 0b 31 12 00 00 00 00 00 ff 07 00 00 |.....1..........|
00000030 02 00 00 00 04 01 2a 00 01 00 00 00 00 08 00 00 |......*.........|
00000040 00 00 00 00 00 00 10 00 00 00 00 00 40 93 d0 d8 |............@...|
00000050 f2 c9 41 48 a1 4c 05 57 a8 d0 61 98 02 02 04 04 |..AH.L.W..a.....|
00000060 a0 00 5c 00 65 00 66 00 69 00 5c 00 65 00 66 00 |..\.e.f.i.\.e.f.|
00000070 69 00 5c 00 65 00 66 00 69 00 5c 00 65 00 66 00 |i.\.e.f.i.\.e.f.|
00000080 69 00 5c 00 65 00 66 00 69 00 5c 00 65 00 66 00 |i.\.e.f.i.\.e.f.|
00000090 69 00 5c 00 65 00 66 00 69 00 5c 00 45 00 46 00 |i.\.e.f.i.\.E.F.|
000000a0 49 00 5c 00 5c 00 62 00 6f 00 6f 00 74 00 5c 00 |I.\.\.b.o.o.t.\.|
000000b0 65 00 66 00 69 00 5c 00 45 00 46 00 49 00 5c 00 |e.f.i.\.E.F.I.\.|
000000c0 61 00 72 00 63 00 68 00 5c 00 66 00 77 00 5c 00 |a.r.c.h.\.f.w.\.|
000000d0 66 00 77 00 5c 00 66 00 77 00 75 00 70 00 64 00 |f.w.\.f.w.u.p.d.|
000000e0 61 00 74 00 65 00 2d 00 32 00 4c 00 61 00 7a 00 |a.t.e.-.2.L.a.z.|
000000f0 73 00 61 00 2e 00 63 00 61 00 70 00 00 00 7f ff |s.a...c.a.p.....|
00000100 04 00 |.. |
```

After removing the entries
```
sudo chattr -i /sys/firmware/efi/efivars/fwupdate-*
sudo rm /sys/firmware/efi/efivars/fwupdate-*
```
it worked:
```
❯ sudo fwupdmgr update
No upgrades for device, current is 1.3.1.0: 1.3.1.0=same
Downloading 0.2.5.0 for XPS 13 9360 System Firmware...
Updating 0.2.5.0 on XPS 13 9360 System Firmware...
Decompressing… [***************************************]
Authenticating… [***************************************]
Scheduling… [***************************************]
```

So it might not be the same path, but certinaly there is a bug were it ends up appending the directly indefinetly as running over and over ends up with more and more `[...]efi/efi/efi/[...]`

I hope this additional information helps.
Comment by Bruno Pagani (ArchangeGabriel) - Thursday, 11 January 2018, 19:03 GMT
That’s because you don’t have efi mounted at /boot/efi but /boot directly, which isn’t supported by fwupdate currently. Next version (10) fixes this, but is currently blocked by  FS#57043 .
Comment by Gonzalo Peci (pecigonzalo) - Friday, 12 January 2018, 13:31 GMT
Bruno, thanks for you reply, AFAIK the mounting is ok as long as I copy the files to the correct place, creating the /boot/EFI/EFI structure.
I think the issue actually comes from reading the previous location on the efivars and appending the path again in some way.
Im testing some fixes, but its slow as im not any good on C.

Do you know what is blocking  FS#57043 ? I cant see any comments there. (sorry a bit new to Arch bug tracker)

Additionally, Im using systemd-boot and I believe the "only" way is to mount to /boot otherwise we need some awkward copy hooks to move the files to /boot/efi. Is this correct or there is some other way?
Comment by Bruno Pagani (ArchangeGabriel) - Friday, 12 January 2018, 13:37 GMT
I think both issue are linked and will both be fixed by the new fwupdate version.

 FS#57043  is just waiting for someone (normally the maintainer, which is current assignee) to decide whether to accept the patch or not. Since efivars is a [core] package, not anyone can do this. If the patch is rejected, we will have to wait for efivars 33.

And yes, when using systemd-boot, you have to mount to /boot AFAIK. The issue is not with your setup but with fwupdate.
Comment by Eyal Kalderon (ebkalderon) - Monday, 19 February 2018, 08:00 GMT
This bug should be fixed upstream with fwupdate version 10, according to https://github.com/rhboot/fwupdate/issues/80#issuecomment-356406060. Hope the updated package gets released soon.
Comment by Bruno Pagani (ArchangeGabriel) - Monday, 19 February 2018, 12:46 GMT
@ebkalderon: We are definitively aware of that but the update is blocked by  FS#57043  (two information that are already present in above comments ;)).
Comment by Mario (superm1) - Tuesday, 27 February 2018, 14:56 GMT
FYI efivar 34 is in testing, this should be fixable now.
Comment by Bruno Pagani (ArchangeGabriel) - Tuesday, 27 February 2018, 18:37 GMT
So fwupdate-10-1 in [community-testing] can handle manual update, but now we need something in fwupd, see https://github.com/hughsie/fwupd/issues/421.
Comment by Bruno Pagani (ArchangeGabriel) - Tuesday, 06 March 2018, 22:37 GMT
fwupd in [community-testing] allows configuring the ESP path as described in the updated wiki page: https://wiki.archlinux.org/index.php/Fwupd#Running_fwupd

Loading...