Description of problem: rpm's pretrans scripts are run before any package installation is run, as such the scripts must not depend on any interpreter/only lua is allowed. The problem occurs when creating livecd or similar chroots from scratch, then the pretrans script fails because there is nothing that would provide /bin/sh to run the script Also the pretrans script certainly doesn't need to be pretrans: pretrans scriptlet (using /bin/sh): if [ -f /usr/lib64/libnssckbi.so -a ! -L /usr/lib64/libnssckbi.so ]; then rm -f /usr/lib64/libnssckbi.so fi That could just as well be done in the regular %pre script (that is run after the dependencies were installed, so /bin/sh is available) But I also don't quite see the point in having the script in the first place. I guess the file's owner was moved from libnss to p11-kit-trust and use of a transitional package was avoided with that? But the lib64nss3 package still owns the symlink, so none of that should be necessary in the first place. tldr: * the %pretrans script seems unnecessary/pointless * if it is required, it should be rewritten to lua, similar to https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replacement/#_scriptlet_to_replace_a_symlink_to_a_directory_with_a_directory %pretrans -p <lua> path="/usr/lib64/libnssckbi.so" st=posix.stat(path) if st and st.type == "regular" then os.remove(path) end (the existing pretrans script doesn't remove dangling symlinks, so it's not removed in that snippet either)
Thank you for this learned report. Assuming it applies to just nss, assigning to nicolasS who nurses that. If it is more generic, it should go to mageiatools. CC'ing Jani who knows about this sort of thing.
Assignee: bugsquad => nicolas.salgueroCC: (none) => jani.valimaa
Yep, I'd say %pretrans scriptlet is useless nowadays. Pushed nss-3.113.0-1.1.mga9 without %pretrans to mga9 core/updates_testing. SRPMS: nss-3.113.0-1.1.mga9 RPMS: lib(64)nss-devel-3.113.0-1.1.mga9 lib(64)nss-static-devel-3.113.0-1.1.mga9 lib(64)nss3-3.113.0-1.1.mga9 nss-3.113.0-1.1.mga9 nss-doc-3.113.0-1.1.mga9
Depends on: (none) => 34393Assignee: nicolas.salguero => qa-bugs
Keywords: (none) => advisory
RH x86_64 installing lib64nss3-3.113.0-1.1.mga9.x86_64.rpm nss-3.113.0-1.1.mga9.x86_64.rpm from //home/katnatek/qa-testing/x86_64 Preparing... ################################################################################################## 1/2: nss ################################################################################################## 2/2: lib64nss3 ################################################################################################## 1/2: removing lib64nss3-2:3.113.0-1.mga9.x86_64 ################################################################################################## 2/2: removing nss-2:3.113.0-1.mga9.x86_64 ################################################################################################## strace chromium-browser shows openat(AT_FDCWD, "/lib64/libnss3.so", O_RDONLY|O_CLOEXEC) = 3 Browser works OK strace pidgin shows openat(AT_FDCWD, "/lib64/libnss3.so", O_RDONLY|O_CLOEXEC) = 13 OK for me
Clean update and use with firefox on both i585 (just small test) and x86_64 in use on three machines for some hours of various surfing.
CC: (none) => fri
MGA9-64 server Plasma Wayland on Compaq H000SB No installation issues. Run firefox under strace to be sure mib64nss items are used: they show up. So for me good, awaiting some more tests?
CC: (none) => herman.viaene
I think is good set of test
Whiteboard: (none) => MGA9-64-OK,MGA9-32-OKCC: (none) => andrewsfarm
Validating.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2025-0067.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED