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

boot_order_source_priority fails with Debian 11 guest #783

Closed
iximeow opened this issue Oct 8, 2024 · 0 comments · Fixed by #785
Closed

boot_order_source_priority fails with Debian 11 guest #783

iximeow opened this issue Oct 8, 2024 · 0 comments · Fixed by #785
Assignees
Labels
testing Related to testing and/or the PHD test framework.

Comments

@iximeow
Copy link
Member

iximeow commented Oct 8, 2024

found while digging into #781: repro steps are basically identical. get a Debian 11 image, get Propolis from any commit at or after 11371b0.

run the test with an appropriate adaptation of a command like:

./target/debug/phd-runner run \
    --propolis-server-cmd ./target/release/propolis-server \
    --tmp-directory /tmp/phd \
    --artifact-toml-path ./artifacts-debian-bullseye.toml \
    --default-guest-artifact debian_bullseye \
    --include-filter boot_order_source_priority

this should exit with something like test result: ok. 1 passed; 0 failed; 0 skipped; 0 not run; finished in 23.39s - this is the result with an Alpine guest.

instead, with a Debian 11 guest, this hangs at Waiting for serial output on serial console target="root@debian:~#" and eventually times out.

the tell here is that the line just before is Waiting for output on serial console target="reboot". that is from this reboot, where we're waiting for the new line after sending reboot. it turns out on Debian 11, reboot just reboots the machine immediately, but on more recent linuxes (recent Alpine, Ubuntu 22.04, etc) this is just a compatibility adapter for, it seems like, some systemd incantation that will reboot the machine in the near future.

this is why "reboot and wait for login" works as a strategy for more recent Linux images, but just hangs on Debian 11. on Debian 11, we even cycle all the way through to the login prompt, it's just not what we expected to see in response to reboot, so we keep waiting.

i figure i'll add a helper in the guest adaptations for "Perform graceful reboot initiated by the guest", which should fix this in the process.

@iximeow iximeow added the testing Related to testing and/or the PHD test framework. label Oct 8, 2024
@iximeow iximeow self-assigned this Oct 8, 2024
iximeow added a commit that referenced this issue Oct 9, 2024
While in many cases a procedure like "`reboot` and wait for login" is
sufficient to reboot a guest, it is not sufficient for *all* cases. For
Windows, the command is spelled `shutdown /r` instead. And on Debian (at
least 11), `reboot` will immediately take the guest down instead of
printing a new shell prompt first.

So, have guest OS adapters provide commands that impel a guest to
reboot, and wait for that reboot to occur (rather than the naive initial
approach of reboot, wait for shell prompt, wait for login prompt,
proceed).

Fixes #783.
iximeow added a commit that referenced this issue Oct 9, 2024
While in many cases a procedure like "`reboot` and wait for login" is
sufficient to reboot a guest, it is not sufficient for *all* cases. For
Windows, the command is spelled `shutdown /r` instead. And on Debian (at
least 11), `reboot` will immediately take the guest down instead of
printing a new shell prompt first.

So, have guest OS adapters provide commands that impel a guest to
reboot, and wait for that reboot to occur (rather than the naive initial
approach of reboot, wait for shell prompt, wait for login prompt,
proceed).

Fixes #783.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
testing Related to testing and/or the PHD test framework.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant