apt-get install breaks the test runner #5
Labels
bug
Something isn't working
Comments
|
@Mic92 suggests to get rid of the current backdoor service in favor of something like https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/vm_tools/vsh/README.md Would make sense to upstream this to the NixOS test runner if we go that route. |
am-on
added a commit
to am-on/nixpkgs
that referenced
this issue
Feb 15, 2025
When running the test-driver on other distros (e.g., via [https://github.com/numtide/nix-vm-test/](nix-vm-test)) executing a command can fail if the driver receives both stdout and stderr. The test-driver’s logic for reading output currently assumes it will only read base64 encoded stdout, so any extra stderr content leads to unexpected failures. This commit fixes the issue by redirecting the stderr to /dev/null, ensuring the driver only sees stdout. The tradeoff is losing stderr messages in the machine logs. Users can work around this by redirecting stderr to stdout in the command they are sending to the machine: ```python machine.execute("some_command 2>&1") ``` Related issues: - numtide/nix-vm-test#84 - numtide/nix-vm-test#5
13 tasks
am-on
added a commit
to am-on/nixpkgs
that referenced
this issue
Feb 15, 2025
When running the test-driver on other distros (e.g., via [https://github.com/numtide/nix-vm-test/](nix-vm-test)) executing a command can fail if the driver receives both stdout and stderr. The test-driver’s logic for reading output currently assumes it will only read base64 encoded stdout, so any extra stderr content leads to unexpected failures. This commit fixes the issue by redirecting the stderr to /dev/null, ensuring the driver only sees stdout. The tradeoff is losing stderr messages in the machine logs. Users can work around this by redirecting stderr to stdout in the command they are sending to the machine: ```python machine.execute("some_command 2>&1") ``` Related issues: - numtide/nix-vm-test#84 - numtide/nix-vm-test#5
am-on
added a commit
to am-on/nixpkgs
that referenced
this issue
Feb 15, 2025
When running the test-driver on other distros (e.g., via [https://github.com/numtide/nix-vm-test/](nix-vm-test)) executing a command can fail if the driver receives both stdout and stderr. The test-driver’s logic for reading output currently assumes it will only read base64 encoded stdout, so any extra stderr content leads to unexpected failures. This commit fixes the issue by redirecting the stderr to /dev/null, ensuring the driver only sees stdout. The tradeoff is losing stderr messages in the machine logs. Users can work around this by redirecting stderr to stdout in the command they are sending to the machine: ```python machine.execute("some_command 2>&1") ``` Related issues: - numtide/nix-vm-test#84 - numtide/nix-vm-test#5
am-on
added a commit
to am-on/nixpkgs
that referenced
this issue
Feb 15, 2025
When running the test-driver on other distros (e.g., via [https://github.com/numtide/nix-vm-test/](nix-vm-test)) executing a command can fail if the driver receives both stdout and stderr. The test-driver’s logic for reading output currently assumes it will only read base64 encoded stdout, so any extra stderr content leads to unexpected failures. This commit fixes the issue by redirecting the stderr to /dev/null, ensuring the driver only sees stdout. The tradeoff is losing stderr messages in the machine logs. Users can work around this by redirecting stderr to stdout in the command they are sending to the machine: ```python machine.execute("some_command 2>&1") ``` Related issues: - numtide/nix-vm-test#84 - numtide/nix-vm-test#5
am-on
added a commit
to am-on/nixpkgs
that referenced
this issue
Feb 15, 2025
When running the test-driver on other distros (e.g., via [https://github.com/numtide/nix-vm-test/](nix-vm-test)) executing a command can fail if the driver receives both stdout and stderr. The test-driver’s logic for reading output currently assumes it will only read base64 encoded stdout, so any extra stderr content leads to unexpected failures. This commit fixes the issue by redirecting the stderr to /dev/null, ensuring the driver only sees stdout. The tradeoff is losing stderr messages in the machine logs. Users can work around this by redirecting stderr to stdout in the command they are sending to the machine: ```python machine.execute("some_command 2>&1") ``` Related issues: - numtide/nix-vm-test#84 - numtide/nix-vm-test#5
am-on
added a commit
to am-on/nixpkgs
that referenced
this issue
Feb 15, 2025
When running the test-driver on other distros (e.g., via [https://github.com/numtide/nix-vm-test/](nix-vm-test)) executing a command can fail if the driver receives both stdout and stderr. The test-driver’s logic for reading output currently assumes it will only read base64 encoded stdout, so any extra stderr content leads to unexpected failures. This commit fixes the issue by redirecting the stderr to /dev/null, ensuring the driver only sees stdout. The tradeoff is losing stderr messages in the machine logs. Users can work around this by redirecting stderr to stdout in the command they are sending to the machine: ```python machine.execute("some_command 2>&1") ``` Related issues: - numtide/nix-vm-test#84 - numtide/nix-vm-test#5
am-on
added a commit
to am-on/nix-vm-test
that referenced
this issue
Feb 18, 2025
When running tests on Ubuntu VMs, the `test-driver` can crash if the
executed command calls `sudo` and writes to stderr. For example:
```python
vm.execute("sudo bash -c \"echo 'Created foo → bar.\n' >&2 && echo 'foo' \"")
```
`sudo` spawns a new TTY on Ubuntu, merging both `stdout` and `stderr` into a
single stream. However, the `test-driver` only expects base64-encoded `stdout`
and fails when stderr data appears.
- Normal command (note `1` and `2` are different consoles)
```
> bash -c 'echo $$; ls -l /proc/$$/fd'
lr-x------ 1 root root 64 Feb 18 06:10 0 -> /dev/hvc0
l-wx------ 1 root root 64 Feb 18 06:10 1 -> pipe:[20942]
l-wx------ 1 root root 64 Feb 18 06:10 2 -> /dev/ttyS0
lr-x------ 1 root root 64 Feb 18 06:10 3 -> /proc/664/fd
```
- Using `sudo` (note both `1` and `2` use the same console `/dev/pts/0`)
```
> sudo bash -c 'echo $$; ls -l /proc/$$/fd
lrwx------ 1 root root 64 Feb 18 06:10 0 -> /dev/pts/0
l-wx------ 1 root root 64 Feb 18 06:10 1 -> pipe:[20943]
lrwx------ 1 root root 64 Feb 18 06:10 2 -> /dev/pts/0
lr-x------ 1 root root 64 Feb 18 06:10 3 -> /proc/670/fd
```
Because `stderr` is now mixed with `stdout` on `/dev/pts/0`, the
`test-driver`'s base64 decoding code crashes on unexpected data:
([encoding step](https://github.com/NixOS/nixpkgs/blob/8a24fbd0f3b4f47f01c897a95b1b65d6a5576c01/nixos/lib/test-driver/src/test_driver/machine.py#L578),
[decoding step](https://github.com/NixOS/nixpkgs/blob/8a24fbd0f3b4f47f01c897a95b1b65d6a5576c01/nixos/lib/test-driver/src/test_driver/machine.py#L588)).
A minimal reproducible example is provided in
[am-on/nix-test-driver-ubuntu-bug](https://github.com/am-on/nix-test-driver-ubuntu-bug).
Related issues:
- numtide#84
- numtide#5
am-on
added a commit
to am-on/nix-vm-test
that referenced
this issue
Feb 18, 2025
When running tests on Ubuntu VMs, the `test-driver` can crash if the
executed command calls `sudo` and writes to `stderr`. For example:
```python
vm.execute("sudo bash -c \"echo 'Created foo → bar.\n' >&2 && echo 'foo' \"")
```
`sudo` spawns a new TTY for `stderr` on Ubuntu that gets read by the
`test-driver`'s output parsing. However, the `test-driver` only expects
base64-encoded `stdout` and fails when `stderr` data is read.
- Normal command (note `stderr` usees `/dev/ttyS0`)
```
> bash -c 'echo $$; ls -l /proc/$$/fd'
lr-x------ 1 root root 64 Feb 18 06:10 0 -> /dev/hvc0
l-wx------ 1 root root 64 Feb 18 06:10 1 -> pipe:[20942]
l-wx------ 1 root root 64 Feb 18 06:10 2 -> /dev/ttyS0
lr-x------ 1 root root 64 Feb 18 06:10 3 -> /proc/664/fd
```
- Using `sudo` (note `stderr` uses `/dev/pts/0`)
```
> sudo bash -c 'echo $$; ls -l /proc/$$/fd
lrwx------ 1 root root 64 Feb 18 06:10 0 -> /dev/pts/0
l-wx------ 1 root root 64 Feb 18 06:10 1 -> pipe:[20943]
lrwx------ 1 root root 64 Feb 18 06:10 2 -> /dev/pts/0
lr-x------ 1 root root 64 Feb 18 06:10 3 -> /proc/670/fd
```
Because `stderr` is now read along with the `stdout`, the
`test-driver`'s base64 decoding code crashes on unexpected data:
- [encoding step](https://github.com/NixOS/nixpkgs/blob/8a24fbd0f3b4f47f01c897a95b1b65d6a5576c01/nixos/lib/test-driver/src/test_driver/machine.py#L578),
- [receiving the data](https://github.com/NixOS/nixpkgs/blob/8a24fbd0f3b4f47f01c897a95b1b65d6a5576c01/nixos/lib/test-driver/src/test_driver/machine.py#L515),
- [decoding step](https://github.com/NixOS/nixpkgs/blob/8a24fbd0f3b4f47f01c897a95b1b65d6a5576c01/nixos/lib/test-driver/src/test_driver/machine.py#L588).
A minimal reproducible example is provided in
[am-on/nix-test-driver-ubuntu-bug](https://github.com/am-on/nix-test-driver-ubuntu-bug).
Related issues:
- numtide#84
- numtide#5
picnoir
pushed a commit
that referenced
this issue
Feb 19, 2025
When running tests on Ubuntu VMs, the `test-driver` can crash if the
executed command calls `sudo` and writes to `stderr`. For example:
```python
vm.execute("sudo bash -c \"echo 'Created foo → bar.\n' >&2 && echo 'foo' \"")
```
`sudo` spawns a new TTY for `stderr` on Ubuntu that gets read by the
`test-driver`'s output parsing. However, the `test-driver` only expects
base64-encoded `stdout` and fails when `stderr` data is read.
- Normal command (note `stderr` usees `/dev/ttyS0`)
```
> bash -c 'echo $$; ls -l /proc/$$/fd'
lr-x------ 1 root root 64 Feb 18 06:10 0 -> /dev/hvc0
l-wx------ 1 root root 64 Feb 18 06:10 1 -> pipe:[20942]
l-wx------ 1 root root 64 Feb 18 06:10 2 -> /dev/ttyS0
lr-x------ 1 root root 64 Feb 18 06:10 3 -> /proc/664/fd
```
- Using `sudo` (note `stderr` uses `/dev/pts/0`)
```
> sudo bash -c 'echo $$; ls -l /proc/$$/fd
lrwx------ 1 root root 64 Feb 18 06:10 0 -> /dev/pts/0
l-wx------ 1 root root 64 Feb 18 06:10 1 -> pipe:[20943]
lrwx------ 1 root root 64 Feb 18 06:10 2 -> /dev/pts/0
lr-x------ 1 root root 64 Feb 18 06:10 3 -> /proc/670/fd
```
Because `stderr` is now read along with the `stdout`, the
`test-driver`'s base64 decoding code crashes on unexpected data:
- [encoding step](https://github.com/NixOS/nixpkgs/blob/8a24fbd0f3b4f47f01c897a95b1b65d6a5576c01/nixos/lib/test-driver/src/test_driver/machine.py#L578),
- [receiving the data](https://github.com/NixOS/nixpkgs/blob/8a24fbd0f3b4f47f01c897a95b1b65d6a5576c01/nixos/lib/test-driver/src/test_driver/machine.py#L515),
- [decoding step](https://github.com/NixOS/nixpkgs/blob/8a24fbd0f3b4f47f01c897a95b1b65d6a5576c01/nixos/lib/test-driver/src/test_driver/machine.py#L588).
A minimal reproducible example is provided in
[am-on/nix-test-driver-ubuntu-bug](https://github.com/am-on/nix-test-driver-ubuntu-bug).
Related issues:
- #84
- #5
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
The apt-get install output sometimes breaks the NixOS test runner. I think it's related to the apt menu. The current (terrible) workaround consists in redirecting the apt-get output to a file.
I don't have a minimal reproducer yet.
The text was updated successfully, but these errors were encountered: