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#61808 - {arch-install-scripts} bind mount of /run causes systemd-tmpfiles to mess up uids in host /run

Attached to Project: Arch Linux
Opened by Axel Hinrichs (ahinrichs) - Tuesday, 19 February 2019, 13:54 GMT
Last edited by Eli Schwartz (eschwartz) - Wednesday, 20 February 2019, 17:56 GMT
Task Type Bug Report
Category Arch Projects
Status Assigned
Assigned To Dave Reisner (falconindy)
Eli Schwartz (eschwartz)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No


Description: pacstrap bind mounts host /run into chroot dir. If you install systemd in chroot the post install hook systemd-tmpfiles.hook is run with the chroot /etc/passd but host /run. On my host the uid of systemd-network differes from the new chroot and so /run/systemd/netif gets messed up.

Additional info:
* commit
changed to bind mount the host dir /run in $newroot
* intention was to fix

Steps to reproduce:
# ls -la /run/systemd/
drwxr-xr-x 5 systemd-network systemd-network 120 Feb 19 14:09 netif
# mkdir /tmp/chroot
# pacstrap -c /tmp/chroot systemd
# ls -la /run/systemd/
drwxr-xr-x 5 981 981 120 Feb 19 14:23 netif
This task depends upon

Comment by Dave Reisner (falconindy) - Wednesday, 20 February 2019, 18:07 GMT
Ok, but what's the effect of this?
Comment by Axel Hinrichs (ahinrichs) - Wednesday, 20 February 2019, 22:00 GMT
(actually I searched for a method to change the task description - package name - and severity by myself and didn't succeed...)

I don't think the pacstrap run should have side effects on the hosts /run tree. In my case the effect was, that the host /run/systemd/netif({links/lease} folders weren't writable by the systemd-networkd anymore flooding log with "access denied". But I could think of any kind of problems.

$newroot/run used to be an empty tmpfs. To fix the  bug 61040  the chroot lvm install scripts should be able to talk to the running lvm sockets /run/lvm/lvmetad.socket. For that they bind mount the whole /run folder into $newroot. But any package script of the pacstrap run now operates on the host /run folder which I don't think is intended.

I could think of making $newroot/run again an empty tmpfs and just bind mount /run/lvm on $newroot/run/lvm. Or to fix the other side /usr/share/libalpm/scripts/systemd-hook should check systemd_live before "tmpfiles --create" too.
Comment by loqs (loqs) - Wednesday, 20 February 2019, 22:15 GMT
With lvm 2.03 lvmetad support is removed so there would be no /run/lvm/lvmetad.socket perhaps the changes for  FS#61040  could then be reverted.
Comment by Axel Hinrichs (ahinrichs) - Wednesday, 20 February 2019, 22:46 GMT
Probably. And I actually don't think that the behaviour of systemd is perfect here. But I *really* don't like the idea that any (misbehaving) package script of a pacstrap run could have side effects on the running host. It caused me some headaches to find the cause of the changed uid:gid in /run/systemd/netif.

Comment by tinywrkb (tinywrkb) - Thursday, 04 June 2020, 19:15 GMT
Please switch $chroot/run from /run bind mount to tmpfs.

When bind mounting /run, a docker daemon from host is somehow using $chroot/run/docker/netns/* as mount targets and pacstrap seems to fail (silently) on unmounting $chroot/run because of it.
I might be hitting a similar issue to this:
Patching pacstrap and arch-chroot to mount $chroot/run as tmpfs fix this for me.
Comment by loqs (loqs) - Friday, 05 June 2020, 18:53 GMT
@tinywrkb as you are reverting the fix for  FS#61040  does that reintroduce that issue?
If  FS#61040  is still an issue, is there an alternative solution that can be applied to grub?
Or what if $chroot/run is made a tmpfs again with /run/lvm being bind mounted to $chroot/run/lvm within it?
Comment by tinywrkb (tinywrkb) - Monday, 08 June 2020, 15:38 GMT
@loqs you means this?
then yes, this is basically what I've done.

I don't use lvm so I don't know if the change ends with a regression for lvm users.
But the current behavior is also not unacceptable and it unexpectedly took down my X session as my Xauthority is set to $XDG_RUNTIME_DIR"/Xauthority.
Initially, I also made the mistake of deleting $chroot/run, thinking pacstrap unmounted everything correctly, and that ended with needing to use SysRq in order to reboot.
Comment by loqs (loqs) - Monday, 08 June 2020, 16:43 GMT
See attached patch for what I was attempting to describe. Not implemented is the creation of $chroot/run/lvm being contingent on the existence of /run/lvm

If you build arch-install-scripts with the applied patch does arch-chroot work as expected on your system?
Comment by Axel Hinrichs (ahinrichs) - Tuesday, 09 June 2020, 10:04 GMT
@loqs yes, this was also my suggestion in the first comment. To me this looks good and is a much better solution to fix  FS#61040  than the first fix. (TBH: I did not fully build the package for testing the patch but applied it by hand to arch-chroot)
Comment by tinywrkb (tinywrkb) - Wednesday, 10 June 2020, 21:42 GMT
@loqs yes, with the suggested patch pacstrap is working fine, it doesn't negatively affect the host, and the host's docker service doesn't use $chroot/run/docker/netns/* as mount targets.
Comment by tinywrkb (tinywrkb) - Friday, 28 May 2021, 11:28 GMT
@eschwartz or @falconindy is there a reason not to apply the suggested changes in the patch attached by @loqs and close this issue? It would be nice to be able to switch back to the official arch-install-scripts and not having to maintain my own package.
Comment by Tom Yan (tom.ty89) - Monday, 06 September 2021, 12:43 GMT
Why not just bind mount /run read-only?
Comment by tinywrkb (tinywrkb) - Monday, 06 September 2021, 21:40 GMT
@tom.ty89 some packages might (wrongly) be packaging some resources that are in `/run`. While the packaging should be fixed, it's better not to break the installation process.
For example, samba did this, packaging `/run/samba`, thankfully it was fixed, and my bug report wasn't ignored like the autofs one which I believe is still packaging `/run`, now in the AUR.
Comment by Tom Yan (tom.ty89) - Tuesday, 07 September 2021, 01:16 GMT
IIRC pacman does not even stop when some of the files cannot be updated / rewritten.
Comment by tinywrkb (tinywrkb) - Tuesday, 07 September 2021, 09:47 GMT Comment by Tom Yan (tom.ty89) - Tuesday, 07 September 2021, 13:37 GMT
Honestly, I don't really care (and my "IIRC" was based on some `chattr +i` workaround I practise before I notice NoExtract, in case you are "interested"). Often "showing" what is wrong / broken is the only way to get people motivated in fixing it, and to me it would never be a reason to avoid doing a right thing.

P.S. What I think does not really matter though. At the end of the day it's really just a matter of who's maintaining / who has the right to maintain it, and some Arch dev(s) (well, or just people in general) are known to have their own worldview on what's right or wrong / good or bad, without needing a rationale or proof to support it. (Luckily, it's just a script anyway.)
Comment by tinywrkb (tinywrkb) - Tuesday, 07 September 2021, 14:21 GMT
> Honestly, I don't really care

So you suggest a fix and then don't care about testing if it diverges from current behavior?

>Often "showing" what is wrong / broken is the only way to get people motivated in fixing it

I have bug reports about packaging issues that have been ignored for over a year without any response from the package maintainer, even when suggesting a fix, sometimes as an attached patch.
I think that you shouldn't create a problem that didn't exist and throw this at package maintainers.

> ... are known to have their own worldview on what's right or wrong / good or bad, without needing a rationale or proof to support it.

That's call religion, and I hope that's not a factor in software development related decisions.