#12602 closed bug (fixed)
find_paths does not work inside chroot.
| Reported by: | pulkomandy | Owned by: | pulkomandy |
|---|---|---|---|
| Priority: | high | Milestone: | R1/beta1 |
| Component: | Kits/Storage Kit | Version: | R1/Development |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
The find_paths command (and probably the API as a whole) does not work properly when inside a chroot.
The following command was found in mev build system:
findpaths -r "makefile_engine" B_FIND_PATH_DEVELOP_DIRECTORY
When used inside an haikuporter chroot, it will only work if there is a makefile_engine package installed outside the chroot, in the real /system directory. It is expected that it would look for package mount points inside the chroot, instead.
Attachments (1)
Change History (7)
by , 9 years ago
| Attachment: | mev_build.log added |
|---|
comment:1 by , 8 years ago
| Milestone: | Unscheduled → R1/beta1 |
|---|---|
| Priority: | normal → high |
comment:2 by , 8 years ago
Investigation progress:
findpaths -r needs to first find the requested package. It does so by querying the package roster for all installed packages. This is implemented through BDaemonClient::GetInstallationLocationInfo, which asks the package daemon.
The problem is, the package daemon lives outside the chroot and has no idea about it. So, it will return the main system packages directories instead of the ones in the chroot. Moreover, it returns a device+node pair, which the package kit can use to "escape" the chroot and list packages outside of it. So we end up with the list of packages from the system, which is the cause for the bug here and also a security problem.
comment:3 by , 8 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → in-progress |
comment:5 by , 8 years ago
The link of the fix seems to lead to a commit which has nothing to do with this ticket??
comment:6 by , 8 years ago
This is because that hrev has two (unrelated) commits. The other one is accessible with the "parent" link from cgit: http://cgit.haiku-os.org/haiku/commit/?id=6262ccbbe8b5d6d3b5d6e4c18f378d66cbbe7ba0
Moving to beta1: this error prevents setting up build slaves with mmlr tools.
In this configuration, the build slave does not use the packages from /system at all, instead, a separate local package repository is used. This allows running an old version of Haiku, but building packages for a newer one, and vice versa. So, the buildslaves' system can be left at a single "stable" version, then they can be used to build packages targetting any other version of Haiku.
However,
findpaths -ruses package information from the "real" /boot/system, somehow escaping the chroot. So, it will try to find the makefile_engine package (for example) using the hrev from the real /system, in the repo populated in the package building chroot (confirmed by stracing the call to findpaths).