Bug 1508808

Can you please do the following as root and attach the resulting tarball?

tar cjf vars.tar.bz2 /sys/firmware/efi/efivars/{PK,KEK,db}*

Discussed during blocker review [1]:

RejectedBlocker RejectedFreezeException (Final) - this seems to only affect a minority of UEFI installs, based on current information. the practical consequences of the failure are not too terrible and can be fixed with a post-release update, so given the limited breadth of impact we don't believe this qualifies as a release blocking issue.

[1] https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2017-11-02/

Created attachment 1347115 [details]
efivars

Same issue on fresh F27 b1.5 installation.

I can confirm that this issue is still present. Experiencing this on an F27 machine. However, the sizes differ from those in Petr's output, the remainder of the list being 3752 bytes long and the element being 652.

This is on a ThinkPad T460s, if that helps.

If you need any additional details or fix tests, feel free to message me.

Created attachment 1359276 [details]
tar of requested efivars

tar cjf vars.tar.bz2 /sys/firmware/efi/efivars/{PK,KEK,db}*

Wrong bug, disregard comment 6.

Issue is reproduced on fedora 27 4.13.16-300.fc27.x86_64, dbxtool-8-3.fc27.x86_64.
Output:
```
dbxtool: EFI Signature List is malformed
dbxtool: list has 4657 bytes left, element is 877 bytes
```

Same issue on dbxtool-8-3.fc27.x86_64

Created attachment 1374716 [details]
strace of dbxtool

strace -o strace.dbxtool.txt dbxtool -a /usr/share/dbxtool/DBXUpdate-2016-08-09-13-16-00.bin

I have the same "EFI Signature List is malformed" issue with dbxtool.x86_64 8-3.fc27 on my Clevo/Sager laptop.  I uploaded the strace output.

Same issue here, Thinkpad t440. I get:

dbxtool: EFI Signature List is malformed
dbxtool: list has 3800 bytes left, element is 76 bytes

(In reply to Milan J from comment #12)
> Same issue here, Thinkpad t440. I get:
> 
> dbxtool: EFI Signature List is malformed
> dbxtool: list has 3800 bytes left, element is 76 bytes

Same on HP EliteBook 840 G4

$ rpm -q dbxtool
dbxtool-8-3.fc27.x86_64

Created attachment 1383794 [details]
efivars - Dell Latitude 7350, BIOS A14

This also happens on a Dell Latitude 7350. It has BIOS version A14 (released last week), and the Secure Boot EFI variables have the default values shipped by Dell.

dbxtool: EFI Signature List is malformed
dbxtool: list has 2343 bytes left, element is 1691 bytes

efivars are attached. (Note that these contain some different keys than the other Dell system in comment #3.)

Same Issue on a Lenovo T530

dbxtool-8-3.fc27.x86_64

I do have the same issue on a Lenovo T460

I also have this on a Dell XPS 15 (9550)

Also here on ASUS N550J

systemd[1]: Started Secure Boot DBX (blacklist) updater.
dbxtool[31702]: dbxtool: EFI Signature List is malformed
dbxtool[31702]: dbxtool: list has 4629 bytes left, element is 877 bytes

dbxtool-8-3.fc27.x86_64

* I cannot run the machine in secure boot mode

Same thing here on a Dell XPS 15

$uname -a
Linux xpsmarco.felini.lan 4.15.4-300.fc27.x86_64 #1 SMP Mon Feb 19 23:31:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux


mar 01 12:02:31 xpsmarco.felini.lan systemd[1]: Started Secure Boot DBX (blacklist) updater.
mar 01 12:02:31 xpsmarco.felini.lan dbxtool[766]: dbxtool: EFI Signature List is malformed
mar 01 12:02:31 xpsmarco.felini.lan dbxtool[766]: dbxtool: list has 5415 bytes left, element is 1691 bytes
mar 01 12:02:31 xpsmarco.felini.lan systemd[1]: dbxtool.service: Main process exited, code=exited, status=1/FAILURE
mar 01 12:02:31 xpsmarco.felini.lan systemd[1]: dbxtool.service: Unit entered failed state.

Dell XPS 13 9343

Linux cloudy 4.16.0-0.rc3.git0.1.fc28.x86_64 #1 SMP Mon Feb 26 15:15:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Mar 04 19:27:58 cloudy systemd[1]: Started Secure Boot DBX (blacklist) updater.
Mar 04 19:27:58 cloudy dbxtool[1282]: dbxtool: EFI Signature List is malformed
Mar 04 19:27:58 cloudy dbxtool[1282]: dbxtool: list has 2343 bytes left, element is 1691 bytes

I have the same issue on a toshiba satellite c55-a

Mar 14 21:39:13 blakeeastman systemd[1]: Started Secure Boot DBX (blacklist) updater.
Mar 14 21:39:13 blakeeastman dbxtool[825]: dbxtool: EFI Signature List is malformed
Mar 14 21:39:13 blakeeastman dbxtool[825]: dbxtool: list has 3828 bytes left, element is 76 bytes
Mar 14 21:39:13 blakeeastman systemd[1]: dbxtool.service: Main process exited, code=exited, status=1/FAILURE
Mar 14 21:39:13 blakeeastman systemd[1]: dbxtool.service: Unit entered failed state.
Mar 14 21:39:13 blakeeastman systemd[1]: dbxtool.service: Failed with result 'exit-code'.

I've got the same error on a Dell Optiplex 7040 SFF with firmware version 0.1.5.7.

I am getting the same error:

4.15.9-300.fc27.x86_64 #1 SMP Mon Mar 12 17:07:55 UTC 2018
Machine:   Device: laptop System: Dell product: Inspiron 15-3567 serial: 62FS6F2
           Mobo: Dell model: 0J3PPW v: A00 serial: /62FS6F2/CNWSC0075H04OS/ UEFI: Dell v: 2.1.2 date: 11/09/2017


Mar 17 15:00:58 redwolf.ultrazone systemd[1]: Started Secure Boot DBX (blacklist) updater.
Mar 17 15:00:59 redwolf.ultrazone dbxtool[982]: dbxtool: EFI Signature List is malformed
Mar 17 15:00:59 redwolf.ultrazone dbxtool[982]: dbxtool: list has 2343 bytes left, element is 1691 bytes
Mar 17 15:00:59 redwolf.ultrazone systemd[1]: dbxtool.service: Main process exited, code=exited, status=1/FAILURE
Mar 17 15:00:59 redwolf.ultrazone systemd[1]: dbxtool.service: Unit entered failed state.
Mar 17 15:00:59 redwolf.ultrazone systemd[1]: dbxtool.service: Failed with result 'exit-code'.

Any update on this bug?
I have upgraded to Fedora 28, and the bug still present

Created attachment 1437368 [details]
[PATCH] fix relop in esl_iter_next()

I'm attaching the patch that fixes the issue.

The patch applies to upstream dbxtool @ commit 7fbfc83aae7d ("Update travis to use some better build scripts", 2018-04-11).

Fedora 27 scratch build (dbxtool-8-3.bz1508808.fc27):
https://koji.fedoraproject.org/koji/taskinfo?taskID=26991195

Fedora 28 scratch build (dbxtool-8-5.bz1508808.fc28):
https://koji.fedoraproject.org/koji/taskinfo?taskID=26991206

Testing, with the patch applied:

(1) Run dbxtool with the chattr workaround mentioned in bug 1516599 comment 12:

# chattr -i /sys/firmware/efi/efivars/dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f
# dbxtool -a /usr/share/dbxtool/
Applying 1 updates
Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21

(2) List the contents of the "dbx" signature database:

# dbxtool -l

   1: {d5c1df0b-1bac-4edf-ba48-08834009ca5a} {sha256} e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
   2: {microsoft} {sha256} 80b4d96931bf0d02fd91a61e19d14f1da452e66db2408ca8604d411f92659f0a
   3: {microsoft} {sha256} f52f83a3fa9cfbd6920f722824dbe4034534d25b8507246b3b957dac6e1bce7a
   4: {microsoft} {sha256} c5d9d8a186e2c82d09afaa2a6f7f2e73870d3e64f72c4e08ef67796a840f0fbd
   5: {microsoft} {sha256} 363384d14d1f2e0b7815626484c459ad57a318ef4396266048d058c5a19bbf76
   6: {microsoft} {sha256} 1aec84b84b6c65a51220a9be7181965230210d62d6d33c48999c6b295a2b0a06
   7: {microsoft} {sha256} e6ca68e94146629af03f69c2f86e6bef62f930b37c6fbcc878b78df98c0334e5
   8: {microsoft} {sha256} c3a99a460da464a057c3586d83cef5f4ae08b7103979ed8932742df0ed530c66
   9: {microsoft} {sha256} 58fb941aef95a25943b3fb5f2510a0df3fe44c58c95e0ab80487297568ab9771
  10: {microsoft} {sha256} 5391c3a2fb112102a6aa1edc25ae77e19f5d6f09cd09eeb2509922bfcd5992ea
  11: {microsoft} {sha256} d626157e1d6a718bc124ab8da27cbb65072ca03a7b6b257dbdcbbd60f65ef3d1
  12: {microsoft} {sha256} d063ec28f67eba53f1642dbf7dff33c6a32add869f6013fe162e2c32f1cbe56d
  13: {microsoft} {sha256} 29c6eb52b43c3aa18b2cd8ed6ea8607cef3cfae1bafe1165755cf2e614844a44
  14: {microsoft} {sha256} 90fbe70e69d633408d3e170c6832dbb2d209e0272527dfb63d49d29572a6f44c
  15: {microsoft} {sha256} 075eea060589548ba060b2feed10da3c20c7fe9b17cd026b94e8a683b8115238
  16: {microsoft} {sha256} 07e6c6a858646fb1efc67903fe28b116011f2367fe92e6be2b36999eff39d09e
  17: {microsoft} {sha256} 09df5f4e511208ec78b96d12d08125fdb603868de39f6f72927852599b659c26
  18: {microsoft} {sha256} 0bbb4392daac7ab89b30a4ac657531b97bfaab04f90b0dafe5f9b6eb90a06374
  19: {microsoft} {sha256} 0c189339762df336ab3dd006a463df715a39cfb0f492465c600e6c6bd7bd898c
  20: {microsoft} {sha256} 0d0dbeca6f29eca06f331a7d72e4884b12097fb348983a2a14a0d73f4f10140f
  21: {microsoft} {sha256} 0dc9f3fb99962148c3ca833632758d3ed4fc8d0b0007b95b31e6528f2acd5bfc
  22: {microsoft} {sha256} 106faceacfecfd4e303b74f480a08098e2d0802b936f8ec774ce21f31686689c
  23: {microsoft} {sha256} 174e3a0b5b43c6a607bbd3404f05341e3dcf396267ce94f8b50e2e23a9da920c
  24: {microsoft} {sha256} 18333429ff0562ed9f97033e1148dceee52dbe2e496d5410b5cfd6c864d2d10f
  25: {microsoft} {sha256} 2b99cf26422e92fe365fbf4bc30d27086c9ee14b7a6fff44fb2f6b9001699939
  26: {microsoft} {sha256} 2bbf2ca7b8f1d91f27ee52b6fb2a5dd049b85a2b9b529c5d6662068104b055f8
  27: {microsoft} {sha256} 2c73d93325ba6dcbe589d4a4c63c5b935559ef92fbf050ed50c4e2085206f17d
  28: {microsoft} {sha256} 2e70916786a6f773511fa7181fab0f1d70b557c6322ea923b2a8d3b92b51af7d
  29: {microsoft} {sha256} 306628fa5477305728ba4a467de7d0387a54f569d3769fce5e75ec89d28d1593
  30: {microsoft} {sha256} 3608edbaf5ad0f41a414a1777abf2faf5e670334675ec3995e6935829e0caad2
  31: {microsoft} {sha256} 3841d221368d1583d75c0a02e62160394d6c4e0a6760b6f607b90362bc855b02
  32: {microsoft} {sha256} 3fce9b9fdf3ef09d5452b0f95ee481c2b7f06d743a737971558e70136ace3e73
  33: {microsoft} {sha256} 4397daca839e7f63077cb50c92df43bc2d2fb2a8f59f26fc7a0e4bd4d9751692
  34: {microsoft} {sha256} 47cc086127e2069a86e03a6bef2cd410f8c55a6d6bdb362168c31b2ce32a5adf
  35: {microsoft} {sha256} 518831fe7382b514d03e15c621228b8ab65479bd0cbfa3c5c1d0f48d9c306135
  36: {microsoft} {sha256} 5ae949ea8855eb93e439dbc65bda2e42852c2fdf6789fa146736e3c3410f2b5c
  37: {microsoft} {sha256} 6b1d138078e4418aa68deb7bb35e066092cf479eeb8ce4cd12e7d072ccb42f66
  38: {microsoft} {sha256} 6c8854478dd559e29351b826c06cb8bfef2b94ad3538358772d193f82ed1ca11
  39: {microsoft} {sha256} 6f1428ff71c9db0ed5af1f2e7bbfcbab647cc265ddf5b293cdb626f50a3a785e
  40: {microsoft} {sha256} 71f2906fd222497e54a34662ab2497fcc81020770ff51368e9e3d9bfcbfd6375
  41: {microsoft} {sha256} 726b3eb654046a30f3f83d9b96ce03f670e9a806d1708a0371e62dc49d2c23c1
  42: {microsoft} {sha256} 72e0bd1867cf5d9d56ab158adf3bddbc82bf32a8d8aa1d8c5e2f6df29428d6d8
  43: {microsoft} {sha256} 7827af99362cfaf0717dade4b1bfe0438ad171c15addc248b75bf8caa44bb2c5
  44: {microsoft} {sha256} 81a8b965bb84d3876b9429a95481cc955318cfaa1412d808c8a33bfd33fff0e4
  45: {microsoft} {sha256} 82db3bceb4f60843ce9d97c3d187cd9b5941cd3de8100e586f2bda5637575f67
  46: {microsoft} {sha256} 895a9785f617ca1d7ed44fc1a1470b71f3f1223862d9ff9dcc3ae2df92163daf
  47: {microsoft} {sha256} 8ad64859f195b5f58dafaa940b6a6167acd67a886e8f469364177221c55945b9
  48: {microsoft} {sha256} 8bf434b49e00ccf71502a2cd900865cb01ec3b3da03c35be505fdf7bd563f521
  49: {microsoft} {sha256} 8d8ea289cfe70a1c07ab7365cb28ee51edd33cf2506de888fbadd60ebf80481c
  50: {microsoft} {sha256} 9998d363c491be16bd74ba10b94d9291001611736fdca643a36664bc0f315a42
  51: {microsoft} {sha256} 9e4a69173161682e55fde8fef560eb88ec1ffedcaf04001f66c0caf707b2b734
  52: {microsoft} {sha256} a6b5151f3655d3a2af0d472759796be4a4200e5495a7d869754c4848857408a7
  53: {microsoft} {sha256} a7f32f508d4eb0fead9a087ef94ed1ba0aec5de6f7ef6ff0a62b93bedf5d458d
  54: {microsoft} {sha256} ad6826e1946d26d3eaf3685c88d97d85de3b4dcb3d0ee2ae81c70560d13c5720
  55: {microsoft} {sha256} aeebae3151271273ed95aa2e671139ed31a98567303a332298f83709a9d55aa1
  56: {microsoft} {sha256} afe2030afb7d2cda13f9fa333a02e34f6751afec11b010dbcd441fdf4c4002b3
  57: {microsoft} {sha256} b54f1ee636631fad68058d3b0937031ac1b90ccb17062a391cca68afdbe40d55
  58: {microsoft} {sha256} b8f078d983a24ac433216393883514cd932c33af18e7dd70884c8235f4275736
  59: {microsoft} {sha256} b97a0889059c035ff1d54b6db53b11b9766668d9f955247c028b2837d7a04cd9
  60: {microsoft} {sha256} bc87a668e81966489cb508ee805183c19e6acd24cf17799ca062d2e384da0ea7
  61: {microsoft} {sha256} c409bdac4775add8db92aa22b5b718fb8c94a1462c1fe9a416b95d8a3388c2fc
  62: {microsoft} {sha256} c617c1a8b1ee2a811c28b5a81b4c83d7c98b5b0c27281d610207ebe692c2967f
  63: {microsoft} {sha256} c90f336617b8e7f983975413c997f10b73eb267fd8a10cb9e3bdbfc667abdb8b
  64: {microsoft} {sha256} cb6b858b40d3a098765815b592c1514a49604fafd60819da88d7a76e9778fef7
  65: {microsoft} {sha256} ce3bfabe59d67ce8ac8dfd4a16f7c43ef9c224513fbc655957d735fa29f540ce
  66: {microsoft} {sha256} d8cbeb9735f5672b367e4f96cdc74969615d17074ae96c724d42ce0216f8f3fa
  67: {microsoft} {sha256} e92c22eb3b5642d65c1ec2caf247d2594738eebb7fb3841a44956f59e2b0d1fa
  68: {microsoft} {sha256} fddd6e3d29ea84c7743dad4a1bdbc700b5fec1b391f932409086acc71dd6dbd8
  69: {microsoft} {sha256} fe63a84f782cc9d3fcf2ccf9fc11fbd03760878758d26285ed12669bdc6e6d01
  70: {microsoft} {sha256} fecfb232d12e994b6d485d2c7167728aa5525984ad5ca61e7516221f079a1436
  71: {microsoft} {sha256} ca171d614a8d7e121c93948cd0fe55d39981f9d11aa96e03450a415227c2c65b
  72: {microsoft} {sha256} 55b99b0de53dbcfe485aa9c737cf3fb616ef3d91fab599aa7cab19eda763b5ba
  73: {microsoft} {sha256} 77dd190fa30d88ff5e3b011a0ae61e6209780c130b535ecb87e6f0888a0b6b2f
  74: {microsoft} {sha256} c83cb13922ad99f560744675dd37cc94dcad5a1fcba6472fee341171d939e884
  75: {microsoft} {sha256} 3b0287533e0cc3d0ec1aa823cbf0a941aad8721579d1c499802dd1c3a636b8a9
  76: {microsoft} {sha256} 939aeef4f5fa51e23340c3f2e49048ce8872526afdf752c3a7f3a3f2bc9f6049
  77: {microsoft} {sha256} 64575bd912789a2e14ad56f6341f52af6bf80cf94400785975e9f04e2d64d745
  78: {microsoft} {sha256} 45c7c8ae750acfbb48fc37527d6412dd644daed8913ccd8a24c94d856967df8e

(Don't be surprised by item #1, that comes from EnrollDefaultKeys.efi.)

The regression was introduced in upstream commit c15deceee16a ("Fix some minor bugs our new gcc arguments found."). The Author date of that commit is 2017-10-18 (consistent with the timestamp on comment 0 here), while the Commit date is 2018-04-09. So I think the master branch must have been rebased recently.

Either way, c15deceee16a is part of release 8 and not part of release 7, so I believe RHEL-7 should not be affected. (RHEL7 ships dbxtool-7-1.el7 starting with RHEL-7.4.)

... Indeed, dbxtool-7-1.el7.x86_64 + efivar-31-4.el7.x86_64 are not affected by either bug 1516599 or bug 1508808 (this bug).

I'm failing on:
> Oct 19 12:06:36 localhost.localdomain dbxtool[747]: Could not apply database
> update "DBXUpdate-2016-08-09-13-16-00.bin": Invalid argument

I'm also not using secure boot mode:

mokutil --sb-state
SecureBoot disabled

So, I'm assuming I don't need this process running anyway, correct?  

If so, why isn't it disabled?  Why is it enabled by default?  The mokutil command gives the state of secureboot on the machine.

This also applies to mcelog.service and rngd.service.  Why are we enabling services by default that don't have the required hardware to run, and then generating nasty error messages causing people to spend time tracking down things which aren't really applicable to their environment?

Created attachment 1455580 [details]
efivars

Same problem on ASUS rog 551jw, kernel 4.17.3-100.fc27.x86_64 with secure boot disabled.

Same on Fedora 28, almost new HP EliteDesk 800 G3 SFF:
Jul 19 12:11:09  dbxtool[31063]: dbxtool: EFI Signature List is malformed
Jul 19 12:11:09  dbxtool[31063]: dbxtool: list has 3800 bytes left, element is 76 bytes


rpm -q efivar
efivar-35-1.fc28.x86_64

rpm -q dbxtool
dbxtool-8-5.fc28.x86_64

SecureBoot enabled.

Is there a fix for this yet?

On Fedora 27, Thinkpad X230:

# /usr/bin/dbxtool -a /usr/share/dbxtool/ -v
Getting next EFI_SIGNATURE_DATA
Getting next ESL buffer
Getting next EFI_SIGNATURE_DATA
Getting next EFI_SIGNATURE_LIST
dbxtool: EFI Signature List is malformed
dbxtool: list has 3800 bytes left, element is 76 bytes

# rpm -q dbxtool
dbxtool-8-3.fc27.x86_64

How do I download the scratch builds from comment 25? There is no obvious download link on https://koji.fedoraproject.org/koji/taskinfo?taskID=26991195.

Upstream dbxtool git 338a2d097 works for me (F27).

(In reply to Mike Gerber from comment #30)
> How do I download the scratch builds from comment 25? There is no obvious
> download link on
> https://koji.fedoraproject.org/koji/taskinfo?taskID=26991195.

Right, koji removes files associated with scratch builds ("scratch = True") after a while. For that reason, I always stash those files locally, and in such cases, I can upload them to my personal RH web space for users to check.

However:

(In reply to Mike Gerber from comment #31)
> Upstream dbxtool git 338a2d097 works for me (F27).

commit 338a2d097 seems to be the patch from comment 25. So I believe what remains now is an official build in Fedora that contains this upstream commit (via either backport or rebase).

Building the most recent git version of dbxtool worked for me as well on F28.

This same bug happens in the beta version of Silverblue, based on F29.

Bug still happens with dbxtool-8-7.fc29.x86_64 (Fedora Workstation and Server).

Still happens on dbxtool-8-7.fc29.x86_64, fixed (again) by using upstream dbxtool git 338a2d097.

*subscribed
Also affects my FC28 install. Would be great if someone could push the fixed dbxtool to the repos.

On my XPS15 with Fedora 29 I still have this issue.
dbxtool-8-7.fc29.x86_64

Is there any progress on a fixed version? 
Do we have a working patch somewhere that can be applied to get a working version?

(In reply to Jan Hugo Prins from comment #38)

> Do we have a working patch somewhere that can be applied to get a working
> version?

See comment 31, comment 32, comment 33, comment 36.

So, concluding without testing for now, we have a patch, we have a bug we don't have a new package yet. Who is is able to create this new package? I can create the package, I could even create a src.rpm package from the current package and include this patch. Would this speed up the process?

Created a package myself with the patch and below is the result.

● dbxtool.service - Secure Boot DBX (blacklist) updater
   Loaded: loaded (/usr/lib/systemd/system/dbxtool.service; enabled; vendor preset: enabled)
   Active: active (exited) since Mon 2018-11-05 22:55:36 CET; 1s ago
  Process: 9346 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ -q (code=exited, status=0/SUCCESS)
 Main PID: 9346 (code=exited, status=0/SUCCESS)

Nov 05 22:55:36 capetown.lan.betterbe.com systemd[1]: Started Secure Boot DBX (blacklist) updater.

(In reply to Jan Hugo Prins from comment #41)
> Created a package myself with the patch and below is the result.
>

Jan, would you please attach your package to the ticket. I would like to test on my system.

What version of Fedora did you use to compile?

(In reply to Jürgen Hörmann from comment #42)
> (In reply to Jan Hugo Prins from comment #41)
> > Created a package myself with the patch and below is the result.
> >
> 
> Jan, would you please attach your package to the ticket. I would like to
> test on my system.
> 
> What version of Fedora did you use to compile?

I have it working on Fedora 29.

Created attachment 1502355 [details]
New version with fix for bug 1508808

Created attachment 1502356 [details]
Mock build version for Fedora 29.

Created attachment 1506802 [details]
/sys/firmware/efi/efivars/{PK,KEK,db}*

Came here after updating a Dell Inspiron 7773 to Fedora 29 with the same issue.
More important bugs are being fixed, I guess.

Seeing this on a fresh install of F29 on an HP 15-g023cl...

pjones, ping? This has been sitting awhile.

dbxtool-8-8.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-b8b22622a0

dbxtool-8-8.fc29 has been pushed to the Fedora 29 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-2019-b8b22622a0

dbxtool-8-8.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.