Created attachment 1357973 [details] strace.dbxtool +++ This bug was initially created as a clone of Bug #1489942 +++ 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. --- Additional comment from Mads Villadsen on 2017-09-16 07:55:18 EDT --- I'm seeing the same problem on x86 with dbxtool-7-6.fc27.x86_64 --- Additional comment from Dusty Mabe on 2017-10-11 14:11:54 EDT --- is this a blocker for f27 ? can we submit it as a blocker if it is ? --- Additional comment from Dusty Mabe on 2017-10-11 14:12:36 EDT --- FYI we are seeing this in atomic as well: https://pagure.io/atomic-wg/issue/348 --- Additional comment from Dusty Mabe on 2017-10-11 14:27:35 EDT --- 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? --- Additional comment from Paul Whalen on 2017-10-11 16:16:07 EDT --- [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 --- Additional comment from Paul Whalen on 2017-10-11 16:16 EDT --- --- Additional comment from Peter Jones on 2017-10-17 16:52:40 EDT --- 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} --- Additional comment from Dusty Mabe on 2017-10-17 17:53:19 EDT --- 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 --- Additional comment from Dusty Mabe on 2017-10-17 18:07:14 EDT --- 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. --- Additional comment from Fedora Blocker Bugs Application on 2017-10-17 18:08:31 EDT --- 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. --- Additional comment from Peter Jones on 2017-10-18 13:39:17 EDT --- 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". --- Additional comment from Fedora Update System on 2017-10-18 13:46:23 EDT --- dbxtool-8-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-671a614067 --- Additional comment from Adam Williamson on 2017-10-18 15:01:45 EDT --- 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." --- Additional comment from Fedora Update System on 2017-10-19 11:23:02 EDT --- 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 --- Additional comment from Dusty Mabe on 2017-10-19 12:10:55 EDT --- 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 ``` --- Additional comment from Dusty Mabe on 2017-10-19 12:41:12 EDT --- 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. ``` --- Additional comment from Dusty Mabe on 2017-10-19 12:42 EDT --- --- Additional comment from Fedora Update System on 2017-10-19 12:54:19 EDT --- dbxtool-8-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-671a614067 --- Additional comment from Paul Whalen on 2017-10-19 13:40:52 EDT --- [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. --- Additional comment from Paul Whalen on 2017-10-19 13:42 EDT --- --- Additional comment from Dusty Mabe on 2017-10-19 13:47:08 EDT --- 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 ``` --- Additional comment from Adam Williamson on 2017-10-19 20:34:13 EDT --- 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. --- Additional comment from Dusty Mabe on 2017-10-19 21:32:05 EDT --- (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. --- Additional comment from Adam Williamson on 2017-10-20 12:35:33 EDT --- Oh, OK. We already do such a test in openQA, but from BIOS installs, not UEFI installs. --- Additional comment from Gleidson Baleeiro on 2017-10-20 17:19:07 EDT --- 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 ? --- Additional comment from Adam Williamson on 2017-10-20 17:24:54 EDT --- 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... --- Additional comment from Dusty Mabe on 2017-10-21 10:42:57 EDT --- (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? --- Additional comment from Matthew Miller on 2017-10-21 13:32:32 EDT --- +1 blocker based on the criteria Adam quotes --- Additional comment from Fedora Update System on 2017-10-21 15:26:18 EDT --- 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 --- Additional comment from Gleidson Baleeiro on 2017-10-22 18:30:06 EDT --- 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'. --- Additional comment from Gleidson Baleeiro on 2017-10-22 19:14:52 EDT --- 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 :---------------------:// --- Additional comment from Geoffrey Marr on 2017-10-23 15:30:48 EDT --- 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 --- Additional comment from Fedora Update System on 2017-10-24 12:45:45 EDT --- dbxtool-8-3.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-671a614067 --- Additional comment from Paul Whalen on 2017-10-24 13:02:36 EDT --- 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 --- Additional comment from Fedora Update System on 2017-10-25 11:22:42 EDT --- 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 --- Additional comment from Gleidson Baleeiro on 2017-10-25 12:06:58 EDT --- 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? --- Additional comment from Gleidson Baleeiro on 2017-10-25 12:08:36 EDT --- test of comment #36 was using dbxtool-8-3.fc27.x86_64 --- Additional comment from Adam Williamson on 2017-10-25 12:41:51 EDT --- 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. --- Additional comment from Fedora Update System on 2017-10-29 21:52:34 EDT --- 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. --- Additional comment from Peter Jones on 2017-10-30 11:31:03 EDT --- (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.) --- Additional comment from Alvin on 2017-11-21 07:25:08 EST --- 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'.
Still seeing the file (no such file or directory ) error dbxtool-8-3.fc27.x86_64 strace attached
Getting next EFI_SIGNATURE_DATA Getting next ESL buffer Getting next EFI_SIGNATURE_DATA Getting next EFI_SIGNATURE_LIST Attempting to identify filetype: va2 guid is {pkcs7_cert} guid table guid is {pkcs7_cert} ft_append_timestamp is 2010-03-06 19:17:21 Attempting to apply 1 updates Sorting updates list Checking if "DBXUpdate-2016-08-09-13-16-00.bin" has been applied. Getting next EFI_SIGNATURE_DATA Getting next ESL buffer Update entry is not applied. Update "DBXUpdate-2016-08-09-13-16-00.bin" is not applied Applying 1 updates Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21 Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Operation not permitted Cannot Continue.: Operation not permitted error trace: efivarfs.c:319 efivarfs_set_variable(): open(/sys/firmware/efi/efivars/dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f, O_WRONLY|O_CREAT, mode) failed: Operation not permitted efivarfs.c:361 efivarfs_append_variable(): efivarfs_set_variable failed: Operation not permitted lib.c:113 efi_append_variable(): ops->append_variable() failed: Operation not permitted
Hello I'm also getting dbxtool errors on a Lenovo ideapad 510 # rpm -q dbxtool dbxtool-8-3.fc27.x86_64 # 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 Sat 2017-11-25 20:55:14 GMT; 23min ago Process: 789 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ -q (code=exited, status=1/FAILURE) Main PID: 789 (code=exited, status=1/FAILURE) Nov 25 20:55:09 bwlaptop systemd[1]: Started Secure Boot DBX (blacklist) updater. Nov 25 20:55:11 bwlaptop dbxtool[789]: Applying 1 updates Nov 25 20:55:11 bwlaptop dbxtool[789]: Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21 Nov 25 20:55:11 bwlaptop dbxtool[789]: Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Operation Nov 25 20:55:11 bwlaptop dbxtool[789]: Cannot Continue.: Operation not permitted Nov 25 20:55:14 bwlaptop systemd[1]: dbxtool.service: Main process exited, code=exited, status=1/FAILURE Nov 25 20:55:14 bwlaptop systemd[1]: dbxtool.service: Unit entered failed state. Nov 25 20:55:14 bwlaptop systemd[1]: dbxtool.service: Failed with result 'exit-code'.
I see this same message on an Intel NUC with current firmware from Intel. [ 0.000000] DMI: /NUC5PPYB, BIOS PYBSWCEL.86A.0063.2017.0807.1503 08/07/2017 # rpm -q dbxtool dbxtool-8-3.fc27.x86_64
Created attachment 1359277 [details] tar of requested efivars tar cjf vars.tar.bz2 /sys/firmware/efi/efivars/{PK,KEK,db}*
I have exactly the same issue as Subhendu Ghosh reported. ThinkPad T440, BIOS version 2.44 (latest).
Created attachment 1361625 [details] Archive with efivars Attached archive w/ efivars
Same 'Operation not permitted' messages on Hewlett-Packard HP Pavilion 15 Notebook. bash-4.4$ sudo rpm -q dbxtool dbxtool-8-3.fc27.x86_64 strace -o strace.dbxtool.txt dbxtool -a /usr/share/dbxtool Applying 1 updates Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21 Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Operation not permitted Cannot Continue.: Operation not permitted bash-4.4$ ls /sys/firmware/efi/efivars/ | grep dbx dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f dbxDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
I see this failure, too, on a Dell XPS 13 9343 with BIOS version A14. Secure Boot is disabled. % rpm -q dbxtool dbxtool-8-3.fc27.x86_64 % sudo /usr/bin/dbxtool -a /usr/share/dbxtool/ --verbose [...] Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Operation not permitted Cannot Continue.: Operation not permitted error trace: efivarfs.c:319 efivarfs_set_variable(): open(/sys/firmware/efi/efivars/dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f, O_WRONLY|O_CREAT, mode) failed: Operation not permitted efivarfs.c:361 efivarfs_append_variable(): efivarfs_set_variable failed: Operation not permitted lib.c:113 efi_append_variable(): ops->append_variable() failed: Operation not permitted I did notice a page in the firmware under Secure Boot named Expert Key Management. It contained a checkbox, disabled by default, "Enable Custom Mode", with UI elements to manipulate PK/KEK/db/dbx. The help text explained: > Expert Key Management allows the PK, KEK, db and dbx security key databases > to be manipulated. The keys can only be modified if the system is in Custom > Mode. If Custom mode is disabled, any changes made while in Custom Mode will > be erased and the keys will revert back to their default setting. > [Documentation about the buttons in this UI to manipulate each database > elided.] Enabling this checkbox sounded promising but sadly had absolutely no effect on opening dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f for write.
Same problem on Dell Inspiron 7548/0AM6R0. Also on Fedora 28 with dbxtool-8-4.fc28.x86_64: systemd[1]: Started Secure Boot DBX (blacklist) updater. dbxtool[10106]: Applying 1 updates dbxtool[10106]: Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21 dbxtool[10106]: Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Operation not permitted dbxtool[10106]: Cannot Continue.: Operation not permitted BTW, this bug looks just about the same as https://bugzilla.redhat.com/show_bug.cgi?id=1489942
Seeing the same issue on a Zotac Ci327 Nano; Fedora 27 installed, x86_64 Secure boot enable Same messages as comment 10.
The "Operation not permitted" error occurs because efivarfs_set_variable() [src/efivarfs.c] calls open() in not-read-only-mode *before* it calls efivarfs_set_fd_immutable(..., 0). (Looking at upstream efivar @ 9896c26c7e68.) That won't work; the kernel sets the dbx-... pseudo-file to immutable by default, and that can only be cleared by opening the file for r/o first, and calling the ioctl(). The open for write can come only after. A similar issue was corrected earlier in upstream efivar commit 4c20a6de. This issue can be worked around by running "chattr -i" on the dbx-... file manually, before invoking dbxtool. I see another issue in efivarfs_set_variable(): if (attributes & EFI_VARIABLE_APPEND_WRITE) { flags = O_APPEND|O_CREAT; flagstr = "O_APPEND|O_CREAT"; } else { technically this might work on Linux, but really one of O_RDWR or O_WRONLY should be present too.
Created attachment 1437631 [details] [PATCH] rewrite efivarfs_set_variable() [based on tag "32"] Attaching the patch that fixes efivarfs_set_variable(). The patch applies to the upstream efivar tag called "32", hence it is suitable for Fedora 27: - scratch build: efivar-32-2.bz1516599.fc27 https://koji.fedoraproject.org/koji/taskinfo?taskID=27001571 I tested this on OVMF, together with the dbxtool fix (from bug 1508808 comment 25). The dbxtool systemd service now works fine without errors or workarounds. I tested two scenarios: - when "dbx" didn't exist on boot (but SB was otherwise enabled), - when "dbx" existed with a single sha256 entry. NOTE: if you try this and it bricks your device, I take no responsibility. You have been warned.
Created attachment 1437643 [details] [PATCH] rewrite efivarfs_set_variable() [9896c26c7e68-based] Attaching the patch that fixes efivarfs_set_variable(). The patch applies to current upstream efivar (master @ commit 9896c26c7e68), hence it is suitable for Fedora 28: - scratch build: efivar-35-1.bz1516599.fc28 https://koji.fedoraproject.org/koji/taskinfo?taskID=27001318 NOTE: if you try this and it bricks your device, I take no responsibility. You have been warned.
Laszlo -- Thanks for the workaround + patch - will give it a try once it hits the testing repo.
I still see this on an Intel NUC with current firmware and efivar-35-1.fc28.x86_64 dbxtool-8-5.fc28.x86_64
Removing the immutable flag worked for me (Thinkpad X230): # chattr -i /sys/firmware/efi/efivars/dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f # /usr/bin/dbxtool -a /usr/share/dbxtool/ -q Applying 1 updates Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21 After that, I get a possibly unrelated error: # /usr/bin/dbxtool -a /usr/share/dbxtool/ -q dbxtool: EFI Signature List is malformed dbxtool: list has 3800 bytes left, element is 76 bytes # echo $? 1
Upstream efivar now contains the patch from comment 14, as commit 9c51123abebd.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening for Fedora 28. - According to comment 18, the upstream fix is commit 9c51123abebd. The first upstream tag that said commit is part of is "36". - Checking the "efivar" package in Koji: <https://koji.fedoraproject.org/koji/packageinfo?packageID=17225>, the latest build for Fedora 28 is "efivar-35-1.fc28" <https://koji.fedoraproject.org/koji/buildinfo?buildID=1067810>. It is based on upstream tag "35", and the %changelog does not mention a backport of upstream commit 9c51123abebd. (In fact, the package is dated 2018-Apr-09, while the upstream fix was applied on 2018-May-17.)
This should be fixed in the most recent build: efivar-37-1.fc28 https://koji.fedoraproject.org/koji/buildinfo?buildID=1169369
Any idea why efivar-37-1 isn't listed in Bodhi? It's not in updates-testing for either Fedora 28 or 29. https://bodhi.fedoraproject.org/updates/?packages=efivar
Chris, thanks for raising this question. In fact when I made comment 22 yesterday, I intended to provide a direct Bodhi link as well. However... (1) Not sure when exactly it must have happened, but the Bodhi WebUI has semi(?)recently regressed to the point where it's now borderline unusable, in my opinion anyway. For about ten minutes I couldn't decide whether the reason for my not finding a Bodhi update for efivar was my lacking Bodhi-fu, or the actual absence of a Bodhi update. Consider, for example <https://bodhi.fedoraproject.org/updates/?releases=F28&status=testing>. It currently gives you a list of 325 package updates, broken down into 17 pages of 20 updates each. There is no way to search for a package by name, or to increase the update count per page (after which one could use the browser's in-page search function). Am I *really* supposed to click through 17 pages to find the update I'm looking for? (2) Ultimately, I somehow stumbled upon Peter's page at <https://bodhi.fedoraproject.org/users/pjones>. That's a lot more focused view, and I didn't see an update there. So I *guess* that the Bodhi update is not there because Peter has yet to submit it.
If you're searching for an update by package name, just...search. There's a magnifying glass at top-right of the web UI. That's the search button. Click it, type the package name. Maybe it could be a bit more prominent, it is a bit small and grey and out of the way. Really it's probably the most common 'entry point' for doing stuff with Bodhi from the front page, I'd think (that and the 'profile' page, I guess).
Hi Adam, thanks for the hint. In the upper right corner of <https://bodhi.fedoraproject.org/>, I don't see a magnifying glass. Instead, I see the number "14", in digital clock script: <https://imgur.com/a/SYe76GH>.
That's...not normal. I see the search icon whether I'm logged in or out. Are you blocking scripts or CSS, perhaps? Or forcing fonts? Does it actually work for searching when you click on it, regardless of what it looks like?
If I set "Allow pages to choose their own fonts, instead of my selections above" in Firefox, then the magnifying glass appears. However, I didn't randomly clear that checkbox. I need to enforce a minimum font size, and I depend on fonts to look mostly uniform. Bodhi's use of a custom font for the magnifying glass / search link is *wrong*. For starters, it is inconsistent with the rest of the landing page. The "Stats" and "Login" widgets are in normal Latin script, why can't "Search" be the same? Furthermore, the small icons all over the table (Security updates / Bugfix updates / Enhancement updates / New package updates) look like normal images to me. If "Search" has to be a magnifying glass and not Latin script, why can't it be a similar picture?
Anyway, yes, if I click "14", the search function works fine. Thank you!
There is a ticket about making the search more obvious in the UI: https://github.com/fedora-infra/bodhi/issues/1455
Thank you Randy, I've now pinged that ticket.
Using some kind of image font is pretty standard practice on Teh Intarwebz these days. I gave up trying to force font selection because of this a couple of years back. I just use text zoom for pages that use stupidly tiny fonts now :/
efivar-37-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-9963fc558e
efivar-37-1.fc28 has been pushed to the Fedora 28 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-2018-9963fc558e
efivar-37-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.