Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionChristophe Besson
2020-09-28 13:19:46 UTC
Description of problem:
Customer creates for its own needs several custom actors executed during the FirstBoot phase. Very rarely one of the custom actors is not executed and the leapp_resume.service fails. A custom actor in itself is not supported, but here it seems leapp crashes and the leapp.db doesn't show latest actions:
~~~
$ sqlite3 ./var/lib/leapp/leapp.db --cmd "select data from audit where event = 'process-result';" | ~/jq-linux64 "." 2>/dev/null | tail -n 16
{
"id": "c915d68e-f264-44ad-94bb-c2a75db65430",
"parameters": [
"systemctl",
"disable",
"leapp_resume.service"
],
"result": {
"signal": 0,
"exit_code": 0,
"pid": 44937,
"stdout": "",
"stderr": "Removed /etc/systemd/system/default.target.wants/leapp_resume.service.\n"
},
"env": null
}
~~~
Version-Release number of selected component (if applicable):
leapp-repository-0.10.0-2.el7_8.noarch
How reproducible:
Rare / Random.
Actual results:
~~~
Sep 23 19:00:25 <hostname> leapp3[12955]: ====> * custom_fix_lvm
Sep 23 19:00:25 <hostname> leapp3[12955]: Remove lv_tmp if it exists
Sep 23 19:00:28 <hostname> leapp3[12955]: ====> * remove_systemd_resume_service
Sep 23 19:00:28 <hostname> leapp3[12955]: Remove systemd service to launch Leapp.
Sep 23 19:00:29 <hostname> leapp3[12955]: ====> * custom_upgrade_3rdparty
Sep 23 19:00:29 <hostname> leapp3[12955]: upgrade 3rd_party to RHEL8 version
Sep 23 19:00:36 <hostname> systemd[1]: leapp_resume.service: Current command vanished from the unit file, execution of the command list won't be resumed.
Sep 23 19:00:37 <hostname> systemd[1]: leapp_resume.service: Start operation timed out. Terminating.
~~~
Additional info:
I discussed this issue with Petr Stodulk which told me to open a bug.
Will add some private attachments: leapp.db, messages and also the latest custom actor (its role is to upgrade a 3rd party SW).
Will ask the customer to provide the logs for an upgrade with the --debug mode enabled, and also ask for not installing temporary their Antivirus SW (Veritas).
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (leapp, leapp-repository, and cockpit-leapp bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2020:4882
Comment 19Red Hat Bugzilla
2023-09-15 00:48:53 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days
Description of problem: Customer creates for its own needs several custom actors executed during the FirstBoot phase. Very rarely one of the custom actors is not executed and the leapp_resume.service fails. A custom actor in itself is not supported, but here it seems leapp crashes and the leapp.db doesn't show latest actions: ~~~ $ sqlite3 ./var/lib/leapp/leapp.db --cmd "select data from audit where event = 'process-result';" | ~/jq-linux64 "." 2>/dev/null | tail -n 16 { "id": "c915d68e-f264-44ad-94bb-c2a75db65430", "parameters": [ "systemctl", "disable", "leapp_resume.service" ], "result": { "signal": 0, "exit_code": 0, "pid": 44937, "stdout": "", "stderr": "Removed /etc/systemd/system/default.target.wants/leapp_resume.service.\n" }, "env": null } ~~~ Version-Release number of selected component (if applicable): leapp-repository-0.10.0-2.el7_8.noarch How reproducible: Rare / Random. Actual results: ~~~ Sep 23 19:00:25 <hostname> leapp3[12955]: ====> * custom_fix_lvm Sep 23 19:00:25 <hostname> leapp3[12955]: Remove lv_tmp if it exists Sep 23 19:00:28 <hostname> leapp3[12955]: ====> * remove_systemd_resume_service Sep 23 19:00:28 <hostname> leapp3[12955]: Remove systemd service to launch Leapp. Sep 23 19:00:29 <hostname> leapp3[12955]: ====> * custom_upgrade_3rdparty Sep 23 19:00:29 <hostname> leapp3[12955]: upgrade 3rd_party to RHEL8 version Sep 23 19:00:36 <hostname> systemd[1]: leapp_resume.service: Current command vanished from the unit file, execution of the command list won't be resumed. Sep 23 19:00:37 <hostname> systemd[1]: leapp_resume.service: Start operation timed out. Terminating. ~~~ Additional info: I discussed this issue with Petr Stodulk which told me to open a bug. Will add some private attachments: leapp.db, messages and also the latest custom actor (its role is to upgrade a 3rd party SW). Will ask the customer to provide the logs for an upgrade with the --debug mode enabled, and also ask for not installing temporary their Antivirus SW (Veritas).