Hide Forgot
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.
I'm seeing the same problem on x86 with dbxtool-7-6.fc27.x86_64
is this a blocker for f27 ? can we submit it as a blocker if it is ?
FYI we are seeing this in atomic as well: https://pagure.io/atomic-wg/issue/348
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?
[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
Created attachment 1337411 [details] strace.dbxtool.txt
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}
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
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.
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.
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".
dbxtool-8-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-671a614067
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."
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
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 ```
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. ```
Created attachment 1340833 [details] strace.dbxtool.txt (Thu Oct 19 12:41:38 EDT 2017)
dbxtool-8-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-671a614067
[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.
Created attachment 1340853 [details] dbxtool-8-2.fc27.aarch64 strace
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 ```
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.
(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.
Oh, OK. We already do such a test in openQA, but from BIOS installs, not UEFI installs.
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 ?
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...
(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?
+1 blocker based on the criteria Adam quotes
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
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'.
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 :---------------------://
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
dbxtool-8-3.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-671a614067
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
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
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?
test of comment #36 was using dbxtool-8-3.fc27.x86_64
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.
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.
(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.)
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'.