Skip to content

Conversation

@hawkw
Copy link
Member

@hawkw hawkw commented Feb 5, 2026

That PHD test lshw_lifecycle_test, which starts a VM, runs lspci
and lshw, stops, and restarts the VM, and asserts that the output of
those commands on the original and subsequent VM are the same. This is
intended to demonstrate that guest devices are not arbitrarily scrambled
after restarting the guest, which is important.

Fortunately for us, when running PHD tests with Alpine Linux as the
guest OS (as we do on CI), the output of those commands on the initial
and subsequent guests are, in fact, the same.

Unfortunately, however, the output is:

localhost:~# stty -F `tty` cols 9999
localhost:~# sudo lspci -vvx
-ash: sudo: not found
localhost:~# sudo lshw -notime
-ash: sudo: not found

Which, as you can see, does in fact successfully demonstrate that both
guests are seeing the same PCIe devices and such. :)

Yeah.

That sucks lol.

This commit fixes that by removing the sudo, which doth not exist on
Alpine Linux without having installed it. We don't actually need sudo
on Alpine, since we log in as root anyway, which is the correct and
proper thing to do on linux
.

This should be fine when running the tests with other Linuces as the
guest OS, since the very first thing the GuestOs implementation for
Ubuntu 22.04, does is to immediately sudo bash to become root
immediately
, and the Debian 11 one also does the morally correct
thing and logs in as root
.

Fixes #1036

That PHD test `lshw_lifecycle_test`, which starts a VM, runs `lspci` and
`lshw`, stops, and restarts the VM, and asserts that the output of those
commands on the original and subsequent VM are the same. This is
intended to demonstrate that guest devices are not arbitrarily scrambled
after restarting the guest, which is important.

Fortunately for us, when running PHD tests with Alpine Linux as the
guest OS (as we do on CI), the output of those commands on the initial
and subsequent guests are, in fact, the same.

Unfortunately, however, the output is:

```console localhost:~# stty -F `tty` cols 9999 localhost:~# sudo lspci
-vvx -ash: sudo: not found localhost:~# sudo lshw -notime -ash: sudo:
not found ```

Which, as you can see, _does_ in fact successfully demonstrate that both
guests are seeing the same PCIe devices and such. :)

Yeah.

That sucks lol.

This commit fixes that by removing the `sudo`, which doth not exist on
Alpine Linux without having installed it. We don't actually need `sudo`
on Alpine, since we log in as root anyway, [which is the correct and
proper thing to do on linux][1].

This should be fine when running the tests with other Linuces as the
guest OS, since the very first thing the `GuestOs` implementation for
Ubuntu 22.04, does is [to immediately `sudo bash` to become root
immediately][2], and the Debian 11 one [also does the morally correct
thing and logs in as root][3].

Fixes #1036

[1]: https://loginasroot.net/linux_root_login_faq [2]:
https://github.com/oxidecomputer/propolis/blob/21b3da87b70b4342eb22d861eedb083c32cf08b7/phd-tests/framework/src/guest_os/ubuntu22_04.rs#L20-L21
[3]:
https://github.com/oxidecomputer/propolis/blob/21b3da87b70b4342eb22d861eedb083c32cf08b7/phd-tests/framework/src/guest_os/debian11_nocloud.rs#L13-L17
@hawkw hawkw requested a review from iximeow February 5, 2026 23:35
async fn lspci_lifecycle_test(ctx: &Framework) {
const LSPCI: &str = "sudo lspci -vvx";
const LSHW: &str = "sudo lshw -notime";
const LSPCI: &str = "lspci -vvx";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so the real trick here is that i don't think there is an lspci (or lshw) in the Alpine image, at least the oldish 3.20 image i've got just says -ash: lshw: not found and the same for lspci. since the output can vary by distro's choice and version of the tools, i think we don't want to just compare to a golden output

i'm pretty sure this is actually why i'd wanted to get #797 in, because the sign that this output is uninformative is, i think, getting a non-zero status.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah. we should really try and pick #797 back up, this is a very unfortunate situation.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

want PHD lshw_lifecycle_test to, uh, actually involve lshw(1) in some way

2 participants