Also https://github.com/rhboot/fwupdate/issues/62#issuecomment-327445657

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

Changing `create-fw-directory.patch` to the attached patch fixes the problem for me and allowed me to update the firmware through fwupdmgr.

Please try fwupdate 9-3 from [community-testing].

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
[...]
```

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.

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 .

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?

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.

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.

@ebkalderon: We are definitively aware of that but the update is blocked by  FS#57043  (two information that are already present in above comments ;)).

FYI efivar 34 is in testing, this should be fixable now.

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.

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