Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#15294 - pacman doesn't chroot prior to executing ldconfig
Attached to Project:
Pacman
Opened by Alexander Foremny (harlekin) - Sunday, 28 June 2009, 10:37 GMT
Last edited by Dan McGee (toofishes) - Thursday, 16 July 2009, 11:16 GMT
Opened by Alexander Foremny (harlekin) - Sunday, 28 June 2009, 10:37 GMT
Last edited by Dan McGee (toofishes) - Thursday, 16 July 2009, 11:16 GMT
|
Detailspacman executes ldconfig with the assumption that packages are installed in the host system. While this assumption is correct in most cases it isn't in all.
Trying to port Arch Linux to ARM based smart phones and using pacman to install the base system we ran into a rather unusual case where we execute pacman from the host system (i686, x86_64) to produce an ARM system (target system). We use qemu's user mode to let pacman install scriptlets in the target system due to emulation, which works fine as pacman chroots. But for the ldconfig call pacman doesn't chroot but instead uses the target system's binary from within the host system. But we cannot execute ARM binaries that easily. As far as I can see it can be considered a bug that pacman doesn't chroot for the ldconfig call. pacman's debug output from the installer: *snip* sh: /home/harlekin/arch/inst/sbin/ldconfig: no such file or directory debug: running "ldconfig -r /home/harlekin/arch/inst/" *snap* This is the typical error if one tries to execute a binary which is compiled for the wrong architecture: $ file /home/harlekin/arch/inst/sbin/ldconfig inst/sbin/ldconfig: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.29, stripped I attached a patch to libalpm which makes pacman chroot prior to the ldconfig call. This solves the issue for me. I hope the patch is useful. The paths could probably be hardcoded, though. 
libalpm-ldconfig-chroot.patch
(3 KiB)
|
This task depends upon
Closed by Dan McGee (toofishes)
Thursday, 16 July 2009, 11:16 GMT
Reason for closing: Fixed
Additional comments about closing: Commit 2e043aae36bdb8a7591646db00a95dd21f1f368f
Thursday, 16 July 2009, 11:16 GMT
Reason for closing: Fixed
Additional comments about closing: Commit 2e043aae36bdb8a7591646db00a95dd21f1f368f
What do others think?
My main problem is that it is not clear atm when we run ldconfig. Sometimes alpm_commit reaches ldconfig, sometimes not (ctrl-c, RET_ERR <- here remove differs from upgrade). It can happen, that ldconfig runs twice, -S conflict resolving (remove + install transactions). I created a patch 1 month ago, but I didn't sent to the ML, because I am not really an ldconfig exprert, and I don't know what is the expected behavior (from end-user) in the above cases (ctrl-c, RET_ERR).
But now I attached that patch. (It is interesting, that with the new patch ldconfig doesn't run when user presses ctrl-c in the download part. This is because of our ctrl-c handling + trans->state)
I would also much prefer reusing or repurposing the existing code for forking and executing install scriptlets, as it looks like this patch duped a lot of that stuff right back in here.
That is the way we run ldconfig : ldconfig -r /home/harlekin/arch/inst/
This affects only the target system, doesn't it?
The only problem is that we use the ldconfig binary from the host, which is sometimes wrong.
If we ran the following : /home/harlekin/arch/inst/bin/ldconfig -r /home/harlekin/arch/inst/ (replace bin/ by the correct dir)
then it would be fine.
However we would assume that ldconfig exists in the target system, which is probably not true from the beginning.
Instead of having the variables char *ldconfig = "/sbin/ldconfig" and use access(ldconfig,...) we could write access("/sbin/ldconfig",...) and drop the extra variable. That's what I meant by "hardcoded paths."
> I would also much prefer reusing or repurposing the existing code for forking and executing install scriptlets, as it looks like this patch duped a lot of that stuff right back in here.
I would agree.
@shining:
We should not run the host system's ldconfig for the target system. pacman doesn't do that right now and it'd be a regression to make pacman do whilst fixing this bug. The chroot is necessary for the target's ldconfig to function correctly.
pacman doesn't rely on ldconfig being present. It only executes ldconfig if it is. This is the default behaviour in 3.2.2. As pointed out in the bug report we cannot rely on the host system being able to execute the target system's binaries.
And your usage of "hardcoding" actually confused me, because ldconfig path is already hardcoded.
It is indeed already the target ldconfig which is used by pacman, not the host one.
But it is not always possible to run the target ldconfig from the host, so a chroot is needed.
So the only point here is that we should try to refactor this chroot code.
harlekin, could you please test(/review) it?
add.c simply calls _alpm_ldconfig(handle->root) and _alpm_ldconfig (util.c) just uses system to execute /path/to/root/sbin/ldconfig -r /path/to/root. To fix this bug we have to execute /sbin/ldconfig (inside /path/to/root chrooted)!
But in general your patch refactors the chroot call. There are just a few things I want to note because I don't know whether they are correct:
1. Is the code to restore the CWD specific to _alpm_run_chroot or to _alpm_runscriptlet? I don't see a reason for it in _alpm_run_chroot.
2. Theoretically the access() checks in _alpm_ldconfig have to be done inside the chroot. Practically one really must not care.
However, those questions are critical to the patch, because if 2 matters we cannot simply chroot to execute a string via the shell, but instead we have to execute a C function. We could make _alpm_run_chroot accept a callback or we could change _alpm_run_chroot to _alpm_fork_chrooted.
I am sorry for the vague comments on your patch, but there are a few things where I just lack experience to decide whether they're right. Because of that I wanted to point them out and let others decide that.
- system(cmd);
+ _alpm_run_chroot(root, "ldconfig");
now it will chroot and run the ldconfig command inside that chroot.
1. the code to restore CWD was made because of the chroot, as far as I can tell
2. access() checks could be done both outside or inside the chroot. but my _alpm_run_chroot function is generic so I cannot do the check there.
http://www.dimoulet.net
http://www.dimoulet.net