UEFI firmware update failed: Unknown error -1

[fwupd]

UEFI firmware update failed: Unknown error -1

[superm1]

There's a few common causes for this, but we'll have to narrow down some details.

Which distribution do you have installed?

What version of efivar, fwupd and fwupdate are installed?

Do you have secure boot turned on?

What kernel version installed?

Can you please kill fwupd and manually restart it with the debug flag turned on? Check output from its console when this error occurs.

[GTB3NW]

Which distribution do you have installed?

Arch Linux

What version of efivar, fwupd and fwupdate are installed?

efivar 30-1
fwupd 0.7.5-1
fwupdate 8-1

Do you have secure boot turned on?

Nope

What kernel version installed?

Linux archbook 4.8.12-3-ARCH #1 SMP PREEMPT Thu Dec 8 16:10:23 CET 2016 x86_64 GNU/Linux

Can you please kill fwupd and manually restart it with the debug flag turned on?

I've killed the process but I'm honestly not too sure how to start fwupd with the debug flag. It looks like the daemon is automatically started when you run fwupdmgr. It runs as root so I suspect there's some kind of socket hook to spawn the daemon since I run fwupdmgr as non-root. Couldn't find any service files.

sudo /usr/lib/fwupd/fwupd/fwupd -v
15:00:46	Verbose debugging enabled (on console 1)
15:00:46	adding plugin /usr/lib/fwupd-plugins-1/libfu_plugin_steelseries.so
15:00:46	adding plugin /usr/lib/fwupd-plugins-1/libfu_plugin_test.so
15:00:46	performing init() on test
15:00:46	Loading fallback values from /etc/fwupd.conf
15:00:46	adding udev device: /sys/devices/pci0000:00/0000:00:02.0
15:00:46	using 3ec3df3a-2290-56e5-9d2f-eda62e9ab50b for 0x8086:0x5916
15:00:46	emit added from Udev: ro__sys_devices_pci0000_00_0000_00_02_0
15:00:46	emit added from UEFI: UEFI-48af7d21-3145-4f5e-b1b4-c8fc67b6e646-dev0
Failed to get OnBattery property as no UPower
15:00:46	Failed to get OnBattery property as no UPower
Failed to coldplug: Dell: firmware updating not supported (0)
15:00:46	Failed to coldplug: Dell: firmware updating not supported (0)
15:00:47	using 4ec19583-c132-5c27-a9cf-061419e838dc for USB\VID_0C45&PID_670C
15:00:47	using 6b31e6e6-ba7c-5251-8f4c-7f2571612251 for USB\VID_0C45&PID_670C&REV_5626
15:00:47	emit added from USB: usb:00:05
15:00:47	using 31cc46f6-9bdc-5b1e-b48b-1c791781dcdc for USB\VID_04F3&PID_20D0
15:00:47	using 9fd88db6-a96d-505b-bbea-92aee9d07455 for USB\VID_04F3&PID_20D0&REV_1112
15:00:47	emit added from USB: usb:00:04
15:00:47	no product string descriptor
###########################################                                            @0190ms AsStore:load 190ms
###########################################                                            @0190ms AsStore:load{per-system} 190ms
##########################                                                             @0114ms AsStore:store-from-file{/usr/share/app-info/xmls/extra.xml.gz} 113ms
                            #                                                          @0130ms AsStore:store-from-file{/usr/share/app-info/xmls/org.freedesktop.fwupd.xml} 5ms
                              ###########                                              @0179ms AsStore:store-from-file{/usr/share/app-info/xmls/community.xml.gz} 48ms
                                             ########################################  @0373ms FuMain:coldplug 175ms
                                              ############                             @0256ms FuMain:coldplug{Dell} 56ms
                                                           ##########################  @0373ms FuMain:coldplug{USB} 116ms
                                                           ##########################  @0372ms FuProviderUsb:added{0c45:670c} 115ms
                                                                                    #  @0371ms FuProviderUsb:get-string-desc 5ms
15:00:47	FuMain: acquired name: org.freedesktop.fwupd
15:00:47	devices now in store:
15:00:47	1	com.steelseries.rival-legacy.firmware	SteelSeries Firmware
15:00:47	2	UEFI-dummy-dev0	UEFI Updates
15:00:47	3	com.via.VL811.firmware	VL811 Firmware
15:00:47	4	com.via.VL811+.firmware	VL811+ Firmware
15:00:47	5	com.via.VL812.firmware	VL812 Firmware
15:00:47	6	com.via.VL812_B2.firmware	VL812 B2 Firmware
15:00:47	7	com.8bitdo.fc30.firmware	FC30
15:00:47	8	com.8bitdo.fc30arcade.firmware	FC30 Joystick
15:00:47	9	com.8bitdo.fc30pro.firmware	FC30 Pro
15:00:47	10	com.8bitdo.nes30.firmware	NES30
15:00:47	11	com.8bitdo.nes30pro.firmware	NES30 Pro
15:00:47	12	com.8bitdo.sfc30.firmware	SFC30
15:00:47	13	com.8bitdo.snes30.firmware	SNES30
15:00:47	14	com.dell.uefi124c207d.firmware	XPS 15 9550/Precision 5510 System Update
15:00:47	15	com.dell.uefi293af847.firmware	OptiPlex 3050 System Update
15:00:47	16	com.dell.uefi33773727.firmware	XPS 13 9350 System Update
15:00:47	17	com.dell.uefi3c20b9e1.firmware	OptiPlex 7450 AIO System Update
15:00:47	18	com.dell.uefi43ca3264.firmware	OptiPlex 7440 AIO System Update
15:00:47	19	com.dell.uefi48af7d21.firmware	XPS 13 9360 System Update
15:00:47	20	com.dell.uefi49e03513.firmware	Latitude E5X80 System Update
15:00:47	21	com.dell.uefi4fed6c9d.firmware	OptiPlex 7050 System Update
15:00:47	22	com.dell.uefi8080d214.firmware	OptiPlex 5050 System Update
15:00:47	23	com.dell.uefi8b7b32a7.firmware	Latitude E5X80 System Update
15:00:47	24	com.dell.uefia0a3aa54.firmware	Embedded Box PC 5000 System Update
15:00:47	25	com.dell.uefiaee2604a.firmware	Embedded Box PC 3000 System Update
15:00:47	26	com.dell.uefib566a9b1.firmware	OptiPlex 5250 AIO System Update
15:00:47	27	com.dell.uefid69fed57.firmware	OptiPlex 3050 AIO System Update
15:00:47	28	com.dell.uefie0f614ed.firmware	Edge Gateway 5000/5100 System Update
15:00:47	29	com.hughski.ColorHug.firmware	ColorHug
15:00:47	30	com.hughski.ColorHug2.firmware	ColorHug2
15:00:47	31	com.hughski.ColorHugALS.firmware	ColorHugALS
15:01:04	Called GetUpdates()
15:01:08	Called Install(UEFI-48af7d21-3145-4f5e-b1b4-c8fc67b6e646-dev0,0)
15:01:08	got option reason
15:01:08	got option filename
15:01:08	Emitting PropertyChanged('Status'='decompressing')
15:01:08	Using keyring at /var/lib/fwupd/gnupg
15:01:08	Adding public key /etc/pki/fwupd/GPG-KEY-Hughski-Limited
15:01:08	importing key 7E5439F64986F7A9E973809BAD8A528FEC44881E [0] Success
15:01:08	Adding public key /etc/pki/fwupd/GPG-KEY-Linux-Vendor-Firmware-Service
15:01:08	importing key 3FC6B804410ED0840D8F2F9748A6D80E4538BAC2 [0] Success
15:01:08	returned signature fingerprint 3FC6B804410ED0840D8F2F9748A6D80E4538BAC2
15:01:08	marking payload as trusted
15:01:08	Emitting PropertyChanged('Status'='idle')
15:01:08	Called Install(UEFI-48af7d21-3145-4f5e-b1b4-c8fc67b6e646-dev0,0)
15:01:08	got option reason
15:01:08	got option filename
15:01:08	got option offline
15:01:08	Emitting PropertyChanged('Status'='decompressing')
15:01:08	Using keyring at /var/lib/fwupd/gnupg
15:01:08	Adding public key /etc/pki/fwupd/GPG-KEY-Hughski-Limited
15:01:08	importing key 7E5439F64986F7A9E973809BAD8A528FEC44881E [0] Success
15:01:08	Adding public key /etc/pki/fwupd/GPG-KEY-Linux-Vendor-Firmware-Service
15:01:08	importing key 3FC6B804410ED0840D8F2F9748A6D80E4538BAC2 [0] Success
15:01:08	returned signature fingerprint 3FC6B804410ED0840D8F2F9748A6D80E4538BAC2
15:01:08	marking payload as trusted
15:01:08	Performing UEFI capsule update
15:01:08	Emitting PropertyChanged('Status'='scheduling')
15:01:08	Emitting PropertyChanged('Status'='idle')

[superm1]

Arch Linux
efivar 30-1
fwupd 0.7.5-1
fwupdate 8-1

OK so latest versions on all the packages and a kernel that has everything needed for ESRT to work correctly. That rules out the common stuff that people have mentioned recently. You're the first person I know of with an arch problem, so it's possible that it's an arch specific integration issue, but we'll need to dig into it further.

It's not the root cause of your issue, but according to that log upower isn't built in. It's worth you mentioning that to the maintainer so that they can fix that in a future arch package.

As for your specific issue unfortunately that log isn't any more useful, so we'll need to run down the list of stuff that libfwup0 (from fwupdate) does to find out where the problem is.

1. Can you check efibootmgr -v output? See if the Linux-Firmware-Updater entry was created and what it points to.
2. Check the ESP to see whether fwupx64.efi and the payload have been installed to it. You can share a recursive listing of whats on your ESP.
3. Check /sys/firmware/efi/efivars to see if any fwupdate-* entries were created. If they were, we might have to dig further into that.

[GTB3NW]

It's not the root cause of your issue, but according to that log upower isn't built in. It's worth you mentioning that to the maintainer so that they can fix that in a future arch package.

I'm not quite sure what that means to be honest. I have seen a few power related messages in the journal on early boot and shutdown. Where would I submit the bug report and what should it say. I'm just lacking the understanding of what the issue is there, once I understand that I can probably fill in the gaps and complete a bug report. Thanks for pointing it out :)

1. I'm not sure why there's entries for windows, I don't see them within the bios utility, just the single linux boot loader. shrugs

$ efibootmgr -v                                                                                                                                                 
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0003
Boot0000* Windows Boot Manager	HD(2,GPT,3518f332-d55f-4d32-8a97-45c50652194f,0xe1800,0x32000)/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.}....................
Boot0002  Linux Boot Manager	HD(1,GPT,817c2879-6db0-4b33-bec1-62ce7756cab4,0x800,0x100000)/File(\EFI\systemd\systemd-bootx64.efi)
Boot0003* Linux Boot Manager	HD(1,GPT,9f131103-0d0e-47cc-8f4b-a56d2a2b6ade,0x800,0x100000)/File(\EFI\systemd\systemd-bootx64.efi)

2. No fwup I'm afraid, when I straced before I couldn't see fwupdmgr trying to write anything like that, but maybe it's fwupd which does it..?

$ tree /esp                                                                                                                                                     
/esp
├── EFI
│   ├── arch
│   │   ├── initramfs-linux-fallback.img
│   │   ├── initramfs-linux.img
│   │   ├── intel-ucode.img
│   │   └── vmlinuz-linux
│   ├── BOOT
│   │   └── BOOTX64.EFI
│   └── systemd
│       └── systemd-bootx64.efi
└── loader
    ├── entries
    │   └── arch.conf
    └── loader.conf

3. No fwupdate efi vars according to:

$ efivar -l | grep fwupdate

I really appreciate your help :)

[superm1]

I'm not quite sure what that means to be honest. I have seen a few power related messages in the journal on early boot and shutdown. Where would I submit the bug report and what should it say. I'm just lacking the understanding of what the issue is there, once I understand that I can probably fill in the gaps and complete a bug report. Thanks for pointing it out :)

Sure. When you file the bug report, mention to the maintainer that "fwupd isn't compiled with upower support". That should be enough. You can attach your verbose log too to show that to them.

I'm not sure why there's entries for windows, I don't see them within the bios utility, just the single linux boot loader. shrugs

If you're not dual booting, feel free to delete that entry.

No fwup I'm afraid, when I straced before I couldn't see fwupdmgr trying to write anything like that, but maybe it's fwupd which does it..?

So this is the most likely problem, the package fwupdate didn't install fwupx64.efi to the ESP. As part of the installation of the CAB, it's supposed to use that to make an EFI entry to do the update on reboot.

[GTB3NW]

Sure. When you file the bug report, mention to the maintainer that "fwupd isn't compiled with upower support". That should be enough. You can attach your verbose log too to show that to them.

It's from the user repositories so it should be easy to get fixed, I can also recompile with the correct features. Thank you :)

If you're not dual booting, feel free to delete that entry.

Is this done within the bios or is there a tool to perform this?

So this is the most likely problem, the package fwupdate didn't install fwupx64.efi to the ESP. As part of the installation of the CAB, it's supposed to use that to make an EFI entry to do the update on reboot.

I've ran the tools with elevated privs so it should be able to write to those directories. Is there a command I can run manually to try and install the efi? At least then if that errors I can strace and see what's going on.

Cheers!

[superm1]

Is this done within the bios or is there a tool to perform this?

You can do it with efibootmgr. The BIOS won't show entries that don't resolve to something real.

I've ran the tools with elevated privs so it should be able to write to those directories. Is there a command I can run manually to try and install the efi? At least then if that errors I can strace and see what's going on.

So fwupdate assumes that it was properly installed (as in from make install). That means it makes an assumption that fwupx64.efi is already on the ESP in the proper location. In your install it's definitely not in the ESP.

Here is how upstream normally installs it when not packaged:
https://github.com/rhinstaller/fwupdate/blob/master/Make.defaults#L45
https://github.com/rhinstaller/fwupdate/blob/master/efi/Makefile#L100

Debian & Ubuntu both do it with a post-install script. This is because the ESP might not be available until after install is done.
https://anonscm.debian.org/cgit/uefi/fwupdate.git/tree/debian/fwupdate.postinst.in#n40
https://anonscm.debian.org/cgit/uefi/fwupdate.git/tree/debian/scripts/install.in

Fedora installs it directly into the RPM.
https://github.com/rhinstaller/fwupdate/blob/master/fwupdate.spec.in#L126

[GTB3NW]

Ahh that makes sense, I'll try get the maintainer to update. Here's the current PKGBUILD for the make section, would I add something here to get this to work correctly?

build() {
  cd "${srcdir}/${pkgname}-${pkgver}"
  
  ./autogen.sh --prefix=/usr \
               --sysconfdir=/etc \
               --localstatedir=/var \
               --libexecdir=/usr/lib/fwupd \
               --enable-uefi \
               --enable-colorhug \
               --disable-rpath
  make
}

[superm1]

That's the PKGBUILD for fwupd, you'll be looking for the one for fwupdate.

[GTB3NW]

Found the problem!

package() {
  cd "${srcdir}/${pkgname}-${pkgver}"

  make LIBDIR=/usr/lib EFIDIR=/usr/lib DESTDIR="${pkgdir}" libexecdir=/usr/lib/ install
  
  #don't install into /boot. copy files to /usr/lib/fwupdate for manual installation
  install -d ${pkgdir}/usr/lib/fwupdate
  mv ${pkgdir}/boot/efi/EFI ${pkgdir}/usr/lib/fwupdate/EFI
  rm -rf ${pkgdir}/boot
  rm -rf ${pkgdir}/usr/src
  rm -rf ${pkgdir}/usr/lib/debug
}

Which is why I couldn't see anything in /boot either, since the folders don't exist. Tad frustrating, will recompile and report back.

Also I've removed the boot loaders and didn't brick my system (Which is nice :P)

Thank you I really appreciate it!

[GTB3NW]

Please could you confirm that the directory structure should be:

EFI/fw/fwupx64.efi

Do I need to make any other changes so that the system will boot with this? Or will it be handled by fwupdmgr?

Cheers

[GTB3NW]

Looks like fwupdate by default tries to put files within /boot/efi, is there any way to change this to /esp? My /boot partition is actually a bind mount to /esp/EFI/arch. I suppose I could do a symlink back to the correct directory, would that work? <- /boot is vfat :/

[superm1]

EFIDIR needs to be properly set because it's used in fwupdate code too. I think it should be "Arch" most likely.

If you keep your esp in /esp I think you'll need to set up a symlink structure that matches a /boot/EFI structure. Fwupdate assumes it will be working in that type of structure. Otherwise expect to be laying other patches into fwupdate about using /esp.

That would be /boot/EFI/EFI/$EFIDIR/fwupx64.efi and make the directory /boot/EFI/EFI/$EFIDIR/fw for storing payloads.

[GTB3NW]

See my edit, wont be able to symlink, hopefully I will be able to do something like bind mount. Will look into it.

I only really need to apply this patch once, I'm not too fussed for ongoing updates, if I am I'm happy to do a manual method if there is one. Is there any manual method?

[superm1]

Is the /esp as a mount normal for arch, or something custom you did? If it's how arch normally does things it would be good to solve this more generally for the rest of arch users.

If it's just something odd you decided to do then sure there are manual ways to flash BIOS, but you'll hit this again when the next XPS 9360 bios is posted to LVFS again.

[GTB3NW]

Lots of people just bundle everything into /boot, however the install guide specifically mentions a bind mount setup for a cleaner install, so I wont be the only person to have this setup. Currently in IRC to see if there's any workaround for this. If there is I'll add it as a note to the wiki for the mount bind setup and specifically for fwupd in the wiki

[superm1]

Okay, so if a lot of people do this I agree it's worthwhile to come up with a good solution. This bug should probably be filed against https://GitHub.com/rhinstaller/fwupdate about coming up with a way to support this ESP not at /boot/EFI setup.

For now here is the manual way to do the update though if you want to apply it manually.
http://www.dell.com/support/article/us/en/4/SLN171755/en

[GTB3NW]

Opened a bug: rhboot/fwupdate#58

Hopefully that gets resolved. It will likely require a flag for fwupdmgr too right? I will look at applying the patch manually. Cheers!

[superm1]

Somewhere I think it makes sense to try to detect this situation has happened and will cause problems, but otherwise there shouldn't be another bug in fwupd or fwupdmgr, it's all fwupdate.

[GTB3NW]

No worries. I managed to apply the update manually (Yay my machine can wake up from suspend!)

I'll close this now since all discussion will move to fwupdate. I've added some notes to the arch wiki on this issue FYI