Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#43002 - [pacman] [arch-install-scripts] [gnupg] arch-chroot and pacman-key --init fail to work together

Attached to Project: Arch Linux
Opened by brent saner (sanerb) - Thursday, 04 December 2014, 10:21 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 13 December 2014, 15:06 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dan McGee (toofishes)
Gaetan Bisson (vesath)
Dave Reisner (falconindy)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Sometime after 11.27.2014 it seems that I can no longer properly do the following:

arch-chroot /path/to/chroot pacman-key --init

on the snapshot tarballs (once uncompressed) as noted here: .
I use Arch for a multitude of different chroots in a development setup and I'm having some trouble determining what broke exactly.

It begins to generate the keys, but then fails with:

mount: udev is already mounted or /path/to/chroot/dev busy
udev is already mounted on /path/to/chroot/dev
udev is already mounted on /bind/mount/path/to/chroot/dev
udev is already mounted on /bind/mount/path/to/chroot/dev
udev is already mounted on /bind/mount/path/to/chroot/dev

==> ERROR: failed to setup API filesystems in chroot /path/to/chroot

And before you say it, no, it's not because I have the chroot in a bind mount elsewhere because I can confirm this same behavior on a different machine that isn't using bind mounts.

Additional info:
* package version(s)
[root@dawid ~]# pacman -Q | egrep '(linux\ 3|arch-install-scripts|pacman\ )'
arch-install-scripts 13-1
linux 3.17.4-1
pacman 4.1.2-7

[root@dawid ~]# for i in linux arch-install-scripts pacman;do echo ${i} ; pacman -Qi ${i} | egrep '^.*\ Date' ; echo ; done
Build Date : Fri 21 Nov 2014 03:18:29 PM EST
Install Date : Thu 27 Nov 2014 03:00:46 AM EST

Build Date : Wed 05 Feb 2014 05:32:41 PM EST
Install Date : Wed 23 Apr 2014 12:34:24 AM EDT

Build Date : Fri 21 Nov 2014 06:12:25 AM EST
Install Date : Tue 25 Nov 2014 03:00:53 AM EST

My best guess, currently, is pacman (and therefore pacman-key) having been modified, as I doubt it's kernel-related (I'm using 3.15.8-1-ARCH on the other machine exhibiting the same symptoms), and arch-install-scripts has been installed since April and hasn't been updated since.
Either that or something changed with the snapshots themselves (I use the latest, which was updated 12.1.2014).

This occurs when working on both 64- and 32-bit chroots.

Here's some more information about the primary build host:

[root@dawid ~]# uname -a
Linux dawid.loc.lan 3.17.4-1-ARCH #1 SMP PREEMPT Fri Nov 21 21:14:42 CET 2014 x86_64 GNU/Linux

exact snapshots used:

Steps to reproduce:
See above.
This task depends upon

Closed by  Dave Reisner (falconindy)
Saturday, 13 December 2014, 15:06 GMT
Reason for closing:  Fixed
Additional comments about closing:  arch-install-scripts-14
Comment by Doug Newgard (Scimmia) - Thursday, 04 December 2014, 14:14 GMT
Do you get this by simply arch-chrooting? IE, without running pacman-key?
Comment by brent saner (sanerb) - Thursday, 04 December 2014, 19:01 GMT
No, weirdly enough-

In fact, it seems to *only* occur with pacman-key --init being passed as the chrooted command. arch-chroot /path/to/chroot bash -c "pacman-key --init" doesn't work either, unfortunately.

Other pacman-key functions even work fine:

[root@dawid chroot]# arch-chroot root.x86_64/ bash
[root@dawid /]# pacman-key --init
[root@dawid /]# exit
[root@dawid chroot]# arch-chroot root.x86_64/ pacman-key --populate archlinux
==> Appending keys from archlinux.gpg...
==> Locally signing trusted keys in keyring...
-> Locally signing key 0E8B644079F599DFC1DDC3973348882F6AC6A4C2...
-> Locally signing key 684148BB25B49E986A4944C55184252D824B18E8...
-> Locally signing key 44D4A033AC140143927397D47EFD567D4C7EA887...
-> Locally signing key 27FFC4769E19F096D41D9265A04F9397CDFD6BB0...
-> Locally signing key AB19265E5D7D20687D303246BA1DFB64FFF979E7...
==> Importing owner trust values...
==> Disabling revoked keys in keyring...
-> Disabling key F5A361A3A13554B85E57DDDAAF7EF7873CFD4BB6...
-> Disabling key 7FA647CD89891DEDC060287BB9113D1ED21E1A55...
-> Disabling key D4DE5ABDE2A7287644EAC7E36D1A9E70E19DAA50...
-> Disabling key BC1FBE4D2826A0B51E47ED62E2539214C6C11350...
-> Disabling key 4A8B17E20B88ACA61860009B5CED81B7C2E5C0D2...
-> Disabling key 63F395DE2D6398BBE458F281F2DBB4931985A992...
-> Disabling key 0B20CA1931F5DA3A70D0F8D2EA6836E1AB441196...
-> Disabling key 8F76BEEA0289F9E1D3E229C05F946DED983D4366...
-> Disabling key 66BD74A036D522F51DD70A3C7F2A16726521E06D...
-> Disabling key 81D7F8241DB38BC759C80FCE3A726C6170E80477...
-> Disabling key E7210A59715F6940CF9A4E36A001876699AD6E84...
==> Updating trust database...
gpg: next trustdb check due at 2015-03-31

But still, when run directly from the host:

[root@dawid to]# arch-chroot chroot/ pacman-key --init
gpg: /etc/pacman.d/gnupg/trustdb.gpg: trustdb created
gpg: no ultimately trusted keys found
gpg: starting migration from earlier GnuPG versions
gpg: porting secret keys from '/etc/pacman.d/gnupg/secring.gpg' to gpg-agent
gpg: migration succeeded
gpg: Generating pacman keyring master key...
gpg: key 3D1E64AD marked as ultimately trusted
gpg: directory '/etc/pacman.d/gnupg/openpgp-revocs.d' created
gpg: Done
==> Updating trust database...
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
umount: /path/to/chroot/dev: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).)
umount: /path/to/chroot: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).)

I then have to umount -l /path/to/chroot

If I cancel the pacman-key init before it "completes", I am able to rm -rf the root.x86_64 directory (/path/to/chroot). However, if I don't, I get a "Device or resource busy" when trying to remove the directory (though I can delete content inside it); it's as if the mounting isn't being handled properly.

I'm attaching mounts.txt, good_mounts.txt, findmnt.txt, and good_findmnt.txt
the mounts and findmnt show how it looks when the pacman-key --init is running; the good_* files show how it normally looks.

Now, I'd expect to see the mountpoints maybe possibly show up twice in mount/findmnt (one for the actual mount, another for the bind mount)... but four times?

It also strikes me- could this be something GnuPG is doing? I have my strong doubts, but it's a possibility as some libraries for GnuPG have been updated recently as well.
Comment by brent saner (sanerb) - Thursday, 04 December 2014, 19:04 GMT
Whoops, forgot to attach.

Inside, please find:
mounts.txt = mountpoints listed during the behaviour
findmnt.txt = findmnt output listed during the behaviour
good_mounts.txt = mountpoints that are "normally" run (i.e. after a fresh boot of the host)
good_findmnt.txt = the above, for findmnt.

They have been sed'd to match my above references.
Comment by brent saner (sanerb) - Thursday, 04 December 2014, 19:04 GMT
(oh, also- i doubt it has any bearing, but in the interest of full disclosure this is also running inside a git repository.)
Comment by Dave Reisner (falconindy) - Friday, 05 December 2014, 00:39 GMT
Probably Yet Another Bug related to gnupg 2.1.0
Comment by Doug Newgard (Scimmia) - Friday, 05 December 2014, 00:48 GMT
Most likely. I'm going to assign it to everyone involved.
Comment by Jared Biel (jaredbiel) - Monday, 08 December 2014, 20:35 GMT
I ran into this issue too. In my case, I modified the build script that I'm using ( to kill all gpg-agent processes after pacman-key is run for the last time (line 39.)
Comment by brent saner (sanerb) - Monday, 08 December 2014, 20:39 GMT
I rewrote my personal build scripts to use systemd-nspawn instead if present on the system, but being that arch-chroot is the "recommended" way of installing per the wiki and someone out there, I'm sure, turns up new full installs in this way, it's probably something that should be fixed. :)
Comment by Dave Reisner (falconindy) - Friday, 12 December 2014, 02:48 GMT