You are not logged in.
.INSTALL line 44 is "systemctl --system daemon-reexec"
I run it, and it is actually what caused container crash
but still no clue what happened and why
Offline
The initprocess needs to be restarted when libsystemd updates *sigh*
Apparently this crashes the init process for you at least when moving from 257 to 258, does it also happen when you've already started 258, don't update anything and just restart the daemon?
Offline
What exactly do you mean by "don't update anything and just restart the daemon"?
When I updated all like in previous attempt (systemctl: command not found). Manually extract systemctl v258. Then stopped container. Container cannot be started again.
Offline
Avodi the crash to update to 258, restart the container (w/ properly and completely installed/upgraded 258) and then try to re-exec the 258 init process (so the process memory gets replaced w/ itself and not a new binary/libs)
Offline
As I described, container cannot be started with updated systemd. It immediately crashes during start without any meaningful explanation
https://paste.c-net.org/CoolingSuggest
in this topic https://bbs.archlinux.org/viewtopic.php?id=308393 , there was another report about problems with Archlinux systemd v258 inside lxc
Last edited by prMoriarty (2025-09-22 20:56:59)
Offline
Just in case, I tested new build systemd-258-3 it caused the same behaviour.
I am not sure how to continue future debugging of this issue and to whom I should report bug (systemd, lxc or ChromeOS) there is almost 0 logs just crash during "systemctl --system daemon-reexec" and container start. I will be appreciated for any hints and support.
Offline
As I described, container cannot be started with updated systemd. It immediately crashes during start without any meaningful explanation
means it's not only the reload by the systemd daemon itself.
=> https://github.com/systemd/systemd/issues
Does https://bbs.archlinux.org/viewtopic.php … 3#p2262853 apply to you?
You might be running into one of the various udev changes, eg. https://github.com/systemd/systemd/issues/39056 / https://github.com/systemd/systemd/issues/39043
Offline
Does https://bbs.archlinux.org/viewtopic.php … 3#p2262853 apply to you?
I don't think so. But I also haven't access to change lxc settings, as the lxc environment is managed on system level and Google/ChromeOS does not provide write access for users.
(termina) chronos@localhost ~ $ cat /etc/lxc/default.conf
lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up
lxc.net.0.hwaddr = 00:16:3e:xx:xx:xx
Thank you for your time and detailed steps for debug. I will try to open a bug for systemd, but I will not be able to provide many details for them.
Offline
I created bug for systemd https://github.com/systemd/systemd/issues/39097
If anyone can add or suggest mindful technical details to add to this bug, I will be very appreciative.
Edit: Chromium issue https://issues.chromium.org/issues/446925532
Last edited by prMoriarty (2025-09-23 23:33:17)
Offline
From the systemd bug
Detected cgroup v1 hierarchy at /sys/fs/cgroup/, which is no longer supported by current version of systemd.
Please instruct your initrd to mount cgroup v2 (unified) hierarchy,
possibly by removing any stale kernel command line options, such as:
systemd.legacy_systemd_cgroup_controller=1
systemd.unified_cgroup_hierarchy=0
[!!!!!!] Detected unsupported legacy cgroup hierarchy, refusing execution.
Exiting PID 1...
Error: write /dev/pts/ptmx: file already closed
was lethal - we got too much caught up in the restart situation.
Offline