You are not logged in.
When I use pacstrap (from `arch-install-scripts`) to build a chroot environment or container image, I see it's trying to use the pacman hooks installed on my host system. However, the hooks always fail, presumably because the requisite binaries are missing from the empty chroot directory. For example:
$ sudo pacstrap -c ./chroot base
...
:: Running pre-transaction hooks...
(1/1) Backing up /boot...
error: unable to run hook 50-boot-backup.hook: could not satisfy dependencies
Is there a way to avoid this behavior without removing these hooks for my host system? I know I can suppress a hook by overwriting it with a symlink to `/dev/null`, but I still want the hooks to run normally, just not when using pacstrap.
I understand pacstrap is mostly just a wrapper script for pacman, but I haven't been able to figure out a way to do this by invoking pacman directly either.
Last edited by quyk (2020-04-26 02:49:38)
Offline
It sounds like you are running pacstrap from an arch installation. If this is the case, then pacstrap will not behave as it would during a live boot, where it is designed to install packages onto a partition of your choice. I would suggest creating a live boot on a USB key or something like that and try using pacstrap from there.
Offline
build a chroot environment or container image
Use a bootstrap image for that: https://wiki.archlinux.org/index.php/In … commended)
Offline
When I use pacstrap (from `arch-install-scripts`) to build a chroot environment or container image, I see it's trying to use the pacman hooks installed on my host system. However, the hooks always fail, presumably because the requisite binaries are missing from the empty chroot directory. For example:
$ sudo pacstrap -c ./chroot base ... :: Running pre-transaction hooks... (1/1) Backing up /boot... error: unable to run hook 50-boot-backup.hook: could not satisfy dependencies
Is there a way to avoid this behavior without removing these hooks for my host system? I know I can suppress a hook by overwriting it with a symlink to `/dev/null`, but I still want the hooks to run normally, just not when using pacstrap.
Is this actually problematic, or just a prettiness concern? Since pacstrap is invoking pacman with the host /etc/pacman.conf and simply replacing the RootDir using the --root option, you're still using the host's CacheDir, GPGDir, HookDir... if you have manually specified DBPath or LogFile on the host, then these too will be used from the host even though they'd normally be used on the guest.
The pacman(8) manpage documents these concerns under the -root option.
I understand pacstrap is mostly just a wrapper script for pacman, but I haven't been able to figure out a way to do this by invoking pacman directly either.
pacman --sysroot exists for this purpose (to chroot into a directory and treat it as a guest OS instead of just changing the extraction path), but it assumes you already have an install.
The pacman(8) manpage documents under the --root option that you should consider using --sysroot instead.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
I tried moving some of my hook files from `/etc/pacman.d/hooks/` to `/usr/share/libalpm/hooks/`, and I no longer see them appearing in output from pacstrap. I think it solves the problem, though I'm not entirely clear on why.
Use a bootstrap image for that: https://wiki.archlinux.org/index.php/In … commended)
This is interesting, I hadn't noticed there was an image available for this purpose.
Is this actually problematic, or just a prettiness concern?
My concern is that hooks added by packages I've installed on my host make it difficult to build a clean chroot.
Since pacstrap is invoking pacman with the host /etc/pacman.conf and simply replacing the RootDir using the --root option, you're still using the host's CacheDir, GPGDir, HookDir... if you have manually specified DBPath or LogFile on the host, then these too will be used from the host even though they'd normally be used on the guest.
pacman --sysroot exists for this purpose (to chroot into a directory and treat it as a guest OS instead of just changing the extraction path), but it assumes you already have an install.
Ah, I appreciate the explanation; I misunderstood the description of these options in the manual.
Offline
I tried moving some of my hook files from `/etc/pacman.d/hooks/` to `/usr/share/libalpm/hooks/`, and I no longer see them appearing in output from pacstrap. I think it solves the problem, though I'm not entirely clear on why.
It's not a HookDir, it's hardcoded into pacman, so IIRC that path is therefore resolved relative to the extraction dir, because packages installing hooks would install them there too.
eschwartz wrote:Is this actually problematic, or just a prettiness concern?
My concern is that hooks added by packages I've installed on my host make it difficult to build a clean chroot.
Hmm? Packages you've installed on your host should be putting hooks in the /usr/share directory reserved for packages and shouldn't be a problem. The one hook for which you showed output didn't run due to missing dependencies. I think dependencies are a reasonable way to handle this... any hook should be able to function if its dependencies are met.
eschwartz wrote:Since pacstrap is invoking pacman with the host /etc/pacman.conf and simply replacing the RootDir using the --root option, you're still using the host's CacheDir, GPGDir, HookDir... if you have manually specified DBPath or LogFile on the host, then these too will be used from the host even though they'd normally be used on the guest.
pacman --sysroot exists for this purpose (to chroot into a directory and treat it as a guest OS instead of just changing the extraction path), but it assumes you already have an install.
Ah, I appreciate the explanation; I misunderstood the description of these options in the manual.
The differences between --root and --sysroot are confusing enough that we tried deprecating --root for removal, but had to un-deprecate it because it doesn't handle all cases. Specifically, we couldn't yet implement pacstrap with --sysroot, which is why it stays for now.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline