You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Actual behavior
dhcp is replaced by dhcp-server which turns a previously enabled service unit off with no mention of it whatsoever in /var/log/leapp/leapp-report.txt.
To Reproduce
Probably pretty obvious. Let me know if it's not.
Expected behavior
If one package replaces another, which results in the systemd unit file changing which results in a previously enabled service being disabled after the upgrade, the least that should be done is a mention of the situation in the report. I would argue that more should be done and that the replacing unit should be set to the same state as the replaced unit so that post-upgrade, service continues as it was before upgrade.
System information (please complete the following information):
OS and version: CentOS 7.9
Linux server.interlinx.bc.ca 3.10.0-1160.49.1.el7.x86_64 #1 SMP Tue Nov 30 15:51:32 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Hi \o I am sorry for the late response. Thanks for the feedback. We know about several related issues. Currently, we have delivered in the first iteration fixes for services with broken symlinks (caused e.g. by changed name of the rpm) and for the next one we plan to deliver the general hangling of systemd services, so e.g. dhcp should be covered by that (unless it's already covered by previous fixes). pinnning the issue (@matejmatuska fyi)
Actual behavior
dhcp is replaced by dhcp-server which turns a previously enabled service unit off with no mention of it whatsoever in
/var/log/leapp/leapp-report.txt
.To Reproduce
Probably pretty obvious. Let me know if it's not.
Expected behavior
If one package replaces another, which results in the systemd unit file changing which results in a previously enabled service being disabled after the upgrade, the least that should be done is a mention of the situation in the report. I would argue that more should be done and that the replacing unit should be set to the same state as the replaced unit so that post-upgrade, service continues as it was before upgrade.
System information (please complete the following information):
Linux server.interlinx.bc.ca 3.10.0-1160.49.1.el7.x86_64 #1 SMP Tue Nov 30 15:51:32 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
leapp-upgrade-el7toel8-deps-0.14.0-100.202109271224Z.b7ebfca.master.el7.elevate.noarch
leapp-upgrade-el7toel8-0.14.0-100.202109271224Z.b7ebfca.master.el7.elevate.noarch
leapp-deps-0.12.1-100.20210924142320684911.master.28.g1f03432.el7.noarch
python2-leapp-0.12.1-100.20210924142320684911.master.28.g1f03432.el7.noarch
leapp-data-almalinux-0.1-2.el7.noarch
The text was updated successfully, but these errors were encountered: