Error: unable to write to pipe (Broken pipe)

Got this for the second time in the last few days.
I reinstalled kernels before rebooting.

I read through previous posts about broken pipe errors, just wondering if this may be an issue that needs to be addressed since it’s happening with the last couple of updates.

:: Running post-transaction hooks...
( 1/17) Creating system user accounts...
( 2/17) Reloading system manager configuration...
( 3/17) Reloading user manager configuration...
( 4/17) Updating udev hardware database...
( 5/17) Restarting marked services...
( 6/17) Creating temporary files...
( 7/17) Reloading device manager configuration...
( 8/17) Arming ConditionNeedsUpdate...
( 9/17) Running kernel-install...
Running kernel-install for 6.17.9-arch1-1
Running kernel-install for 6.12.59-1-lts
error: unable to write to pipe (Broken pipe)
(10/17) Reloading system bus configuration...
(11/17) Checking for old perl modules...
(12/17) Hook to rank EndeavourOS mirrors after installing or upgrading the related mirrorlist package
  -> configuration set to rank mirrors
==> eos-rankmirrors: info: extracting package endeavouros-mirrorlist 25.11.1-1 ...
==> eos-rankmirrors: info: ranking EndeavourOS mirrors, please wait ...

==> Writing new ranked EndeavourOS mirrorlist to /etc/pacman.d/endeavouros-mirrorlist.pacnew.

(13/17) Check if user should be informed about rebooting after certain system package upgrades.
(14/17) Updating icon theme caches...
(15/17) Checking which packages need to be rebuilt
(16/17) Updating the desktop file MIME type cache...
(17/17) Updating the vlc plugin cache...
[eosblu@machina ~]$ sudo reinstall-kernels
Installing kernel 6.17.9-arch1-1
Installing kernel 6.12.59-1-lts
[eosblu@machina ~]$ 

That can safely be ignored. All is well.

I’m assuming the OP is using systemd-boot?

Update (rebuild) kernel boot images

When using default systemd-boot and dracut:

sudo reinstall-kernels

When using Grub and dracut:

sudo dracut-rebuild

Yes, systemd-boot.
Does the error message eventually go away?

I’m not sure…. I don’t use systemd much. I do have it on one laptop which has both the lts and current kernel installed. I just started it up and ran an update. I didn’t get that error. I will post the output in a second.

Edit: Sorry I didn’t notice it at first. But I think @UncleSpellbinder is correct it’s not an issue.

:: Running post-transaction hooks…
( 1/18) Creating system user accounts…
( 2/18) Reloading system manager configuration…
( 3/18) Reloading user manager configuration…
( 4/18) Updating udev hardware database…
( 5/18) Restarting marked services…
( 6/18) Creating temporary files…
( 7/18) Reloading device manager configuration…
( 8/18) Arming ConditionNeedsUpdate…
( 9/18) Updating module dependencies…
(10/18) Running kernel-install…
Running kernel-install for 6.17.9-arch1-1
Running kernel-install for 6.12.59-1-lts
error: unable to write to pipe (Broken pipe)
(11/18) Reloading system bus configuration…
(12/18) Checking for old perl modules…
(13/18) Hook to rank EndeavourOS mirrors after installing or upgrading the related mirrorlist package
→ configuration set to rank mirrors
==> eos-rankmirrors: info: extracting package endeavouros-mirrorlist 25.11.1-1 …
==> eos-rankmirrors: info: ranking EndeavourOS mirrors, please wait …

==> Writing new ranked EndeavourOS mirrorlist to /etc/pacman.d/endeavouros-mirrorlist.pacnew.

For what it’s worth: I see this message intermittently as well. From the sources I looked at when I first saw it, I understood the message could safely be ignored.

It’s a message you see sometimes, it only relates to a shell pipe (|), usually it means that a process has ended while one connected to it is still running. There is nothing wrong with the update.

This is just a nuisance message. It is a message from pacman. Unfortunately, pacman throws that error if the hook doesn’t read the entire pipe. My script stops reading the pipe once it has enough information.

I need to fix it but it doesn’t hurt anything. It doesn’t mean the process wasn’t successful.

I only recently found out what the source of the problem was when someone opened an issue about it.

I found this

Perhaps of interest?

Yes, I read that. You can see that they opened an issue in my gitlab last week.

I would have seen it sooner except it was posted at the wrong dracut repo.