Creating temporary files... error: command failed to execute correctly

jamespharvey20 · 2018-05-19 12:28:10

pacman -Syu

Just ended with:

(13/19) Creating temporary files...
error: command failed to execute correctly

Everything else looks fine, except for some directory permissions warnings.

What happened? Does something need to be fixed?

This is about 2 month's worth of updates, from kernel 4.15.12-1. Very bad design of a Marvell SATA controller, a bug in btrfs replace, and a bug in btrfs lzo compression have had me pre-occupied, and have been primarily running off ISO's since then diagnosing and digging.

This was off an ISO, in an arch-chroot.

pacman full output: https://pastebin.com/UqnafpfH
applicable part of /var/log/pacman.log: https://pastebin.com/cHiW7ZEL

Last edited by jamespharvey20 (2018-05-20 00:03:59)

a821 · 2018-05-19 13:42:41

Please post full output: https://bbs.archlinux.org/viewtopic.php?id=57855

jamespharvey20 · 2018-05-20 00:29:57

a821 wrote:

Please post full output: https://bbs.archlinux.org/viewtopic.php?id=57855

Fixed, sorry about that!

Looks like "Creating temporary files..." runs "systemd-tmpfiles.hook", which contains:

[Trigger]
Type = File
Operation = Install
Operation = Upgrade
Target = usr/lib/tmpfiles.d/*.conf

[Action]
Description = Creating temporary files...
When = PostTransaction
Exec = /usr/share/libalpm/scripts/systemd-hook tmpfiles
NeedsTargets

"systemd-hook" contains:

#!/bin/sh -e

systemd_live() {
  if [ ! -d /run/systemd/system ]; then
    echo >&2 "  Skipped: Current root is not booted."
    exit 0
  fi
}

udevd_live() {
  if [ ! -d /run/udev ]; then
    echo >&2 "  Skipped: Device manager is not running."
    exit 0
  fi
}

each_conf() {
  while read -r f; do
    "$@" "$(basename "$f")"
  done
}

case $1 in
  catalog)  /usr/bin/journalctl --update-catalog ;;
  hwdb)     /usr/bin/systemd-hwdb --usr update ;;
  update)   touch -c /usr ;;
  sysusers) each_conf /usr/bin/systemd-sysusers ;;
  tmpfiles) each_conf /usr/bin/systemd-tmpfiles --create ;;

  daemon-reload) systemd_live; /usr/bin/systemctl daemon-reload ;;
  udev-reload)   udevd_live;   /usr/bin/udevadm control --reload ;;
  binfmt)        systemd_live; each_conf /usr/lib/systemd/systemd-binfmt ;;
  sysctl)        systemd_live; each_conf /usr/lib/systemd/systemd-sysctl ;;

  *) echo >&2 "  Invalid operation '$1'"; exit 1 ;;
esac

exit 0

So its pertinent parts are merely:

each_conf() {
  while read -r f; do
    "$@" "$(basename "$f")"
  done
}

case $1 in
  ...
  tmpfiles) each_conf /usr/bin/systemd-tmpfiles --create ;;

So, this is running "/usr/bin/systemd-tmpfiles --create [conf file name]" for each conf file in /usr/lib/tmpfiles.d

Running that manually, for each conf, after booting off the drive rather than the ISO appears to succeed, returning 0 on each.

So, I'm guessing whatever didn't run correctly the first time can be ignored since it ran the second time off the actual disk.

regid · 2019-02-14 07:44:31

I, too, had

Creating temporary files...
error: command failed to execute correctly

While using a chroot. This error is not mentioned neither in /var/log/pacman.log, nor in the journal. It was written only to the screen. Why it couldn't be written to the log too?
I got it when

installed xorg-xinit (1.4.0-3)
upgraded libassuan (12.5.2-1 -> 2.5.3-1)
upgraded gnupg (2.2.12-2 -> 2.2.13-1)
upgraded linux-firmware (20190118.a8b75ca-1 -> 20190212.28f5f7d-1)
upgraded linux (4.20.7.arch1-1 -> 4.20.8.arch1-1)

Does one of

$ cat /usr/lib/tmpfiles.d/linux-firmware.conf
w /sys/devices/system/cpu/microcode/reload - - - - 1

$ cat /usr/lib/tmpfiles.d/mkinitcpio.conf 
# Create /run/initramfs for shutdown

d /run/initramfs 0755 root root

is to blame?
I think that when systemd tries to reactivate a deamon, it does manage to recognise it is running in a chroot environment. Can that ability used here too, assuming the chroot is the cause?

Last edited by regid (2019-02-15 20:31:37)

loqs · 2019-02-14 22:39:34

regid wrote:

Can that ability used here too, assuming the chroot is the cause?

Yes modify the tmpfiles entry of /usr/share/libalpm/scripts/systemd-hook so it calls systemd_live in the same manner as the sysctl entry.

regid · 2019-02-15 20:28:55

/usr/share/libalpm/scripts/systemd-hook declares systemd_live to determine if it is running within a chroot environment by looking for the absence of /run/systemd/system.

systemd_live() {
  if [ ! -d /run/systemd/system ]; then
    echo >&2 "  Skipped: Current root is not booted."
    exit 0
  fi
}

Since I actually use arch-chroot, not just chroot, systemd_live does see a /run/systemd/system directory. arch-chroot is using

chroot_add_mount /run "$1/run" --bind &&

Yet for certain actions I am quite sure systemd is able to detect it is running within an arch-chroot environment. I guess it has other means to find that out. Does it? What other means?

loqs · 2019-02-15 21:31:40

If you execute `/usr/bin/systemd-tmpfiles --create` in the arch-chroot does that produce the error message?

alphaniner · 2019-02-15 22:39:38

@jamespharvey20

I've done most of my updates through arch-chroot for years and regularly see that error. I've never noticed any consequences.

regid · 2019-02-18 02:23:32

loqs wrote:

At post #7: If you execute `/usr/bin/systemd-tmpfiles --create` in the arch-chroot does that produce the error message?

(chroot)# /usr/bin/systemd-tmpfiles --create /usr/lib/tmpfiles.d/linux-firmware.conf 
Failed to open file "/sys/devices/system/cpu/microcode/reload": Read-only file system
(chroot)# echo $?
73

loqs · 2019-02-18 02:57:26

If that is the only one then you could file a bug against linux-firmware asking for /usr/lib/tmpfiles.d/linux-firmware.conf to be removed as both intel-ucode and amd-ucode support early loading.
intel-ucode infact only supports early loading 59841. Although at least in the linux-firmware case the issue is not causing any harm.

eschwartz · 2019-02-18 03:06:07

regid wrote:

Does one of

$ cat /usr/lib/tmpfiles.d/linux-firmware.conf
w /sys/devices/system/cpu/microcode/reload - - - - 1

Yes, this is absolutely to blame. What of it? How is the pacman hook supposed to know that a certain subset of the tmpfiles snippets rely on filesystems that are being mounted readonly?

It is not an error that matters. Furthermore, I get the same error, only better.

$ arch-nspawn /var/lib/archbuild/extra-x86_64/eschwartz pacman -S linux-firmware
[sudo] password for eschwartz: 
resolving dependencies...
looking for conflicting packages...

Packages (1) linux-firmware-20190212.28f5f7d-1

Total Installed Size:  430.79 MiB

:: Proceed with installation? [Y/n] 
(1/1) checking keys in keyring                                                             [####################################################] 100%
(1/1) checking package integrity                                                           [####################################################] 100%
(1/1) loading package files                                                                [####################################################] 100%
(1/1) checking for file conflicts                                                          [####################################################] 100%
:: Processing package changes...
(1/1) installing linux-firmware                                                            [####################################################] 100%
:: Running post-transaction hooks...
(1/2) Creating temporary files...
Failed to open file "/sys/devices/system/cpu/microcode/reload": Read-only file system
error: command failed to execute correctly
(2/2) Arming ConditionNeedsUpdate...

So what I want to know is why does pacman in an nspawn container show the error output of the hook, and pacman in a chroot not show the error output?

Note: if pacman *does* show the error output (failed to open file on read-only filesystem), it will be correctly logged to pacman.log -- what it does not however record is "error: command failed to execute correctly".

eschwartz · 2019-02-18 03:57:20

Modifying the hook to strace systemd-tmpfiles...

Inside arch-nspawn, and when run by a pacman hook, it logs the message using:

writev(2, [{iov_base="Failed to create file /sys/devic"..., iov_len=85}, {iov_base="\n", iov_len=1}], 2Failed to create file /sys/devices/system/cpu/microcode/reload: Read-only file system

When pacman was run from an arch-chroot instead, then it logs:

sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="PRIORITY=3\nSYSLOG_FACILITY=3\nCOD"..., iov_len=165}, {iov_base="MESSAGE=", iov_len=8}, {iov_base="Failed to open file \"/sys/device"..., iov_len=85}, {iov_base="\n", iov_len=1}], msg_iovlen=4, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 259

Arch Linux

#1 2018-05-19 12:28:10

Creating temporary files... error: command failed to execute correctly

#2 2018-05-19 13:42:41

Re: Creating temporary files... error: command failed to execute correctly

#3 2018-05-20 00:29:57

Re: Creating temporary files... error: command failed to execute correctly

#4 2019-02-14 07:44:31

Re: Creating temporary files... error: command failed to execute correctly

#5 2019-02-14 22:39:34

Re: Creating temporary files... error: command failed to execute correctly

#6 2019-02-15 20:28:55

Re: Creating temporary files... error: command failed to execute correctly

#7 2019-02-15 21:31:40

Re: Creating temporary files... error: command failed to execute correctly

#8 2019-02-15 22:39:38

Re: Creating temporary files... error: command failed to execute correctly

#9 2019-02-18 02:23:32

Re: Creating temporary files... error: command failed to execute correctly

#10 2019-02-18 02:57:26

Re: Creating temporary files... error: command failed to execute correctly

#11 2019-02-18 03:06:07

Re: Creating temporary files... error: command failed to execute correctly

#12 2019-02-18 03:57:20

Re: Creating temporary files... error: command failed to execute correctly

Board footer