search

fwupd / fwupd

A system daemon to allow session software to update firmware
GNU Lesser General Public License v2.1
2.89k stars 432 forks source link

ARCH: Bios update fails on Dell 9350 (developer edition) #100

Closed fredoche closed 7 years ago

fredoche commented 7 years ago

Hi,

This is a copy of an issue opened on the fwupdate project https://github.com/rhinstaller/fwupdate/issues/62

I wrote:

Gnome-software 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?

fwupdmgr update in a terminal as root worked and both TPM and BIOS have been updated at the same time on reboot.

superm1 commented:

Well that's really odd if it "just started working". Both TPM and FW updated at the same time? I wonder if that's possibly related (it's new that the updates for TPM are available). Can you file an issue with the fuwpd project to investigate further? I don't think the issue is with the fwupdate project and this issue can close.

Thanks for your awesome work & let me know how I can help with that issue.

hughsie commented 7 years ago

Is it possible to reproduce the original issue? If so, what does "gnome-software --verbose" say when you click install? Thanks.

fredoche commented 7 years ago

Hi, There's been another update to the TPM firmware according to gnome-software. I'd like to copy the output of gnome-software --verbose , however, the TPM update disappeared from the update's list on restart. I'll let you know once I can have both --verbose and the TPM update showing. Thanks

fredoche commented 7 years ago

i'm pasting here the output of efibootmgr -v I don't know much about efi boot but the bootorder seems to be missing an entry?

BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0002
Boot0000* Fedora    HD(1,GPT,597ea7fd-7be1-488c-81e3-2a4a7b6c779d,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0001* Linux-Firmware-Updater \fwupx64.efi   HD(1,GPT,597ea7fd-7be1-488c-81e3-2a4a7b6c779d,0x800,0x64000)/File(\EFI\fedora\shim.efi)\.f.w.u.p.x.6.4...e.f.i...
Boot0002* UEFI: PM951 NVMe SAMSUNG 512GB, Partition 1   HD(1,GPT,597ea7fd-7be1-488c-81e3-2a4a7b6c779d,0x800,0x64000)/File(EFI\boot\bootx64.efi)..BO
superm1 commented 7 years ago

Can you show fwupdmgr get-devices output? Does it still think there is a TPM update available?

The efibootmgr output doesn't look suspicious to me. The Linux Firmware Updater entry is only added to BootNext when needed, not every time.

Queuecumber commented 7 years ago

I can confirm that on my machine, 9560, from gnome software, the install button just does nothing as of the recent 1.3.3 bios release. On top of that, fwupdmgr update (as root or user) gives me 

Downloading 0.1.3.3 for XPS 15 9560...
Updating 0.1.3.3 on XPS 15 9560...
Decompressing…         
Retrying as an offline update...
Scheduling…            
UEFI firmware update failed: Unknown error -1
superm1 commented 7 years ago

@Queuecumber To make sure we can work on this effectively while in this state can you comment on your stack?

Queuecumber commented 7 years ago

BTW I should point out that the last BIOS update, 0.1.2.4 which is installed, was done through fwupd and it worked great

XPS 15 9560 Guid: 34578c72-11dc-4378-bc7f-b643866f598c UniqueID: system//ubuntu-yakkety-updates-restricted/firmware/com.dell.uefi34578c72.firmware/ DeviceID: UEFI-34578c72-11dc-4378-bc7f-b643866f598c-dev0 Description:

Updating the system firmware improves performance.

Plugin: uefi Flags: internal|allow-offline|require-ac|supported Version: 0.1.2.4 VersionLowest: 0.1.2.4 Created: 2017-05-19 AppstreamId: com.dell.uefi34578c72.firmware Summary: Firmware for the Dell XPS 15 9560/Precision 5520 UpdateVersion: 0.1.3.3 UpdateHash: 47d24687c83c3c8e56226c4e0bbb5f1ac2eb7ced UpdateChecksumKind: sha1 License: proprietary UpdateUri: https://secure-lvfs.rhcloud.com/downloads/88402006d070ab9ad60529ab397de9c95244e866-1.3.3.cab UrlHomepage: http://support.dell.com/ Vendor: Dell Inc. Trusted: none

Unknown Device Guid: 37921484-dff0-57a0-b7dd-4cd6a82b54a1 DeviceID: ro__sys_devices_pci0000_00_0000_00_01_0_0000_01_00_0 Plugin: udev Flags: internal|locked DeviceVendor: NVIDIA Corporation Created: 2017-05-19

AX88179 Guid: da6082b0-a033-5b25-b280-bcba3720eddd Guid: 69b5c44a-b47b-578c-8a91-490fc0715fa1 DeviceID: usb:00:01:01 Plugin: usb Flags: none Version: 1.0 Created: 2017-05-21

USB Keyboard Guid: 32f85e43-a122-5e40-b182-de1372d2dee8 Guid: eccb930e-5f25-5eb9-90c9-a93fd0445914 DeviceID: usb:00:01:04:01 Plugin: usb Flags: none Version: 1.1 Created: 2017-05-21

superm1 commented 7 years ago

Have you built any of the tools (fwupd/fwupdate) from source? Or are these all distro versions in Ubuntu 17.04? I'm guessing you built fwupd from source at least to support the thunderbolt stuff, so if so which git sha1 was it built from (you can look at git log -n1 --oneline in your source tree)

tomhughes commented 7 years ago

Quick question to anybody that has encountered this - were you on AC power at the time?

Queuecumber commented 7 years ago

@superm1 8b90f35 Update Czech translation

Queuecumber commented 7 years ago

@tomhughes I was on AC over thunderbolt, I just tried again with the Dell AC adapter and got the same error

dkowis commented 7 years ago

I'm having the same problem as @Queuecumber, except I'm on ubuntu 16.10 and I installed fwupd from the dell PPA: https://launchpad.net/~dell-team/+archive/ubuntu/ppa

~ > fwupdmgr get-updates
XPS 15 9560 has firmware updates:
ID:                      com.dell.uefi34578c72.firmware
GUID:                    34578c72-11dc-4378-bc7f-b643866f598c
Update Version:          0.1.3.3
Update Checksum:         47d24687c83c3c8e56226c4e0bbb5f1ac2eb7ced
Update Checksum Type:    sha1
Update Location:         https://secure-lvfs.rhcloud.com/downloads/88402006d070ab9ad60529ab397de9c95244e866-1.3.3.cab
~ > fwupdmgr update                                                                                                           1s
Downloading 0.1.3.3 for XPS 15 9560...
Updating 0.1.3.3 on XPS 15 9560...
Decompressing…         
Retrying as an offline update...
Scheduling…            
UEFI firmware update failed: Unknown error -1

Integrated Webcam HD Guid: 4a6dd514-e790-5275-8300-beba6b66d801 Guid: 487c77d3-9219-5ac3-841a-ac0a645c47e9 DeviceID: usb:00:0c Plugin: usb Flags: none Version: 86.5 Created: 2017-06-18

Unknown Device Guid: 37921484-dff0-57a0-b7dd-4cd6a82b54a1 DeviceID: ro__sys_devices_pci0000_00_0000_00_01_0_0000_01_00_0 Plugin: udev Flags: internal|locked DeviceVendor: NVIDIA Corporation Created: 2017-06-18

superm1 commented 7 years ago

@dkowis I think your contextual problem is a little bit different than the others in this thead. You're missing the EFI boot entry which leads me to believe one of these things is going on:

  1. The systemd rules aren't recognized on Ubuntu 16.10 (check journalctloutput to confirm). If this is what's going on, it's already sorted on master in some ways. There is a build dependency on master now on systemd 231. https://github.com/hughsie/fwupd/blob/master/meson.build#L178 This probably isn't it though - systemd is already 231 on Ubuntu 16.10. https://launchpad.net/ubuntu/+source/systemd/231-9ubuntu4

  2. You have secure boot enabled and are missing fwupdate-signed Can you share a recursive directory listing of your EFI system partition to confirm?

dkowis commented 7 years ago

Secure boot isn't enabled. I know I've disabled that.

The boot listing is stupid long because I have dual boot windows 10, can you trust me that I have disabled secure boot?

luzpaz commented 7 years ago

I have this issue as well on OS: Manjaro 17.2 fwupd 0.9.4-2 fwupdate 9-1 efivar 31-1 efibootmgr version 15

efibootmgr -v
BootCurrent: 0008
Timeout: 2 seconds
BootOrder: 0008,0007,0002,0000,0001,0003,0004,0005,0006
Boot0000* Windows Boot Manager  HD(1,GPT,79a64bd7-96c9-4d21-9f1d-5ea39db7657a,0x800,0xf9800)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...r................
Boot0001* UEFI: THNSN5512GPU7 NVMe TOSHIBA 512GB, Partition 1   HD(1,GPT,79a64bd7-96c9-4d21-9f1d-5ea39db7657a,0x1001,0x96001)/File(EFI\boot\bootx64.efi)..BO
Boot0002* ubuntu    HD(1,GPT,79a64bd7-96c9-4d21-9f1d-5ea39db7657a,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0003* Diskette Drive    BBS(Floppy,Diskette Drive,0x0)..BO
Boot0004* M.2 PCIe SSD  BBS(HD,THNSN5512GPU7 NVMe TOSHIBA 512G,0x0)..BO
Boot0005* USB Storage Device    BBS(USB,USB Storage Device,0x0)..BO
Boot0006* CD/DVD/CD-RW Drive    BBS(CDROM,CD/DVD/CD-RW Drive,0x0)..BO
Boot0007* USB   PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-08-0D-03-00-02-56-1E)/HD(1,GPT,ae6741c8-3be2-4795-88f2-a5f39af3839b,0x1001,0x96001)/File(\EFI\boot\bootx64.efi)
Boot0008* Manjaro   HD(1,GPT,79a64bd7-96c9-4d21-9f1d-5ea39db7657a,0x1001,0x96001)/File(\EFI\Manjaro\grubx64.efi)
[beast@beast ~]$ fwupdmgr get-devices
  Guid:                 33773727-8ee7-4d81-9fa0-57e8d889e1fa
  DeviceID:             UEFI-33773727-8ee7-4d81-9fa0-57e8d889e1fa-dev0
  DisplayName:          XPS 13 9350
  Description:          <p>Updating the system firmware improves performance.</p>
  Plugin:               uefi
  Flags:                internal|allow-offline|require-ac|supported
  Version:              0.1.4.4
  VersionLowest:        0.1.4.4
  Created:              2017-07-06

  Guid:                 d433959e-03ca-524b-92b7-5022eff81a31
  DeviceID:             DELL-d433959e-03ca-524b-92b7-5022eff81a31lu
  DisplayName:          XPS 13 9350 TPM 1.2
  Description:          <p>Updating the system firmware improves performance.</p>
  Plugin:               dell
  Flags:                internal|allow-offline|require-ac|supported
  Version:              5.81.0.0
  Created:              2017-07-06

  Guid:                 b62a2412-5ac4-5350-b16e-7e8f4655d096
  DeviceID:             DELL-b62a2412-5ac4-5350-b16e-7e8f4655d096lu
  DisplayName:          XPS 13 9350 TPM 2.0
  Plugin:               dell
  Flags:                internal|require-ac|locked
  Created:              2017-07-06

  Guid:                 4ec19583-c132-5c27-a9cf-061419e838dc
  Guid:                 6b31e6e6-ba7c-5251-8f4c-7f2571612251
  DeviceID:             usb:00:05
  DisplayName:          Integrated Webcam HD
  Plugin:               usb
  Flags:                none
  DeviceVendorId:       USB:0x0C45
  Version:              86.38
  Created:              2017-07-06

  Guid:                 040347ea-2d0b-5cfd-851d-84d8f37dec7f
  DeviceID:             ro__sys_devices_pci0000_00_0000_00_02_0
  DisplayName:          Iris Graphics 540
  Plugin:               udev
  Flags:                internal|locked
  DeviceVendor:         Intel Corporation
  DeviceVendorId:       PCI:0x8086
  Created:              2017-07-06

[beast@beast ~]$ fwupdmgr refresh
Fetching metadata https://s3.amazonaws.com/lvfsbucket/downloads/firmware.xml.gz
Downloading…           [****************************************]
Fetching signature https://s3.amazonaws.com/lvfsbucket/downloads/firmware.xml.gz.asc
Downloading…           [****************************************]
[beast@beast ~]$ fwupdmgr get-updates
XPS 13 9350 has firmware updates:
ID:                      com.dell.uefi33773727.firmware
GUID:                    33773727-8ee7-4d81-9fa0-57e8d889e1fa
Update Version:          0.1.4.17
Update Remote ID:        lvfs
Update Location:         https://secure-lvfs.rhcloud.com/downloads/ea2aa51a9db18a3b980d6fa8f4472aca6b3757eb-XPS_9350_1.4.17.cab
XPS 13 9350 TPM 1.2 has firmware updates:
ID:                      com.dell.uefi5034bac4.firmware
GUID:                    d433959e-03ca-524b-92b7-5022eff81a31
Update Version:          5.81.2.1
Update Remote ID:        lvfs
Update Location:         https://secure-lvfs.rhcloud.com/downloads/f7375df3c5f903f55ffd64e9ce891da3aa535355-DellTpm1.2_Fw5.81.2.1.cab
[beast@beast ~]$ fwupdmgr update
Downloading 0.1.4.17 for XPS 13 9350...
Updating 0.1.4.17 on XPS 13 9350...
Decompressing…         
Retrying as an offline update...
Scheduling…            
UEFI firmware update failed: Unknown error -1
superm1 commented 7 years ago

@luzpaz @dkowis In order to make debugging this problem (and other UEFI ones) easier, I've added a commit that will more verbosely show the actual problem with the UEFI firmware update.

Can you please either:

  1. (preferably) Download/compile current master and reproduce again showing the error?
  2. Backport this commit: https://github.com/hughsie/fwupd/commit/c1a4bd469dcb4d558eac2d60d4ed91bc27060507 to your local build and reproduce again, showing the error?
luzpaz commented 7 years ago

In order to make debugging this problem (and other UEFI ones) easier, I've added a commit that will more verbosely show the actual problem with the UEFI firmware update.

CC @heftig would you backporting new fwupd commits to manjaro community builds so I can test this ?

superm1 commented 7 years ago

@heftig OT to this issue, but also please feel free to to submit a pull request with the relevant stuff that lets manjaro build out of a docker container here (see https://github.com/hughsie/fwupd/tree/master/contrib). This would allow folks like @luzpaz to easily compile master into a packaged format for the purposes of bugs like this.

heftig commented 7 years ago

@superm1 I work on Arch, not Manjaro. As far as I can see there's already CI support for Arch.

@luzpaz I don't maintain fwupd, @ArchangeGabriel does. However, we generally only backport bugfixes. Also, if you use Manjaro there will be additional delay to all releases, so depending on the repos for debug feedback will generally be too slow. You will likely have to build test packages yourself.

superm1 commented 7 years ago

Manjaro can run Arch packages since it's based on it right? If so, @luzpaz just use the docker build to generate arch stuff from master. Directions here: https://github.com/hughsie/fwupd/tree/master/contrib

ArchangeGabriel commented 7 years ago

Unless dependencies are lagging behind and you get a missing .so file… But yes it could work.

superm1 commented 7 years ago

If they don't work due to library mess, then the other option is just install build-deps on manjaro and run contrib/ci/build_and_install_pkgs.sh outside the container.

ArchangeGabriel commented 7 years ago

Or just use the PKGBUILD… That’s what they’re for.

psafont commented 7 years ago

Using arch with a Latitude E7470 here, I compiled master using the docker method and I get the same error:

$ efibootmgr -v
BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 0001,0000
Boot0000* Windows Boot Manager  HD(1,GPT,6c01bc99-42b0-4e76-9ae8-14989ebab8ad,0x800,0xfa000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....~...............
Boot0001* Manjaro       HD(1,GPT,6c01bc99-42b0-4e76-9ae8-14989ebab8ad,0x1001,0x96001)/File(\EFI\Manjaro\grubx64.efi)
Boot0006* UEFI: SK hynix SC308 SATA 512GB, Partition 1  HD(1,GPT,76e3360c-bb6c-4073-baa6-a0eb47653687,0x800,0xfa000)/File(EFI\boot\bootx64.efi)..BO

(Yes, it says Manjaro, but I'm using Arch now)

# pacman -U fwupd-0.9.5.r14.gc633edc-1-x86_64.pkg.tar.xz
loading packages...
resolving dependencies...
looking for conflicting packages...

Package (3)           New Version           Net Change

extra/appstream-glib  0.6.13-1                2.84 MiB
extra/gcab            0.7+16+g4bc4be1-1       0.35 MiB
fwupd                 0.9.5.r14.gc633edc-1    3.27 MiB
$ fwupdmgr get-devices
  DisplayName:          Intel AMT (unprovisioned)
  DeviceID:             /dev/mei
  Guid:                 2800f812-b7b4-2d4b-aca8-46e0ff65814c
  Plugin:               amt
  Flags:                internal
  Version:              11.0.0
  VersionBootloader:    11.0.0
  Created:              2017-07-10

  DisplayName:          Latitude E7470
  DeviceID:             UEFI-212026ee-fde4-4d08-ac41-c62cb4036a42-dev0
  Guid:                 212026ee-fde4-4d08-ac41-c62cb4036a42
  Description:          <p>Updating the system firmware improves performance.</p>
  Plugin:               uefi
  Flags:                internal|allow-offline|require-ac|supported
  Version:              0.1.5.3
  VersionLowest:        0.1.5.3
  Created:              2017-07-10

  DisplayName:          Latitude E7470 TPM 2.0
  DeviceID:             DELL-a0451b50-d5e2-5821-9fce-43314d3d70fdlu
  Guid:                 a0451b50-d5e2-5821-9fce-43314d3d70fd
  Description:          <p>Updating the system firmware improves performance.</p>
  Plugin:               dell
  Flags:                internal|allow-offline|require-ac|supported
  Version:              1.3.0.1
  Created:              2017-07-10

  DisplayName:          Latitude E7470 TPM 1.2
  DeviceID:             DELL-b2432fd8-8ab5-5346-907b-aa459bcfd3a9lu
  Guid:                 b2432fd8-8ab5-5346-907b-aa459bcfd3a9
  Plugin:               dell
  Flags:                internal|require-ac|locked
  Created:              2017-07-10

  DisplayName:          HD Graphics 520
  DeviceID:             ro__sys_devices_pci0000_00_0000_00_02_0
  Guid:                 a3361e1f-f523-5cfc-ad68-e20d0f792003
  Plugin:               udev
  Flags:                internal
  DeviceVendor:         Intel Corporation
  DeviceVendorId:       PCI:0x8086
  Created:              2017-07-10
$ fwupdmgr update
Downloading 0.1.16.4 for Latitude E7470...
Updating 0.1.16.4 on Latitude E7470...
Decompressing…         Retrying as an offline update...
Scheduling…            UEFI firmware update failed: Unknown error -1
superm1 commented 7 years ago

@psafont It looks to me like you're missing https://github.com/hughsie/fwupd/commit/c1a4bd469dcb4d558eac2d60d4ed91bc27060507

Can you make sure you pull latest master?

Also i'm not sure where gc633edc came from, I don't see that upstream (was it a local commit or local history)?

psafont commented 7 years ago

Hmmm I just cloned the repo and run both docker commands, one for building the build image, the other for the package.

I'm on this commit when running them (which should include https://github.com/hughsie/fwupd/commit/c1a4bd469dcb4d558eac2d60d4ed91bc27060507 according to git log): 

commit c633edc773aaff08a6bbd1e2b14b4b10a683813a (HEAD -> master, origin/master, origin/HEAD)
Author: Richard Hughes <richard@hughsie.com>
Date:   2017-07-07 13:41:49 +0100

    unifying: Don't log a warning when an unknown report is parsed

    Fixes: https://github.com/hughsie/fwupd/issues/151
superm1 commented 7 years ago

Hmm yeah. Did you kill fwupd daemon process after installing (if it was running from an earlier version)?

psafont commented 7 years ago

You were right:

fwupdmgr update
Downloading 0.1.16.4 for Latitude E7470 System Firmware...
Updating 0.1.16.4 on Latitude E7470 System Firmware...
Decompressing…         Retrying as an offline update...
Scheduling…            UEFI firmware update failed: efivarfs.c:230 efivarfs_get_variable(): open(/sys/firmware/efi/efivars/fwupdate-212026ee-fde4-4d08-ac41-c62cb4036a42-0-0abba7dc-e516-4167-bbf5-4d9d1c739416): No such file or directory
superm1 commented 7 years ago

Ah great. So the problem is libfwup can't read the EFI variable in sysfs.

Can you browse to that directory /sys/firmware/efi/efivars? Eg is your kernel compiled with CONFIG_EFI_VARS support?

Can you share you kernel config snippet of the EFI section?


#
# EFI (Extensible Firmware Interface) Support
#
CONFIG_EFI_VARS=y
CONFIG_EFI_ESRT=y
CONFIG_EFI_VARS_PSTORE=m
# CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE is not set
CONFIG_EFI_RUNTIME_MAP=y
# CONFIG_EFI_FAKE_MEMMAP is not set
CONFIG_EFI_RUNTIME_WRAPPERS=y
# CONFIG_EFI_BOOTLOADER_CONTROL is not set
# CONFIG_EFI_CAPSULE_LOADER is not set
# CONFIG_EFI_TEST is not set
CONFIG_APPLE_PROPERTIES=y
CONFIG_UEFI_CPER=y
CONFIG_EFI_DEV_PATH_PARSER=y
hughsie commented 7 years ago

CONFIG_EFI_VARS

If this is indeed unset (good detective work!) can we detect this before we offer the update? Although, this does mean the user would never get the GUI notification...

superm1 commented 7 years ago

Yeah I was thinking perhaps from coldplug the plugin could check if the sysfs directory exists. If it doesn't, then set plugin as not updatable offline to avoid this error and put a warning in fwupd daemon log.

psafont commented 7 years ago

I'm using the default arch kernel:

$ uname -r
4.11.9-1-ARCH
$ cat /proc/config.gz | gunzip | grep CONFIG_EFI_VARS
# CONFIG_EFI_VARS is not set

But I can list and navigate to the folder:

$ ls /sys/firmware/efi/efivars | head
AssetTag-01368881-c4ad-4b1d-b631-d57a8ec8db6b
BiosGuardCapsuleVariable-368b3153-563d-4610-8d94-47a9fa8c4c16
BiosGuardRecoveryAddressVariable-368b3152-563d-4670-8d94-47a9fa8c4c16
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0006-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootFFF7-5990c250-676b-4ff7-8a0d-529319d0b254
BootFFF8-5990c250-676b-4ff7-8a0d-529319d0b254
BootFFFB-5990c250-676b-4ff7-8a0d-529319d0b254
superm1 commented 7 years ago

I believe efivar writes into/sys/firmware/efi/varsand then reads from/sys/firmware/efivars (both are different kernel conf options though). Do you have /sys/firmware/efi/vars?

Can you share that whole section?

psafont commented 7 years ago

/sys/firmware/efi/vars doesn't exist in the fs, as for the EFI section:

#
# EFI (Extensible Firmware Interface) Support
#
# CONFIG_EFI_VARS is not set
CONFIG_EFI_ESRT=y
CONFIG_EFI_RUNTIME_MAP=y
# CONFIG_EFI_FAKE_MEMMAP is not set
CONFIG_EFI_RUNTIME_WRAPPERS=y
CONFIG_EFI_CAPSULE_LOADER=m
# CONFIG_EFI_TEST is not set
CONFIG_APPLE_PROPERTIES=y
CONFIG_UEFI_CPER=y
CONFIG_EFI_DEV_PATH_PARSER=y
superm1 commented 7 years ago

So efivar is supposed to walk through a list of backends from what I can tell. https://github.com/rhboot/efivar/blob/e75634066b32def3ecc74525d7a4266566c3ca68/src/lib.c#L247

The efivars backend (/sys/firmare/efi/efivars) is supposed to be first, then vars backend (/sys/firmware/efi/vars). So I think that backend should be used anyway, missing having CONFIG_EFI_VARSI don't think is the right root cause.

Do you have any fwupdate-* variables in /sys/firmware/efi/efivars as it stands? Can you share the lsattrinformation if so?

tomhughes commented 7 years ago

So CONFIG_EFI_VARS is the older interface (at /sys/firmware/efi/vars I assume) and CONFIG_EFIVAR_FS is the newer interface (normally at /sys/firmware/efi/efivars) which avoids the 1024 byte variable size limit according to the kernel source, though I don't know how that limit in the old interface presents itself.

psafont commented 7 years ago

@superm1 There aren't any files starting withfwupdate- in there.

superm1 commented 7 years ago

@psafont Do you have apparmor or SELinux configured that might cause apps to be unable to touch stuff in /sys/? Can you manually touch that file to create it? (If so, please remove it after touching it until we have this figured out).

You're on systemd 233 right? I can't imagine it's systemd confinement problems, but additionally anything in your journalctl log about systemd confinement of fwupd not working right?

psafont commented 7 years ago

I'm not at work right, I'll continue tomorrow.

And thanks for the troubleshooting :) (yes, I'm systemd 233)

superm1 commented 7 years ago

OK other than checking for that confinement stuff I've added another commit today that will display the full trace of efivar errors (not just the first). Can you (or anyone else affected) git pull, recompile and try again?

Errors might be more informative. Specifically fwupdate's get_info does call to check for an existing variable, but it looks to me that it has a case for if the existing variable doesn't exist that it's supposed to be following. The rest of the error trace may show more messages about what is happening.

Also I realized I was reading the git describe output wrong earlier. that g that's prefixed in the hash is to indicate the start of the hash, my apology.

psafont commented 7 years ago

So I've checked and I don't have neither SELinux nor Apparmor (default kernel in Arch isn't configured to use them) As for the logs, I couldn't find anything eye-catching in there.

I cannot create files in that directory:

# touch test.file
touch: setting times of 'test.file': Invalid argument

Is it related to how systemd mounts it?

with the new HEAD I get 11 errors when updating:

$ fwupdmgr update
Downloading 0.1.16.4 for Latitude E7470 System Firmware...
Updating 0.1.16.4 on Latitude E7470 System Firmware...
Decompressing…         Retrying as an offline update...
Scheduling…            UEFI firmware update failed:
{error #0} efivarfs.c:230 efivarfs_get_variable(): open(/sys/firmware/efi/efivars/fwupdate-212026ee-fde4-4d08-ac41-c62cb4036a42-0-0abba7dc-e516-4167-bbf5-4d9d1c739416): No such file or directory
{error #1} lib.c:152 efi_get_variable(): ops->get_variable failed: No such file or directory
{error #2} efivarfs.c:230 efivarfs_get_variable(): open(/sys/firmware/efi/efivars/fwupdate-212026ee-fde4-4d08-ac41-c62cb4036a42-0-0abba7dc-e516-4167-bbf5-4d9d1c739416): No such file or directory
{error #3} lib.c:152 efi_get_variable(): ops->get_variable failed: No such file or directory
{error #4} efivarfs.c:230 efivarfs_get_variable(): open(/sys/firmware/efi/efivars/fwupdate-212026ee-fde4-4d08-ac41-c62cb4036a42-0-0abba7dc-e516-4167-bbf5-4d9d1c739416): No such file or directory
{error #5} lib.c:152 efi_get_variable(): ops->get_variable failed: No such file or directory
{error #6} libfwup.c:1190 get_fd_and_media_path(): mkostemps(/boot/efi/EFI/arch/fw/fwupdate-eydR49.cap) failed: No such file or directory
{error #7} efivarfs.c:230 efivarfs_get_variable(): open(/sys/firmware/efi/efivars/fwupdate-212026ee-fde4-4d08-ac41-c62cb4036a42-0-0abba7dc-e516-4167-bbf5-4d9d1c739416): No such file or directory
{error #8} lib.c:152 efi_get_variable(): ops->get_variable failed: No such file or directory
{error #9} efivarfs.c:230 efivarfs_get_variable(): open(/sys/firmware/efi/efivars/fwupdate-212026ee-fde4-4d08-ac41-c62cb4036a42-0-0abba7dc-e516-4167-bbf5-4d9d1c739416): No such file or directory
{error #10} lib.c:152 efi_get_variable(): ops->get_variable failed: No such file or directory
{error #11} libfwup.c:1190 get_fd_and_media_path(): mkostemps(/boot/efi/EFI/arch/fw/fwupdate-u1v9Jt.cap) failed: No such file or directory
superm1 commented 7 years ago

The unable to touch I think you need to touch a file with the full guid.

Ok I am suspecting the first 10 are misnomers because get_info and put_info have a special case to follow if they don't exist.

That last error number 11 however might be the real problem. See https://github.com/rhboot/fwupdate/pull/68

Where do you have your EFI system partition? I think it would be a good idea to include that patch in fwupdate even before it was accepted upstream.

In your EFI system partition is there an "fw" directory?

psafont commented 7 years ago

The folder /boot/efi/EFI/arch doesn't exist, shouldn't it try to use /boot/efi/EFI/Manjaro? (as per https://github.com/hughsie/fwupd/issues/100#issuecomment-314102210) In any case, there is no fw folder:

$ tree -d /boot/efi/
/boot/efi/
└── EFI
    ├── boot
    └── Manjaro
superm1 commented 7 years ago

Since you switched to arch, fwupdate arch package is compiled to use that above directory. It doesn't look at existing boot entries to figure out what to use. It's explicitly compiled with a particular path.

It sounds like the fwupdate arch package is probably missing the the fw subdirectory.

For now, I would make it manually exactly as fwupdate as compiled is expecting it. # mkdir -p /boot/efi/EFI/arch/fw/

@ArchangeGabriel from glancing over https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/fwupdate it looks like it is not creating the 'fw' directory on the ESP.

superm1 commented 7 years ago

@ArchangeGabriel If it's not possible to do this in PKGBUILD for whatever reason, here's another way to do it that I threw together. Maybe carry that in packaging until it gets merged and the next release of fwupdate is made. https://github.com/rhboot/fwupdate/pull/72

psafont commented 7 years ago

Progress, I get a new error:

$ fwupdmgr update
Downloading 0.1.16.4 for Latitude E7470 System Firmware...
Updating 0.1.16.4 on Latitude E7470 System Firmware...
Decompressing…         Retrying as an offline update...
Scheduling…            UEFI firmware update failed:
{error #0} libfwup.c:733 get_paths(): could not find shim or fwup on ESP: No such file or directory
{error #1} libfwup.c:860 set_up_boot_next(): could not find paths for shim and fwup: No such file or directory

And after running it:

$ tree /boot/efi/
/boot/efi/
└── EFI
    ├── arch
    │   └── fw
    │       └── fwupdate-f8NVMC.cap
    ├── boot
    │   └── bootx64.efi
    └── Manjaro
        └── grubx64.efi
superm1 commented 7 years ago

You're missing fwupx64.efi. Looking at @ArchangeGabriel 's packaging it's something you are manually supposed to do.

superm1 commented 7 years ago

So in summary from all this discussion:

  1. fwupdate errors 0-10 in https://github.com/hughsie/fwupd/issues/100#issuecomment-314371610, about unable to read EFI variables are red herrings ( https://github.com/rhboot/fwupdate/pull/73 to fwupdate submitted to fwupdate to fix this and make it clearer for future debugging)
  2. fwupdate errors about unable to write fwupdate-XXXXX.cap are valid because the 'fw' directory was missing. ( https://github.com/rhboot/fwupdate/pull/72 submitted to create this dynamically - so Arch packaging needs to fix this or carry that patch)
  3. fwupdate errors about unable to find fwup or shim are valid because the EFI application needs to be on the ESP. Arch packaging doesn't do this currently and either needs to tell the user to do it or do it in a post-install step.

@ArchangeGabriel i'm guessing arch packaging isn't doing this placing bootloader currently because people can choose what to do with their own bootloaders in Arch. In your post-install script for fwupdate, can you detect which configuration they're using (via the presence of /boot/efi mountpoint perhaps) and do the right thing?

luzpaz commented 7 years ago

@superm1 are these fixes in 0.9.5 or in the upcoming 0.9.6 ? CC @heftig

superm1 commented 7 years ago

@luzpaz The stuff that shows more verbose information on the errors will be part of fwupd 0.9.6. If you want to run/test it locally, you can backport the two commits(https://github.com/hughsie/fwupd/commit/c1a4bd469dcb4d558eac2d60d4ed91bc27060507 and https://github.com/hughsie/fwupd/commit/c7e53224540b794e27ae3b506bd53a838c4d0589) or you can run master. You can build local builds with the docker scripts.

The stuff I mentioned in my 2 above bullet points are part of the fwupdate project, not fwupd project. They haven't yet been reviewed, but will probably be part of the 10 release of fwupdate if accepted.