[root@dell-r640-053 69]# ls kernel-6.9.0-64.fc41.x86_64.rpm kernel-modules-6.9.0-64.fc41.x86_64.rpm kernel-core-6.9.0-64.fc41.x86_64.rpm kernel-modules-core-6.9.0-64.fc41.x86_64.rpm [root@dell-r640-053 69]# rpm -ivh kernel-* --force Verifying... ################################# [100%] Preparing... ################################# [100%] Updating / installing... 1:kernel-modules-core-6.9.0-64.fc41################################# [ 25%] 2:kernel-core-6.9.0-64.fc41 ################################# [ 50%] 3:kernel-modules-6.9.0-64.fc41 ################################# [ 75%] 4:kernel-6.9.0-64.fc41 ################################# [100%] warning: posix.fork(): .fork(), .exec(), .wait() and .redirect2null() are deprecated, use rpm.execute() instead warning: posix.wait(): .fork(), .exec(), .wait() and .redirect2null() are deprecated, use rpm.execute() instead warning: posix.exec(): .fork(), .exec(), .wait() and .redirect2null() are deprecated, use rpm.execute() instead Reproducible: Always Steps to Reproduce: 1. install the kernel rpm 2. 3.
I think this is glibc-common's %transfiletriggerpostun (which does call posix.fork() etc) firing on /lib/modules: %transfiletriggerin common -P 2000000 -p <lua> -- /lib /usr/lib /lib64 /usr/lib64 A deprecation warning is not a bug. Reassiging to glibc where these originate from. But, I also see this in glibc.spec, added last December according to git: -- We must not use rpm.execute because this is a RPM 4.15 features and -- we must still support downstream bootstrap with RPM 4.14 and missing -- containerized boostrap. So it's a bit of a bind here, and we'll need to figure out something. Is the rpm 4.14 version requirement from RHEL 8 or something else, and how long do you need to maintain this compatibility?
Panu, The rpm 4.14 version requirement comes from the CentOS Stream 10 and RHEL10 bootstrap effort. See https://issues.redhat.com/browse/RHEL-19045 I expect that we should be able to clean this up for Rawhide and Fedora 41 in short order. Marking this as a duplicate of an earlier issue we have for tracking this cleanup. *** This bug has been marked as a duplicate of bug 2291869 ***
Ack, that's good news then, thanks for the clarification. The main thing is that this is more of a temporary need for a while more, and not "until RHEL 8 goes out of support" kind of thing. FWIW, I'm open to temporarily silencing the warning in Fedora if it starts getting on your nerves in the meanwhile.
(In reply to Panu Matilainen from comment #1) > I think this is glibc-common's %transfiletriggerpostun (which does call > posix.fork() etc) firing on /lib/modules: > > %transfiletriggerin common -P 2000000 -p <lua> -- /lib /usr/lib /lib64 > /usr/lib64 > > A deprecation warning is not a bug. Reassiging to glibc where these > originate from. > > But, I also see this in glibc.spec, added last December according to git: > > -- We must not use rpm.execute because this is a RPM 4.15 features and > -- we must still support downstream bootstrap with RPM 4.14 and missing > -- containerized boostrap. > > So it's a bit of a bind here, and we'll need to figure out something. Is the > rpm 4.14 version requirement from RHEL 8 or something else, and how long do > you need to maintain this compatibility? That's the easy part, we can just use rpm.execute if it's available for that. The hard part is this one: -- (4) On upgrades, restart systemd if installed. "systemctl -q" does -- not suppress the error message (which is common in chroots), so -- open-code rpm.execute with standard error suppressed. if tonumber(arg[2]) >= 2 and posix.access("%{_prefix}/bin/systemctl", "x") then local pid = posix.fork() if pid == 0 then posix.redirect2null(2) posix.exec("%{_prefix}/bin/systemctl", "daemon-reexec") elseif pid > 0 then posix.wait(pid) end end We really want that posix.redirect2null(2) part, and we can't get that with rpm.execute today. Reported here as well: posix.redirect2null deprecated without replacement <https://github.com/rpm-software-management/rpm/issues/3192>