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#63920 - [shadow] error message during pacstrap

Attached to Project: Arch Linux
Opened by Toolybird (Toolybird) - Wednesday, 25 September 2019, 23:07 GMT
Last edited by Dave Reisner (falconindy) - Sunday, 12 July 2020, 14:11 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No



The fix for  FS#63248  introduced an install scriptlet which calls setcap. This now produces an error during pacstrap.

Additional info:
* package version(s) -> shadow-4.7-2
* config and/or log files etc.

( 35/125) installing pambase
( 36/125) installing pam
( 37/125) installing libcap-ng
( 38/125) installing audit
( 39/125) installing shadow
error: command failed to execute correctly
( 40/125) installing libcap
( 41/125) installing coreutils
( 42/125) installing libgpg-error
( 43/125) installing libgcrypt

Steps to reproduce:

mkdir /path/to/chroot
mkarchroot /path/to/chroot/root base-devel

shadow likely needs a dep on libcap
This task depends upon

Closed by  Dave Reisner (falconindy)
Sunday, 12 July 2020, 14:11 GMT
Reason for closing:  Fixed
Additional comments about closing:  shadow-4.8.1-2
Comment by Daan De Meyer (DaanDeMeyer) - Saturday, 23 May 2020, 14:43 GMT
I have been occasionally getting this error when creating Arch based images with mkosi ( Error occurs when libcap is installed after shadow. The failure is in the post_install step of the .INSTALL script because setcap is not available when the script is run. A dependency on libcap which provides /usr/bin/setcap should fix the problem.
Comment by Daan De Meyer (DaanDeMeyer) - Saturday, 23 May 2020, 15:33 GMT
Actually, shadow already has a transitive dependency on libcap-ng so it could simply use filecap instead.

Something like the following should work:

setcaps() {
# shadow ships these as setuid, but if we can apply file caps, use those instead.
filecap usr/bin/newuidmap setuid 2>/dev/null && chmod -s usr/bin/newuidmap
filecap usr/bin/newgidmap setgid 2>/dev/null && chmod -s usr/bin/newgidmap

post_install() {

post_upgrade() {
Comment by Daan De Meyer (DaanDeMeyer) - Sunday, 31 May 2020, 13:23 GMT
Ping. It's not a massive issue but constantly seeing errors when pacstrapping does get annoying after a while. The solution I provided should work although it's probably a good idea to add an explicit dependency on libcap-ng instead of relying on it to be transitively available.
Comment by Daan De Meyer (DaanDeMeyer) - Monday, 08 June 2020, 19:55 GMT
Comment by Dave Reisner (falconindy) - Sunday, 12 July 2020, 14:08 GMT
Thanks. Your solution doesn't work, but not for lack of trying. filecap has a terrible UI that assumes that relative paths are caps:

# filecap usr/bin/newuidmap setuid # broken
Unrecognized capability.
usage: filecap [-a | -d | /dir | /dir/file [cap1 cap2 ...] ]

# filecap /usr/bin/newuidmap setuid # works fine