On 3/8/19 2:52 PM, Panu Matilainen wrote:
On 3/8/19 2:29 PM, Panu Matilainen wrote:
On 3/8/19 1:54 PM, Florian Weimer wrote:
* Panu Matilainen:
On 3/7/19 5:52 PM, Florian Weimer wrote:
* Panu Matilainen:
On 3/7/19 1:13 PM, Florian Weimer wrote:
* Richard W. M. Jones:
$ sudo dnf install glibc-headers.i686
…
Downgrading:
That looks like a bug in itself.
The last time I looked at something similar, I saw this: RPM
would not
adjust a pre-existing symbolic link to a new target very late in the
transaction. Like deleting old files which are gone in an update or
downgrade, this does *not* happen when the unpacking of the
replacement
package happens, but towards the conclusion of the transaction.
In the
meantime, scriptlets run with the broken file system.
In your case, maybe one of the scriptlet errors prevented the
final step
with the adjustment of the symbolic link by RPM.
(Just to be clear, the symbolic link is regularly packaged, it's not
something that we manage using scripts.)
IIRC the issue is that at when ldconfig runs from the package
scripts,
on downgrade the newer file is still on disk and thus ldconfig leaves
the link the way it is, but at the end of transaction it'll be gone
and symlinks can be broken.
Is there a chance that RPM will be changed to run more scriptlets with
the final disk contents?
There's %transfiletriggerin, %transfiletriggerpostun and %posttrans
that run after the entire transaction, and then the individual
postun-type scripts/triggers. What is it that you're missing?
Correct symbolic links.
If the symbolic links are not installed as they are in the packaged
contents before running scriptlets (any scriptlets), we need to bring
back the ldconfig scriptlets. This is not just a problem for glibc.
Ehm? Symlinks are installed just like any other content, and rpm has
no reason to mess with them. Like I said above, the problem is almost
certainly a mistimed ldconfig causing the links changed back to the
version that is about to get removed.
Hmm, except that in this particular there shouldn't be any mistimed
ldconfigs present. Perhaps I should take a closer look.
It's glibc's own %post own scripts that are somehow breaking it. I've a
minimal reproducer here with glibc 2.29 in /srv/root chroot. The bash
version is just to show whether bash is alive or not:
[root@sopuli glibc]# chroot /srv/test bash --version|head -1
GNU bash, version 4.4.23(1)-release (x86_64-redhat-linux-gnu)
[root@sopuli glibc]# rpm -Uv --oldpackage --root /srv/test
glibc-2.28-26.fc29.x86_64.rpm glibc-common-2.28-26.fc29.x86_64.rpm
glibc-minimal-langpack-2.28-26.fc29.x86_64.rpm
Verifying packages...
Preparing packages...
glibc-common-2.28-26.fc29.x86_64
glibc-minimal-langpack-2.28-26.fc29.x86_64
glibc-2.28-26.fc29.x86_64
glibc-2.29-8.fc30.x86_64
glibc-minimal-langpack-2.29-8.fc30.x86_64
glibc-common-2.29-8.fc30.x86_64
error: failed to exec scriptlet interpreter /bin/sh: No such file or
directory
warning: %triggerpostun(glibc-common-2.28-26.fc29.x86_64) scriptlet
failed, exit status 127
error: failed to exec scriptlet interpreter /bin/sh: No such file or
directory
warning: %triggerin(glibc-common-2.28-26.fc29.x86_64) scriptlet failed,
exit status 127
[root@sopuli glibc]# chroot /srv/test bash --version|head -1
chroot: failed to run command ‘bash’: No such file or directory
So, exactly the same as the original posting. Now, lets go back to the
original scenario, and run the same downgrade with --nopost:
[root@sopuli glibc]# rpm -U --root /srv/test
glibc-2.29-8.fc30.x86_64.rpm glibc-common-2.29-8.fc30.x86_64.rpm
glibc-minimal-langpack-2.29-8.fc30.x86_64.rpm
warning: glibc-2.29-8.fc30.x86_64.rpm: Header V3 RSA/SHA256 Signature,
key ID cfc659b9: NOKEY
[root@sopuli glibc]# chroot /srv/test bash --version|head -1
GNU bash, version 4.4.23(1)-release (x86_64-redhat-linux-gnu)
[root@sopuli glibc]# rpm -Uv --oldpackage --nopost --root /srv/test
glibc-2.28-26.fc29.x86_64.rpm glibc-common-2.28-26.fc29.x86_64.rpm
glibc-minimal-langpack-2.28-26.fc29.x86_64.rpm
Verifying packages...
Preparing packages...
glibc-common-2.28-26.fc29.x86_64
glibc-minimal-langpack-2.28-26.fc29.x86_64
glibc-2.28-26.fc29.x86_64
glibc-2.29-8.fc30.x86_64
glibc-minimal-langpack-2.29-8.fc30.x86_64
glibc-common-2.29-8.fc30.x86_64
[root@sopuli glibc]# chroot /srv/test bash --version|head -1
GNU bash, version 4.4.23(1)-release (x86_64-redhat-linux-gnu)
[root@sopuli glibc]#
glibc's %post is /usr/sbin/glibc_post_upgrade.<arch>, so that's what's
doing something bad here. When straced through forks and all, guess
what? It's running ldconfig:
22611 execve("/usr/sbin/glibc_post_upgrade.x86_64",
["/usr/sbin/glibc_post_upgrade.x86"...], 0x7ffc249bfc00 /* 50 vars */) = 0
22611 arch_prctl(0x3001 /* ARCH_??? */, 0x7ffd33d5ed40) = -1 EINVAL
(Invalid argument)
22611 brk(NULL) = 0x7f42ba930000
22611 brk(0x7f42ba9311c0) = 0x7f42ba9311c0
22611 arch_prctl(ARCH_SET_FS, 0x7f42ba930880) = 0
22611 uname({sysname="Linux", nodename="sopuli.koti.laiskiainen.org",
...}) = 0
22611 readlink("/proc/self/exe", 0x7ffd33d5dc50, 4096) = -1 ENOENT (No
such file or directory)
22611 brk(0x7f42ba9521c0) = 0x7f42ba9521c0
22611 brk(0x7f42ba953000) = 0x7f42ba953000
22611 openat(AT_FDCWD, "/etc/ld.so.conf", O_RDONLY) = 3
22611 fstat(3, {st_mode=S_IFREG|0644, st_size=28, ...}) = 0
22611 read(3, "include ld.so.conf.d/*.conf\n", 28) = 28
22611 close(3) = 0
22611 access("/sbin/ldconfig", X_OK) = 0
22611 vfork( <unfinished ...>
22612 execve("/sbin/ldconfig", ["/sbin/ldconfig"], 0x7ffd33d5ee08 /* 50
vars */ <unfinished ...>
So it's exactly the situtation I explained where a mistimed ldconfig
breaks things. No mystery there.
- Panu -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
