Bug 1489942 - dbxtool fails at boot 'Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Permission denied'
Summary: dbxtool fails at boot 'Could not apply database update "DBXUpdate-2016-08-09-...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dbxtool
Version: 27
Hardware: aarch64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
Keywords:
Depends On:
Blocks: ARMTracker F27FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2017-09-08 18:07 UTC by Paul Whalen
Modified: 2018-03-22 16:36 UTC (History)
15 users (show)

(edit)
Clone Of:
: 1516599 (view as bug list)
(edit)
Last Closed: 2017-10-30 01:52:34 UTC


Attachments (Terms of Use)
strace.dbxtool.txt (7.21 KB, text/plain)
2017-10-11 20:16 UTC, Paul Whalen
no flags Details
strace.dbxtool.txt (Thu Oct 19 12:41:38 EDT 2017) (6.05 KB, text/plain)
2017-10-19 16:42 UTC, Dusty Mabe
no flags Details
dbxtool-8-2.fc27.aarch64 strace (6.04 KB, text/plain)
2017-10-19 17:42 UTC, Paul Whalen
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1508808 None CLOSED dbxtool service fails to start - EFI Signature List is malformed 2019-03-26 11:40 UTC

Internal Trackers: 1508808

Description Paul Whalen 2017-09-08 18:07:45 UTC
Description of problem:
dbxtool fails at boot 'Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Permission denied'


Version-Release number of selected component (if applicable):
dbxtool-7-6.fc27.aarch64

How reproducible:
always

Steps to Reproduce:
1. Install on aarch64 using Fedora-27-20170901.n.1

[root@seattle ~]# systemctl --all --failed
  UNIT            LOAD   ACTIVE SUB    DESCRIPTION                        
● dbxtool.service loaded failed failed Secure Boot DBX (blacklist) updater

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

1 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.
[root@seattle ~]# systemctl status dbxtool.service
● dbxtool.service - Secure Boot DBX (blacklist) updater
   Loaded: loaded (/usr/lib/systemd/system/dbxtool.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2017-09-08 13:03:12 EDT; 38min ago
  Process: 665 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ (code=exited, status=1/FAILURE)
 Main PID: 665 (code=exited, status=1/FAILURE)

Sep 08 13:03:12 localhost.localdomain systemd[1]: Started Secure Boot DBX (blacklist) updater.
Sep 08 13:03:12 localhost.localdomain dbxtool[665]: Applying 1 updates
Sep 08 13:03:12 localhost.localdomain dbxtool[665]: Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21
Sep 08 13:03:12 localhost.localdomain dbxtool[665]: Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Permission denied
Sep 08 13:03:12 localhost.localdomain dbxtool[665]: Cannot Continue.: Permission denied
Sep 08 13:03:12 localhost.localdomain systemd[1]: dbxtool.service: Main process exited, code=exited, status=1/FAILURE
Sep 08 13:03:12 localhost.localdomain systemd[1]: dbxtool.service: Unit entered failed state.
Sep 08 13:03:12 localhost.localdomain systemd[1]: dbxtool.service: Failed with result 'exit-code'.


Expected results:
No failed services.

Comment 1 Mads Villadsen 2017-09-16 11:55:18 UTC
I'm seeing the same problem on x86 with dbxtool-7-6.fc27.x86_64

Comment 2 Dusty Mabe 2017-10-11 18:11:54 UTC
is this a blocker for f27 ? can we submit it as a blocker if it is ?

Comment 3 Dusty Mabe 2017-10-11 18:12:36 UTC
FYI we are seeing this in atomic as well: https://pagure.io/atomic-wg/issue/348

Comment 4 Dusty Mabe 2017-10-11 18:27:35 UTC
14:25:09    pjones | can you get an strace of it running?
14:25:25 dustymabe | an strace of dbxtool? 
14:25:45    pjones | yeah
14:26:06 dustymabe | i can try 
14:26:10    pjones | probably just "sudo strace -o dbxtool.strace dbxtool -a"

ksinny/pwhalen, can we get that output?

Comment 5 Paul Whalen 2017-10-11 20:16:07 UTC
[root@seattle ~]# strace -o strace.dbxtool.txt dbxtool -a /usr/share/dbxtool/DBXUpdate-2016-08-09-13-16-00.bin
Applying 1 updates
Applying "/usr/share/dbxtool/DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21
Could not apply database update "/usr/share/dbxtool/DBXUpdate-2016-08-09-13-16-00.bin": Permission denied
Cannot Continue.: Permission denied

Comment 6 Paul Whalen 2017-10-11 20:16 UTC
Created attachment 1337411 [details]
strace.dbxtool.txt

Comment 7 Peter Jones 2017-10-17 20:52:40 UTC
So, this is really quite perplexing:
> openat(AT_FDCWD, "/sys/firmware/efi/efivars/dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f", O_WRONLY|O_CREAT, 000) = 3
> ioctl(3, FS_IOC_GETFLAGS, 0xfffffd98b104) = 0
> ioctl(3, FS_IOC_SETFLAGS, 0xfffffd98b104) = 0
> write(3, "g\0\0\0\332\7\3\6\23\21\25\0\0\0\0\0\0\0\0\0\21\r\0\0\0\2\361\16\235\322\257J"..., 7089) = -1 EACCES (Permission denied)

That basically says the file isn't there, but we also can't write to it when it's created.  Normally this means Secure Boot is enabled but the Key Exchange Key is a different one than our dbx was created with.  Does the machine have secure boot enabled at all?  Can you attach the results of:

tar cf sb.tar.gz /sys/firmware/efi/efivars/{{PK,KEK}-8be4df61-93ca-11d2-aa0d-00e098032b8c,*-d719b2cb-3d3a-4596-a3bc-dad00e67656f}

Comment 8 Dusty Mabe 2017-10-17 21:53:19 UTC
This is actually very easy to reproduce using a UEFI x86_64 VM and an atomic host ISO [1]. Just boot up the VM and run through the anaconda install giving it all the defaults. 

[1] https://kojipkgs.fedoraproject.org/compose/branched/Fedora-27-20171017.n.0/compose/Atomic/x86_64/iso/Fedora-Atomic-ostree-x86_64-27-20171017.n.0.iso

I see the same strace output as reported by pwhalen. None of those files that you are asking for exist on my system:

[root@localhost ~]# rpm -q grub2-efi-x64 dbxtool kernel
grub2-efi-x64-2.02-18.fc27.x86_64
dbxtool-7-6.fc27.x86_64
kernel-4.13.5-300.fc27.x86_64
[root@localhost ~]# ls -1 /sys/firmware/efi/efivars/
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot000A-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
ErrOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
Key0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
Key0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c
LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
MemoryOverwriteRequestControl-e20939be-32d4-41be-a150-897f85d49829
MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23
MTC-eb704011-1402-11d3-8e77-00a0c969723b
OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
PlatformRecovery0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
VarErrorFlag-04b37fe8-f6ae-480b-bdd5-37d98c5e89aa

Comment 9 Dusty Mabe 2017-10-17 22:07:14 UTC
Note this also happens for a UEFI x86_64 VM install using the (non-atomic) Everything netinstall ISO. 

https://kojipkgs.fedoraproject.org/compose/branched/Fedora-27-20171017.n.0/compose/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-27-20171017.n.0.iso

going to propose this as a blocker for f27.

Comment 10 Fedora Blocker Bugs Application 2017-10-17 22:08:31 UTC
Proposed as a Blocker for 27-final by Fedora user dustymabe using the blocker tracking app because:

 systemd unit failure on UEFI x86_64 VMs with a vanilla install.

Comment 11 Peter Jones 2017-10-18 17:39:17 UTC
So I think what's going on here is the firmware added the feature that doesn't allow you to create variables in the global namespace that aren't defined in the spec, only they picked "not defined in features we implement" instead of "not defined at all".

Comment 12 Fedora Update System 2017-10-18 17:46:23 UTC
dbxtool-8-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-671a614067

Comment 13 Adam Williamson 2017-10-18 19:01:45 UTC
The criterion here is "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present."

Comment 14 Fedora Update System 2017-10-19 15:23:02 UTC
dbxtool-8-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-671a614067

Comment 15 Dusty Mabe 2017-10-19 16:10:55 UTC
dbxtool-8-1.fc27 does not seem to fix the problem for me: 

```
[root@localhost ~]# systemctl status dbxtool.service 
● dbxtool.service - Secure Boot DBX (blacklist) updater
   Loaded: loaded (/usr/lib/systemd/system/dbxtool.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2017-10-19 12:06:36 EDT; 2min 41s ago
  Process: 747 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ -q -f (code=exited, status=1/FAILURE)
 Main PID: 747 (code=exited, status=1/FAILURE)

Oct 19 12:06:36 localhost.localdomain systemd[1]: Started Secure Boot DBX (blacklist) updater.
Oct 19 12:06:36 localhost.localdomain dbxtool[747]: Applying 1 updates
Oct 19 12:06:36 localhost.localdomain dbxtool[747]: Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21
Oct 19 12:06:36 localhost.localdomain dbxtool[747]: Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Invalid argument
Oct 19 12:06:36 localhost.localdomain dbxtool[747]: Cannot Continue.: Invalid argument
Oct 19 12:06:36 localhost.localdomain systemd[1]: dbxtool.service: Main process exited, code=exited, status=1/FAILURE
Oct 19 12:06:36 localhost.localdomain systemd[1]: dbxtool.service: Unit entered failed state.
Oct 19 12:06:36 localhost.localdomain systemd[1]: dbxtool.service: Failed with result 'exit-code'.
[root@localhost ~]# 
[root@localhost ~]# 
[root@localhost ~]# rpm -q dbxtool 
dbxtool-8-1.fc27.x86_64
```

Comment 16 Dusty Mabe 2017-10-19 16:41:12 UTC
I ran an strace again:

```
# strace -o strace.dbxtool.txt dbxtool -a /usr/share/dbxtool                                                                         
dbxtool: PK is not set on this system.
dbxtool: KEK is not set on this system.
dbxtool: Not attempting to apply updates.

```

Comment 17 Dusty Mabe 2017-10-19 16:42 UTC
Created attachment 1340833 [details]
strace.dbxtool.txt (Thu Oct 19 12:41:38 EDT 2017)

Comment 18 Fedora Update System 2017-10-19 16:54:19 UTC
dbxtool-8-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-671a614067

Comment 19 Paul Whalen 2017-10-19 17:40:52 UTC
[root@mustang ~]# rpm -q dbxtool
dbxtool-8-2.fc27.aarch64
[root@mustang ~]# systemctl status dbxtool
● dbxtool.service - Secure Boot DBX (blacklist) updater
   Loaded: loaded (/usr/lib/systemd/system/dbxtool.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2017-07-12 09:02:23 CDT; 3 months 7 days ago
  Process: 1375 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ -q (code=exited, status=1/FAILURE)
 Main PID: 1375 (code=exited, status=1/FAILURE)

Jul 12 09:02:22 localhost.localdomain systemd[1]: Started Secure Boot DBX (blacklist) updater.
Jul 12 09:02:23 localhost.localdomain systemd[1]: dbxtool.service: Main process exited, code=exited, status=1/FAILURE
Jul 12 09:02:23 localhost.localdomain systemd[1]: dbxtool.service: Unit entered failed state.
Jul 12 09:02:23 localhost.localdomain systemd[1]: dbxtool.service: Failed with result 'exit-code'.
[root@mustang ~]# strace -o strace.dbxtool.txt dbxtool -a /usr/share/dbxtool
dbxtool: PK is not set on this system.
dbxtool: KEK is not set on this system.
dbxtool: Not attempting to apply updates.

Comment 20 Paul Whalen 2017-10-19 17:42 UTC
Created attachment 1340853 [details]
dbxtool-8-2.fc27.aarch64 strace

Comment 21 Dusty Mabe 2017-10-19 17:47:08 UTC
fails for me too: 

```
[root@localhost ~]# rpm -q dbxtool 
dbxtool-8-2.fc27.x86_64
[root@localhost ~]# dbxtool -a /usr/share/dbxtool
dbxtool: PK is not set on this system.
dbxtool: KEK is not set on this system.
dbxtool: Not attempting to apply updates.
[root@localhost ~]# echo $?
1
```

Comment 22 Adam Williamson 2017-10-20 00:34:13 UTC
If this is aarch64 specific, it cannot possibly be a release blocker, as aarch64 is not a release-blocking arch at present. The release-blocking arches for F27 are armhfp and x86_64.

Comment 23 Dusty Mabe 2017-10-20 01:32:05 UTC
(In reply to Adam Williamson from comment #22)
> If this is aarch64 specific, it cannot possibly be a release blocker, as
> aarch64 is not a release-blocking arch at present. The release-blocking
> arches for F27 are armhfp and x86_64.

This is not aarch64 specific. We need to add a "does `systemctl --failed` pass?" test to our Atomic Host ISO tests and our Everything ISO installer test. That would have uncovered these problems.

Comment 24 Adam Williamson 2017-10-20 16:35:33 UTC
Oh, OK. We already do such a test in openQA, but from BIOS installs, not UEFI installs.

Comment 25 Gleidson Baleeiro 2017-10-20 21:19:07 UTC
The problem persist on x86_64 arch.

$ rpm -qa dbxtool 
dbxtool-8-1.fc27.x86_64


$ /usr/bin/dbxtool -a /usr/share/dbxtool/ -q -f
dbxtool: EFI Signature List is malformed
dbxtool: list has 2343 bytes left, element is 1691 bytes
$ echo $?
1

$ systemctl status dbxtool 
● dbxtool.service - Secure Boot DBX (blacklist) updater
   Loaded: loaded (/usr/lib/systemd/system/dbxtool.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2017-10-20 18:57:05 -02; 14min ago
  Process: 957 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ -q -f (code=exited, status=1/FAILURE)
 Main PID: 957 (code=exited, status=1/FAILURE)
      CPU: 11ms

Oct 20 18:57:01 inspiron7000 systemd[1]: Started Secure Boot DBX (blacklist) updater.
Oct 20 18:57:02 inspiron7000 dbxtool[957]: dbxtool: EFI Signature List is malformed
Oct 20 18:57:02 inspiron7000 dbxtool[957]: dbxtool: list has 2343 bytes left, element is 1691 bytes
Oct 20 18:57:05 inspiron7000 systemd[1]: dbxtool.service: Main process exited, code=exited, status=1/FAILURE
Oct 20 18:57:05 inspiron7000 systemd[1]: dbxtool.service: Unit entered failed state.
Oct 20 18:57:05 inspiron7000 systemd[1]: dbxtool.service: Failed with result 'exit-code'.

How can i help with this problem ?

Comment 26 Adam Williamson 2017-10-20 21:24:54 UTC
Well, for a start can you test with 8-2 rather than 8-1? that's the most recent attempt to fix this. though Dusty and Paul already report that it doesn't work, so my hopes aren't high. Other than that I'm not sure there's a lot you can do, as pjones can probably reproduce the bug quite trivially locally and just has to come up with a fix that actually works...

Comment 27 Dusty Mabe 2017-10-21 14:42:57 UTC
(In reply to Adam Williamson from comment #24)
> Oh, OK. We already do such a test in openQA, but from BIOS installs, not
> UEFI installs.

can you add that test to UEFI installs, or can you show me how?

Comment 28 Matthew Miller 2017-10-21 17:32:32 UTC
+1 blocker based on the criteria Adam quotes

Comment 29 Fedora Update System 2017-10-21 19:26:18 UTC
dbxtool-8-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-671a614067

Comment 30 Gleidson Baleeiro 2017-10-22 22:30:06 UTC
The problem persist with version dbxtool-8-2.fc27.x86_64

● dbxtool.service - Secure Boot DBX (blacklist) updater
   Loaded: loaded (/usr/lib/systemd/system/dbxtool.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2017-10-22 19:21:54 -02; 45min ago
  Process: 920 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ -q (code=exited, status=1/FAILURE)
 Main PID: 920 (code=exited, status=1/FAILURE)
      CPU: 9ms

Oct 22 19:21:52 inspiron7000 systemd[1]: Started Secure Boot DBX (blacklist) updater.
Oct 22 19:21:52 inspiron7000 dbxtool[920]: dbxtool: EFI Signature List is malformed
Oct 22 19:21:52 inspiron7000 dbxtool[920]: dbxtool: list has 2343 bytes left, element is 1691 bytes
Oct 22 19:21:54 inspiron7000 systemd[1]: dbxtool.service: Main process exited, code=exited, status=1/FAILURE
Oct 22 19:21:54 inspiron7000 systemd[1]: dbxtool.service: Unit entered failed state.
Oct 22 19:21:54 inspiron7000 systemd[1]: dbxtool.service: Failed with result 'exit-code'.

Comment 31 Gleidson Baleeiro 2017-10-22 23:14:52 UTC
my system configuration 

           /:-------------:\          gleidson@inspiron7000
        :-------------------::        OS: Fedora 27 TwentySeven
      :-----------/shhOHbmp---:\      Kernel: x86_64 Linux 4.13.8-300.fc27.x86_64
    /-----------omMMMNNNMMD  ---:     Uptime: 1h 53m
   :-----------sMMMMNMNMP.    ---:    Packages: 3304
  :-----------:MMMdP-------    ---\   Shell: zsh 5.4.1
 ,------------:MMMd--------    ---:   Resolution: 3840x1080
 :------------:MMMd-------    .---:   DE: GNOME 
 :----    oNMMMMMMMMMNho     .----:   WM: GNOME Shell
 :--     .+shhhMMMmhhy++   .------/   WM Theme: 
 :-    -------:MMMd--------------:    GTK Theme: Arc [GTK2/3]
 :-   --------/MMMd-------------;     Icon Theme: Papirus
 :-    ------/hMMMy------------:      Font: Cantarell 11
 :-- :dMNdhhdNMMNo------------;       CPU: Intel Core i7-7500U @ 4x 3.5GHz [25.0°C]
 :---:sdNMMMMNds:------------:        GPU: intel
 :------:://:-------------::          RAM: 2367MiB / 15942MiB
 :---------------------://

Comment 32 Geoffrey Marr 2017-10-23 19:30:48 UTC
Discussed during the 2017-10-23 blocker review meeting: [1]

The decision to classify this bug as a RejectedBlocker and an AcceptedFreezeException was made on the basis that this bug will not affect all installs and there is no practical consequence to the bug. Fixing this will improve the "polish" of Fedora and can't be accomplished with an update, so it has been accepted as an FE.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2017-10-23/f27-blocker-review.2017-10-23-16.00.txt

Comment 33 Fedora Update System 2017-10-24 16:45:45 UTC
dbxtool-8-3.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-671a614067

Comment 34 Paul Whalen 2017-10-24 17:02:36 UTC
dbxtool-8-3.fc27 is working with no failure on boot

[root@mustang ~]# systemctl --all --failed
0 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.
[root@mustang ~]# systemctl status dbxtool
● dbxtool.service - Secure Boot DBX (blacklist) updater
   Loaded: loaded (/usr/lib/systemd/system/dbxtool.service; enabled; vendor pres
   Active: active (exited) since Wed 2017-07-12 10:01:23 EDT; 3 months 12 days a
  Process: 617 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ -q (code=exited
 Main PID: 617 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/dbxtool.service

Jul 12 10:01:23 localhost.localdomain systemd[1]: Started Secure Boot DBX (black
[root@mustang ~]# rpm -q dbxtool
dbxtool-8-3.fc27.aarch64

Comment 35 Fedora Update System 2017-10-25 15:22:42 UTC
dbxtool-8-3.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-671a614067

Comment 36 Gleidson Baleeiro 2017-10-25 16:06:58 UTC
The initial problem of permission denied was resolved, but at my laptop x86_64 (arch) the problem of comment #30 persist. 

Is it some misconfiguration no my system?

Comment 37 Gleidson Baleeiro 2017-10-25 16:08:36 UTC
test of comment #36 was using dbxtool-8-3.fc27.x86_64

Comment 38 Adam Williamson 2017-10-25 16:41:51 UTC
gleidson: it looks like you're seeing a system-specific problem that's different from everyone else's:

dbxtool: EFI Signature List is malformed

that sounds like dbxtool thinks something's wrong with the signatures stored in your system's list. It should probably be followed up separately, but I'm not sure a bug report's the right way, as at least on the face of it, dbxtool isn't actually doing anything 'wrong', it's reporting an unexpected and apparently incorrect situation it's found in your system firmware. pjones may have ideas about how to deal with it.

Comment 39 Fedora Update System 2017-10-30 01:52:34 UTC
dbxtool-8-3.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Comment 40 Peter Jones 2017-10-30 15:31:03 UTC
(If you could open an issue about the "Signature List is malformed" thing on https://github.com/rhboot/dbxtool/issues , that would be good.  Please include the command line you used, etc.)

Comment 41 Alvin 2017-11-21 12:25:08 UTC
dbxtool-8-3.fc27 here:

● dbxtool.service - Secure Boot DBX (blacklist) updater
   Loaded: loaded (/usr/lib/systemd/system/dbxtool.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2017-11-21 13:19:18 CET; 3min 40s ago
  Process: 7667 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ -q (code=exited, status=1/FAILURE)
 Main PID: 7667 (code=exited, status=1/FAILURE)

systemd[1]: Started Secure Boot DBX (blacklist) updater.
dbxtool[7667]: Applying 1 updates
dbxtool[7667]: Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21
dbxtool[7667]: Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Operation not permitted
dbxtool[7667]: Cannot Continue.: Operation not permitted
systemd[1]: ^[[0;1;39mdbxtool.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: ^[[0;1;39mdbxtool.service: Unit entered failed state.
systemd[1]: ^[[0;1;39mdbxtool.service: Failed with result 'exit-code'.


Note You need to log in before you can comment on or make changes to this bug.