Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LXD/LXC Debian 11 fails to boot #5504

Closed
7 tasks
vholer opened this issue Aug 19, 2021 · 1 comment
Closed
7 tasks

LXD/LXC Debian 11 fails to boot #5504

vholer opened this issue Aug 19, 2021 · 1 comment

Comments

@vholer
Copy link
Contributor

vholer commented Aug 19, 2021

Description

All Debian 11 guest images from

fails to start completely both inside LXD (ONE 5.12 and 6.0) and LXC (ONE 6.1.80). Systemd inside is stuck on:

...
Aug 19 13:29:31 localhost.localdomain systemd[1]: Condition check resulted in ACPI event daemon being skipped.
Aug 19 13:29:31 localhost.localdomain systemd[1]: Condition check resulted in ACPI event daemon being skipped.
Aug 19 13:29:31 localhost.localdomain systemd[1]: Condition check resulted in ACPI event daemon being skipped.
Aug 19 13:29:31 localhost.localdomain systemd[1]: Condition check resulted in ACPI event daemon being skipped.
Aug 19 13:29:31 localhost.localdomain systemd[1]: Condition check resulted in ACPI event daemon being skipped.
Aug 19 13:29:31 localhost.localdomain systemd[1]: Condition check resulted in ACPI event daemon being skipped.
...

Details

  • Affected Component: LXD, LXC, context?
  • Hypervisor: LXD, LXC
  • Version: 5.12+

Progress Status

  • Branch created
  • Code committed to development branch
  • Testing - QA
  • Documentation
  • Release notes - resolved issues, compatibility, known issues
  • Code committed to upstream release/hotfix branches
  • Documentation committed to upstream release/hotfix branches
@vholer
Copy link
Contributor Author

vholer commented Oct 22, 2021

IMHO the problem is more on the systemd side, as it doesn't handle correctly trigger events from one unit to another, if the target can't process the event. In this case, the source of the events is acpid.path which should kick into acpid service if directory /etc/acpi/events/ is not empty. In case of the containers, the acpid service is disabled by conditional check ConditionVirtualization=!container and can't run. This leads systemd into an infinite loop when the acpid.path generates again and again same trigger events and targeted acpid.service can never process it.

Solution is easy:

  • have package dependency on acpid OR systemd (which should handle ACPI events itself already),
  • where acpid is already used, introduce systemd acpid.path override to check also only when not in containers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants