Created attachment 13806 [details] report.bug.xz from installation that showed the error Seen several times when installing from the latest (03-May-2023) Mageia-9-beta2-x86_64 ISO currently in QA. It doesn't happen every time, so is most likely a package dependency or dependency loop issue that depends on the exact order the packages get installed. The error prevents the auditd service from being enabled during installation, but has no other obvious ill-effects.
From the install log: /var/tmp/rpm-tmp.GJ9Dtn: line 12: /usr/bin/systemd-tmpfiles: No such file or directory /var/tmp/rpm-tmp.GJ9Dtn: line 17: systemctl: command not found /var/tmp/rpm-tmp.GJ9Dtn: line 18: systemctl: command not found %post(audit-3.0.9-2.mga9.x86_64) scriptlet failed, exit status 127
Thanks. The audit package has Requires(post): rpm-helper, which requires systemd-units, which is provided by systemd, which provides those commands, so we're dealing with a dependency loop here, which is why it doesn't happen every time.
Thank you both for your learned comments. So what can we do? Is it specific to the audit package - to assign appropriately? Make this an Installer bug, and assign to mageiatools in consequence?
CC: (none) => lewyssmith
I think, but am not sure, that it's due to trying to start the audit service rather then just enabling it due to the installation going to a chroot.
CC: (none) => davidwhodgins
The way the audit scriplets do that isn't normal (it using our macros, because systemctl stop does not work with the audit service, but the old service command does for some reason), but the fact that it does it isn't abnormal, but that's the issue here. Martin's logs show that the systemctl command is missing (which would trip up even our normal macros if they were being used). It's a dependency loop between audit and systemd (i.e., through some dependency chain, systemd is also requiring audit). On Mageia 8, I don't see that, so I can't debug it further.
"it using our macros" was supposed to be "it isn't using our macros"
Geez I'm sloppy, I just found another typo. Reposting. The way the audit scriplets do that isn't normal (it isn't using our macros, because systemctl stop does not work with the audit service, but the old service command does for some reason), but the fact that it does it isn't abnormal, but that isn't the issue here. Martin's logs show that the systemctl command is missing (which would trip up even our normal macros if they were being used). It's a dependency loop between audit and systemd (i.e., through some dependency chain, systemd is also requiring audit). On Mageia 8, I don't see that, so I can't debug it further.
systemd and audit are in the same transaction. Shouldn't the enabling/starting (however it's done for audit) be in a posttrans scriptlet rather then a postinstall scriptlet?
I'm on Mageia 8 too, but 'urpmq --use-distrib' is your friend :-) The dependency loop is audit -> rpm-helper -> shadow-utils -> libsemanage -> audit The dependency was added in this commit to libsemanage https://svnweb.mageia.org/packages?view=revision&revision=1954969 If that dependency is really needed, then yes, the way to fix this is to change the audit package %post scriplet into a %posttrans scriplet.
unneeded harcoded dependencies fixed in libsemanage-3.4-4.mga9
CC: (none) => geiger.david68210
Thanks to everyone for profound contributions. And DavidG for a fix. Closing with optimism; re-open if need be.
Source RPM: (none) => libsemanage-3.4-4.mga9.src.rpm, audit-3.0.9-2.mga9.src.rpmStatus: NEW => RESOLVEDResolution: (none) => FIXED
*** Bug 31943 has been marked as a duplicate of this bug. ***
CC: (none) => linux
Still valid with the publicly available Beta 2 ISO. But I don't know if it is normal because it will be fixed for RC or if it should be fixed with these ISOs.
CC: (none) => cyril.levet0780
It will be fixed in the rc iso images. The beta 2 iso images were already in qa testing when it was fixed in the repos. The decision was not to rebuild and retest the iso images, as that would have delayed the beta 2 release likely for another week.
Also, just fyi, we know the error is fixed in the repos that will be used to build the rc iso images by testing with the online repos enabled at the start of the install. While annoying, the message is cosmetic. It does not stop the installation.
Ok. Thanks. I was not sure because the last message on this thread was May the 8th, when the public ISOs are dated May the 19th. Of course is a minor error but if someone outside Mageia test it and see it's bad publicity.
$ cat m9/Mageia-9-beta2-x86_64/DATE.txt Wed May 3 11:09:46 AM CEST 2023 The iso images were gpg signed and then released May the 19th, but were built on May the 3rd. It takes one to two weeks for the qa iso testers to test the 6 iso images, especially the classical iso images where multiple combinations of the various desktop environments undergo testing, including getting those bugs fixed. The rc iso images should take less time as there should be fewer changes between beta2 and the rc iso images. It depends on what bugs are found during the public testing of the beta 2 images. Given the time it takes to build and test the iso images, only very severe bugs result in the images getting rebuilt for alpha and beta iso images. I've added an entry for this to https://wiki.mageia.org/en/Mageia_9_Errata#Various_software