runtime-cleanup: don't strip device-mapper-event #1328
Conversation
The openQA install_blivet_lvmthin test - which, as the name
implies, does an LVM thinp install - is consistently failing
(only on ppc64le, for some reason). The logs show that lvm2 is
trying to run dmeventd as part of some kind of check of the
pool, but it's failing because dmeventd isn't there:
Failed to call the 'LvCreate' method on the '/com/redhat/lvmdbus1/ThinPool/0' object: GDBus.Error:org.freedesktop.DBus.Python.dbus.exceptions.DBusException: ('com.redhat.lvmdbus1.Lv', 'Exit code 5, stderr = /usr/sbin/dmeventd: stat failed: No such file or directory, /usr/sbin/dmeventd: stat failed: No such file or directory, Check of pool fedora/00 failed (status:64). Manual repair required!, Failed to activate thin pool fedora/00.')
So, apparently we do need this now. Whether to use dmeventd or
not seems to be a build time check/config option for lvm2, but
I don't think we can turn that off just to save a bit of space
in the installer image - the package is only about 50K.
Signed-off-by: Adam Williamson <[email protected]>
Pull Request Test Coverage Report for Build 5297278368
💛 - Coveralls |
|
Adding this turns on the dm-event.socket listener, and during the install I see logging about dmeventd trying to dlopen But if we also add |
We don't install dmeventd or the event libraries so monitoring will fail to start. The should solve weldr#1328 and rhbz#2236524 With this in place there are no syslog messages about dmeventd or event libraries. lvm.conf does contain logged messages about dmeventd falling back to various things, but no actual errors.
|
Yes, but it requires a bit of bodging and it's not my number 1 priority right now, so I can't promise I'm gonna get to it. I will try, though! |
|
BTW, the bug is actually fixed in Rawhide already since 2023-09-01, because Marian's fix for device-mapper-persistent-data landed that day ( device-mapper-persistent-data-1.0.6-2.fc40 ). |
|
So, since the install fail is already fixed a different way on Rawhide, I can't immediately confirm that this would also have fixed it...but it at least doesn't break install again: https://openqa.stg.fedoraproject.org/tests/3141546 I can re-run the process on F39 tomorrow, I guess. F39 doesn't have the other fix yet, so we can see if this fixes the install there. |
Thanks! |
|
Merged the monitoring=0 change in #1343 |
|
Unfortunately seems like the bug still happens: https://openqa.stg.fedoraproject.org/tests/3146620 . I'll verify that the test was good tomorrow, but I think it was. |
|
Hrm. So the error about dmeventd isn't there anymore. I see:
In the storage log for the failed test. But I can't tell what caused it. |
|
I guess that could still simply be caused by the bug the device-mapper-persistent-data update fixes? edit: I checked and the test does look valid - the lorax scratch build did apply the patch, and the openQA installer build test did use the scratch lorax. |
|
Closing because it looks like this was fixed by https://bodhi.fedoraproject.org/updates/FEDORA-2023-b45924046a |
The openQA install_blivet_lvmthin test - which, as the name implies, does an LVM thinp install - is consistently failing (only on ppc64le, for some reason). The logs show that lvm2 is trying to run dmeventd as part of some kind of check of the pool, but it's failing because dmeventd isn't there:
Failed to call the 'LvCreate' method on the '/com/redhat/lvmdbus1/ThinPool/0' object: GDBus.Error:org.freedesktop.DBus.Python.dbus.exceptions.DBusException: ('com.redhat.lvmdbus1.Lv', 'Exit code 5, stderr = /usr/sbin/dmeventd: stat failed: No such file or directory, /usr/sbin/dmeventd: stat failed: No such file or directory, Check of pool fedora/00 failed (status:64). Manual repair required!, Failed to activate thin pool fedora/00.')
So, apparently we do need this now. Whether to use dmeventd or not seems to be a build time check/config option for lvm2, but I don't think we can turn that off just to save a bit of space in the installer image - the package is only about 50K.