A couple of systemd unit failures on f27 atomic host images from last night. I booted on an x86_64 machine with libvirt (with --arch aarch64). We need to investigate these and see if we can resolve them:
--arch aarch64
[root@cloudhost ~]# systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION ● dbxtool.service loaded failed failed Secure Boot DBX (blacklist) updater ● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online 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. 2 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'. [root@cloudhost ~]# [root@cloudhost ~]# [root@cloudhost ~]# 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-10-07 15:30:00 UTC; 5min ago Process: 786 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ (code=exited, status=1/FAILURE) Main PID: 786 (code=exited, status=1/FAILURE) Oct 07 15:29:58 localhost.localdomain systemd[1]: Started Secure Boot DBX (blacklist) updater. Oct 07 15:29:59 localhost.localdomain dbxtool[786]: Applying 1 updates Oct 07 15:29:59 localhost.localdomain dbxtool[786]: Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21 Oct 07 15:29:59 localhost.localdomain dbxtool[786]: Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Invalid argument Oct 07 15:29:59 localhost.localdomain dbxtool[786]: Cannot Continue.: Invalid argument Oct 07 15:30:00 localhost.localdomain systemd[1]: dbxtool.service: Main process exited, code=exited, status=1/FAILURE Oct 07 15:30:00 localhost.localdomain systemd[1]: dbxtool.service: Unit entered failed state. Oct 07 15:30:00 localhost.localdomain systemd[1]: dbxtool.service: Failed with result 'exit-code'. [root@cloudhost ~]# [root@cloudhost ~]# systemctl status NetworkManager-wait-online.service ● NetworkManager-wait-online.service - Network Manager Wait Online Loaded: loaded (/usr/lib/systemd/system/NetworkManager-wait-online.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sat 2017-10-07 15:30:35 UTC; 5min ago Docs: man:nm-online(1) Process: 818 ExecStart=/usr/bin/nm-online -s -q --timeout=30 (code=exited, status=1/FAILURE) Main PID: 818 (code=exited, status=1/FAILURE) Oct 07 15:30:03 localhost.localdomain systemd[1]: Starting Network Manager Wait Online... Oct 07 15:30:35 localhost.localdomain systemd[1]: NetworkManager-wait-online.service: Main process exited, code=exited, status=1/FAILURE Oct 07 15:30:35 localhost.localdomain systemd[1]: Failed to start Network Manager Wait Online. Oct 07 15:30:35 localhost.localdomain systemd[1]: NetworkManager-wait-online.service: Unit entered failed state. Oct 07 15:30:35 localhost.localdomain systemd[1]: NetworkManager-wait-online.service: Failed with result 'exit-code'.
Metadata Update from @dustymabe: - Issue tagged with: F27, host, multi-arch
@sinnykumari - can I get you to look at these?
Thanks for creating issue for this. I will look into it.
I booted Atomic qcow2 image mentioned and latest one on aarch64 machine. Both shows only dbxtool.service as failed status. NetworkManager-wait-online.service started successfully.
$ systemctl --failed --all 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'.
Will check why dbxtool service is failing.
FYI, dbxtool service failure has also been observed with regular F27, aarch64 compose. Related bugzilla - https://bugzilla.redhat.com/show_bug.cgi?id=1489942
This is probably because I was booting in an aarch64 VM on an X86_64 host (slow!!). We can ignore the NetworkManager-wait-online.service.
Thanks for the link to the bug. This is an issue on non-aarch64 hardware and non-atomic hosts as well. I proposed the bug as a blocker for f27. We can close this ticket in favor of the bug.
closing this ticket as the issue is tracked in BZ#1489942
Metadata Update from @dustymabe: - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.