It was <2020-06-09 wto 22:07>, when Andreas Beckmann wrote:
> On 09/06/2020 10.43, Lukasz Stelmach wrote:
>> I assume, however,that in case of chroot environmets running udevadm
>> isn't crucial for a successful installation. I was thinking, maybe run
>> udevadm only if /sys is mounted like this?
>
> systemd/udev already uses this check in various places, there is no need
> to add another one effectively doing the same:
>
> (implementation from systemd/sid, src/basic/virt.c)
> int running_in_chroot(void) {
> int r;
>
> if (getenv_bool("SYSTEMD_IGNORE_CHROOT") > 0)
> return 0;
>
> r = files_same("/proc/1/root", "/", 0);
> if (r < 0)
> return r;
>
> return r == 0;
> }
I hadn't got /proc mounted in chroot. Hence, files_same returned r < 0
as did running_in_chroot() which in turn confused udevadm trigger.
if (running_in_chroot() > 0) {
log_info("Running in chroot, ignoring request.");
return 0;
}
Mounting /proc in chroot fixes the problem.
Honestly, I am not quite sure what is the right solution here. They are
all arbitrary. On one hand, probably chroot should have all the API file
systems mounted properly to expect tools like udevadm to behave
reasonably. But on the other, I can't see a reason (as I mentioned
before), for the dmraid postinst script to fail. Mounting API file
systems in a foreign (different arch) chroot may also be confusing for
some other tools. I don't know.
Anyway, thanks for helping me analyze the problem.
Kind regards,
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
signature.asc
Description: PGP signature
